DKIM for Developers: A No-Fluff Guide to Email Authentication

No cryptography background needed. Here's what DKIM is, why the selector trips everyone up, the exact records to publish, and a free tool that grades your keys.

TL;DR: DKIM (DomainKeys Identified Mail) is a system where your mail server adds a hidden cryptographic signature to every email you send. You publish the matching public key in DNS. The receiving server checks the signature against that key and confirms two things: the message really came from your domain, and nobody altered it along the way. The key lives at an address like selector1._domainkey.yourcompany.com. And unlike SPF, the signature survives forwarding.

That's the concept. Now let me show you the part every guide gets wrong: you can't even find your own DKIM record without knowing a secret label called the selector.

The Problem SPF Can't Solve

Last week I walked through SPF. It's the guest list that tells mail servers which machines can send as you. It works. It's essential. And it has one hole you can't patch.

Somebody forwards your email.

The message keeps your name in the From field. But now it arrives from their server, which is obviously not on your guest list. SPF fails. Your perfectly legitimate email, forwarded by a happy customer to a colleague, gets flagged as suspicious.

Now scale that up. Mailing lists forward. Alumni addresses forward. That info@ alias that redirects to three people forwards. Every one of those breaks SPF.

DKIM is what fixes it. Instead of asking "did this come from an approved server," DKIM asks a completely different question: "was this message signed by the domain owner, and has it been tampered with since?"

Forward it a hundred times. The signature travels with the message. It still checks out.

That's why you need both.

What Is DKIM, in Plain English

Forget the acronym. Think about a wax seal on a letter.

In the old days, you'd fold a letter, drip wax on the flap, and press your family signet ring into it. Two things happened at once:

1. Anyone could see the seal was yours because only you had the ring.
2. If the seal was broken or smudged, the letter had been opened.

DKIM is that, done with math instead of wax.

Your mail server has a private key. It's a long secret string that never leaves the server. Every time you send a message, the server runs the message through a calculation using that private key and produces a signature. The signature gets attached to the email in a hidden header nobody sees.

Your domain publishes the matching public key in DNS, out in the open for anyone to read. Public keys are useless for forging signatures. They can only verify them. That asymmetry is the entire trick.

The receiving server grabs your public key, runs the check, and gets a clean yes or no.

DKIM is defined in RFC 6376. The cryptography rules were updated in RFC 8301.

The Selector: The Part That Confuses Everyone

Here's the thing that makes DKIM different from every other DNS record you've dealt with.

With SPF, you look up yourcompany.com and you find the record. Done.

With DKIM, there's no fixed address. The public key sits at a location that includes an arbitrary label the sender chose, called a selector. The full address looks like this:

selector1._domainkey.yourcompany.com

The _domainkey part is fixed. Everyone uses it. But selector1 is just a name somebody picked. It could be google. It could be pm. It could be k1, or fm2, or s2026a, or bananas.

Why does this design exist? Because one domain usually sends mail through several different services, and each one needs its own key. Your main email platform signs with one selector. Your marketing tool signs with another. Your invoicing system with a third. Separate selectors mean you can rotate or shut off one platform without touching any of the others.

Why is this annoying? Because DNS provides no way to list every name under a branch. You can't ask "show me all the DKIM keys for this domain." There is no such query. If you don't know the selector, you can't look it up, full stop.

This one design choice is responsible for most of the confusion around DKIM. Once you understand it, the rest is easy.

Why This Matters Right Now

DKIM is the least deployed of the three protocols. A February 2026 scan of 5,499,028 domains from the Tranco top sites list found DKIM adoption at just 22.7%, compared with 56.0% for SPF and 30.4% for DMARC, according to DMARCguard's State of Email Authentication research.

Read that again. More than three quarters of the internet's most visited domains publish no verifiable signing key at all.

Email fraud is not slowing down. The FBI's Internet Crime Complaint Center recorded over one million complaints and $20.88 billion in losses in 2025. Business email compromise accounted for $3,046,598,558 from 24,768 complaints, second only to investment fraud. The full data is in the 2025 IC3 Annual Report.

AI joined the party officially. That same report added an AI-related crime category for the first time in 25 years: 22,364 complaints and $893,346,472 in losses. Writing a convincing impersonation of your CFO no longer requires talent.

Email is still the front door. Verizon's 2026 Data Breach Investigations Report analyzed more than 22,000 confirmed breaches and found the human element in 62% of them, with phishing behind 16% of initial access. Among AI-assisted intrusions, phishing was the largest single category at 44%.

And the mailbox providers now require it. Google and Yahoo started enforcing authentication for senders above 5,000 messages a day in February 2024. Microsoft followed on May 5, 2025, rejecting non-compliant mail to Outlook.com, Hotmail.com and Live.com outright with the error 550 5.7.515 Access denied, as documented in Microsoft's announcement. Google's rules live in the Gmail sender guidelines.

Both explicitly require DKIM. Not SPF or DKIM. DKIM.

How DKIM Works, Step by Step

Here's what happens between you hitting send and the message landing.

Step 1. Your server signs the message. Before it goes out, your mail platform selects a set of headers (usually From, Subject, Date, To and a few others) plus the body, runs them through a hashing calculation, and encrypts the result with its private key.

Step 2. It attaches the signature. A hidden header called DKIM-Signature is added to the message. Inside it are the signing domain (d=), the selector (s=), the list of headers that were signed (h=), a hash of the body (bh=), and the signature itself (b=).

Step 3. The message travels. Through your outbound server, through relays, possibly through a forwarder or two.

Step 4. The receiving server reads the header. It pulls out d= and s= and builds the DNS address: <selector>._domainkey.<domain>.

Step 5. It fetches your public key. One DNS lookup. Milliseconds.

Step 6. It recalculates and compares. It hashes the same headers and body the sender did, decrypts your signature with the public key, and checks whether the two match.

Step 7. Result. Match means the message is authentic and unmodified. No match means something changed in transit, or the signature was never valid to begin with.

The whole thing is invisible to the person reading the email. It just quietly decides whether your message is trusted.

What DKIM Does Not Do

This section matters. Skip it and you'll overestimate what you just installed.

DKIM does not prove who sent the message from where. It proves the signature is valid. That's a subtly different thing, and attackers have learned to exploit the gap.

DKIM signatures can be replayed. This is the big one. A DKIM signature has no timestamp and no recipient binding. If an attacker gets hold of a legitimately signed message, they can resend that exact message to thousands of new victims and the signature still verifies.

This is not theoretical. In April 2025, attackers pulled off a live DKIM replay attack against Google itself. They registered a domain, created an OAuth app whose name contained an entire phishing message, and triggered Google's automated security alert. Google generated that alert and signed it with a valid DKIM signature. The attackers then relayed the untouched message onward, and it landed in Gmail inboxes showing as signed by Google, complete with a fake subpoena notice. Abnormal AI published a full technical breakdown.

Authentication passed. The email was still a phish.

DKIM breaks when the message body is modified. Mailing lists that append a footer, or gateways that rewrite links, change the body and invalidate the body hash. Signature fails, and nothing was malicious.

DKIM does not stop spoofing on its own. A signature can verify perfectly while the visible From address belongs to someone else entirely. Only DMARC forces the signing domain to align with what the recipient actually sees.

So DKIM is not a magic wand. It's the durable half of a three part system.

Why You Should Set Up DKIM: The Real Benefits

1. Your email survives forwarding. The single biggest practical win. SPF cannot do this. DKIM can.

2. Tamper evidence. If anything modifies your message in transit, the signature breaks and the recipient's server knows.

3. You meet the bulk sender requirements. Google, Yahoo and Microsoft all require it above 5,000 messages a day, and increasingly expect it below that threshold too.

4. DMARC becomes reliable. DMARC passes when either SPF or DKIM aligns. With both published, a forwarded message that fails SPF still passes on DKIM. Your legitimate mail stops getting caught in the crossfire.

5. Better sender reputation. Enterprise gateways score signing configuration, not just pass or fail. A properly signed 2048-bit message reads as a maintained, professional operation.

6. You can revoke a compromised sender instantly. If a marketing platform gets breached, you retire that one selector and every other sending stream keeps working.

7. It costs nothing. Your mail provider generates the key. You publish one DNS record. No license, no subscription.

8. Compliance. PCI DSS 4.0, NIS2 and DORA all treat email authentication as a required control.

Every Tag Inside a DKIM Record, Decoded

Your DKIM DNS record is a list of short tags separated by semicolons. Here they all are.

Tag	What it means in plain English	Watch out for
v=	Version declaration. Says "this is a DKIM record."	Technically optional, but if present it must come first.
k=	The type of key. Usually rsa. Sometimes ed25519.	Ed25519 keys look tiny compared to RSA. Short does not mean weak.
p=	The public key itself. This is the long block of gibberish.	An empty p= revokes the key. A truncated key fails silently.
t=	Testing mode. Tells receivers to ignore failures.	Belongs in the first hour of setup and nowhere else. Remove it.
h=	Which hash algorithms are allowed.	Never restrict to sha1. It is deprecated.
s=	Service type. Almost always email or *.	Rarely set. Harmless.
n=	A free text note for administrators.	Ignored by every verifier. Purely a comment.

The tags inside the message itself

You'll also encounter tags in the DKIM-Signature header on an actual email. These are the ones worth recognizing:

Tag	What it means
d=	The signing domain. This is what has to align with your From address for DMARC to pass.
s=	The selector. This is how you find your key.
h=	The list of headers that were signed.
bh=	The body hash. If the body changes, this breaks.
b=	The actual signature.

Reading a real record

v=DKIM1; k=rsa; h=sha256; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...

In English: this is a DKIM record, using an RSA key, with SHA-256 hashing, and here is the public key. Clean and correct.

Now here's one that's quietly broken:

v=DKIM1; k=rsa; t=y; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQ...

The t=y means testing mode is still on, so receivers have been told to ignore any failure. You're signing every message and getting zero benefit from it. This is one of the most common findings on a domain that "has DKIM set up."

And this one:

v=DKIM1; k=rsa; p=

Empty p=. The key is revoked. If you're still signing with this selector, every message you send is failing DKIM right now.

How to Find Your DKIM Selector

Three reliable methods, in order of certainty.

Method 1: Read it from a message you sent (definitive)

Send yourself an email. Open it in Gmail, click the three dots, choose Show original. Find the DKIM-Signature header.

The s= tag is your selector. The d= tag is your signing domain. This is the only method that cannot be wrong, because it tells you what your server is actually doing right now, not what it's supposed to be doing.

Method 2: Check your provider's setup instructions

When your mail platform asked you to add a DNS record, the hostname contained the selector. Look for something ending in ._domainkey.

Method 3: Guess the common ones

Most hosted platforms use predictable selectors. Here are the ones you'll encounter most:

Provider	Selector	Full hostname
Google Workspace	google	google._domainkey.example.com
Microsoft 365	selector1, selector2	selector1._domainkey.example.com
Zoho Mail	zoho, zmail	zoho._domainkey.example.com
Proton Mail	protonmail, protonmail2	protonmail._domainkey.example.com
Fastmail	fm1, fm2, fm3	fm1._domainkey.example.com
SendGrid	s1, s2	s1._domainkey.example.com
Mailchimp / Mandrill	k1, k2, mandrill	k1._domainkey.example.com
Postmark	pm, pic	pm._domainkey.example.com
Amazon SES	three rotating tokens	<token>._domainkey.example.com, published as CNAMEs
Self-hosted servers	default, mail	default._domainkey.example.com

A useful side note for anyone doing competitive research: a selector name usually identifies the platform behind it. Finding k1._domainkey on a domain tells you they use Mailchimp. That's a public fact sitting in DNS.

Full Tutorial: Publishing Your DKIM Record

Step 1: List every service that sends email as you

Same exercise as SPF, and just as important. Each one needs its own key and its own selector.

Your main email platform. Your marketing tool. Your transactional sender. Your CRM. Your helpdesk. Your invoicing software. Your ecommerce order confirmations. Your monitoring alerts. Anything that sends without a signature is mail your recipients cannot verify.

Step 2: Generate the key inside your provider

Do not generate keys by hand unless you run your own mail server. Every hosted platform has a DKIM setup screen that generates the key pair for you, keeps the private half, and shows you exactly what to publish.

Roughly where to look:

• Google Workspace: Admin console, Apps, Google Workspace, Gmail, Authenticate email
• Microsoft 365: Defender portal, Email and collaboration, Policies, Email authentication settings, DKIM
• SendGrid, Postmark, Mailchimp, Brevo, Klaviyo: usually under Sender Authentication or Domain Verification

When the tool offers you a key length, choose 2048-bit. Always. More on this below.

Step 3: Publish it in DNS

Your provider will hand you either a TXT record or a CNAME record. These are handled differently and it matters.

If they give you a TXT record, create it like this:

Field	What to enter
Type	TXT
Name / Host	selector._domainkey (for example google._domainkey). Most panels append your domain automatically.
Value / Content	The full string starting with v=DKIM1;
TTL	3600 or Auto

If they give you a CNAME record, which is how Microsoft, SendGrid, Fastmail and Amazon SES all do it:

Field	What to enter
Type	CNAME
Name / Host	selector1._domainkey
Value / Target	The long hostname your provider gave you

A CNAME is a pointer. It tells DNS to go look at the provider's own record instead of storing a copy. This is strictly better, because the provider can rotate the underlying key on their schedule without ever touching your DNS.

Never convert a CNAME into a TXT copy. People do this when their DNS panel is fussy. It works right up until the provider rotates the key, and then your mail fails DKIM with no warning.

Step 4: Handle the 255 character problem

This is the trap that catches almost everyone using TXT records.

A 2048-bit public key is around 392 characters. A single DNS TXT string is limited to 255 characters. So the record has to be split into multiple quoted chunks inside one record, and DNS joins them back together automatically.

Most modern DNS panels do this for you invisibly. Some do not, and some silently truncate the value instead of warning you.

The failure mode is nasty: your mail still sends, your logs stay clean, nothing looks wrong on your end, and every receiving server rejects the signature. This is why step 6 exists.

Do not solve this by dropping to a 1024-bit key. Split the string, or use a CNAME, or move to a DNS host that handles it.

Step 5: Turn on signing and remove testing mode

Publishing the key does nothing by itself. Go back into your provider and switch signing on. In Google Workspace this is a button labeled Start authentication.

If your record contains t=y, remove it once you've confirmed signatures verify. Testing mode tells the world to ignore your failures, which cancels out the entire point.

Step 6: Test it, and do not skip this

Verify with the free DKIM Record Checker from EmailVerifyerAPI. It solves the selector problem, which is why it earns a spot here.

Leave the selector field blank and it probes around thirty selectors used by Google, Microsoft, Zoho, Postmark, Mailchimp, Fastmail, SendGrid and others, then reports what it finds. If you already know your selector, enter it for a definitive answer.

Here's what you get:

• A score out of 100 with a band from Missing through Weak, Low, Normal, Strong and Excellent, rated on key hygiene rather than mere presence.
• Selector discovery, so you can audit a domain without knowing its setup in advance.
• Key strength assessment, flagging 1024-bit keys that should be rotated.
• Revocation detection, catching the empty p= tag that means a key is retired but still in use.
• Testing mode detection, catching t=y left on from setup day.
• DMARC context, because a signature with no DMARC policy behind it has no consequence.
• A numbered findings list, each item explaining what is wrong and the specific change to make.
• No account, no signup, nothing stored on their side.

One thing I respect about it: when you supply no selector and it finds nothing, it reports that as inconclusive rather than scoring you a zero. That's the honest answer, because DNS genuinely cannot enumerate names under a subtree, and a blank result means the guesses missed, not that no key exists. Tools that report "no DKIM found" in that situation are lying to you.

How to use it:

1. Open the DKIM record checker.
2. Enter your domain. Add your selector if you know it, leave it blank if you don't.
3. Read the band first. Anything below Normal needs attention.
4. Work down the findings list. Revoked keys and testing mode first, key length second.
5. Re-run after each DNS change.
6. Then check your own domain against the SPF and DMARC checkers on the same site, because DKIM alone is not a finished job.

Step 7: Confirm with a real message

Send an email to a Gmail address you control. Show original. Look for:

DKIM: 'PASS' with domain yourcompany.com

If the domain shown next to DKIM is not your domain, you have a signature that verifies but does not align, and DMARC will not pass on it. That usually means your platform is signing with its own domain instead of yours, and you need to finish the branded sending setup.

What Makes a Perfect, Strong DKIM Setup

Eight characteristics. All of them checkable in a few minutes.

1. Every sending service signs. Not just your main mail platform. Your invoices and order confirmations matter more than your newsletter.

2. Keys are 2048-bit RSA. RFC 8301 updated the cryptographic requirements for DKIM, and 1024-bit has been below NIST's recommended minimum since 2013. A 1024-bit signature still verifies almost everywhere, but enterprise gateways like Proofpoint and Mimecast factor key strength into sender scoring. It's a visible signal that nobody has looked at your setup in a decade.

3. One selector per service. Shared keys mean you cannot revoke one platform without breaking the rest.

4. Selector names are versioned or dated. Something like s2026a instead of default. Future you will know instantly which key is current.

5. No t=y anywhere. Testing mode off.

6. No stale or revoked keys still in use. An empty p= on a selector you are actively signing with means silent, total DKIM failure.

7. The signing domain aligns with your From address. Verify signature is not the same as DMARC passes.

8. Keys rotate on a schedule. Every 6 to 12 months is the widely accepted practice.

How to Rotate a Key Without Breaking Anything

Follow the order exactly.

1. Publish the new key at a NEW selector: s2026b._domainkey
2. Wait for the old TTL to expire
3. Switch your platform to sign with the new selector
4. Revoke the old key, do NOT delete it: v=DKIM1; k=rsa; p=

Step 4 is the one people get wrong. Revoking means publishing the record with an empty p= value. That's the defined way to retire a key.

Deleting the record instead leaves any messages still in transit unverifiable rather than definitively unsigned, and it erases the evidence that the selector was ever yours. Keep the revoked record published.

On Ed25519 Keys

You may see the option for Ed25519, a newer and much shorter key type. The keys look almost suspiciously small compared to RSA. They are not weak. They are a different kind of mathematics.

The catch is that support across receivers and sending platforms is still uneven in 2026. If you want to use them, dual sign: publish Ed25519 alongside RSA-2048 so receivers that do not support the newer type fall back gracefully. Do not switch to Ed25519 alone.

The Eight Mistakes I See Most Often

1. The key was published but signing was never switched on. The record exists, the platform never activated. Extremely common.

2. t=y left on forever. You are signing everything and getting nothing.

3. A truncated 2048-bit key. The DNS panel silently cut the value at 255 characters. Everything looks fine and nothing verifies.

4. 1024-bit keys nobody has revisited. Some hosting panels still generate these by default.

5. A CNAME flattened into a TXT copy. Works until the provider rotates. Then it doesn't.

6. One selector shared across every platform. Cannot revoke anything without breaking everything.

7. Signing with the provider's domain instead of yours. Signature passes, alignment fails, DMARC fails.

8. Set up once, never checked again. Providers rotate keys. Teams add tools. Nobody is watching.

SPF, DKIM and DMARC: How the Three Fit Together

One line each.

SPF answers: is this server allowed to send for this domain? It's the guest list. It breaks on forwarding.

DKIM answers: was this message signed by the domain owner, and is it unaltered? It's the wax seal. It survives forwarding.

DMARC answers: what should receivers do when the others fail, and does the authenticated domain match the From address the human sees? It's the policy and reporting layer.

DMARC passes if either SPF or DKIM passes and aligns with your visible From domain. That's the whole reason to publish both. When one breaks, the other carries the message.

The gap in the real world is enormous. DMARCguard found only 12.8% of scanned domains actually enforce a policy that stops spoofing. As Valimail notes in its 2026 assessment, strong authentication is defined by alignment and governance, not by the presence of DNS records alone.

Publishing a key is the easy part. Making it mean something takes DMARC.

Frequently Asked Questions

What is a DKIM record in simple terms?

It's a public key published in your domain's DNS that lets receiving mail servers verify a cryptographic signature your mail server adds to every message. If the signature checks out, the message genuinely came from your domain and was not altered in transit.

What is a DKIM selector?

An arbitrary label chosen by the sender that identifies which key to use, allowing one domain to publish many keys. It appears in the DNS hostname as <selector>._domainkey.<domain> and in the s= tag of the message's DKIM-Signature header.

How do I find my DKIM selector?

Send yourself an email and view the raw source. In the DKIM-Signature header, the s= tag is your selector. Your mail provider's DNS setup instructions also name it, for example google for Google Workspace or selector1 for Microsoft 365.

Why can't a checker find my DKIM record automatically?

Because DNS offers no way to list names under a subtree. Selectors are arbitrary strings, so a tool can only guess. A checker that probes common selectors covers most hosted platforms, but a blank result means the guesses missed, not that no key exists.

Should DKIM keys be 1024-bit or 2048-bit?

Use 2048-bit RSA. 1024-bit keys still verify at most receivers but fall below NIST's minimum and are treated as weak by security-conscious gateways. If your DNS provider rejects the longer value, split the p= tag into multiple 255-character strings inside one record rather than downgrading.

What does an empty p= tag mean?

It revokes the key. Publishing p= with no value is the defined way to retire a selector. Signatures made with that key stop verifying while the record itself stays in place. If you see an empty p= on a selector you still sign with, your mail is failing DKIM right now.

What is DKIM testing mode (t=y)?

It tells receivers the domain is still testing and that failures should not affect handling. Useful during the first hour of setup, harmful afterwards, because it neutralizes the value of the signature entirely. Remove it once you confirm signatures verify.

Do I need DKIM if I already have SPF?

Yes. SPF breaks whenever a message is forwarded, because the relaying server is not on your list. A DKIM signature travels with the message and still verifies after forwarding. DMARC passes when either aligns, so publishing both is what keeps legitimate mail delivering in the real world.

Does DKIM stop email spoofing completely?

No. A signature can verify perfectly while the visible From address is forged, and DKIM signatures can be captured and replayed to new recipients because they carry no timestamp or recipient binding. DMARC is what ties the signature to the address the recipient actually sees.

What is a DKIM replay attack?

An attacker takes a legitimately signed message and resends it unmodified to new victims. Because nothing changed, the signature still verifies and the message passes authentication. The April 2025 campaign that spoofed [e-mail] worked exactly this way.

How often should I rotate DKIM keys?

Every 6 to 12 months. Publish the new key at a new selector, wait for propagation, switch signing, then revoke the old key with an empty p= rather than deleting it.

Is DKIM free?

Yes. Your mail provider generates the key pair at no cost, and the public key is a DNS record on a domain you already pay for.

Your 30 Minute Action Plan

1. Run your domain through the free DKIM checker. Leave the selector blank if you don't know it. Two minutes.
2. Send yourself an email and read the DKIM-Signature header to confirm your real selector and signing domain. Three minutes.
3. List every service that sends email as you. Five minutes.
4. Generate a 2048-bit key in each platform that is not yet signing. Ten minutes.
5. Publish each record, using CNAME wherever the provider offers it. Five minutes.
6. Remove any t=y you find, and revoke any stale selector properly with an empty p=. Three minutes.
7. Re-run the checker. Confirm Strong or Excellent. Two minutes.
8. Set a calendar reminder for six months out, titled "rotate DKIM keys."

Then finish the job with DMARC, because a signature nobody acts on is just decoration.

If you haven't checked your SPF record yet, do that first. DKIM is the durable half of email authentication, but SPF is the foundation, and DMARC is what turns either of them into actual protection.