DKIM: the complete guide to DKIM signatures

The DKIM-Signature header, decoded

The entire DKIM machinery lives in one header added to the message. Here is one, as found in the raw source of an email:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
  d=example.com; s=s2026; t=1753344000;
  h=from:to:subject:date:mime-version;
  bh=KWSe46TZKCcDbH4klJPo+tjk5LWJnVRlP5pvjXFZYLQ=;
  b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZVoG4ZHRNiYzR...

The tags it is made of are standardized. The seven main ones:

Tag	Name	Role
v=	Version	Always 1: the version of the DKIM standard in use.
a=	Algorithm	The signing and hashing algorithm, rsa-sha256 in the vast majority of cases (ed25519-sha256 for modern keys).
d=	Domain	The signing domain, the one claiming the message. This is what DMARC will compare to the visible From:.
s=	Selector	The name of the key used, telling the recipient where to find the public key in DNS.
h=	Signed headers	The list of headers covered by the signature; any header absent from this list can change without breaking it.
bh=	Body hash	The hash of the message body at signing time.
b=	Signature	The cryptographic signature itself, base64-encoded.

Other tags appear depending on the setup: c= (the canonicalization mode discussed above), t= (signature timestamp), x= (expiry date beyond which the signature must no longer be accepted), i= (identity of the signing agent, sometimes a subdomain or an address), or l= (signed body length — a risky option, since it allows content to be appended after the signed portion, and one best practice advises against).

Two tags deserve special attention. d= first: it is the signature's identity claim, and the pivot of the entire DMARC edifice. Then h=: the list of signed headers determines what the signature actually protects. Signing From is mandatory; also signing Subject, Date, To and Reply-To is strongly recommended, so they cannot be forged after the fact.

Selectors: several keys for one domain

A domain almost never has just one DKIM key. Business email typically leaves from several places — the main mailbox provider, a marketing tool, a CRM, a billing service — and each one signs with its own key pair. The selector is the mechanism that makes this coexistence possible: an arbitrary name, chosen by the signer, that identifies each published key.

Public-key discovery follows a fixed convention. The recipient reads s= and d= from the signature, then queries DNS at:

<selector>._domainkey.<domain>

For s=s2026 and d=example.com, the TXT query therefore targets s2026._domainkey.example.com. Each sending provider has its own naming conventions: google for Google Workspace, selector1/selector2 for Microsoft 365, platform-specific names elsewhere. That makes for a useful audit reflex: enumerating the selectors published under _domainkey reveals the list of services authorized to sign for the domain — including the ones everyone had forgotten about.

This multi-key architecture brings two major operational benefits. Isolation: if one provider is compromised or dropped, you revoke its selector without touching the other flows, which keep signing normally. Flexibility: a new key can be introduced alongside the old one, which is the foundation of the zero-downtime rotation described below. The selector's exact role, conventions and pitfalls are covered in our dedicated selector guide.

Generating and publishing a DKIM key

In practice, the key pair comes into existence in one of two ways. Either the sending platform generates it for you — the case with office suites and most email platforms, which hand you the DNS record to publish — or you generate it yourself (self-hosted mail server, a requirement to keep control of the keys), with a standard tool such as OpenSSL. The exact commands, step by step, are in our step-by-step generation guide.

The public key is then published in DNS, and two models coexist:

The direct TXT record. You create the TXT record yourself under <selector>._domainkey.<domain>, with the key in plain sight:

s2026._domainkey.example.com.  IN TXT
  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

You keep full control of the key — you rotate it, you revoke it. One caveat: a 2048-bit RSA key exceeds the 255-character limit of a single DNS string; the record is then split into several quoted strings that resolvers reassemble automatically. The splitting is normal, but some DNS interfaces handle it poorly.

The delegated CNAME. You publish a simple alias pointing at a record hosted by the sending provider:

s1._domainkey.example.com.  IN CNAME  s1.domainkey.sending-provider.example.

The provider hosts the real key and can rotate it without you ever touching your DNS zone. This is the dominant model among email platforms, and it has a genuine operational merit: rotation becomes their problem, not yours. The trade-off is a delegation of trust — the provider controls one of your domain's cryptographic identities. In both models, the t=y tag (test mode) can accompany an initial rollout, and revocation is performed by emptying the record's p= value.

Key rotation: hygiene, not an event

A DKIM key is not meant to live forever. The longer a private key exists, the higher the odds it leaks: a misplaced backup, a compromised server, a former provider that kept the key active, a copy forgotten in a code repository. And a stolen DKIM private key lets an attacker sign messages that look perfectly authentic to recipients — with DMARC alignment thrown in. Periodic rotation bounds that risk in time: a key stolen yesterday is worthless after the rotation.

On frequency, the reference figure commonly cited across the industry (notably in M3AAWG recommendations) is a rotation at least twice a year, roughly every six months. In practice: every six months for sensitive flows, once a year at the bare minimum, and immediately upon any suspicion of compromise or when parting ways with a provider.

The remarkable part is that rotation can be entirely transparent, thanks to selectors. The zero-downtime procedure takes four steps:

1. Generate a new key pair and publish the new public key under a new selector (say s2027), leaving the old one untouched.
2. Switch signing on the sending side over to the new key.
3. Wait a few days: mail signed with the old key, still in transit or queued, must finish being delivered and verified.
4. Revoke the old selector (empty its p=), then remove it.

At no point does a message travel without a verifiable public key: both selectors coexist during the switchover. The full procedure, the pitfalls, and the case of CNAME-delegated keys are the subject of our key rotation guide. One last point of the same hygiene: the private key is a critical secret, to be stored as such (secrets vault, restricted access), never in plain text in a repository or a ticket.

1024 or 2048 bits: choosing the key size

For RSA keys, two sizes are found in the wild. 1024 bits, long the default, is still accepted by verifiers but no longer offers a serious security margin: RFC 8301 set it as the absolute minimum, and factoring a key of that size is no longer beyond the reach of a very well-resourced adversary. 2048 bits is today's standard: a comfortable cryptographic margin, universal support on the receiving side, and its only practical constraint — the DNS record split across several strings — is a non-issue with any decent DNS host.

The rule is therefore simple: every new key is generated at 2048 bits, and a domain still running 1024 uses its next rotation to upgrade — exactly the kind of switchover that the selector mechanism makes painless. History has already ruled on this: short keys (512 and 768 bits) were publicly factored more than a decade ago, and major providers penalize or ignore signatures produced with weak keys. The full argument, numbers included, is in the 1024 vs 2048-bit comparison.

Beyond RSA, RFC 8463 introduced Ed25519 keys: much shorter at equivalent strength, they fit in a DNS record without any splitting. Verifier support is growing but still partial; the recommended practice is to publish them as a second selector, dual-signing alongside an RSA 2048 key, never as a dry replacement.

DKIM and DMARC: aligning the d=

Let it be said plainly: DKIM alone does not protect against impersonation. A valid DKIM signature proves the message is intact and signed by the d= domain — but nothing in DKIM requires that d= to match the domain the reader sees in the From: field. An attacker can sign cleanly with their own domain and display yours in the From:: DKIM will show green.

That is precisely the link DMARC adds: alignment. For a message to pass DMARC via DKIM, the signature must be valid and its d= domain must align with the From: domain. In relaxed mode (the default), a shared organizational domain is enough — a signature by newsletter.example.com aligns with a From: at example.com; in strict mode (adkim=s), the match must be exact. This rule is what turns a proof of integrity into genuine identity protection, and it is why DKIM is always deployed with DMARC in mind — the complete policy mechanics are described in the DMARC reference page.

DKIM alignment has one decisive property: it survives forwarding. When an email is relayed onward — from a work mailbox to a personal address, say — the forwarding server is the one delivering it, and the original IP no longer matches: the IP check fails, as explained in the SPF reference page. The DKIM signature, however, travels inside the message: as long as the signed content is unmodified, it remains valid across one or several hops. On forwarded mail, DKIM is often the only mechanism still able to produce an aligned result — which is why a strict DMARC policy without solid DKIM is a fragile policy. The limit exists too: mailing lists that rewrite the subject or append a footer break the signature, a case the ARC standard aims to recover. In practice, DKIM signed and aligned across all sources is condition number one for calmly completing the journey from p=none to p=reject.

Verifying a DKIM signature

Good news: there is nothing to recompute yourself. Every receiving server verifies signatures and records its verdict in an Authentication-Results header, visible in the raw source of any received message:

Authentication-Results: mx.example.net;
  dkim=pass header.d=example.com;
  spf=pass ...; dmarc=pass ...

Two pieces of information matter. dkim=pass: the signature is cryptographically valid. header.d=: the signing domain — the one to compare against the From: to judge alignment. A dkim=pass carrying a provider's header.d= contributes nothing to DMARC: valid signature, unaligned identity. Reading these headers in detail, tag by tag, along with the typical failure causes, is covered in our signature verification guide.

That per-message check, however, says nothing about your traffic as a whole. The exhaustive view comes from DMARC aggregate reports, which list, source by source, the DKIM results and their alignment as the large receivers actually evaluated them — the subject of our guide to aggregate reports. And for an instant status check of your domain — detected selectors, published keys, alignment, DMARC policy — our free DKIM checker lays it all out in seconds, no sign-up required.

FAQ

Is DKIM mandatory for sending email?

Formally, no: an unsigned message can still be delivered. In practice, yes. The Gmail and Yahoo sender requirements mandate DKIM for bulk senders, DMARC cannot produce robust alignment without it, and receivers place less trust in unsigned mail. For any domain sending business email, DKIM is a de facto prerequisite.

Does DKIM encrypt message content?

No. DKIM signs, it does not encrypt: from that standpoint the message travels in the clear, and the signature only proves its origin and integrity. Transport confidentiality is handled by other mechanisms (TLS between servers, hardened by MTA-STS), and end-to-end encryption by yet other tools (S/MIME, OpenPGP).

What happens when a DKIM signature fails?

Nothing automatic. An isolated dkim=fail does not cause the message to be rejected: it is a signal, which the receiver combines with SPF, reputation and above all the domain's DMARC policy. DMARC is what decides — if neither DKIM nor SPF produces an aligned result, the published policy (none, quarantine or reject) applies.

How many selectors can a domain publish?

As many as needed: the standard sets no limit. An active domain commonly publishes five to ten selectors — one or two per sending service, plus those that temporarily coexist during a rotation. The good practice is not to cap them but to inventory them: every active selector is an identity able to sign for the domain, and a forgotten selector from a departed provider is a door left open.

How often should the DKIM key be rotated?

The industry reference is a twice-yearly rotation, once a year at the bare minimum, and without delay upon suspected compromise or when leaving a provider. Thanks to the dual-selector method, the operation causes no interruption at all. CNAME-delegated keys are rotated by the provider itself — verify that this actually happens, as delegation is not a guarantee.

Can one message carry several DKIM signatures?

Yes, and it is common: the standard allows multiple DKIM-Signature headers on a single message. An email platform often signs with its own domain and with yours; dual RSA + Ed25519 signing is also a transition practice. For DMARC, a single valid, aligned signature is enough — the others do no harm.