Why Adding an Email Signature Can Break DKIM and S/MIME (And How to Avoid It)

TL;DR: A message that’s already been cryptographically signed — by DKIM as it leaves Microsoft 365, or by S/MIME in the sender’s own Outlook client — can’t have content appended to it afterwards without invalidating that signature. Adding a signature or disclaimer after the fact isn’t a cosmetic risk; it’s a specific, well-documented failure mode, and Microsoft’s own guidance names it directly. This is a distinct problem from the social-engineering angle covered in Consistent Email Signatures as a Phishing and BEC Defence — this one is purely cryptographic integrity, and it has a clean test you can run yourself.

Two distinct failure modes, not one

DKIM and S/MIME are both digital-signature mechanisms, but they operate at completely different points in an email’s life, and each breaks for a slightly different reason when a signature or disclaimer is appended at the wrong moment. Worth separating them cleanly, because the fix for one doesn’t automatically fix the other.

DKIM: the body-hash problem

DKIM works by having the sending domain digitally sign specific parts of an outbound message — key headers and the message body — and attach that signature in a DKIM-Signature header. The receiving mail system recalculates the same hash over the message it actually received and checks it against the signed value. If anything in the signed portions changed in transit, the hashes no longer match, and DKIM fails.

Microsoft’s own Security Operations guide for email authentication documents this exact scenario as a named failure mode: dkim=fail with a body hash mismatch, which it describes as happening “when an intermediary (for example, a mailing list, forwarding service, or security appliance) alters the message body content after the DKIM signature was originally applied.” The guide’s recommended action is specific and directly relevant here: “Consider using Microsoft 365 to apply message modifications (footers, disclaimers, subject, etc.) instead of non-Microsoft services.”

That’s Microsoft naming, in its own words, the exact architecture question this site keeps returning to. A signature or disclaimer applied by a third-party service that the message is routed out to — the model most server-side email signature tools use — modifies the body after Microsoft has already applied its DKIM signature for that leg of the journey, which is precisely the pattern the sec-ops guide flags. The mechanics of that round trip are mundane rather than exotic: a transport rule redirects the message to the vendor’s cloud via an outbound connector, the signature is applied, and the message is routed back into Microsoft 365 for final delivery — a well-established pattern that shows up in Microsoft’s own troubleshooting documentation for exactly this kind of third-party mail flow integration.

It’s worth being precise about one detail that sounds like it should help but doesn’t: DKIM’s default body canonicalization in Microsoft 365 is Relaxed, which “tolerates changes in whitespace and changes in empty lines at the end of the message body.” That’s a real tolerance — but it’s whitespace-only. Appending an entire signature block, with visible text and formatting, is not a whitespace change, and relaxed canonicalization does nothing to protect against it.

The honest caveat: exactly where inside Microsoft 365’s own mail flow pipeline a native transport rule’s disclaimer action runs relative to DKIM signing isn’t something Microsoft documents at the level of internal ordering, and it isn’t something an admin can directly inspect. What Microsoft does document clearly is the recommendation to prefer Microsoft 365’s own modification mechanism over routing mail out to a non-Microsoft service — which is exactly why the practical test below matters more than reasoning about pipeline internals.

S/MIME: insertion has to happen before signing, not after

S/MIME digital signatures work differently, but land in the same place. A message signed with S/MIME is signed by the sender’s own Outlook client, using the sender’s private certificate, before the message is even sent — the signature covers the message exactly as it existed at that moment. Any alteration to the content afterwards, by any mechanism, invalidates the signature. There’s no server-side or add-in method that can append content to an already-S/MIME-signed message without breaking it; the only way to avoid the problem is to insert the signature before the user’s client applies the S/MIME signature, not after.

Exchange Online’s own mail flow rules engine actually enforces a version of this distinction directly, and it’s worth knowing the specifics rather than assuming a generic answer. Per Microsoft’s mail flow rules documentation:

S/MIME encrypted messages: mail flow rules “can only access envelope headers… rules with conditions that require inspection of the message’s content, or actions that modify the message’s content can’t be processed.” A transport rule configured to add a disclaimer simply can’t touch the content of an S/MIME-encrypted message at all — the action is blocked outright, not silently applied and then broken. Worth knowing, because the practical symptom is different: the disclaimer just won’t appear on those messages, rather than an error being visible to the sender.
Clear-signed messages (signed but not encrypted): mail flow rules can modify the content — Exchange doesn’t block the action here. But doing so still invalidates the S/MIME signature for the recipient, because the content the rule modifies is exactly the content the signature was computed over. This is the more dangerous case precisely because it doesn’t fail loudly: the disclaimer gets added, the email sends normally, and the recipient’s client is the one that silently reports (or worse, doesn’t clearly report) a broken signature.

The practical test

Given the internal ordering isn’t fully inspectable and the failure modes differ by scenario, the reliable way to know whether a deployed tool is safe is to test it directly, not assume:

Send a message from a DKIM-enabled domain through whatever tool applies your signature, to an external mailbox (a personal Gmail or Outlook.com account works). Check the destination mailbox’s message headers for dkim=pass versus dkim=fail with a body hash note — Microsoft’s DKIM verification guidance covers how to read these headers, including via the free Message Header Analyzer tool it links to.
If your organisation uses S/MIME, send both a clear-signed and an S/MIME-encrypted test message through the same tool, and confirm on the receiving end whether the signature still validates and whether the signature/disclaimer content actually appears at all.

Run this test against any new signature tool before a full rollout, and re-run it after any change to how the tool is deployed — a working configuration can silently start failing if a routing change is made later. It’s a natural addition to the broader evaluation framework covered in How to Manage Email Signatures Across a Company — most rollout checklists don’t include a cryptographic-integrity test, and this is exactly the kind of failure that only surfaces once a DKIM-aligned or S/MIME-using recipient reports a problem.

How this maps onto architecture

This is where the server-side-vs-add-in distinction, covered in full in Email Signature Management for Microsoft 365: Server-Side vs Add-In, becomes directly relevant rather than academic. A signature inserted at compose time, inside Outlook, before the message is sent, is inserted before any signing step — DKIM or S/MIME — has happened. There’s no post-signing modification to worry about, because nothing gets modified after signing; the content is simply part of what gets signed in the first place. A server-side tool that routes mail out to apply a signature, by contrast, is structurally the exact pattern Microsoft’s own guidance warns against for DKIM, and can’t insert content into an S/MIME-signed message without invalidating it regardless of timing. This is a genuinely different consideration from the GDPR/data-routing question covered elsewhere on this site — it’s a cryptographic integrity problem, not a data-processing one — but it points to the same architectural answer.

Frequently asked questions

Does adding an email signature always break DKIM?

No — it depends entirely on when the signature is added relative to DKIM signing. A signature inserted before the message is signed (as with compose-time, client-side insertion) doesn’t affect DKIM at all, because it’s part of what gets signed. A signature or disclaimer appended by a service the message is routed out to after DKIM has already applied is the documented risk — Microsoft’s own security operations guidance specifically recommends using Microsoft 365’s own modification mechanism over non-Microsoft services for this reason.

Can a transport rule add a disclaimer to an S/MIME-signed email safely?

Not without breaking the signature. Exchange Online’s mail flow rules can technically modify the content of a clear-signed (signed but not encrypted) S/MIME message, but doing so invalidates the signature for the recipient, because the content no longer matches what was originally signed. For S/MIME-encrypted messages, mail flow rules can’t modify the content at all — the action is blocked outright, so the disclaimer or signature simply won’t appear.

How can I test whether our email signature tool is breaking DKIM or S/MIME?

Send a test message through the deployed tool to an external mailbox and inspect the message headers for dkim=pass versus dkim=fail with a body hash mismatch note. If your organisation uses S/MIME, separately test a clear-signed and an S/MIME-encrypted message and confirm both that the signature validates and that the signature content actually appears. Re-test after any change to how the tool is deployed, since a working setup can silently regress.

Does relaxed DKIM canonicalization protect against a signature being added afterwards?

No. Microsoft 365’s default relaxed body canonicalization tolerates whitespace and trailing empty-line changes only — it does not tolerate real content being appended, such as a signature block. Adding visible signature content after DKIM signing breaks the signature regardless of canonicalization mode.

Is this the same risk as email signature phishing/spoofing?

No — it’s a related but distinct problem, covered separately in Consistent Email Signatures as a Phishing and BEC Defence. That article covers signature consistency as a visual, human-layer cue against social-engineering attacks. This article covers a purely cryptographic integrity question: whether a legitimate, correctly-signed message’s signature survives having a signature or disclaimer added to it.

SigHQ is building an add-in-first email signature management tool for Microsoft 365 organisations of 50–250 employees — signatures applied in Outlook at compose time, before any DKIM or S/MIME signing has taken place, without email routing through third-party infrastructure. Join the waitlist to follow progress.