DKIM Records Explained: Signing Your Email So It Can't Be Faked

SPF checks which servers are allowed to send email for your domain. DKIM checks something different: whether a message that arrived is the same message that was sent, unmodified, and actually signed by the domain it claims to be from. Both live in DNS as TXT records, both get checked by receiving mail servers, and both are usually set up by pasting a string your mail provider gives you. What that string does is worth understanding on its own.

What DKIM actually does

DKIM stands for DomainKeys Identified Mail. When your mail provider sends a message on your behalf, it attaches a digital signature to the message headers, generated with a private key only the provider holds. The corresponding public key is published in DNS, on your domain, as a TXT record.

When the message arrives, the receiving server:

1. Reads the signature attached to the message.
2. Looks up the public key published at the selector and domain named in that signature.
3. Uses the public key to verify the signature matches the message content.

If the signature checks out, the receiving server knows two things: the message was signed by whoever holds the private key (presumably your mail provider, acting on your behalf), and the signed parts of the message haven't been altered since it was signed. If a message is intercepted and modified in transit, the signature no longer matches and verification fails.

This is different from SPF, which only checks that the sending server's IP address is authorized. DKIM survives being forwarded through servers that SPF would reject, because it travels with the message itself rather than depending on which server delivered it.

Why DKIM records live on a subdomain, one per sender

Unlike SPF, where every sending source is merged into a single record at whichever domain the envelope sender uses (usually the root domain, sometimes a subdomain), DKIM records are split up. Each sending service gets its own key, published at its own subdomain:

selector1._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."

The selector is a short name your mail provider chooses, and it's what lets multiple DKIM records coexist without conflicting. If you send through Google Workspace, Postmark, and Mailchimp, you'll have three separate DKIM records, each with a different selector and a different key, each managed independently by that provider:

google._domainkey.example.com.     TXT  "v=DKIM1; k=rsa; p=..."
pm._domainkey.example.com.         TXT  "v=DKIM1; k=rsa; p=..."
k1._domainkey.example.com.         TXT  "v=DKIM1; k=rsa; p=..."

This also means removing a sending service you no longer use doesn't affect the DKIM records for services you still use. Each one is independent.

Reading a DKIM record

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...

• v=DKIM1 marks the version. Always present, always first.
• k=rsa names the key algorithm. RSA is standard; some providers use k=ed25519.
• p= is the actual public key, base64-encoded. This is the long part. If it's empty (p=), the key has been revoked and signatures from that selector will no longer verify. Providers do this deliberately during key rotation.

There's no allow-list of servers here and no pass/fail policy, unlike SPF and DMARC. A DKIM record just publishes a key. Verification either succeeds mathematically or it doesn't.

How to check your DKIM records

You need the selector, which your mail provider documents. Common ones: Google Workspace uses google, Microsoft 365 uses selector1 and selector2, Postmark and SendGrid each generate their own when you add a domain.

dig TXT google._domainkey.example.com

If that returns nothing, either the record hasn't been added yet, or you have the wrong selector. Check the DKIM setup page in your mail provider's dashboard, it will tell you exactly which selector and record value to publish. MyDMARC's DKIM checker will look up a selector for you and flag whether the key is valid, malformed, or missing.

To see the signature on a message that already arrived, check the DKIM-Signature header in the raw email source. The s= field in that header names the selector used, and d= names the domain, which is what you'd query.

What breaks DKIM even when the record exists

Wrong selector. If your mail provider changes selectors, for example during a key rotation, and the old record gets removed before the new one propagates, or the new selector is never added, signing continues but verification fails.

Line-wrapped or truncated keys. DKIM public keys are long, and some DNS providers split TXT record values into multiple quoted strings or truncate them at a length limit. A key that gets cut off mid-string breaks verification even though a record technically exists at the right name.

Editing the record by hand. Because the key is a long opaque blob, it's easy to introduce a typo or drop a character when copying it manually. Always paste directly from what the provider gives you rather than retyping it.

Provider-side key rotation with no DNS-side follow-up. Some providers rotate DKIM keys periodically and expect you to update the DNS record when they do. If the record isn't updated, old signatures still verify against the previous key until it's revoked, then verification starts failing with no local configuration change to explain why.

How DKIM, SPF, and DMARC fit together

Each of these checks works on its own: a receiving server can evaluate SPF and verify a DKIM signature whether or not a DMARC record exists at all. SPF authorizes sending servers. DKIM verifies message integrity and origin. DMARC is what ties the two together into a policy: it tells receiving servers what to do when SPF or DKIM fails, and where to send reports about it.

A message can fail SPF and still pass DMARC, if DKIM passes and the domains align. This is exactly why forwarded mail, which usually breaks SPF, can still authenticate: DKIM's signature travels with the message regardless of which server relayed it. For the full picture of how all three records work together, see DNS TXT Records: SPF, DKIM, and DMARC All Live Here. If you're troubleshooting a specific "missing SPF" flag rather than DKIM, see Your Domain Has No SPF Record.

Those DMARC reports are where SPF and DKIM results actually become visible per-message. MyDMARC parses the aggregate reports your policy generates and shows you which sending sources are passing DKIM, which aren't, and which ones you've never heard of.

How DNS monitoring fits in

DKIM records are easy to lose during a DNS migration, the same way SPF and DMARC records are: they exist on your old nameservers, and nothing forces them to get recreated on new ones. Unlike a missing MX record, a missing DKIM record doesn't stop email from sending. It just stops it from being signed, and every message from that sender starts failing DKIM verification silently.

OneDollarDNS monitors DKIM TXT records alongside SPF, DMARC, and every other record type, and alerts you if one is changed or removed. If your mail provider rotates a key and you need to confirm the new record actually propagated, or if you want to know the moment a DKIM record disappears during a migration, that's what the alert is for.