Why does header re-ordering sometimes break DKIM?

When your server signs a DKIM message, it hashes a specific list of headers in a specific order. That order is recorded in the signature. When the receiving server verifies the signature, it reconstructs the same header list in the same sequence and checks that the hash matches.

If a mail relay has reordered those headers by the time the message arrives, the hash is different, and DKIM fails. The content is technically unchanged, but the order isn't, and DKIM can't tell the difference between reordering and tampering.

Why relays reorder headers

Some mail servers sort or normalize headers during processing. Mailing list software, forwarding services, and enterprise mail gateways often rewrite the header block to their preferred sequence. It's not malicious. It's just mail plumbing being imperfect. The headers arrive intact but in a different order than when they were signed.

Does canonicalization help?

Partly. Relaxed canonicalization normalizes whitespace and lowercases header names before hashing, which makes minor formatting changes survivable. But it doesn't handle full header reordering. Both simple and relaxed canonicalization will fail if the sequence of signed headers is shuffled.

When this actually happens

The most common place you'll see this is enterprise mail gateways. Products like Proofpoint, Mimecast, and some Microsoft Exchange configurations process and requeue messages, rewriting the header block in the process. If DKIM passes at Gmail but fails at corporate Outlook addresses, a rewriting gateway is worth investigating.

There's no setting you can flip to make DKIM survive full header reordering. The real fix is identifying which gateway is rewriting and whether its vendor supports DKIM-aware processing. Check your current canonicalization mode with our DKIM checker. If you're chasing a provider-specific failure you can't pin down, the SOS hotline is free.