DKIM Record Checker

What DKIM Is and Why It Matters

DKIM, short for DomainKeys Identified Mail, is an email authentication standard defined in RFC 6376. It lets a receiving mail server verify two things about a message: that it was genuinely authorized by the domain claiming to send it, and that the signed parts were not altered along the way. Your sending server signs each outgoing message with a private key it keeps secret, and receivers fetch the matching public key from your DNS to check that signature. The record the checker above looks up is that public key, published as a TXT record in your DNS zone.

For deliverability, DKIM is one of the strongest signals you control. Mailbox providers weigh it, together with SPF and DMARC, when deciding whether mail from your domain is trustworthy. A valid DKIM signature that aligns with your visible From address is also what makes DMARC pass reliably, even when a message is forwarded, something SPF frequently cannot survive. If the checker reported a problem, the sections below explain what each part means and how to fix it.

How the DKIM Signing Flow Works

When your mail server or email service provider sends a message, it adds a header called DKIM-Signature. The signer first normalizes the message, a step called canonicalization, so harmless changes such as whitespace adjustments do not break verification. It then computes a hash of the message body and stores it in the signature's bh= tag, hashes a chosen set of headers together with the signature header itself, and signs that hash with your private key. The resulting signature becomes the b= tag. The header also records which domain signed the message in d=, which selector to use in s=, and which headers were covered in h=.

On arrival, the receiving server reads those tags, builds the DNS name by joining the selector, the literal label _domainkey, and the signing domain, and fetches the TXT record published there. With the public key, the receiver checks the signature against hashes it computes itself. If they match, DKIM passes. If anything covered by the signature changed in transit, or the DNS record is missing, malformed, or holds the wrong key, DKIM fails. The private key never appears in DNS; publishing the public half is completely safe.

Selectors: Why They Exist and How to Find Yours

A selector is the label that tells receivers where in your DNS to find the right public key. It forms the first part of the record's hostname: in mail._domainkey.example.com, the selector is mail. Selectors exist so one domain can publish many keys at once; without them, seamless key rotation would be impossible and only one service could ever sign for the domain.

The most reliable way to find your selector is to inspect a real message. Send yourself an email from the system you want to test, open the full message headers (often called Show Original), locate the DKIM-Signature header, and read its s= tag. That selector, combined with the domain in the d= tag, is exactly what the checker above asks for.

Provider conventions help when you cannot send a test message. Google Workspace uses the selector google by default, with the key generated in its admin console. Microsoft 365 uses two selectors, selector1 and selector2, published as CNAME records that point into your tenant's onmicrosoft.com namespace. Amazon SES generates three CNAME records with randomized selector names when you enable its managed DKIM setup, which lets it rotate keys on your behalf. Marketing and transactional platforms each follow their own pattern, but every legitimate provider shows the exact hostnames and values during domain verification.

A Worked Example: Reading a Real DKIM Record

Suppose the checker queries mail._domainkey.example.com and finds this TXT record, with the key shortened for readability: v=DKIM1; k=rsa; t=s; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArZ3kQm9X...IDAQAB.

v=DKIM1 declares the record version; it is optional, but when present it must come first. k=rsa states the key type. RSA is the default, so many records omit this tag, but it becomes essential if you publish an Ed25519 key instead. t=s is an optional flag that enables strict mode: the signing identity in the message must use the d= domain itself, not one of its subdomains, which stops subdomains from borrowing the key. Finally, p= carries the public key itself as base64 text. It is by far the longest part of the record and the one most often damaged by copy-and-paste mistakes, stray quotation marks, or line breaks added by a DNS control panel.

The hostname matters as much as the value. The record must live at the selector, then the fixed label _domainkey, then the signing domain. If a message is signed with d=example.com and s=mail but the key was published under a different selector, or under a subdomain by mistake, verification fails even though the record itself is flawless. When the checker reports that no record was found, a misplaced hostname is one of the first things to rule out.

DKIM Record Tag Reference

The table below covers the tags you may encounter inside a DKIM TXT record in DNS. These are distinct from the tags found in the DKIM-Signature header of a message, even though some letters repeat. Most records contain only v and p; the rest appear when finer control is needed.

Key Types and Lengths: RSA and Ed25519

RFC 8301 modernized DKIM's cryptography. Verifiers must be able to validate RSA keys from 1024 up to 4096 bits, signers must use at least 1024 bits, and 2048 bits is the recommended size for new keys. The same document retired the old SHA-1 signing algorithm, so modern signatures use rsa-sha256. A 1024-bit key still verifies everywhere, but its security margin is thin by current standards, so treat any 1024-bit key the checker finds as a candidate for rotation.

RFC 8463 added a second key type, Ed25519, which signs with the ed25519-sha256 algorithm. Its public keys are dramatically shorter than RSA keys, short enough to fit inside a single DNS string, which sidesteps the record-splitting headaches that 2048-bit RSA keys can cause. The catch is that verifier support is still not universal. The safe pattern is dual signing: publish an Ed25519 key under one selector and an RSA key under another, sign every message with both, and let each receiver verify whichever it understands.

CNAME Delegation to Email Service Providers

Many providers ask you to publish CNAME records rather than TXT records for DKIM. Instead of placing the key itself in your zone, you create an alias such as em123._domainkey.example.com pointing to a hostname in the provider's DNS, where the actual TXT record lives. DNS resolution follows the alias automatically, so verifiers and the checker above read the provider's record as if it were yours. The advantage is operational: the provider holds the private key and can rotate it whenever needed without asking you to change DNS again.

Delegation comes with a few rules. A hostname carrying a CNAME cannot carry any other record, so you cannot publish your own TXT at the same name. The alias must point to a target that actually resolves; a typo in the target silently breaks signing for that selector. And watch for control panels that append your domain automatically, producing doubled hostnames like em123._domainkey.example.com.example.com. If a delegated record fails in the checker, verify the full hostname and the CNAME target first.

Rotation and Revocation

DKIM keys should not live forever. A private key can leak through a compromised server, a departing employee, or a vendor you stop using, and an attacker holding it can sign mail as your domain until the public key leaves DNS. Rotation is straightforward because selectors exist: generate a new key pair, publish the new public key under a new selector, switch your signer to it, then leave the old record up briefly so messages still in transit can verify. After that overlap, retire the old key. Providers using CNAME delegation typically rotate for you automatically.

Retiring a key properly means revoking it. RFC 6376 defines a record with an empty p= value, such as v=DKIM1; k=rsa; p=, as an explicit statement that the key has been revoked. This is cleaner than deleting the record outright: a missing record looks the same as a DNS outage or a typo, while an empty p= tells every verifier, unambiguously, that signatures from this selector must no longer be trusted. After a suspected compromise, publish the empty-key record immediately rather than waiting for a scheduled change.

Common DKIM Failures and How to Fix Them

Publishing problems are the most frequent. A 2048-bit RSA public key, encoded as base64, is longer than the 255-character limit of a single DNS string, so it must be split into multiple quoted strings that resolvers join back together; most DNS hosts handle this automatically, but pasting a key with line breaks or a truncated tail corrupts it. Two TXT records under the same selector hostname will also break verification, as will a record published at the wrong hostname. The checker above flags syntax damage in the p= value, which is the usual culprit.

A correct record can still produce failing signatures. Anything that modifies a signed message in transit, like mailing-list software adding a footer or a security gateway rewriting links, invalidates the body hash and fails DKIM. Forwarding through such systems is the classic cause of intermittent failures. Separately, DKIM can pass while DMARC fails: if your provider signs with its own domain rather than yours, the d= value does not align with your From address, and DMARC ignores the otherwise valid signature. The fix is almost always enabling custom-domain signing with your provider, usually via CNAME delegation.

Finally, check the small operational details. A t=y flag left over from setup tells receivers the domain is merely testing DKIM, which can soften how much trust the signature earns. Deleting an old selector too soon after rotation fails messages still in transit. And remember DNS caching: after fixing a record, verifiers may see the old version until the TTL expires, so retest after that window.

Frequently asked questions

How do I find my DKIM selector?

Send yourself a message from the system you want to test and open the full headers. The s= tag inside the DKIM-Signature header is your selector, and the d= tag is the signing domain; together they are what the checker above needs. Provider documentation also lists defaults, such as google for Google Workspace or selector1 and selector2 for Microsoft 365.

Can one domain have multiple DKIM records?

Yes. Every key lives under its own selector, so a domain can publish as many keys as it has selectors, which is how several services sign for one domain side by side. What you must avoid is two TXT records under the same selector hostname, which makes the lookup ambiguous and breaks verification.

What does an empty p= value mean?

A record like v=DKIM1; p= means the key has been deliberately revoked, a meaning defined in RFC 6376. Signatures made with that key will fail permanently, which is the intended outcome after a compromise. It is clearer than deleting the record, because a missing record can also be a DNS error.

Should I use a 1024-bit or a 2048-bit RSA key?

Choose 2048 bits for any new key; RFC 8301 recommends it, and 1024 bits is only the minimum that must remain supported. The one practical wrinkle with 2048-bit keys is that they exceed a single 255-character DNS string, which most DNS hosts split automatically.

Does passing DKIM guarantee my mail reaches the inbox?

No. DKIM proves that a message is authentic and unmodified, not that recipients want it. Mailbox providers also weigh sender reputation, list quality, engagement, and content. Treat DKIM, alongside SPF and DMARC, as a requirement for good deliverability rather than a guarantee of it.

Why does DKIM pass but DMARC still fail?

DMARC requires alignment: the domain in the signature's d= tag must match your visible From domain, either exactly under strict alignment or by sharing the same organizational domain under the default relaxed mode. If your provider signs with its own domain, the signature is valid but unaligned, so DMARC disregards it. Enable custom-domain signing with your provider, typically through CNAME delegation, so the signature carries your domain.

How often should I rotate DKIM keys?

There is no fixed interval in the standards, but rotating on a regular schedule limits the damage if a key ever leaks. Rotate immediately if you suspect compromise or stop working with a vendor that held a key. Providers using CNAME delegation usually rotate automatically, with no action needed from you.