Email and DNS

What is DKIM and how does it work?

SPF checks which server sent a message. DKIM checks that the message itself was not changed on the way, which is a different guarantee and the one DMARC leans on most.

DKIM (DomainKeys Identified Mail) is an email authentication method in which the sending mail server signs each outgoing message with a private key, and the receiving server verifies that signature using a matching public key published in the sender’s DNS as a TXT record. A valid signature proves two things: the message was authorised by whoever controls that domain’s DNS, and the signed parts of it were not altered in transit. It is the second of the three records (SPF, DKIM, DMARC) that a domain needs to be treated as trustworthy by Gmail, Yahoo and Outlook.

Worked out 2026-10-16 (IST) · DKIM as specified in RFC 6376 with the algorithm rules of RFC 8301

What a DKIM record and a DKIM signature look like

Two pieces exist, one in DNS and one inside every message. The DNS side is a TXT record at a name built from the selector:

The DNS record
Part	Example	What it means
Name	selector1._domainkey.example.com	Selector, the fixed label _domainkey, then the signing domain
Type	TXT	DKIM keys are published as plain text records
v=	DKIM1	Version tag, always DKIM1
k=	rsa	Key type; ed25519 is also defined, in RFC 8463
p=	MIIBIjANBgkq... (long base64 string)	The public key itself. An empty p= means the key has been revoked

The message side is a header called DKIM-Signature, added by the sending server:

The signature header
Tag	Meaning
d=	The signing domain - the domain taking responsibility for the message
s=	The selector, which tells the receiver where to find the public key
h=	Which headers were signed (From must always be one of them)
bh=	A hash of the message body
b=	The signature itself, computed over the signed headers and the body hash
a=	The algorithm - rsa-sha256 today; rsa-sha1 was deprecated by RFC 8301

How the check actually runs

The receiving server reads the d= and s= tags, builds the DNS name, fetches the public key, recomputes the body hash and header hash from the message it received, and verifies the b= signature against them. If everything matches, the result is "dkim=pass". No shared secret ever crosses the network; the private key stays on the sending server and only the public half is published, which is why it is safe for the key to be visible to anyone who queries DNS.

Where DKIM fits with SPF and DMARC

Three layers, three different questions
Layer	Question it answers	Survives forwarding?
SPF	Is this server allowed to send for this domain?	No - the forwarder’s IP is not in your SPF record
DKIM	Was this message signed by the domain, and is it unchanged?	Yes, if the message is not modified
DMARC	Do SPF or DKIM pass AND align with the visible From domain?	Passes if either underlying check passes and aligns

DMARC needs only one of SPF or DKIM to pass with alignment, but relying on SPF alone is fragile precisely because of forwarding. Setting up DKIM is what makes a DMARC "reject" policy safe to turn on. Since February 2024, Google and Yahoo have required senders of more than 5,000 messages a day to have SPF, DKIM and DMARC all in place, so for bulk senders it stopped being optional.

How to set it up and verify it

Four steps
Step	What to do
1. Generate the key	In your email provider’s admin console (Google Workspace, Microsoft 365, Zoho, or your sending service). Choose 2048-bit
2. Publish it	Add the TXT record at selector._domainkey.yourdomain.com exactly as the provider gives it
3. Switch signing on	Most providers require a separate "start authentication" click after the DNS record is detected
4. Verify	Send a message to a Gmail address, open "Show original" and look for DKIM: PASS; or look up the TXT record at the selector in a DNS tool

If a message goes to spam despite passing all three, the cause is elsewhere in the list at why emails go to spam, starting with the sending IP’s reverse DNS.

Sources: IETF RFC 6376 (DomainKeys Identified Mail), RFC 8301 (cryptographic algorithm and key usage update, which deprecated rsa-sha1 and set a 1024-bit RSA minimum), RFC 8463 (Ed25519-SHA256), and the bulk-sender requirements Google and Yahoo began enforcing in February 2024.

Check your own numbers

Look up the TXT record at a DKIM selector to see whether a public key is published.

DNS LookupA, AAAA, MX, NS, TXT, CNAME and SOA records, live from the resolver.

Frequently asked

What is a DKIM selector?

A selector is a label that lets one domain publish several DKIM keys at once. The signature header names the selector (s=google, s=selector1, s=k1 and so on), and the receiver looks up the key at selector._domainkey.yourdomain.com. Selectors are what make key rotation possible without downtime: publish the new key under a new selector, switch signing to it, and retire the old one later.

How long should a DKIM key be?

Use 2048-bit RSA. RFC 8301 sets 1024 bits as the minimum a signer may use and tells verifiers to accept anything from 1024 to 4096, but 1024-bit keys are within reach of well-funded attackers and most providers now generate 2048-bit keys by default. The practical catch is that a 2048-bit public key is longer than the 255-character limit on a single DNS TXT string, so it must be split into two quoted strings inside one record, which most DNS dashboards do automatically.

Does DKIM encrypt my email?

No. DKIM only signs; the message stays readable in transit exactly as before. It proves origin and integrity, not secrecy. Encryption between servers is a separate mechanism (STARTTLS), and end-to-end encryption is separate again.

Why does DKIM fail after a message is forwarded?

Usually because something along the way changed a signed part of the message - a mailing list adding a footer or rewriting the subject, or a security gateway appending a disclaimer. Any change to a signed header or to the body breaks the body-hash comparison and the signature no longer verifies. Plain forwarding that leaves the message untouched keeps DKIM valid, which is exactly why DKIM survives forwarding when SPF does not.

Need email authentication checks inside your own product?

We build SPF, DKIM, DMARC and MX validators as embeddable widgets or a plain JSON API in your branding, wired to your own lead form. Tell us which checks you need and we will send a working demo.