DKIM is the email-authentication record that feels the most mysterious, because it involves cryptography. But the idea is simple: your mail provider signs every message you send, and anyone receiving it can verify that signature against a public key you publish in DNS. This guide explains how that works, what a selector is, and how to find and rotate your keys.

What DKIM does

DKIM (DomainKeys Identified Mail) proves two things about a message: that it genuinely came from your domain, and that it wasn't altered between sending and delivery. It does this with a digital signature added to the message headers — invisible to the reader, but checked by the receiving server.

How the signing works

DKIM uses a public/private key pair:

• The private key lives with your mail provider and is never shared. When you send a message, the provider computes a signature over the message's headers and body using this key, and adds it as a DKIM-Signature header.
• The public key is published in your DNS as a TXT record. Anyone can read it.

When a receiving server gets your message, it reads the DKIM-Signature header, fetches your public key from DNS, and uses it to verify the signature. If the maths checks out, the message is authentic and unmodified. If even a single byte of the signed content changed in transit, verification fails.

What a selector is

A domain often needs more than one DKIM key — different providers, or old and new keys during a rotation. The selector is the label that says which key to use. It appears in the signature and points to where the public key lives in DNS, at:

selector._domainkey.yourdomain.com

So a message signed with the selector google for example.com tells the receiver to fetch the key from google._domainkey.example.com. Providers each use their own selector names — Google uses google, Microsoft 365 uses selector1 and selector2, and many bulk senders use a custom one.

What a DKIM record contains

The published TXT record holds the public key and a few options. A typical record looks like:

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

• v=DKIM1 — the version.
• k=rsa — the key type (RSA is standard).
• p= — the public key itself, as a long base64 string. An empty p= means the key has been revoked.

Why DKIM matters more than SPF for forwarded mail

Because the DKIM signature travels inside the message, it keeps verifying even when mail is forwarded — unlike SPF, which breaks the moment a forwarding server becomes the new sender. That resilience is why DMARC alignment via DKIM is generally more reliable than via SPF, and why you should always enable DKIM, not just SPF.

Rotating your keys

Good practice is to rotate DKIM keys periodically (many providers do this automatically). Rotation works smoothly thanks to selectors: you publish a new key under a new selector, switch signing to it, and once no in-flight mail relies on the old key, remove it. Because each key has its own selector, old and new can coexist with no downtime.

Common DKIM problems

• DKIM never enabled. Many providers don't sign by default — you have to switch it on and publish the key.
• Key published incorrectly. A long key split wrong, or pasted with stray spaces, won't validate.
• Wrong or unknown selector. If you can't find your record, you're likely looking under the wrong selector.
• Revoked key (p= empty). Signing was turned off or the key was withdrawn.

Find and verify your DKIM record

Use the DKIM lookup to locate your key — it tries the selectors used by major providers — and the full domain check to see DKIM alongside SPF and DMARC. New to all this? Start with SPF, DKIM & DMARC explained.