- DKIM, defined
- DKIM attaches a cryptographic signature to each outgoing message, letting the receiving server fetch your public key from DNS and confirm the message body and headers were not altered in transit.
Your sending platform holds a private key and adds a DKIM-Signature header to every message. That header names the domain, the selector, which headers were signed, and the hash of the body.
The receiver reads the selector, queries selector._domainkey.yourdomain.com, gets the public key, and recomputes the hash. Match means the message arrived as sent.
The signature travels with the message, so it survives forwarding in a way SPF does not. A mailing list that rewrites the subject line will break it, which is the case ARC exists to repair.
Signed mail is not trusted mail. A spammer can sign their own messages perfectly well. What the signature establishes is that this domain took responsibility for this message, which is the thing DMARC then checks against the visible From address.
How ZapBounce reports it
Verification never sees a DKIM signature, because we close the connection before any message body exists. Our free DKIM checker looks up a selector and reports the key it finds, along with the bit length.
Following one signature from header to DNS
Open any message you've sent to a Gmail account and choose Show original. Near the top you'll see a line like DKIM: PASS with domain example.com. Further down is the header that produced it, beginning DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=google.
Two of those tags tell you where the key lives. The d value is the signing domain and the s value is the selector, so the public key sits in a TXT record at google._domainkey.example.com. Run dig +short TXT on that name and you'll get back a string starting v=DKIM1; k=rsa; p= followed by the key.
Selectors differ by provider. Google Workspace uses google unless you changed it. Microsoft 365 publishes selector1 and selector2 as CNAME records pointing into its own zone, which lets Microsoft rotate keys without you editing anything.
A pass that still fails DMARC
Check the d value against the address in your From line. Many sending platforms sign with their own domain until you set up a custom one. The signature verifies, the report says DKIM pass, and DMARC ignores it, because the signing domain has nothing to do with the domain your recipient sees.
This is the most common reason a sender with working DKIM fails DMARC at Gmail. The fix is on the platform's side of the fence: add the CNAME or TXT records they give you, so they can sign as your domain. Afterwards, confirm it by sending a test and reading d again.
One practical trap catches people on the way. A 2048-bit key is longer than the 255 characters a single DNS string can hold, so it has to be published as two quoted strings inside one record. Some DNS control panels handle that split for you and some silently cut the key short. If a new selector fails, compare the published value's length with what your platform issued.
DKIM: common questions
What key length should I use?
2048-bit. Major providers expect it, and 1024-bit keys are increasingly treated as a weak signature rather than a valid one.
How often should DKIM keys be rotated?
Every six to twelve months is common practice. Publish the new selector, switch signing to it, then remove the old record after the last signed mail has cleared.
Does DKIM prove the sender is trustworthy?
No. It proves the message was not modified and that a specific domain signed it. Anyone can sign their own mail, including a spammer.