What Is a DKIM Record, and How Does It Protect Your Email?

Email was designed in an era when nobody expected anyone to lie about who sent a message. The From: line is just text, and any server on the internet can type your domain into it. That's why phishing works, and it's why mailbox providers now lean heavily on cryptographic proof before trusting a message. DKIM is the piece of that proof that travels with the message itself: a digital signature, checked against a public key you publish in DNS.

This article explains what a DKIM record is, how signing and verification actually work, what each part of the record means, how to generate keys and publish them, and how to test and rotate them. DKIM works alongside SPF and DMARC — this post stays focused on DKIM and links out to the others where they connect.

What Is a DKIM Record?

DKIM (DomainKeys Identified Mail), defined in RFC 6376, lets a sending domain attach a cryptographic signature to each outgoing email. The DKIM record is a TXT record in DNS that holds the public half of the key pair used to create that signature.

When a receiving server gets a signed message, it looks up your DKIM record, uses the public key to check the signature, and learns two things:

1. The message was signed by someone holding your private key — in practice, your mail server or email provider.
2. The signed parts of the message haven't changed since it was signed. Edited headers or a modified body break the signature.

Unlike SPF, which checks the IP address of the server that handed over the message, DKIM is attached to the message itself. That means it survives forwarding, mailing lists that don't modify content, and multi-hop relays — situations where SPF often fails.

How DKIM Works, Step by Step

Signing (on the sending side)

1. Your mail server takes a set of headers (such as From, To, Subject, Date) and the body of the message.
2. It normalizes them using a canonicalization algorithm, so harmless changes like extra whitespace don't break the signature.
3. It hashes the body and stores that hash in the signature.
4. It hashes the selected headers plus the signature header itself, and signs that hash with your private key.
5. It adds a DKIM-Signature header to the message.

A real DKIM-Signature header looks like this:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=s2026;
    t=1790000000; h=from:to:subject:date:message-id:mime-version;
    bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
    b=Fh7bY0kR1dY...signature-data...Q2w==

The important tags are:

• d= — the signing domain. This is the domain claiming responsibility for the message.
• s= — the selector, which tells the receiver which key to look up.
• h= — the list of headers that were signed.
• bh= — the hash of the message body.
• b= — the signature itself.
• a= and c= — the algorithm and canonicalization used.

Verification (on the receiving side)

The receiver reads d=example.com and s=s2026, then builds the DNS name of the key by combining them with the fixed label _domainkey:

s2026._domainkey.example.com

It queries that name for a TXT record, extracts the public key, recomputes the hashes, and checks the signature. The result is recorded as dkim=pass or dkim=fail in the Authentication-Results header the receiver adds to the message.

DKIM Record Syntax

A DKIM record is a TXT record published at selector._domainkey.yourdomain. In a zone file it looks like this:

s2026._domainkey.example.com. 3600 IN TXT ( "v=DKIM1; k=rsa; "
    "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAu4m1b8Yx...first-part-of-key"
    "...second-part-of-key...nQIDAQAB" )

A 2048-bit RSA public key is longer than the 255-byte limit for a single TXT string, so it's split into multiple strings that receivers concatenate. If you're unfamiliar with that limit, the TXT record guide explains it.

The tags you'll see in DKIM records:

Tag	Required?	Meaning
v=DKIM1	Recommended	Version. If present, it must be first.
k=	Optional	Key type: rsa (default) or ed25519.
p=	Required	The base64-encoded public key. An empty p= means the key has been revoked.
t=	Optional	Flags. t=y means the domain is testing DKIM; t=s restricts the key to the exact domain in d=, not subdomains.
h=	Optional	Acceptable hash algorithms, such as sha256.
s=	Optional	Service type, usually email or *.

What selectors are for

Selectors let one domain publish many DKIM keys at once. That's useful because:

• Different services can each have their own key. Your main mailbox provider might use google._domainkey, your marketing platform k1._domainkey, and your helpdesk tool something else.
• Keys can be rotated without downtime. You publish a new key under a new selector, switch signing to it, and remove the old one later.

Selector names have no meaning beyond being a label. Choose something descriptive, like a date (s2026) or a service name.

CNAME-based DKIM

Many providers don't ask you to paste a key at all. Instead, they ask you to create a CNAME, for example:

selector1._domainkey.example.com. 3600 IN CNAME selector1-example-com._domainkey.provider.example.net.

The receiver follows the CNAME to the provider's DNS, where the actual TXT key lives. This lets the provider rotate keys on your behalf without you ever editing DNS again. Microsoft 365 and several email-sending platforms work this way.

How to Generate a DKIM Key Pair

If you use a hosted provider like Google Workspace or Microsoft 365, the provider generates the key for you — you just publish the DNS record they show you (see the guides for Google Workspace and Microsoft 365). If you run your own mail server, you generate it yourself.

With OpenSSL

openssl genrsa -out s2026.private 2048
openssl rsa -in s2026.private -pubout -outform der 2>/dev/null | openssl base64 -A

The first command creates a 2048-bit RSA private key. The second extracts the public key in DER format and base64-encodes it on a single line — that output is what goes after p= in your DNS record. Keep s2026.private on the mail server only and restrict its permissions.

With OpenDKIM

If your server uses OpenDKIM with Postfix, its key tool generates both files and a ready-made DNS record:

opendkim-genkey -b 2048 -d example.com -s s2026 -D /etc/opendkim/keys/example.com/

This writes s2026.private (the signing key) and s2026.txt (the TXT record in zone-file format) into the target directory. You then point OpenDKIM's signing table and key table at the private key and publish the contents of s2026.txt in DNS.

Key size and algorithm

• Use 2048-bit RSA. 1024-bit keys are considered weak and some receivers treat them with suspicion. Keys larger than 2048 bits are harder to fit in DNS and not widely needed.
• Ed25519 (RFC 8463) gives much shorter keys and signatures, but not every receiver verifies it. If you use Ed25519, sign with an RSA key as well so every receiver can verify at least one signature.

How to Check a DKIM Record

You need to know the selector to look up a DKIM record — there's no way to list all selectors for a domain. You can find it in the s= tag of any DKIM-Signature header in mail you've sent.

dig TXT s2026._domainkey.example.com +short

This returns the key record, usually split into several quoted strings. If you get nothing back, either the selector is wrong or the record hasn't been published.

With PowerShell:

Resolve-DnsName -Name s2026._domainkey.example.com -Type TXT

Verifying a real message

The best test is sending a message to a mailbox you control (Gmail works well) and viewing the original source. Look for a line like this in the Authentication-Results header:

Authentication-Results: mx.google.com;
       dkim=pass header.i=@example.com header.s=s2026 header.b=Fh7bY0kR;

dkim=pass with your domain and selector confirms the whole chain is working.

You can also verify a saved message locally in Python with the dkimpy library:

import dkim

with open("message.eml", "rb") as f:
    message = f.read()

if dkim.verify(message):
    print("DKIM signature is valid")
else:
    print("DKIM signature failed verification")

dkim.verify() parses the DKIM-Signature header, fetches the public key from DNS, and checks both the body hash and the header signature. Install it with pip install dkimpy, and save the message as raw source — copying text from a mail client's display will alter it and break the signature.

DKIM, Alignment, and DMARC

DKIM on its own proves that some domain signed the message. It doesn't require that domain to match the visible From: address. A bulk mail platform could sign your newsletters with its own domain, and DKIM would pass — but that pass says nothing about your domain.

DMARC closes that gap with alignment: it only counts a DKIM pass if the d= domain matches (or, in relaxed mode, shares the organizational domain with) the From: domain. That's why every third-party service that sends mail as you should sign with your domain, using a selector you publish. The DMARC guide covers alignment and policies in detail.

This matters more than ever: since February 2024, Google and Yahoo require bulk senders to authenticate with both SPF and DKIM and to publish a DMARC policy, and all senders need at least one of SPF or DKIM.

Rotating DKIM Keys

Private keys can leak, and long-lived keys give attackers more time to try breaking them. Rotating every six to twelve months is a common practice. Using selectors, rotation causes no downtime:

1. Generate a new key pair and publish the public key under a new selector, such as s2027._domainkey.
2. Wait for the record to propagate — at least the TTL of the record, and confirm it with dig.
3. Switch your mail server to sign with the new selector.
4. Keep the old record published for several days, so messages still sitting in queues or being re-verified can still pass.
5. Revoke the old key by publishing it with an empty p= (for example "v=DKIM1; p="), then remove it entirely later.

If you use a CNAME-based setup, your provider handles these steps for you.

Common Mistakes and Best Practices

1. Broken key strings. A missing character, an extra space between split strings, or a line break pasted into the value will cause dkim=fail with a "bad signature" or "key syntax" error. Compare the published record carefully against the source.
2. Publishing at the wrong name. The record must be at selector._domainkey.yourdomain. Dashboards that auto-append the domain can create s2026._domainkey.example.com.example.com if you type the full name.
3. Forgetting third-party senders. Every platform that sends mail as your domain needs its own DKIM setup. Mail that isn't signed with your domain won't align for DMARC.
4. Leaving t=y in place forever. The testing flag tells receivers to treat failures leniently. Remove it once you've confirmed signing works.
5. Using 1024-bit keys. Upgrade to 2048-bit RSA when you rotate.
6. Losing DKIM during a DNS migration. DKIM records, especially CNAME-based ones, are easy to miss when moving providers. Include them in your checklist — see how changing DNS affects email services.
7. Expecting DKIM to survive every modification. Mailing lists that add footers or rewrite subjects break signatures. That's expected behavior, and why DMARC accepts either an aligned SPF pass or an aligned DKIM pass.

---

DKIM Record FAQ

Conclusion

A DKIM record is a public key in DNS, but what it enables is much bigger: every message your domain sends can carry verifiable proof of where it came from and that it hasn't been tampered with. Because the signature travels with the message, DKIM holds up in forwarding scenarios where SPF falls apart, which makes it the more dependable half of email authentication for DMARC.

Getting it right comes down to a few habits. Use 2048-bit keys, publish them at the correct selector name, make sure every service that sends as your domain signs with your domain, and rotate keys on a schedule using new selectors. Then verify with a real message rather than assuming — a dkim=pass in the headers is the only confirmation that counts.

Here are some useful references for going deeper on DKIM:

1. RFC 6376: DomainKeys Identified Mail (DKIM) Signatures — the core DKIM specification, including record tags and verification.
2. RFC 8463: A New Cryptographic Signature Method for DKIM — adds Ed25519 signing to DKIM.
3. RFC 8301: Cryptographic Algorithm and Key Usage Update to DKIM — deprecates SHA-1 and sets minimum RSA key sizes.
4. Google Workspace Admin Help: Email sender guidelines — Gmail's authentication requirements for senders.
5. MXToolbox: DKIM Lookup — a free tool to check a DKIM record by domain and selector.