DKIM Record Checker
Find the selector, then check the key

What is a DKIM record, and what does this checker test?

DKIM stands for DomainKeys Identified Mail, defined in RFC 6376. Your mail server holds a private key and uses it to sign each outgoing message: it hashes the body and a chosen set of headers, encrypts the result, and adds a DKIM-Signature header. The matching public key sits in your DNS. A receiver reads the signature, fetches that key, and checks the maths. If it adds up, the message has not been altered in the signed parts since it left you.

Here is a record with every part named. Two of the five are not written down at all, and they still apply:

Why you need a selector before you can look anything up

This is the part that makes DKIM harder to check than SPF. An SPF record always sits on the domain itself. A DKIM key does not: its DNS name is built from two tags inside the signature of an actual message.

So a DKIM check has two halves: find the name, then judge what is published there. This tool does both, and it tells you which half failed. Authentication is also the part of sender reputation you control outright rather than earn slowly, which is worth reading alongside how receivers build an IP reputation score.

How to find your DKIM selector

Three methods, and only the first is certain.

1. Read it from a real message — the only method that cannot be wrong

Send yourself an email from the system you are checking, then open the raw source. In Gmail that is the three-dot menu and Show original; in Outlook, View then Message source. Find the DKIM-Signature header and read two tags: s= is the selector, d= is the signing domain. Those two build the DNS name. Paste that header into the box above and both are extracted for you — along with a=, which tells you the algorithm actually used, and h=, which tells you which headers were protected. For a full reading of every authentication result in a message, our email header analyzer takes the whole thing.

2. Let the published list be searched

Leave the selector blank above. Most platforms use a fixed, documented selector, so a search finds the key in one query. Here is the list this tool tries, and where each name comes from. Every attribution was taken from the provider’s own documentation, not from another checker:

3. Check your platform’s DNS setup page

Every provider shows the exact records it wants you to publish. This is the slowest route but it is also the one that tells you whether you were supposed to publish two selectors and only published one — a specific and common Microsoft 365 failure.

How to check a DKIM record

1. Enter the domain that appears after the @ in your address. If your platform signs with its own domain, use that one instead — the key lives wherever d= points.
2. Leave the selector blank the first time. If the search finds selectors, you also learn which platforms are signing for this domain.
3. Read the key length before anything else. It is decoded from the key itself, not read off a tag, so it is the real number.
4. Check the flags. A record can be flawless and still contribute nothing while t=y is set.
5. Re-check after editing DNS. Results here are cached for fifteen minutes, and your record’s own TTL keeps the old value alive at receivers for longer.

Checking it from a terminal

Query the full name, including _domainkey. These return the raw value, which is the way to see whether your DNS host stored the quoting as part of the key rather than as a delimiter.

To read the other records a mail setup depends on — the MX hosts, the _dmarc record, or the SPF record on the same domain — our DNS lookup tool returns them with their TTLs.

Reading the result: tags, defaults and key length

A DKIM key record is short, and most of what governs it is never written down. RFC 6376 §3.6.1 applies a default to every tag you omit, so two records that look different can behave identically — and one that looks complete can be carrying a default you did not intend. The table in the result above marks which values you published and which are defaults in force.

The only tag that is required

p=, the public key, is the single REQUIRED tag. Everything else has a default. That has one consequence worth remembering: p= with nothing after it is not a mistake or a truncation. RFC 6376 §3.6.1 says “an empty value means that this public key has been revoked”. It is the correct way to retire a key — you empty it rather than delete the record, so verifiers get a definite answer instead of a lookup failure.

What the key length actually tells you

The bit count in the result is decoded from the key material itself. RFC 8301 §3.2 sets the thresholds: signers “MUST use RSA keys of at least 1024 bits” and “SHOULD use RSA keys of at least 2048 bits”, while verifiers “MUST NOT consider signatures using RSA keys of less than 1024 bits as valid”. So under 1024 is a hard failure by rule; 1024 is valid but below what the specification asks for; 2048 is the recommendation. The large receivers have settled on the same line rather than a stricter one: Google requires “a DKIM key of 1024 bits or longer” and recommends 2048, and Yahoo requires “1024 bits or greater” and also recommends 2048. So a 1024-bit key is not being refused today — treat the upgrade as a rotation task rather than an emergency, and note that the checkers competing for this search disagree with each other about it, one publishing a 1024-bit minimum and another calling anything under 2048 weak.

An ed25519 key breaks the comparison. RFC 8463 §4.2 notes that “since the key is 256 bits long, the base64 text is 44 octets”. That 256 is not weaker than RSA-2048 — it is a different kind of number, and it is also why a checker that measures every key the same way reports ed25519 keys incorrectly.

Five things that quietly break DKIM

None of these produce an obvious error. In every case the record looks reasonable and the mail stops being trusted.

1. Testing mode left switched on

The worst of the five, because the record is otherwise perfect. RFC 6376 §3.6.1 states that with t=y set, verifiers “MUST NOT treat messages from Signers in testing mode differently from unsigned email, even should the signature fail to verify”. Read that carefully: not “treat with suspicion” but “treat as unsigned”. A valid key with t=y cannot contribute a DMARC pass. It belongs in a rollout and nowhere else.

2. Two records at one selector, mistaken for one split record

These look nearly identical in most tools and mean opposite things. One record published as several character-strings is normal — a DNS character-string cannot exceed 255 octets and a 2048-bit key does not fit, so it must be split, and verifiers join the pieces with nothing added. Two separate records at the same selector is fatal: RFC 6376 §3.6.2.2 says “TXT RRs MUST be unique for a particular selector name; that is, if there are multiple records in an RRset, the results are undefined”. Undefined means different receivers may pick different records, so your mail passes for some recipients and fails for others. It usually happens during a migration when the new key is added beside the old instead of replacing it.

3. The key that decodes to nothing

A 2048-bit key is roughly 400 characters of base64, and DNS control panels handle that badly. Some require you to split and quote it yourself; some split it for you; some have a field limit that truncates it without saying so. The three failure signatures are a key that is valid base64 but not a readable key structure, a key with literal quote marks stored inside the value, and a key with a space inserted at the join. All three leave a record that looks present and cannot be used.

4. A delegation that stopped working

Most platforms have you publish a CNAME at the selector and keep the real key on their side. That is sound, and it introduces two failure modes of its own: publishing a TXT where a CNAME belongs, and a DNS provider that proxies or flattens the CNAME so the lookup returns something other than the intended target. Microsoft documents the second case specifically for proxied records. This tool prints the whole chain so you can see where it ends — and for a delegated setup, key length and rotation are the platform’s decision rather than yours.

5. An algorithm nobody accepts any more

RFC 8301 §3.1 is blunt: “rsa-sha1 MUST NOT be used for signing or verifying”, and signatures using it “have permanently failed evaluation”. If your record’s h= tag lists only sha1, every signature made under it fails by rule. Listing sha1 alongside sha256 is not fatal, but it buys nothing and marks the record as old. If the mail itself is being refused rather than just unauthenticated, the cause may be reputation instead — the comparison in our guide to tools that diagnose deliverability covers where each kind of failure shows up.

DKIM, SPF and DMARC: why a valid key can still fail

A DKIM signature can verify perfectly and do nothing for you, because DMARC asks a second question. Validity is whether the maths checks out. Alignment is whether the signing domain in d= matches the domain your recipient sees in the From: header — the same organisational domain under relaxed alignment, an exact match under strict. Platforms that sign with their own domain produce valid signatures that DMARC will not count. Paste your signature header above and the comparison is made for you; our DMARC checker shows which alignment mode your policy asks for.

One honest limitation of the comparison above: it treats the last two labels of a name as the organisational domain. That is right for example.com and mail.example.com, and wrong for a multi-label public suffix such as co.uk, where the real organisational domain is three labels. Getting that exactly right needs the Public Suffix List, which is more machinery than one tool page should carry. If your domain sits under a suffix like that, read the verdict as a strong indication rather than a ruling.

Why DKIM is the half that matters more

SPF and DKIM are often described as interchangeable belts and braces. The current DMARC specification does not treat them that way. RFC 9989, published in May 2026, states in §7.4 that domains publishing p=reject “MUST NOT rely solely on SPF to secure a DMARC pass and MUST apply valid DKIM signatures to their messages”. That is a requirement, not advice. The reason is practical: SPF authenticates the connecting server, so it breaks the moment a message is forwarded, while a DKIM signature travels with the message and survives the hop.

So the two are not alternatives. SPF is the one that fails on forwarding; DKIM is the one that fails when a message is modified. If you have not yet checked the other half, our SPF record checker counts the ten DNS lookups SPF is limited to and names the term that breaks the limit.

What the large receivers require

The three large consumer providers have each drawn a line, and the wording differs in ways worth reading carefully.

Google operates two tiers. Every sender, at any volume, must “set up SPF or DKIM”. Senders of more than 5,000 messages a day to Gmail accounts must “set up SPF and DKIM” plus DMARC, with the From: domain aligned to either the SPF or the DKIM domain. Those requirements took effect on 1 February 2024. Google also states a key length: “Sending to personal Gmail accounts requires a DKIM key of 1024 bits or longer”, with 2048 recommended.

Microsoft is the one that changed most recently, and it is stricter than Google in one specific way. For senders of 5,000 or more messages a day to Outlook.com and its other consumer services, Microsoft requires that “both SPF and DKIM checks must pass” — not either one — while requiring only that at least one of them be aligned. Non-compliant mail was sent to the junk folder from 5 May 2025, and rejection is now live: Microsoft publishes a dedicated page for the 550 5.7.515 bounce a failing sender receives. If your DKIM has been half-configured for years and nothing appeared to break, this is the change that breaks it.

Yahoo asks bulk senders for both SPF and DKIM and a DMARC policy of at least p=none, and requires “a DKIM key length of 1024 bits or greater”, recommending 2048. Unlike the other two, Yahoo deliberately publishes no volume threshold, stating plainly that it “will not specify a volume threshold”. Any guide quoting you a Yahoo number has invented it.

One operational detail from Microsoft’s own DKIM documentation that most guides skip: every sending subdomain needs its own record, and both selector1 and selector2 must exist or key rotation cannot happen. Leave the selector blank above and this tool tells you whether both are actually published.

What DKIM does not prove

Worth being precise about, because DKIM is routinely described as protection against spoofing and it is narrower than that.

It does not prove who sent the message. A signature proves that the holder of the private key signed this content, and that the signed parts have not changed. It says nothing about the envelope, nothing about the connecting server, and nothing about intent. The specification says so itself: RFC 6376 §8.6, “Replay/Spam Attacks”, notes that “a message signed by a particular domain can be sent to many recipients and still verify correctly at each recipient’s mail system”. Nothing in a signature ties it to one delivery.

It does not protect the headers you did not sign. The h= tag inside a signature lists which headers were covered. Anything absent from that list can be added or altered in transit without breaking the signature. The same applies to the l= tag, which limits how much of the body was signed — text appended after that limit is unsigned and unprotected. RFC 6377 calls l= unworkable for MIME messages and discourages its use.

It does not survive a mailing list unaided. RFC 6377 lists what list software does that invalidates a signature: adding a subject prefix, appending a footer, replacing Reply-To or Sender, reordering or stripping MIME parts. ARC exists to carry the original authentication result across such a hop, but honouring ARC is optional for the receiver. No change to your DNS fixes this, which is worth knowing before you spend an afternoon editing a record that was already correct.

It does not make you trusted. Authentication and reputation are separate. A correctly signed message from a domain with poor sending history still lands in spam. If your record checks out and mail is still being refused, the next place to look is the reputation of the address you send from — our sender reputation check covers the signals receivers weigh, and the walkthrough for diagnosing an SPF, DKIM or DMARC failure starts from what the receiver told you rather than from your DNS.

Frequently asked questions about DKIM records