Setting Up Exclaimer on Microsoft 365: Step-by-Step

TL;DR

Setting up Exclaimer on Microsoft 365 is a four-piece job: an outbound connector to smarthost.exclaimer.net, a transport rule that routes the right mail to that connector, activation in the Exclaimer Cloud portal, and a signature template that survives Outlook’s HTML quirks. None of it is hard. All of it has a quiet failure mode if you skip the verification step, which is where most “it doesn’t work” tickets actually live.

What you need before you start

Three things, in this order.

A live Exclaimer Cloud Signatures licence on the right region (EU, US, AU). The licence sets the smart-host hostname and the regional portal. Wrong region, wrong endpoint, TLS handshake fails.

Global Administrator access to the Microsoft 365 tenant. Exchange Administrator alone is not enough. Exclaimer’s setup wizard registers an enterprise application via the Microsoft Graph consent flow, which only Global Admin can grant.

A list of allowed sending domains. Every domain you intend to sign from has to be added to your Exclaimer tenant and be a verified domain in M365. If you have three brands and four aliases, write them all down before you start. Half the support tickets we field begin with “the new sales domain isn’t getting a signature” and end with “ah, it was never added to the Exclaimer allowed-domain list.”

While you’re prepping, run TamingDNS M365 Check on your primary domain. You want a clean baseline of SPF, DKIM and DMARC before you change anything. If the report flags an SPF lookup count of 8 or higher, fix that first. Adding Exclaimer’s smart-host can push you past the 10-lookup ceiling, and then nothing works.

Step 1: Create the connector in Exchange Online

Sign in to the Exchange admin center at admin.exchange.microsoft.com. Open Mail flow → Connectors → Add a connector.

The wizard asks where mail comes from and where it’s going. Pick:

• From: Office 365
• To: Partner organization

Click Next. Name the connector something readable. We use Outbound to Exclaimer Cloud so anyone reading it in three years knows what it does. Add a one-line description with the date and change-ticket number. Future you will thank present you.

Tick Turn it on if it isn’t already, leave Retain internal Exchange email headers ticked, and click Next.

For When do you want to use this connector, pick Only when I have a transport rule set up that redirects messages to this connector. This is important. The other option (use it for all mail to specific domains) overrides your transport rule logic and routes everything, including mail to non-signed domains, through Exclaimer. You don’t want that.

For How do you want to route email messages, choose Route email through these smart hosts and add smarthost.exclaimer.net. The hostname is the same for every Exclaimer Cloud customer; the region routing happens behind that hostname based on your tenant ID once the transport rule fires.

For How should Office 365 connect to your partner organization’s email server, tick Always use Transport Layer Security (TLS) to secure the connection and Issued by a trusted certificate authority (CA). Do not pick “subject name on certificate matches”. Exclaimer rotates wildcard certs and a name-pinned connector falls over the day they renew.

Validate. The wizard sends a probe email through the connector and confirms a TLS handshake. If validation fails, go back and check the smart-host spelling, then check that your tenant’s outbound IPs are not blocked at your end (rare, but it happens with overzealous firewalls).

Save. The connector is live but inert until a transport rule routes traffic to it.

Step 2: Add the transport rule

Still in the EAC, open Mail flow → Rules → Add a rule → Create a new rule.

Name it Route to Exclaimer Cloud. Match the connector name pattern so anyone auditing the tenant can see they belong together.

Set the conditions:

• Apply this rule if → The sender → Domain is → add every sending domain you want signed (yourcompany.co.za, yourcompany.com, every brand alias).
• And → The recipient → Is external/internal → Outside the organization.

Skip the action that adds a disclaimer. Exclaimer adds the signature, not the M365 transport rule. Set instead:

• Do the following → Redirect the message to → The following connector → pick your new Outbound to Exclaimer Cloud.

Now the bit that gets missed. Add an exception under Except if → A message header → includes any of these words. Header name: X-ExclaimerHostedSignatures-MessageProcessed. Value: true. This stops mail that has already been signed and bounced back from being signed a second time. Without it you can get into a loop where Exclaimer sees its own outbound copy come back through the connector and stamps it twice. Rare but ugly.

Set rule mode to Enforce (not “Test with policy tips”). Set priority to 0 so it runs before any older transport rules that might otherwise grab the mail. Save.

This is the Inspect message attributes family of rules, in the Microsoft documentation’s terminology; same idea, different framing. The message goes through, the rule reads sender, recipient, headers; if the conditions match, the connector fires.

Step 3: Verify the routing in Exclaimer

Log in to the Exclaimer Cloud portal at signatures.exclaimer.cloud. The portal walks through tenant linkage if you haven’t done it. You’ll be asked to consent to a Microsoft Graph application. This is the Global Admin moment from earlier. Grant the consent.

Once linked, Exclaimer shows a list of your verified M365 domains. Tick the ones you want signed. The first time, do the lot. You can always exclude domains later via the rule logic.

Now run the bounce test. Exclaimer asks you to send a test email from any mailbox in the tenant to verify@signatures.exclaimer.cloud (or whatever the current verification address is; the portal tells you). The reply comes back within 30 seconds with a green tick: “Mail received via the correct connector, TLS pass, headers intact.” That confirms the loop end-to-end before you put live signatures in front of anybody.

If the bounce test fails, the failure message tells you which step broke. The two common ones:

• No mail received within 60 seconds. The transport rule didn’t fire. Re-check the sender-domain condition. Did you add the domain to the rule, or only to the connector? They are separate.
• TLS handshake failure. The connector’s TLS settings are wrong. Re-check Always use TLS is on and Issued by a trusted CA is the validation method, not subject-name pinning.

Once the bounce test is green, click Activate in the portal. Until you do, Exclaimer is in monitoring mode and won’t actually stamp signatures.

Step 4: Build your first signature template

In the portal, open Designer → Signatures → Create new.

Start with the closest stock template to your brand and edit. The designer is a HTML-table editor with safety rails: it knows which fonts Outlook silently swaps, which CSS properties Outlook ignores, which images need to be hosted and which can be inline.

A few practical rules, learned from deployments.

Use system fonts as the primary stack: Segoe UI on Windows, San Francisco on Mac, with Arial as the fallback. Web fonts get stripped by half the Outlook clients and the result is Times New Roman, which looks like 1998.

Logo as a hosted PNG, not an inline base64 blob. Base64 inflates message size and some scanners flag it. Host the image on Exclaimer’s CDN (the upload widget puts it there) or on your own static asset host with a stable URL.

Dark mode safe colours. Test the signature on an iPhone in dark mode before you ship. A black logo on a transparent background vanishes. A logo with a thin white outline survives. The Exclaimer designer has a dark-mode preview, so use it.

One CTA, not five. The signature is not a landing page. One link that you want clicked, with a UTM parameter so you can prove it. We use ?utm_source=email-signature&utm_medium=email&utm_campaign=<role-or-campaign> and tag per role: sales, support, exec.

Map the template to the right user group. In M365 most setups want one template per department: Sales, Support, Engineering, Exec. Map by Azure AD group, not by mailbox; new starters get the right signature on day one without anyone updating a list.

Save. Don’t activate yet.

Step 5: Test on real mail

Add yourself and one or two patient colleagues to a pilot group. Activate the template for that group only.

Send tests to:

• A Gmail recipient. Reply. Forward. Look at the signature in the original, the reply and the forwarded message. Exclaimer’s reply-detection should keep the signature on the latest message only.
• A Yahoo recipient. Same drill. Yahoo renders HTML differently from Gmail.
• An Outlook.com recipient. The cousin that never gets tested.
• An iPhone Mail recipient. Dark mode, light mode, both.
• Yourself, internally. Internal mail does not always pass through Exclaimer depending on your transport rule scoping; check that your design doesn’t require the signature internally to make sense.

Look for: signature stacking on long threads (shouldn’t happen if reply-detection is on), broken images (cache or CDN issue), font swaps (web font being stripped), oversized banners (mobile clients squish them), and link tracking (every link should resolve and carry the right UTM).

Once the pilot group is happy, expand to the whole organisation. We do this in two waves: 50% of users on a Tuesday, the remaining 50% on Thursday, with Wednesday as the watch day. If the first wave stays quiet, the second wave is uneventful.

After tenant-wide activation, run TamingDNS M365 Check again and compare to your baseline. SPF should still pass. DKIM should still align. DMARC alignment rate should be 99%+. If it’s not, see the next section.

Also run TamingDNS SPF analyser specifically. The smart-host’s SPF includes are the most common cause of SPF lookup overflow once Exclaimer is live, and SPF overflow is silent until the wrong recipient bounces you.

What goes wrong, and how to fix it

Four classic failures.

TLS handshake failures. The connector validates fine on day one and starts failing on day forty-something. Cause: subject-name pinning got ticked at some point, and Exclaimer rotated their cert. Fix: edit the connector, switch to Issued by a trusted CA, save. Validate. The handshake comes back.

Transport rule order. Mail isn’t getting signed for some users but is for others. Cause: a higher-priority transport rule (often a legacy compliance rule from the previous admin) is matching the message and stopping further rule processing. Fix: in EAC → Rules, look at the priority column. Move the Exclaimer rule above the offender, or set the offender’s “Stop processing more rules” flag to false. Both work; the first is cleaner.

Multi-domain sender mismatch. Sales sends as name@brand-a.co.za from a mailbox at name@parentco.co.za. The transport rule matches the sender’s mailbox domain (parentco), Exclaimer signs with the parent template, the recipient sees a brand mismatch. Fix: change the transport rule condition from “sender domain is” to “sender address is in” and add the alias domains. In the Exclaimer designer, build a template per brand and map by From address, not mailbox. The multi-domain pattern is the most common reason setups need a second pass.

Replies dropping the signature unexpectedly. A subset of replies arrive without the signature. The cause is almost always that the user has hit reply from a cached OWA tab where the connection to Exclaimer is in a degraded state, or, more often, that the message was sent through Send-As from a shared mailbox that wasn’t added to the allowed-domain list. Fix: add the shared mailbox’s primary SMTP domain to the rule and to the Exclaimer tenant, then send a fresh test. If it persists, open a ticket with Exclaimer support; they have headers-level diagnostics in the portal that tell you exactly which connector hop the message took.

One quieter failure mode: DMARC alignment. If your DMARC is at p=reject and DKIM signing isn’t properly handed off to Exclaimer, a percentage of signed mail will fail DMARC at the recipient. The fix is on the DMARC side: publish Exclaimer’s DKIM selector at your DNS, validate it, and check alignment. The full pattern is in the DMARC guide.

Where this fits in the OSH stack

This sits inside the Exclaimer and Microsoft 365 pages. DNS authentication lives in DMARC. If you’d rather we did the deployment, the Professional Services hub is where the engagement starts.

Want this done for you?

OSH runs Exclaimer deployments on M365 tenants from 10 mailboxes to 500+. Five to ten working days from signed quote to tenant-wide rollout. We handle the connector, the rule, the DKIM hand-off, the template design, and the DNS verification. We don’t go live until the bounce test and the post-deployment TamingDNS check both come back clean.

Book a 30-minute fit assessment via the Exclaimer page. Or email support@osh.co.za with the subject Exclaimer M365 setup and we’ll come back with a quote and a timeline within a working day.