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 ReRouting, the following objects are created in Office 365:


  • Outbound connector, used to deliver messages from Office 365 to Xink.
  • Transport rule, used to catch messages that supposed to go to Xink.
  • 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 complex configuration, mail administrator might want to tune Xink connection.

Let’s find out why.


Mail flow


By default, Xink Transport rule is configured to catch all messages originating from organization. 

That is a wide match criterion – all outgoing email will be routed to Xink first, then re-submitted back via Inbound connector.

Roundtrip to Xink is not absolutely transparent for a message. Despite obvious changes – signature injection or marker replacement – there are other changes.


Message that comes in via Inbound connector in is no longer a message from authenticated user of Office 365 tenant. It is a message coming from “on-premises” server and relayed by Office 365. It means, for example, that all closed groups configured to allow authenticated senders only are no longer accessible.


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”. Office 365 allows to build 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 to add 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.