When to use Office 365 rerouting to get email signatures?

Email rerouting can be used in addition to our other services or rerouting can be used as the primary email signature service for Office 365. If you don't have a Xink account yet, please sign up for one here.

Once an email is sent, the rerouting service will replace the signature with the signature you’ve allotted before it arrives in the recipient inbox. 

Here is more information about how it works:

The emails are caught by Xink server in WIndows Azure (same data centers as Office 365) just before they are delivered by Office 365. Once the signature replacement has taken place, the email is delivered back to Office 365, which will then be responsible for sending the mail.

Xink will never deliver any emails, only he signature replacement will take place, and hence the customer's Office 365 account will be responsible for the actual delivery.

In cases where it is not possible to see the email signature while composing your email (for the reasons explained above), you can reroute your emails through our regional servers. 

In doing so, you can ensure that your full branding initiatives are in place and visible, no matter which app you use or where you sent the email from. Xink email rerouting will work pretty much just out-of-the-box.

In this way, Xink enables you to:


  1. Let the user see the email signature while composing the email (when this is possible)
  2. Add the email signature while rerouting the email through Xink’s servers (in cases where the email signature is not visible). 

How to configure rerouting for Office 365 using PowerShell

This article describes how to use Xink rerouting for Office 365.

First download Xink PowerShell script and save it to the Downloads folder of the logged-on user.

The script uses two credentials – one is for Office 365 and the other is for Xink cloud itself. We will save both into PowerShell variables and use both in all subsequent commands.

Type $xinkCred = Get-Credential, then type your Xink user name and password into pop-up window (user name used from the Xink admin logon).

Type $o365Cred = Get-Credential and type your Office 365 admin user name and password into the window.

Creating two variables manually instead of direct input to console prompt string makes it completely secure, Get-Credential cmdlet uses Secure String system type to store the passwords in memory. And it allows to run multiple commands without typing both credentials each time.

The script uses Office 365 credential only to create PowerShell remote session to Microsoft servers and Xink credential only to obtain access token. The script is distributed in sources of course, it is possible to open it in a text editor and check what it does exactly.

Both variables are saved, now configure Xink and Office 365. Just one command with credentials mentioned above as arguments. 

Change directory to the folder where Xink script is saved, in our case it would be “Downloads”, then type .\xink-rerouting.ps1 $o365Cred $xinkCred -Create.

The script makes several API calls:

  1. Create remote PowerShell session to Office 365.(Office 365 Credential is used)
  2. Obtain Xink API access token. (Xink credential is used)
  3. Call Get-AcceptedDomain in Office 365 environment, then push the list to Xink.
  4. Create Inbound Connector in Office 365. It will be used to feed messages from Xink service back to Office 365 for further delivery. Default name of the connector is “Xink-Auto-ReRouting-In”.
  5. Create Outbound Connector in Office 365. It will be used to feed messages to Xink service. By default, it would be named “Xink-Auto-ReRouting-Out”.
  6. Create Transport Rule in Office 365. The rule will catch outgoing images and route these to the outbound connector created in previous step. Default rule name is “Xink-Auto-ReRouting-Catcher”.

This is enough to use Xink rerouting service in most cases.

The script creates a typical rule which would catch all messages originating from inside an organization. Any further manual customizations are possible, say, adding a group of people who actually use Xink and routing only emails sent by members of this group. There is only one requirement: the rule must check X-Xink-Handled header, and if it is set to “Yes” do not route the message back to Xink.

Mail routing can be paused by disabling transport rule temporary, in Exchange admin center, mailflow section, “rules” tab.

The script also has -Remove switch, it removes both connectors and the rule from Office 365. We recommend to pause routing to Xink first, and remove connectors and the rule in few hours, when all stale messages are processed and sent out successfully.

Running the script without -Create or -Remove switches shows current status of Rerouting.

Security considerations

All Xink mailservers are located in Azure datacenters, each one in the same datacenter as Xink application server, e.g. United States, European Union, etc. All communications between Office 365 server and Xink servers are encrypted (TLS/SSL).

Xink mailservers do not deliver emails to the final recipients. After processing the messages, they are returned back to Office 365 for further delivery in a regular way. 

How it works

Email Signatures for Office 365 by Xink is designed to catch outgoing emails in the mail flow and replace specific text occurrences with the actual user’s email signature from Xink. 

We currently only use one string as a signature placeholder - Insert this text:


TIP when using iOS: 

  • Insert the text in BOLD and the iOS device will send emails in HTML and not in Plain Text which is the default email format. 

We appreciate your feed-back

Please submit support ticket and select 'Re-routing':