Skip to content
DomainVigil
Sign up

Reference guide

What is DKIM?

DKIM attaches a cryptographic signature to the message, and the recipient can check it. It is the only one of the three mail protocols that survives forwarding, and nothing else does its job.

7 min readUpdated September 12, 2026

In short

DKIM is a signature the sending server adds to one of the message headers. The public key that verifies it is published in the domain's DNS, under a name of the form selector._domainkey.yourdomain. If the signature recomputes identically at the recipient, the message really came from the domain it claims, and nothing the signature covers changed in transit.

What DKIM is for

SPF looks at where the message came from. DKIM looks at the message itself. The difference is not academic: when a mailbox forwards mail automatically to another address, it goes out again from a server that was never on any SPF list, and the origin check fails. The DKIM signature rides inside the message: it arrives intact and still verifies.

The platform doing the sending applies the signature — company mail, invoicing tool, newsletter service. Each has its own key, and each publishes it under a different selector. A domain therefore normally carries several DKIM records, one per service, and that is perfectly normal.

The domain owner only ever handles one thing: the DNS record that publishes the public key. The private key never leaves the provider. That split is what lets you delegate DKIM to five services without handing out a single secret.

What happens, from departure to arrival

Five steps separate the click on send from the verdict at the far end. Knowing which one failed saves an hour of hunting.

  1. 1

    The sending server picks what it covers

    It hashes the message body, then names the headers it wants to protect — at minimum the visible sender, usually the subject and date as well.

  2. 2

    It signs with its private key

    The result goes into the message as a header carrying the signing domain, the selector, the list of covered headers, the body hash and the signature itself.

    DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=selector1; h=from:to:subject:date; bh=...; b=...

  3. 3

    The message crosses the internet

    Relays along the way may add headers, reflow whitespace, re-encode text. Only the headers listed in the previous step are protected; the rest can move without breaking the signature.

  4. 4

    The recipient fetches the public key

    It builds the name to query from the selector and signing domain in the header, then reads the TXT record it finds there.

    selector1._domainkey.example.com

  5. 5

    It redoes the computation

    If the hash comes out identical, the signature is valid: the message comes from the domain it claims and the covered content was not touched. Otherwise DKIM fails, and what happens to the message is decided elsewhere.

Where the public key lives, and what it holds

The DKIM record is a TXT record published under a three-part name. That name, more than its contents, is what throws people the first time.

selector1._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; t=s; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

  1. selector1The selector

    A free-form name chosen by the signing service. It lets several keys live on the same domain and lets you change one without interruption: publish the new one under another selector, switch over, then remove the old.

  2. _domainkeyThe reserved compartment

    Always written exactly like that, underscore included. It is the fixed part that puts the name in the DKIM namespace and nowhere else.

  3. v=DKIM1The version

    Optional, but when present it must be the first tag in the record.

  4. k=rsaThe key type

    RSA by default. The only other standardized value is ed25519, shorter, but not every verifier knows it yet.

  5. t=sThe flags

    Two values exist. s stops a subdomain from using this key. y announces testing mode: recipients are asked to draw no conclusion from a failure.

  6. p=MIIBIjAN...The public key

    Base64 encoded. An empty p tag is not a typing mistake: it is the standard way to revoke a key without deleting the record.

The tags in a DKIM record

The record reads as a series of tags separated by semicolons. Only two matter; the rest carry a default that is almost always right.

TagWhat it saysDefault
vThe format version. When present, it comes first.Absent
kThe type of key published: rsa, or ed25519 for short signatures.rsa
pThe public key in base64. Required. Empty, it revokes the key.None
hThe hash functions accepted, separated by colons. Restricting to sha256 is common practice.All
sThe service type allowed to use the key. The value email reserves it for mail.*
tThe flags: y for a test mode with no consequence, s to forbid use by subdomains.None
nA free-text note for whoever reads the record.None

Check your own domain, right now

Enter a domain name: the tool looks for its published DKIM signatures, its SPF and its DMARC, and tells you what each one covers.

No sign-up, no email required. You can paste a full address — we'll pull the domain out of it.

Key sizes and what they imply

The key size settles one very concrete thing: whether the record fits in a single DNS string or has to be split.

KeyLength of the p tagWhat to know
RSA 1024around 216 charactersThe accepted floor. Fits in one TXT string, but leaves less headroom than you want today.
RSA 2048around 392 charactersThe usual recommendation. It runs past the 255 character limit on a TXT string, so publish the record in several chunks.
RSA 4096around 736 charactersAccepted, rarely needed. Several chunks are unavoidable, and some DNS interfaces still refuse to join them back correctly.
Ed2551944 charactersFits comfortably in one string. The trade-off: verifiers that do not know it treat the signature as missing.

Verifiers refuse anything below 1024 bits outright: it amounts to not signing at all. If an interface still offers 512 bits, ignore that setting.

What breaks a DKIM signature

  • The record exists but verification fails

    What causes it: The key was copied by hand out of the provider's interface, with a line break or a space in the middle of the p tag.

    What fixes it: Republish the value exactly as supplied, with no reformatting. Split it between quoted strings, never with a line break inside the value.

  • The signature passes at one recipient, fails at another

    What causes it: A mailing list or an inbound security appliance rewrites the subject or the body after signing.

    What fixes it: Nothing to fix in DNS. This is exactly the case DMARC covers: it only needs one of the two checks to pass.

  • The service rotated its key and mail is now flagged

    What causes it: The provider rotated the key, but the old selector is still the only one published in DNS.

    What fixes it: Publish the new selector before the switch, let both live side by side for one TTL, then remove the old one.

  • One service signs, the others do not

    What causes it: DKIM is set up service by service. Adding an invoicing or newsletter tool signs nothing until its selector is published.

    What fixes it: List everything that sends mail under the domain, then publish one record per service.

The questions that come next

How many DKIM records can a domain have?

One per service that sends in its name. Each lives under its own selector and never interferes with the others. Unlike SPF, there is no forbidden duplicate here and no lookup budget.

Can you find a domain's selector without knowing it?

Not reliably: the name is free-form, and DNS gives no way to list what exists under a prefix. Read the selector out of the headers of a message that domain sent you, or out of the provider's documentation.

Should keys be rotated, and how often?

Rotation is good practice, but the provider holding the private key is the one who does it. On the domain side, what matters is publishing the new selector before the switch and not leaving old ones lying around for ever.

Does DKIM replace SPF?

No, and neither does the reverse. SPF guards against spoofing at the source, DKIM against tampering in transit. DMARC requires at least one of the two to pass, and the validated domain to align with the one the reader sees.

A signature that drops tells nobody

A selector removed too early, a key revoked by a provider, a record overwritten during a DNS migration: the mail keeps going out, it is just no longer signed. DomainVigil re-reads the records on every domain you own each day and emails you the moment one changes.

Start for free

Five domains free, forever. No card required.

The other reference guides