Xink rerouter accepts messages from Microsoft 365, adds a signature, and returns messages back to Microsoft 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 Microsoft 365:
- The outbound connector used to deliver messages from Microsoft 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 Microsoft 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 Microsoft 365 mail flow.
Let’s find out why.
Mail flow
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 Microsoft 365 tenant. It is a message coming from “on-premises” server and relayed by Microsoft 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, resource 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.
Fine-tuning
So, it is a good idea to do some fine-tuning.
First – the rule, Transport rule named “Xink-Auto-ReRouting-Catcher”. Microsoft 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 Microsoft 365 to domain’s SPF records. See how to do it.
This can help to avoid Spam filter false positives.
Third - Add Xink server IP to whitelist and/or allow list. Click here for the steps.
Also, you might want to enable DKIM support for some of your domains. Click here to see how to do it.
