The Best Rated EmaiI Signature Portal

IT Pro: How to configure server-side using PowerShell

When you configure Xink rerouting using PowerShell you don’t type credentials in the web console. FYI - We don’t have access nor do we store any credentials typed in the console.

Below PowerShell, method is for IT professionals.

Prefer the web console, which is less technical?

Back to the web console and get familiar with the basics.
Configure Server-side using MFA-enabled Microsoft 365 admin accounts.

How to configure rerouting using PowerShell

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 Microsoft 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 username and password into the pop-up window (username used from the Xink admin login).

Type $o365Cred = Get-Credential and type your Microsoft 365 global admin username and password into the window.

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

The script uses Microsoft 365 credential only to create PowerShell remote session to Microsoft servers and Xink credential to obtain the 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 Microsoft 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 Microsoft 365. (Microsoft 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 Microsoft 365. It will be used to feed messages from Xink service back to Office 365 for further delivery. The default name of the connector is “Xink-Auto-ReRouting-In”.
  5. Create an Outbound Connector in Microsoft 365. It will be used to feed messages to Xink service. By default, it would be named “Xink-Auto-ReRouting-Out”.
  6. Create a Transport Rule in Microsoft 365. The rule will catch outgoing images and route these to the outbound connector created in the 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 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 Microsoft 365. We recommend to pause routing to Xink first and remove connectors and the rule in a few hours when all stale messages are processed and sent out successfully.

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

What’s next?

Add marker or continue without the marker. Review ReRouting best practices.



This command requests Microsoft 365 accepted domain list, compares it to Xink domain map and cache, then looks up for the inbound connector, outbound connector and the transport rule. Only objects created by rerouting configuration script or by the console itself would be recognized.

Here is a sample output:


This command requests Microsoft 365 accepted domain list, saves the list to Xink domain map and cache. Then it creates an inbound connector, outbound connector and the transport rule to catch outgoing messages.


This command removes previously created inbound/outbound connectors and transport rule from Microsoft 365.

Learn more

Server-side Best Practices.

download Xink PowerShell script

Did you find it helpful? Yes No

Send feedback
Sorry we couldn't be helpful. Help us improve this article with your feedback.