DKIM record not found: why the public key is missing and how to fix it

Quick answer

A DKIM record not found means the verifier queried <selector>._domainkey.<domain> in DNS and got back nothing usable: no TXT record, a broken CNAME chain, or an empty public key. Without that record, the DKIM signature in the message cannot be verified, so the result is not a DKIM pass. You need to know the exact selector before you can diagnose or fix this. The selector is in the s= tag of the DKIM-Signature: header on a real message, or in your sending platform's setup documentation.

How DKIM key lookup works

RFC 6376 defines how receiving mail servers find the public key used to verify a DKIM signature. When the verifier reads a DKIM-Signature: header, it extracts two fields: s= (the selector) and d= (the signing domain). It then queries DNS for a TXT record at <s=>._domainkey.<d=>. That record must contain v=DKIM1 and a non-empty p= value holding the base64-encoded public key. If the query returns NXDOMAIN, an empty result, or a p= field with no value, DKIM cannot produce a pass for that signature.

The selector is not standardized. Each sending platform chooses its own. Google Workspace typically uses google. Microsoft 365 uses selector1 and selector2. Amazon SES, SendGrid, Mailchimp, and most other platforms use their own conventions, which they publish in their setup documentation. Google's DKIM setup and Microsoft's DKIM guide document the exact records to add for those platforms. A domain that sends through several platforms may publish three, four, or more DKIM keys under different selectors, one per platform.

There is no DNS-level mechanism to enumerate every selector a domain has ever published. A lookup tool can only check a selector you already know. If you do not know the selector, the only reliable way to find it is to send a real test message from the platform and read the DKIM-Signature: header from the original message source.

Why the record is missing

Several distinct situations produce a "record not found" result, and the correct fix depends on which one applies.

DKIM was never enabled in the sending platform. Most platforms generate a key pair and tell you the DNS records to add, but they do not add those records for you, and signing is not active until you complete both steps. Completing the DNS side without enabling signing in the platform admin UI leaves real messages unsigned. Completing the platform-side step without adding the DNS record leaves verifiers with nowhere to find the key.

The record was never added, or was added at the wrong DNS name. The DNS name must be exactly <selector>._domainkey.<domain>, with the selector, the literal string _domainkey, and the full domain all present. A common mistake is adding the key at <selector>._domainkey without the domain suffix, or typing the selector incorrectly. Some DNS providers require the zone name omitted from the host field and add it automatically; others expect the full name. If the platform's instructions say to add the record at google._domainkey and your provider expects the full hostname, the resulting published name can end up as google._domainkey.example.com.example.com, which will never resolve.

The sending platform uses CNAME delegation, and the CNAME is missing or was flattened. Several platforms, including SendGrid, Amazon SES, and Mailchimp, publish DKIM keys through CNAME delegation rather than by handing you a raw TXT value to add. Your DNS host selector._domainkey.yourdomain is a CNAME pointing to a record the platform controls and rotates. If that CNAME was never added, was mistyped, or was converted to a TXT record at your DNS host (a practice called CNAME flattening), the lookup chain breaks. The verifier follows the CNAME to the platform's name and expects a TXT record there; if the CNAME does not exist or points nowhere valid, the result is a missing record.

The platform signs with a d= domain that is not your visible From domain. If your sending platform is configured to sign with its own domain rather than yours, the key exists in DNS, just under the wrong domain from your perspective. The DKIM-Signature: header will carry a d= value that belongs to the platform. The signature verifies fine for the platform's domain, but it does not produce DKIM alignment with your From domain for DMARC purposes. This is not technically a "record not found" for the verifier, but it appears that way in DMARC reports and authentication headers if you expected your domain to be the signing domain.

The key was revoked. An empty p= field in a DKIM TXT record signals intentional key revocation per RFC 6376. Verifiers treat an empty p= as a permanent failure, not a temporary one. This appears during key rotation when a platform removes an old selector by zeroing out the key rather than deleting the record entirely. If you recently rotated or cycled DKIM keys and your old selector now has p= with no value, messages signed under that selector cannot verify.

DNS has not propagated yet. A record added moments ago may not be visible to every resolver. DNS propagation speed depends on the TTL of the record and on whether intermediate resolvers have cached a negative response. Querying from one location and seeing the record does not mean every resolver on the path between the sending server and the receiving mail server has the updated record. Wait at least one full TTL cycle (often one hour, sometimes up to twenty-four hours for records with high TTL values) before assuming a newly added record is globally visible.

How to find the selector you need to check

For platform documentation, go to the DKIM setup page for your sending platform. Google Workspace, Microsoft 365, SendGrid, Mailchimp, Amazon SES, and most major providers list the exact selector they use and the exact DNS record format you need to publish. Use that selector value directly when querying <selector>._domainkey.<yourdomain>.

For a real message header, send a test message from the platform through your normal sending path to a personal mailbox you control. Open the original message source (in Gmail, the three-dot menu, "Show original"). Find the line beginning with DKIM-Signature:. The s= tag within that header is the selector; the d= tag is the signing domain. Use both values together: <s=>._domainkey.<d=> is the exact DNS name to query.

If neither method is available, start with the platform's documentation. The selector is always documented there.

How to fix a missing DKIM record

1. Identify the selector your sending platform uses, either from the platform's DKIM setup documentation or the s= tag in a real DKIM-Signature: header.
2. In the sending platform's admin UI, locate the DKIM setup or email authentication section. Generate a key pair if the platform requires it (some generate one automatically; others generate on demand).
3. Copy the exact DNS record the platform provides. Note whether it is a TXT record with a raw public key or a CNAME pointing to a platform-managed record; do not substitute one format for the other.
4. Add the record to your DNS host at the exact name <selector>._domainkey.<yourdomain>. Double-check the full hostname your DNS provider expects. Some providers append the domain automatically; others want the fully qualified name.
5. Enable DKIM signing inside the sending platform. Publishing the DNS record is not enough on its own; the platform must be configured to sign outgoing messages with the corresponding private key.
6. Wait for the record to propagate. Check the TTL value on the record. After at least one full TTL cycle, query <selector>._domainkey.<yourdomain> from an external resolver to confirm the TXT record returns v=DKIM1 and a non-empty p= value.
7. Send a real test message through the platform and inspect the Authentication-Results: header in the delivered message. You should see dkim=pass with the selector and your domain. A dkim=fail result when the record now exists usually means the platform is not yet signing, or is signing with a different selector or domain than the one you just published.
8. After DKIM passes, confirm that the d= domain in the DKIM-Signature: header aligns with your visible From domain. DMARC requires alignment, not just a pass.

DKIM and DMARC

DKIM is one of the two authentication paths that DMARC can use to pass. If DKIM cannot be found, DMARC must fall back to a fully aligned SPF result. For that to pass, the SPF-authenticated return-path domain must match the visible From domain under the organizational domain alignment rules in RFC 7489. Many sending configurations do not produce aligned SPF because the return-path domain belongs to the ESP, not to the sender's From domain. In those configurations, a missing DKIM record means DMARC will fail every message from that sending path, regardless of whether SPF itself passes.

If your domain has a p=quarantine or p=reject DMARC policy and DKIM is missing for your primary sending platform, expect DMARC-driven rejections or spam placement until DKIM is restored and aligned.

What this does not prove

A public DNS check confirms whether the DKIM TXT record exists at the queried selector name and whether the p= field contains a non-empty public key value. It cannot confirm that the sending platform is actually signing outgoing messages. It cannot confirm that a specific message was signed, or that the signature will survive forwarding, gateway rewriting, or mailing-list modifications. It cannot enumerate every selector a domain has ever published, or verify that a selector not checked is absent. The only complete DKIM verification is performed by the receiving mail server against an actual delivered message, readable in the Authentication-Results: header.

Relaymetry checks the public DNS baseline. It does not have access to your sending platform's configuration, your message headers, your DMARC aggregate reports, or any mailbox provider's private authentication logs.

Related guides

• Email authentication explained
• Multiple SPF records: how duplicate v=spf1 records break delivery
• No DMARC record: what it means and how to fix it