What Is DKIM? A Complete Guide to Email Signing

DKIM (DomainKeys Identified Mail) is an email authentication protocol that uses public-key cryptography to sign outgoing messages. Receiving servers verify that signature against a public key published in your DNS, confirming the email came from your domain and wasn't altered in transit. It's defined in RFC 6376.

Google reported that requiring authentication on bulk senders in early 2024 cut unauthenticated traffic to Gmail users by 65% within months (Google Security Blog, 2024). DKIM sits at the center of that shift; if your mail isn't signed, large mailbox providers now assume it's suspicious by default.

Table of Contents

What is DKIM?

DKIM is a cryptographic signature attached to every email you send. The sending server signs a chosen set of headers (plus the body) with a private key; the receiving server fetches the matching public key from your DNS, recomputes the hash, and checks that the two match. If they do, the message is authentic.

The spec has been stable since 2011 when RFC 6376 superseded the original RFC 4871. It works with SPF and DMARC, but it answers a different question; SPF asks "is this IP allowed to send?" while DKIM asks "did the claimed domain actually sign this exact message?". That distinction matters because SPF breaks when mail gets forwarded, whereas a DKIM signature survives most forwarding paths (unless a mailing list rewrites the body).

Think of it like a wax seal on a letter. Anyone can copy the envelope, but forging the seal requires the private key sitting on your mail server.

How does DKIM work?

Signing and verifying a DKIM message takes maybe 20 milliseconds end-to-end, but there's a lot happening under the hood. Here's the plain-English version.

When you send an email, your mail server (or your ESP, if you use one like Mailneo) does four things:

1. Picks a canonicalized version of the headers and body (more on canonicalization below).
2. Runs that content through a hash function, usually SHA-256.
3. Encrypts the hash with the private key tied to a specific selector.
4. Attaches the result as a DKIM-Signature: header on the outbound message.

The receiving server, on the other end, does the reverse. It reads the DKIM-Signature header, notes the domain (d= tag) and selector (s= tag), looks up <selector>._domainkey.<domain> in DNS, pulls down the public key, decrypts the signature, and compares hashes. Match = pass. Mismatch = fail. Missing key = permfail.

Gmail's sender guidelines require DKIM signing for any sender pushing more than 5,000 messages per day to personal Gmail accounts; Yahoo adopted the same bar in February 2024. That isn't a suggestion anymore; it's enforced at the SMTP layer.

The selector explained

A selector is just a label. It lets you publish multiple DKIM keys for the same domain, which matters when you send through more than one provider (your ESP, your transactional mail service, your help desk tool, your payroll system, and so on). Each gets its own selector, each publishes its own public key, and they don't collide.

A typical selector looks like google2048 or mailneo202604 or just s1. The DNS record lives at <selector>._domainkey.<yourdomain.com>.

What does a DKIM record look like?

A DKIM public-key record is a TXT record in DNS. Here's an example:

Host: mailneo202604._domainkey.example.com
Type: TXT
Value:
  v=DKIM1;
  k=rsa;
  p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtvX9kP2yT8k...
    [base64 public key continues here, typically 400+ characters for 2048-bit]
    ...nQIDAQAB

The tags break down as follows:

Tag	Required?	What it means
v=DKIM1	Required	Version, always this exact value.
k=rsa	Optional	Key type. RSA is the default; Ed25519 is defined but barely supported in the wild.
p=...	Required	The base64-encoded public key itself. An empty p= revokes the key.
t=y	Optional	Test mode. Remove once signing is verified; some receivers ignore signatures while t=y is set.
s=email	Optional	Service type. Leave it out unless you have a specific reason.

The email you send carries a matching DKIM-Signature header that looks like this:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
    d=example.com; s=mailneo202604;
    h=from:to:subject:date:message-id;
    bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=;
    b=K9x3n...signature...Ql==

The h= tag lists which headers got signed; bh= is the body hash; b= is the actual signature. If you want to see what yours looks like right now, send a test to yourself and view the raw source in Gmail ("Show original"), or use Mailneo's DKIM generator tool to produce a key pair and the DNS record in one shot.

Simple vs. relaxed canonicalization

The c= tag tells the receiver how to clean up whitespace and capitalization before hashing. Two choices: simple (exact match, zero tolerance) or relaxed (collapse extra whitespace, lowercase header names).

relaxed/relaxed is what you want in almost every case. Simple canonicalization breaks if any intermediate server adds a space or rewraps a line, which happens constantly. I've seen maybe one legitimate reason to use simple in five years, and it was a forensic investigation; skip it.

Why does DKIM matter for deliverability?

DKIM is a prerequisite for DMARC, which is the policy layer that actually tells mailbox providers what to do with unauthenticated mail. No DKIM means no durable DMARC pass on forwarded messages, which means fragile deliverability the minute your email hits a mailing list or corporate gateway.

Valimail's 2024 Email Fraud Landscape report found that roughly 70% of domains still don't have a DMARC enforcement policy, and a sizable chunk of those lack DKIM entirely. That's a lot of unprotected domains; it's also a big reason brand-impersonation phishing is still profitable.

Two specific deliverability effects you'll feel:

• Without DKIM alignment, DMARC can't pass when SPF breaks (forwarding, auto-responders, shared hosting). Your reports will show policy failures even for legitimate mail.
• Microsoft and Google both feed DKIM signals into reputation scoring. A consistently-signed domain builds reputation faster than an unsigned one, and reputation is what decides inbox vs. promotions vs. spam.

M3AAWG's Sender Best Common Practices (v3.0, 2022) puts it bluntly: senders should sign every outbound message and rotate keys regularly. Not signing in 2026 is an outlier position; it's also the easiest way to hand criminals your domain for spoofing.

[MY EXPERIENCE: e.g., "describe a DKIM key rotation scare you handled, or helping a customer diagnose a broken DKIM signature"]

How do you set up DKIM correctly?

Rough order of operations, assuming you're using an ESP (which you probably should be):

1. Generate a 2048-bit RSA key pair. RFC 8301 deprecated 1024-bit keys in 2018; M3AAWG backs that up. Some DNS providers still choke on the longer record and need the value split into two quoted strings; that's fine, receivers concatenate them.
2. Pick a selector name with a date or version in it (e.g., s202604). You'll thank yourself during rotation.
3. Publish the public key as a TXT record at <selector>._domainkey.<yourdomain.com>. Propagation usually takes under an hour, but give it up to 24.
4. Store the private key on the sending server (or in your ESP's config). Never commit it to git; never email it to yourself.
5. Send a test message to a mailbox you control. View the raw headers. Look for dkim=pass in the Authentication-Results block.
6. Check alignment. The domain in From: has to match (or be a subdomain of) the d= tag for DMARC to consider DKIM aligned.

[SCREENSHOT: e.g., "DKIM TXT record in DNS with the p= value redacted"]

If you're on Mailneo, the DKIM record appears in your domain settings the moment you add a sending domain; you copy it into your DNS, click verify, and we signal pass/fail. The setup guide for SPF, DKIM, and DMARC together covers the full workflow. For a broader view of how these three protocols interact, see SPF vs. DKIM vs. DMARC or the deeper pieces on what is SPF and what is DMARC.

DKIM alignment (relaxed vs. strict)

DMARC requires that the DKIM signing domain (d=) align with the From: header domain. Two modes:

• relaxed (the default): subdomain matches parent. Signing with d=mail.example.com aligns with From: sales@example.com.
• strict: exact match required. Signing with d=mail.example.com will fail alignment against example.com.

Unless you have a very specific reason (some highly regulated industries use strict for tighter scoping), leave alignment at relaxed. It makes cross-subdomain sending work without weird failures.

DKIM key rotation and common mistakes

Keys should rotate. DKIM.org's operator recommendations and M3AAWG both recommend rotating at least every six months; quarterly is better if you're a high-volume sender. The reason is simple: old keys sit in zone-transfer history, on backup tapes, in cached DNS records; a compromise you don't know about is more likely the longer a key lives.

Rotation works by publishing a new selector (e.g., s202607), updating the signing config to use it, keeping the old selector live for a few days so in-flight mail still verifies, then revoking the old public key by replacing its p= value with an empty string.

Common mistakes I see over and over:

• Publishing the private key instead of the public key. Sounds absurd; happens every month. The p= value is the public half of the pair.
• Using 1024-bit keys because "the DNS provider doesn't support longer TXT values." All the major providers do now, usually by splitting into multiple quoted strings; if yours doesn't, change providers or use a CNAME-based ESP setup.
• Forgetting the trailing == or corrupting the base64 value when pasting. One dropped character breaks every signature.
• Leaving t=y in production. That's test mode; some receivers ignore signatures while it's on.
• Signing too few headers. The h= tag should cover at least From, To, Subject, Date, and Message-ID. Signing only From: is technically valid but makes the signature trivially bypassable.

The Mailneo email deliverability guide walks through the full authentication stack and what to do when things go sideways.

[ORIGINAL DATA: percentage of Mailneo customer domains on 2048-bit keys vs legacy 1024-bit, with the deliverability delta observed between the two groups]

Key takeaways

• DKIM uses a private key on your mail server to sign outgoing messages; receivers verify against a public key in your DNS (per RFC 6376).
• Google and Yahoo require DKIM for any sender over 5,000 messages per day to their users, enforced since February 2024.
• 2048-bit RSA keys are the current standard; 1024-bit was deprecated by RFC 8301 in 2018.
• Rotate keys every three to six months, using dated selectors so overlap is painless.
• Use relaxed/relaxed canonicalization and relaxed DMARC alignment unless you have a specific reason not to.

Frequently asked questions

Can I have more than one DKIM record on the same domain?

Yes. Each sending service publishes its own selector, so you can have a dozen DKIM records on one domain without conflict. They live at different <selector>._domainkey.<domain> subdomains, so DNS never sees them as competing.

Does DKIM encrypt my email?

No. DKIM only signs the email; the contents remain readable by any server that handles the message. For encryption in transit, you need TLS (which most providers negotiate automatically); for end-to-end encryption, you need S/MIME or PGP. See the email authentication glossary entry for how these pieces relate.

What happens if my DKIM signature fails?

It depends on your DMARC policy. If DMARC is at p=none, failing DKIM usually doesn't block delivery by itself (SPF may still pass). At p=quarantine or p=reject, a DKIM failure with no aligned SPF means the message gets filtered to spam or bounced entirely. Check the DKIM glossary entry for the full interaction chart.

How long should a DKIM key be?

2048 bits for RSA. 1024 is deprecated. Ed25519 is in the spec but poorly supported by receivers, so RSA 2048 is the safe choice today.

Is DKIM enough on its own, or do I need SPF and DMARC too?

You need all three. DKIM proves a message wasn't altered; SPF proves it came from an authorized IP; DMARC ties those results to a policy and gives you reporting. The SPF vs. DKIM vs. DMARC comparison explains how each layer covers a different failure mode.

Related resources

• DKIM generator tool. Generate a 2048-bit key pair and DNS record in one step.
• DKIM glossary entry. Quick reference with tag definitions.
• DNS record glossary. The TXT/CNAME basics DKIM depends on.
• SPF vs. DKIM vs. DMARC. How the three authentication standards fit together.
• How to set up SPF, DKIM, and DMARC. Full step-by-step for a new sending domain.
• Email deliverability guide. The broader picture beyond authentication.