How a DKIM Signature Is Made and Checked
DKIM is a digital signature added to each outgoing message, which the receiving server verifies with a public key published in your DNS. A pass tells the receiver that the message was signed by a server holding the private key for that domain and that the signed parts were not changed on the way. This is for anyone adding a new sending service, chasing a DKIM failure in a DMARC report, or trying to work out what DKIM does that SPF does not.
The Header That Carries the Signature
The signature travels inside the message as a header called DKIM-Signature. It is a list of tags, and a handful of them do the work. d= names the domain taking responsibility for the message. s= is the selector, a label that says which key to look up. h= lists the header fields that were signed, bh= holds a hash of the body, and b= is the signature itself. a= names the algorithm, c= the canonicalization, and t= and x= are the timestamp and the expiry.
RFC 6376 requires that the From header be among the signed fields. That one rule is why a forged display address cannot ride along on a genuine signature: change the From line and the hash no longer matches. The full tag list is in RFC 6376.
Where the Public Key Is Published
The receiver builds a hostname from two values in the header: the selector and the domain. A message with s=mail2026 and d=example.com sends the receiver to a TXT record at mail2026._domainkey.example.com. The record looks like v=DKIM1; k=rsa; p=MIIBIjANBgkq..., where p= is the base64 public key. An empty p= means the key has been revoked.
Because the selector is part of the hostname, a domain can publish many keys at once. Your mailbox provider has one, your newsletter tool has another, and a billing system has a third, each under its own selector, none of them aware of the others. That is the feature that makes rotation possible, and it is the reason a DNS record change for one sender cannot break another.
What Is Signed and What Can Break It
The signature covers the headers named in h= and a hash of the body. The c= tag controls how forgiving the comparison is. Under relaxed canonicalization, extra spaces and header case changes are ignored. Under simple, nothing may change at all. Most senders use relaxed/relaxed, and a message that passes through one extra hop that rewraps a line then still verifies.
What a relaxed comparison cannot forgive is a changed word. A mailing list that adds a footer, a gateway that appends a legal disclaimer, or a security product that rewrites links all alter the body after signing, and the body hash stops matching. The result at the receiver is a DKIM failure on a message that left your server perfectly signed. It is why a DKIM fail from a list or a scanner is often not an attack at all.
How DKIM Differs from SPF
SPF asks which server connected. DKIM asks whether the message itself is intact and signed. SPF is checked against the sending address in the envelope and the IP that delivered the mail, so a forwarder that relays your message from its own server breaks it. A DKIM signature lives in the message and survives a plain forward untouched.
Neither replaces the other. SPF is a short list in DNS that is cheap to publish and easy to outgrow, as the SPF record syntax guide explains. DKIM takes more setup per sender and holds up better once mail starts being relayed. Running both is the normal arrangement, and the reason DMARC accepts either.
Why DMARC Cares About the D= Domain
A DKIM pass is not enough on its own for DMARC. The signing domain in d= also has to line up with the domain in the visible From address. RFC 7489 describes two modes. In relaxed mode, the organizational domains must match, so a signature with d=example.com aligns with a From address at alerts@news.example.com. In strict mode, the two fully qualified domain names must be identical, and that same pair fails.
This is the trap with third-party senders. A bulk-mail service that signs with its own domain gets a DKIM pass, but the pass belongs to the vendor, not to you, and DMARC alignment fails. Setting up a custom signing domain in the sender's dashboard, which usually means publishing the CNAME or TXT records it gives you, is what moves d= to your domain.
Setting up DKIM and Fixing It When It Fails
Setup is the same job every time: get a key pair generated for the sender, publish the public half in DNS under a selector, and switch signing on. The steps that go wrong are the small ones.
Choosing a Selector and Key Size
Selectors are free-form labels. Providers ship with their own defaults, such as google, selector1, or s1, and when you control the naming, a date or a service name such as billing2026 makes a record readable a year later.
For key size, RFC 8301 says signers must use RSA keys of at least 1024 bits and should use at least 2048 bits. It also forbids the older rsa-sha1 algorithm for signing and verifying. Google's sender guidelines say mail to personal Gmail accounts needs a DKIM key of 1024 bits or longer, and recommend 2048 when the provider supports it (Google bulk sender guidelines, checked October 2026). Pick 2048 unless the sender cannot do it.
Publishing a 2048-Bit Key Without Breaking the Record
A 2048-bit public key is longer than 255 characters, and a single string inside a TXT record cannot be. The fix is to split the value into two or more quoted strings in the same record, which receivers join back together. Many DNS panels do this for you, some do not, and some will accept an oversized string and then silently publish something unusable.
Paste the value exactly as given. A line break in the middle of p=, a trailing space, or a curly quote picked up from a document will make the key unreadable, and the failure shows up only when mail is sent. Some providers avoid the whole problem by asking for a CNAME instead, so the key lives on their side and rotates without you touching DNS.
Testing a Signature Before You Trust It
Send a message from the real sending service to a mailbox you can open, then view the original message source. Look for the Authentication-Results header the receiver added. A healthy one reads like dkim=pass header.d=example.com header.s=mail2026. Two things to check in that line: the result, and whether header.d is your domain or the vendor's.
If the result is not a pass, the wording points to the cause. dkim=none means no signature was present, so signing is switched off at the sender. A message that says no key was found means the DNS lookup failed, which is a hostname or publishing problem. A body hash mismatch means something altered the message after signing. Exact wording varies between receivers, but those three categories hold.
The Failures That Come up Most
The hostname is the usual culprit. Many DNS panels append the domain automatically, so typing the full mail2026._domainkey.example.com produces mail2026._domainkey.example.com.example.com, which nothing will ever look up. Enter only the part before your domain and then check the result with a public DNS lookup.
The second is a leftover testing flag. A record with t=y marks the domain as testing DKIM. It is meant to come off once signing works, and leaving it on tells anyone who reads the record that the setup was never finished. The third is a stale key: the provider rotated and started signing with a new selector, but your DNS still carries the old one, or the reverse.
The fourth is a sender that was never set up at all. A DMARC report lists a service you forgot, signing with its own domain or not signing, and that line in the report is the earliest warning you get. If your mail is already landing in junk, this is one of the places to look first, alongside the checks in why emails go to spam.
Rotating a Key Without Dropping Mail
Rotation is publish, switch, wait, remove. Publish the new key under a new selector first. Switch the sender to sign with it. Leave the old selector in DNS for a few days, because messages signed before the switch may still be in transit or queued at a receiver, and they need the old key to verify. Remove it only after that.
Skip the order and the symptom is a short burst of DKIM failures that clears by itself, which is exactly why people never connect it to the change they made that morning.
The same discipline applies to a sender that mails on your behalf from a website, such as the order and form notifications a transactional email service sends. The key for that sender needs the same record, the same test, and the same rotation plan as any other.
Getting DKIM Handled for You
With Email Authentication, we find every service that sends as you, sign each sender with DKIM, and publish the keys in your DNS. Selectors are checked daily to confirm they still resolve, rotation is handled when a provider requires it, and you are told the day a signature stops validating. Ongoing deliverability monitoring and the wider email service sit alongside it.
