DKIM Record, in Practice: Every Warning Explained
A DKIM record that a checker calls valid can still be switched off. A testing flag and an empty key field both do it, and both look unremarkable.
A DKIM record is a TXT record at selector._domainkey holding the public key as tag-value pairs. Two of those tags can disable it while leaving the record valid: t=y puts the domain in testing mode, so receivers treat signed mail as unsigned, and an empty p= is an explicit revocation of the key.
Key takeaways
- RFC 6376 says an empty p= value means the key has been revoked, so a syntactically perfect record can instruct every receiver to fail your signatures.
- The t=y flag means the domain is testing, and verifiers must not treat those messages differently from unsigned mail whether or not the signature checks out.
- The signature header matters as much as the key record: h= sets which fields are protected and l= caps how much of the body is covered.
- DMARC grades whether DKIM passed for your domain, so a platform signing with its own domain produces a valid signature that aligns with nothing.
Reviewed and updated August 11, 2026
A DKIM record that a checker calls valid can still be doing nothing. The two most common ways that happens are a flag that tells receivers to ignore the result and an empty key field that formally revokes it, and both render as an unremarkable line of text in a DNS panel. Neither looks like a problem until you read the tags.
This is the practice layer of email authentication. If you want the concept first, the DKIM definition covers what the signature proves and what it does not. What follows is the record itself: the tags it can carry, the warnings a validator emits about them, and the ones worth acting on when you are sending outbound from more than one domain.
What is actually in the record
A DKIM public key lives in a TXT record at <selector>._domainkey.<domain>, and its contents are a set of tag-value pairs defined by RFC 6376. Most records you meet carry three or four of them.
v=DKIM1 declares the version and, when present, has to come first. k=rsa names the key type, and unrecognised types are ignored by verifiers rather than treated as errors. p= carries the public key itself as base64, and it is the only required tag. Everything else is optional and defaults to something sensible.
The optional tags are where the interesting failures live. t= carries flags, and the flag y means the domain is testing DKIM. The specification is blunt about the consequence: verifiers "MUST NOT treat messages from Signers in testing mode differently from unsigned email, even should the signature fail to verify." A record with t=y is not a working DKIM record, it is a rehearsal, and platforms sometimes leave it set after an onboarding wizard finishes.
s= constrains the record to a service type, with email and * as the defined values. n= is a free-text note for administrators that no program interprets, which makes it a good place to record which platform owns a selector and a bad place to put anything load-bearing.
The revocation case deserves its own sentence because it is silent. Per the specification, on the p= tag, "An empty value means that this public key has been revoked." So v=DKIM1; k=rsa; p= is a syntactically perfect record that instructs every receiver on the internet to fail signatures made with that key.
- Receivers fetch the key and verify
- Signature can align for DMARC
- This is the only one of the three that helps you
- Receivers must treat the message as unsigned
- A failure is not counted against you, and neither is a pass
- Usually a leftover from setup
- An empty p= is an explicit revocation
- Signatures with that key fail by design
- Looks identical to a truncated paste
The warnings, and which ones matter
No record found at that name. Almost always a selector mismatch rather than a missing record. The checker asked about the selector you typed; the signature is being made with a different one. Read the DKIM-Signature header on a real message, take the s= value from it, and query that.
The key is shorter than 1024 bits. Treat this as real. RFC 8301 requires that "Signers MUST use RSA keys of at least 1024 bits for all keys" and recommends at least 2048. Short keys exist because older DNS tooling could not fit longer ones into a single string, which the same document explains: the software "only handles a single 256-octet string in a TXT record, and RSA keys significantly longer than 1024 bits don't fit in 256 octets."
Multiple TXT records at one name. A DNS name answering with two DKIM records is ambiguous, and the resolver returns both. This happens when a platform is re-onboarded and publishes a second record instead of replacing the first. Delete the one you are not using rather than leaving the receiver to choose.
Syntax error, usually at the end of the key. A truncated base64 value is the signature of a copy-paste that hit a field length limit, or of a long key published as one string when the panel needed several. The tell is that the record looks right and stops abruptly.
Testing mode enabled. Covered above. It is a genuine finding and takes one edit to clear.
No key type specified. Safe to ignore. The default is RSA and verifiers apply it.
No service type specified. Also safe to ignore, for the same reason: the s= tag defaults to matching all service types, so its absence is the ordinary case rather than an omission. A validator that lists it alongside genuine findings is padding the report, and learning which warnings a given checker pads with is worth ten minutes the first time you use it.
- Yes: The selector you are querying is the one in a real message's DKIM-Signature header
- Yes: p= carries key material rather than being empty
- Yes: t=y is absent
- Yes: Exactly one DKIM record answers at that hostname
- Yes: The signing domain in the header is your domain and not the platform's
- No: A validator called it well-formed, so you stopped there
The half of DKIM that is not in the record
The key record is only one side. The other side is the DKIM-Signature header your platform writes on each message, and two of its tags change what a pass actually proves.
h= lists the header fields covered by the signature. Anything absent from that list is unsigned, so it can be altered in transit without breaking verification. A signature that covers from, to, subject and date is asserting something meaningful about those fields and nothing at all about the rest.
l= is the body length count, described in RFC 6376 as "the number of octets in the body of the email after canonicalization included in the cryptographic hash." Where it appears, only that many octets are protected, and the specification's own security discussion is the reason to care: content appended after the counted length still arrives under a passing signature. Most platforms omit the tag, which is the safe default, and its presence in a header is worth a question to whoever set the platform up.
Neither tag is something you configure in DNS, which is exactly why they get missed. A perfect key record and a narrowly scoped signature will both report as a DKIM pass in an Authentication-Results header, and only one of them is doing much work.
Rotation is the part nobody plans
Keys are meant to be replaced. The mechanics are simple and the coordination is not: publish the new key under a new selector, switch the platform to sign with it, confirm real mail is carrying the new selector, and only then remove the old record. Deleting first is what causes an outage, because mail already in flight was signed with the old key and receivers will still ask for it.
Two things make this harder for outbound teams than for a company with one domain. Keys published as TXT records have to be rotated everywhere you publish them, so a portfolio of sending domains turns one task into as many tasks as you have domains. And a platform that gave you a CNAME instead of a TXT record has taken rotation out of your hands entirely, which is a genuine convenience as long as you know that is the arrangement.
Where DKIM records fail for cold email specifically
A record can be perfect and still leave you failing DMARC, because DMARC does not ask whether DKIM passed. It asks whether DKIM passed for your domain.
Most sending platforms will sign with their own domain by default, which produces a valid signature that aligns with nothing. The fix is to publish the platform's key on your domain and have it sign as you, which is exactly what the CNAME or TXT record they hand you is for. Our walkthrough of why DMARC fails puts unaligned third-party signing at the top of the list, and the combined SPF, DKIM and DMARC setup shows the records side by side.
The second cold-email-specific point is that DKIM is the durable half of authentication. SPF breaks when a message is forwarded, because the forwarding server is not in your SPF record, and it breaks when a domain accumulates enough senders to cross the ten-lookup limit that SPF records for cold email covers. DKIM survives both, because the signature travels with the message. On a portfolio of sending domains, a correct DKIM record is what keeps DMARC passing when SPF stops contributing.
None of this is a reason to run more sending domains than you need. It is a reason to treat each one as a real domain with real records, verified once at setup and read back after every platform change. We maintain more sending capacity than a campaign consumes for related reasons, and every domain in that inventory carries its own authentication rather than inheriting anything.
If you would rather have the authentication layer built and monitored for you, that is part of how we run campaigns.
The short version
The record is a small set of tags and two of them can silently disable it: t=y tells receivers to ignore the result, and an empty p= revokes the key outright. Query the selector that real messages actually name, insist on at least 1024 bits and prefer 2048, keep exactly one record per name, rotate by adding a new selector before removing the old one, and check that the signature is being made on your domain rather than your platform's, because that alignment is what DMARC grades.
Specification behaviour verified as of August 2026 against RFC 6376 and RFC 8301. Verify current key and selector handling with your sending platform before relying on it.
Frequently asked questions.
Frequently asked questions- What does a valid DKIM record look like?
- At minimum v=DKIM1 followed by the public key in p=, usually with k=rsa between them, published as a TXT record at your selector followed by _domainkey. Everything else is optional with sensible defaults, which is why the optional tags are where the surprising failures live.
- Why does my DKIM checker say no record found?
- Almost always because the selector you queried is not the one your platform signs with. The selector is not discoverable from the domain alone. Take it from the s= value in the DKIM-Signature header of a message you actually sent, then query that name instead of guessing.
- How often should DKIM keys be rotated?
- Often enough that the process is known to work, and never by deleting first. Publish the new key under a new selector, switch the platform to sign with it, confirm real mail carries the new selector, and only then remove the old record. Mail already in flight was signed with the old key.
- What key length should a DKIM record use?
- RFC 8301 requires at least 1024 bits and recommends at least 2048. The reason shorter keys persist is that a 2048-bit key does not fit in the single 256-octet string much DNS software handles, so longer keys have to be published as several concatenated strings.
About the author.
Tim Carden is CMO / CTO at RevenueFlow, which builds and operates outbound revenue engines for B2B companies. Studied at McGill University.
Tim Carden · CMO / CTO
Connect on LinkedIn →Explore more.
Ready to scale your outreach?
We build GTM engines that book real meetings. See the receipts.
Related articles.
DKIM on GoDaddy: Step by Step, With the Failure Modes
GoDaddy holds the public key and your sending platform holds the private one. Four things go wrong at that handoff, and none of them reports an error.
DMARC on Cloudflare, in Practice: Step by Step, With the Failure Modes
Two jobs arrive under one search: publishing a DMARC record in a Cloudflare zone, and enabling Cloudflare DMARC Management. They are unrelated.
Google Workspace SPF Record for B2B Teams: Step by Step, With the Failure Modes
The Google Workspace SPF record is one line and almost nobody types it wrong. What breaks is what happens to that line over the next two years.
BIMI Record: Step by Step, With the Failure Modes
A BIMI record is two lines of DNS and about four weeks of prerequisites. Published before those are met, it is valid, resolvable and completely inert.
DMARC Record: The Setup That Survives Multi-Domain Sending
Most DMARC guidance still recommends a staged rollout using a tag the 2026 specification retired. Here is the current record, tag by tag.
7 DMARC Tools Compared on What They Actually Do
This market sells two different things under one word. Record checkers are free everywhere. Report processors are the product you are actually shopping for.