Xink rerouter accepts messages from Office 365, adds a signature and returns messages back to Office 365 tenant.
It sounds quite simple, though let’s take a deeper look at the process and implications.
No matter if you use WebConsole or PowerShell to configure Server Side (ReRouting), the following objects are created in Office 365:
- The outbound connector used to deliver messages from Office 365 to Xink.
- Transport rule used to catch messages that supposed to go to Xink.
- The inbound connector used to receive messages back from Xink.
Those objects are fine for a brand-new Office 365 tenant and would work perfectly out of the box.
And if a tenant has a complex configuration, mail administrator might want to tune Xink connection and Office 365 mail flow.
Let’s find out why.
By default, Xink Transport rule is configured to catch all messages originating from the organization.
That is a wide match criterion – all outgoing email will be routed to Xink first, then re-submitted back via the Inbound connector.
Roundtrip to Xink is not absolutely transparent for a message. Despite obvious changes – signature injection or marker replacement – there are other changes.
The message that comes in via Inbound connector is no longer a message from an authenticated user of Office 365 tenant. It is a message coming from “on-premises” server and relayed by Office 365. It means, for example, all closed groups that are configured to allow authenticated senders only are no longer accessible and message might not be delivered.
Examples are distribution groups, recourse mailboxes, meeting rooms, or generic mailbox. Learn how to exclude mailbox resources from rerouting.
And, of course, if a signature was applied – the message is changed and DKIM signature is broken (Xink removes it to avoid confusion).
Furthermore, extra “Received” headers are added to the message and will be visible for Microsoft Spam filter.
So, it is a good idea to do some fine tuning.
First – the rule, Transport rule named “Xink-Auto-ReRouting-Catcher”. Office 365 allows building a rule with complex conditions. And it is a good idea to alter the rule in a way to match only those senders who actually need rerouting. Or at least exclude those who don’t need it. Mail administrators are absolutely welcome to change match criterions, just remember to never remove “X-Xink-Handled: Yes” header exception, it is required to avoid mail loops.
Second – Spam filter. Microsoft recommends adding all 3rd party service providers that work with Office 365 to domain’s SPF records. See how to do it.
This can help to avoid Spam filter false positives.
Also, you might want to enable DKIM support for some of your domains, see how to do it.