Why Adding an Email Signature Can Break DKIM and S/MIME

TL;DR: DKIM and S/MIME are two ways of digitally signing an email so the recipient can tell it has not been changed. DKIM signing happens as the message leaves Microsoft 365. S/MIME signing happens in the sender’s own Outlook. If you add anything to a message after it is signed, the signature no longer matches and fails. Adding a signature or disclaimer after the fact is a documented failure, and Microsoft’s own guidance names it. This is a different problem from the social-engineering risk in Consistent Email Signatures as a Phishing and BEC Defence. This one is only about whether the message has been altered, and you can test for it yourself.

Two separate failures

DKIM and S/MIME both sign a message digitally, but they sign it at different points in its life. Each breaks for a slightly different reason when a signature or disclaimer is added at the wrong moment. Keep them apart, because fixing one does not fix the other.

Two rows showing the order of signing and inserting: inserting after signing fails verification, inserting before signing passes. — Same two steps, opposite order. A relay that adds the signature after DKIM or S/MIME signing changes what was signed; adding it at compose time makes it part of what gets signed.

DKIM: the body hash problem

DKIM works like this. The sending domain signs certain parts of an outgoing message, mainly key headers and the body, and puts the signature in a DKIM-Signature header. The receiving mail system works out the same hash (a short fingerprint of the content) from the message it received. It compares that with the signed value. If anything in the signed parts changed on the way, the two no longer match and DKIM fails.

Microsoft’s Security Operations guide for email authentication lists this exact case as a named failure. It is dkim=fail with a body hash mismatch, which it says happens “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.” Its advice to senders applies directly here:

“Consider using Microsoft 365 to apply message modifications (footers, disclaimers, subject, etc.) instead of non-Microsoft services.”

Microsoft, Security Operations guide for email authentication, “DKIM failed after modification (Body hash failed)”

That is Microsoft answering, in its own words, the architecture question this site keeps returning to. Most server-side email signature tools send the message out to a third-party service to add the signature. That changes the body after Microsoft has already applied its DKIM signature for that leg of the journey. This is the pattern the guide warns about. The round trip itself is ordinary. A transport rule redirects the message to the vendor’s cloud through an outbound connector. The vendor adds the signature. The message returns to Microsoft 365 for final delivery. Microsoft’s own troubleshooting documentation describes this pattern for third-party mail flow.

One detail sounds helpful but is not. Microsoft 365 uses Relaxed body canonicalization for DKIM by default. This “tolerates changes in whitespace and changes in empty lines at the end of the message body.” That tolerance is real, but it covers whitespace only. A whole signature block, with visible text and formatting, is not a whitespace change. Relaxed canonicalization does not protect against it.

One caveat. Microsoft does not document exactly where a native transport rule’s disclaimer action runs in relation to DKIM signing inside Microsoft 365, and an admin cannot inspect it. What Microsoft does say clearly is to prefer its own modification mechanism over sending mail out to a non-Microsoft service. This is why the test below matters more than guessing at how the pipeline works inside.

S/MIME: add the signature before signing, not after

S/MIME signing works differently but ends in the same place. The sender’s own Outlook signs the message with the sender’s private certificate, before it is sent. The signature covers the message exactly as it was at that moment. Any change afterwards, by any method, makes the signature invalid. No server-side tool or add-in can add content to an already-signed S/MIME message without breaking it. The only way round this is to insert the signature before the user’s client applies the S/MIME signature.

Exchange Online’s mail flow rules already treat the two cases differently, and it helps to know how. Microsoft’s mail flow rules documentation says:

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 rule that adds a disclaimer cannot touch the content of an encrypted S/MIME message. The action is blocked, not applied and then broken. So the symptom is that the disclaimer does not appear on those messages, and the sender sees no error.
Clear-signed messages (signed but not encrypted): mail flow rules can change the content. Exchange does not block it. But doing so breaks the S/MIME signature for the recipient, because the rule changes the very content the signature was calculated over. This is the more dangerous case because it fails quietly. The disclaimer is added and the email sends normally. Then the recipient’s email app reports a broken signature, or does not report it clearly.

The practical test

You cannot inspect the internal order, and the failures differ by case. So the reliable way to know whether a tool is safe is to test it:

Send a message from a DKIM-enabled domain through the tool that applies your signature. Send it to an external mailbox, such as a personal Gmail or Outlook.com account. In the received message’s headers, look for dkim=pass or dkim=fail with a body hash note. Microsoft’s DKIM guidance explains how to read these headers, including with the free Message Header Analyzer tool it links to.
If your organisation uses S/MIME, send one clear-signed and one S/MIME-encrypted test message through the same tool. On the receiving end, check whether the signature still validates. Also check whether the signature or disclaimer content appears at all.

Run this test on any new signature tool before a full rollout. Run it again after any change to how the tool is deployed, because a working setup can start failing after a later routing change. Add it to your email signature software buying checklist. Most rollout checklists have no test for message integrity. This kind of failure often shows up only when a recipient who relies on DKIM or S/MIME reports a problem.

How this relates to architecture

Signature Management for Microsoft 365: Server-Side vs Add-In explains the two approaches in full. Here the difference matters in practice. A signature added at compose time, inside Outlook, goes in before any signing step, DKIM or S/MIME, has happened. Nothing is changed after signing. The signature is simply part of what gets signed.

A server-side tool that sends mail out to add a signature is the pattern Microsoft’s guidance warns against for DKIM. It also cannot add content to an S/MIME-signed message without breaking the signature, whatever the timing. This is a different question from the GDPR and data-routing question covered elsewhere on this site. It concerns whether the message is intact, not how data is processed. But it points to the same answer on architecture.

Frequently asked questions

Does adding an email signature always break DKIM?

No. It depends on when the signature is added compared with DKIM signing. A signature added before the message is signed, as with compose-time insertion in the email app, does not affect DKIM, because it is part of what gets signed. The documented risk is a signature or disclaimer added by a service the message is sent out to after DKIM has already been applied. Microsoft’s security operations guidance recommends using Microsoft 365’s own mechanism instead of 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 change the content of a clear-signed message (signed but not encrypted). But that makes the signature invalid for the recipient, because the content no longer matches what was signed. For S/MIME-encrypted messages, mail flow rules cannot change the content at all. The action is blocked, so the disclaimer or signature does not appear.

How can I test whether our signature tool breaks DKIM or S/MIME?

Send a test message through the deployed tool to an external mailbox. Check the headers for dkim=pass or dkim=fail with a body hash mismatch note. If you use S/MIME, also test one clear-signed and one encrypted message. Check that the signature validates and that the signature content appears. Test again after any change to how the tool is deployed, because a working setup can stop working without anyone noticing.

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

No. Microsoft 365’s default relaxed body canonicalization tolerates changes to whitespace and trailing empty lines only. It does not tolerate real content such as a signature block. Visible signature content added after DKIM signing breaks the signature in either mode.

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

No. It is related but separate, and Consistent Email Signatures as a Phishing and BEC Defence covers the other one. That article treats consistent signatures as a visual cue that helps people spot social-engineering attacks. This article is about whether a genuine, correctly signed message keeps a valid signature after a signature or disclaimer is added.