DKIM

SPF checks the connecting server, so it fails the moment a message is forwarded — the forwarding server is not on the original domain's list. DKIM travels with the message: the signature is in the headers, so it still verifies after a hop, provided nothing rewrote the signed content.

That property is why DKIM is the alignment mechanism most senders end up relying on for DMARC, and why a DKIM failure is a more serious symptom than an SPF failure.

A DKIM record lives at selector._domainkey.yourdomain, which means one domain can carry several keys for several senders without collision. The selector is chosen by whoever generates the key, and it appears in the signature so the receiver knows where to look.

Use 2048-bit keys where the DNS provider allows it, and rotate periodically by publishing a new selector, moving signing to it, and retiring the old one after the mail signed with it has aged out. Rotation done the other way round breaks verification for everything in flight.

Usually something modified the message after signing. Mailing lists that append footers, security appliances that rewrite links or add banners, and gateways that reformat MIME parts all break signatures. The signature was valid; the message is no longer the message that was signed.

Diagnosing it means finding what sits between your signer and the receiver. That is unglamorous work, and it is why DKIM failures are worth checking on your own domain before assuming a recipient's filter is at fault.

DKIM is one of the records SalesShift checks per sending domain, alongside SPF, DMARC, MX and blocklist status, with the time of the check reported next to the result.