DKIM Record Not Found: What It Means and How Agencies Should Fix It

DKIM record not found means a receiving system or audit tool looked for a DKIM public key at a specific selector and domain, but did not find a usable DNS TXT record there. It does not always mean DKIM is impossible, broken everywhere, or that the client domain cannot send authenticated email. It usually means the selector is wrong, the DNS record was never published, the sender was not configured, the DNS host is not the one the team edited, or propagation has not completed yet.

For agencies, the practical mistake is guessing. DKIM is selector-based. Google Workspace, Microsoft 365, Mailgun, SendGrid, Postmark, Klaviyo, HubSpot, and other platforms can all use different selectors and different setup screens. A client domain can pass SPF and have a DMARC record while still showing missing DKIM for one sender.

Use Inbox Pulse for a first-pass bulk email-authentication audit across client domains. Use the broader 10-domain agency audit when you also need SSL, DNS, and domain expiry context. For how CertPilot reads public DNS and email-authentication records safely, see how CertPilot checks domains.

What DKIM does

DomainKeys Identified Mail, usually shortened to DKIM, lets a sending platform attach a cryptographic signature to an email message. The receiving mail system can then look up the sending domain's public DKIM key in DNS and verify whether the message was signed by a platform authorized for that domain.

In practical agency terms, DKIM answers this question:

Did this message carry a valid signature from a sender configured for this domain?

DKIM does not prove the message is wanted, useful, or guaranteed to reach the inbox. It is one authentication signal. It works alongside SPF and DMARC. SPF checks whether the sending server is allowed. DKIM checks a message signature. DMARC checks whether SPF or DKIM aligns with the visible From domain and tells receivers what policy the domain owner wants applied.

For a fuller operating-team explanation, pair this guide with DMARC, SPF, and DKIM explained for agencies.

Why DKIM uses selectors

DKIM does not use one universal key for an entire domain. It uses selectors. A selector is a label that points receivers to the right DNS TXT record.

A DKIM lookup usually follows this shape:

| Part | Example | What it means | |---|---|---| | Selector | google, selector1, s1, pm, k1 | The sender-specific key label | | DKIM namespace | _domainkey | The DNS namespace where DKIM keys live | | Domain | example.com | The signing domain or delegated domain | | Full lookup | google._domainkey.example.com | The TXT record receivers query |

Selectors allow a domain to use multiple senders without forcing all platforms to share one key. Google Workspace can use one selector, Microsoft 365 another, Mailgun another, and a marketing automation platform another. Selectors also allow key rotation. A sender can publish a new selector, switch signing to it, and later retire the old one.

That flexibility is why "DKIM record not found" must be read carefully. If an audit tool checks selector1._domainkey.example.com but the active sender uses google._domainkey.example.com, the selector lookup can fail even though DKIM is configured for another sender.

Why a domain can have DMARC and SPF but still miss DKIM

SPF, DKIM, and DMARC use related but different DNS records. A domain might have:

• An SPF TXT record at the root, such as example.com.
• A DMARC TXT record at _dmarc.example.com.
• One or more DKIM TXT records under selector._domainkey.example.com.

Those records do not create each other. Publishing SPF does not publish DKIM. Publishing DMARC does not publish DKIM. A client may have a DMARC record because a previous consultant added one, while their current email platform never completed DKIM setup.

This is common during migrations. A client may move from Google Workspace to Microsoft 365, change marketing platforms, add a CRM, or switch DNS hosts. The old SPF record remains, the DMARC record remains, and the new DKIM selector is never published.

What "DKIM record not found" can mean

Do not treat the message as a single diagnosis. Treat it as a lookup result.

| Possible cause | What happened | Agency check | |---|---|---| | Wrong selector | The audit checked a selector the sender does not use | Confirm selector in the sender admin panel | | Missing DNS record | The platform provided a DKIM TXT record, but it was never published | Check authoritative DNS | | Wrong DNS host | The team edited a DNS zone that is not authoritative | Confirm nameservers and DNS provider | | Propagation delay | The record was recently added and has not resolved everywhere | Recheck after TTL/propagation window | | Sender not configured | DKIM was never enabled in Google, Microsoft, or the SaaS sender | Finish setup in the platform | | CNAME expected | Some senders use CNAME delegation instead of direct TXT | Follow the sender's exact instructions | | Record malformed | TXT chunks, quotes, or copied values are wrong | Compare with platform-provided value |

The fix depends on which row is true. Guessing can make the situation worse, especially if the agency overwrites an existing DKIM record used by another sender.

Common sender patterns agencies see

Different platforms present DKIM differently.

Google Workspace commonly provides a selector chosen in the Admin console and asks for a TXT record under that selector. Microsoft 365 often uses CNAME-style records such as selector1 and selector2 pointing into Microsoft-controlled hostnames. Mailgun, SendGrid, Postmark, Klaviyo, HubSpot, and similar platforms may provide one or more CNAME or TXT records tied to the sending domain or subdomain.

The agency workflow should not start with a selector list copied from a blog post. Use the client's actual sending platforms as the source of truth. The DKIM selectors cheat sheet is useful for orientation, but the sender admin panel decides the record that needs to exist.

Agency workflow for fixing DKIM record not found

Use this sequence before escalating:

1. Identify the sending platform.
2. Confirm the visible From domain and any custom return-path or bounce domain.
3. Find the DKIM selector in the sender admin panel.
4. Confirm whether the sender expects TXT records or CNAME records.
5. Check authoritative DNS, not only a cached resolver.
6. Confirm the DNS host the client actually uses.
7. Compare the published value with the platform-provided value.
8. Check whether the sender says DKIM is enabled or still pending.
9. Send or inspect a real message only when platform-level checks are inconclusive.
10. Document the sender, selector, DNS host, owner, and action required.

This is especially important for agencies that manage many client domains. One client might use Google Workspace, another Microsoft 365, another a CRM sender, and another a newsletter platform on a subdomain. A single spreadsheet column called "DKIM done" is not enough.

What to document

For each sender, record:

| Field | Why it matters | |---|---| | Client | Keeps the work tied to the account | | Domain or subdomain | DKIM may be configured on a subdomain | | Sender/platform | Google, Microsoft, Mailgun, SendGrid, Postmark, Klaviyo, HubSpot, etc. | | Selector | The exact selector receivers query | | Record type | TXT or CNAME | | DNS host | The authoritative DNS provider | | Owner | Who can change the DNS or sender settings | | Status | Missing, pending, active, misconfigured, unknown | | Evidence | Lookup result, platform screenshot, or message header note |

This documentation prevents repeat work. It also gives account managers a clear handoff when a client owns DNS or when the sender platform admin is outside the agency.

What to check before escalating

Before telling the client "DKIM is broken," verify:

• You checked the selector the sending platform actually uses.
• The domain being checked is the domain used in the message or sender setup.
• The DNS provider you edited is authoritative for the domain.
• The TXT or CNAME value exactly matches the platform instructions.
• The record has had enough time to propagate.
• The sender has DKIM enabled, not merely documented.
• DMARC alignment has been considered, not only DKIM existence.

Escalate when the agency lacks access to the email platform, the client owns DNS, the selector cannot be confirmed, or the platform reports a problem despite correct public DNS.

When to use Inbox Pulse

Use Inbox Pulse when you need a bulk view across client domains. It is useful during onboarding, quarterly reviews, care-plan checks, and pre-migration audits. It can surface domains that deserve deeper DKIM review alongside SPF, DMARC, MX, MTA-STS, TLS-RPT, and BIMI configuration checks.

Inbox Pulse is not a full deliverability platform. It does not read inboxes, send placement tests, aggregate DMARC RUA reports, or prove that messages will land in the inbox. It gives agencies a configuration-risk audit layer so they know where to investigate.

When an admin check is still needed

Some DKIM work cannot be completed from public DNS alone. You still need platform admin access when:

• The selector is not known.
• DKIM must be enabled or rotated inside the sender.
• The platform shows verification errors.
• A sender signs with a different domain than expected.
• A message header needs to be inspected for the actual d= and s= values.
• The client has multiple active senders and nobody knows which are legitimate.

This is where agency process matters. Public DNS checks identify risk. Sender admin checks confirm intent.

Practical DKIM triage table

When an account manager or technical lead sees "DKIM record not found," use a triage table instead of a loose comment thread.

| Triage question | Why it matters | Next action | |---|---|---| | Which sender produced the warning? | DKIM is sender-specific | Identify Google, Microsoft, CRM, marketing, or transactional sender | | Which selector was checked? | Wrong selector is a common false path | Confirm selector in the sender admin panel | | Is the DNS host authoritative? | Editing the wrong DNS provider changes nothing | Check nameservers before requesting changes | | TXT or CNAME? | Platforms publish DKIM differently | Follow the sender's exact record type | | Is the sender active? | Old senders should not be blindly fixed | Ask client or review recent sending workflows | | Is DMARC alignment affected? | DKIM existence is not the same as DMARC pass | Check whether the signing domain aligns |

This table is useful in monthly client reviews because it separates evidence from assumptions. A client does not need to understand every DKIM detail, but they do need to know who owns the next action.

Example agency note to a client

Use calm wording:

We found a missing DKIM record for one of the senders connected to your domain. This does not prove mail is currently blocked, but it means one platform may not be signing messages in a way receivers can verify. We need to confirm the sender and selector, then publish the DNS record provided by that platform or disable the sender if it is no longer used.

Avoid saying:

Your email is broken.

That may be inaccurate. The issue could be selector mismatch, an unused vendor, or a pending setup step.

DKIM and message headers

When public DNS and sender admin screens disagree, a real message header can help. Look for the DKIM signature header and identify:

• d= signing domain.
• s= selector.
• Whether the result passed or failed in authentication results.
• Which platform appears to have sent the message.

This is not always necessary for a first-pass audit, but it is useful when a client insists a sender is configured and the public selector lookup does not match. The s= value tells you which selector the message actually used. The d= value tells you which domain signed it.

Agencies should avoid asking non-technical clients to forward raw headers unless needed. It is usually better to get sender admin access or have the client send a test message to a technical mailbox the agency controls.

Related resources

• DKIM selectors cheat sheet for agencies
• DMARC, SPF, and DKIM explained for agencies
• Google bulk sender DMARC agency checklist
• Bulk DMARC check for client domains

Frequently Asked Questions

What does DKIM record not found mean?

DKIM record not found means the expected selector record could not be found in DNS. The usual lookup is something like selector._domainkey.example.com. If that TXT or CNAME record does not exist, resolves from the wrong DNS host, has not propagated, or uses a different selector, the check can return a missing result. It does not automatically prove that every email from the domain fails DKIM. It means the specific selector and domain combination being checked did not return the expected public key.

Can a domain pass SPF and still have DKIM missing?

Yes. SPF and DKIM are separate authentication mechanisms. SPF is usually published at the root domain as one TXT record that lists allowed sending services. DKIM uses selector-specific records under _domainkey. A domain can have SPF configured for Google or Microsoft and still be missing DKIM for a marketing platform, CRM, or transactional sender. DMARC can also exist while DKIM is missing. Agencies should check all three together instead of assuming one record proves the others are complete.

How do I know which DKIM selector to check?

The safest source is the sending platform's admin panel or a real message header from that sender. Common selectors can help you orient yourself, but they are not a reliable source of truth. Google Workspace, Microsoft 365, Mailgun, SendGrid, Postmark, Klaviyo, HubSpot, and other senders may use different selectors or delegated CNAME records. For a practical reference, use the DKIM selectors cheat sheet, then verify against the platform instructions.

Should an agency add a DKIM record without platform access?

Usually no. An agency can publish a DNS record when the platform has provided the exact selector and value, but guessing is risky. Adding the wrong selector does not fix the sender, and overwriting an existing record can break another service. If the client owns the sender account, ask for the DKIM setup screen or admin access. If the client owns DNS, document the exact record, host, and owner before requesting changes.

Does DKIM guarantee deliverability?

No. DKIM does not guarantee deliverability or inbox placement. It helps receivers authenticate that a message was signed by a configured sender for a domain. Mailbox providers still consider many other signals, including reputation, content, user engagement, spam complaints, sending patterns, and policy alignment. Inbox Pulse should be treated as an email-authentication configuration audit, not a deliverability guarantee.

When should I use Inbox Pulse for DKIM issues?

Use Inbox Pulse when you need to find DKIM, SPF, DMARC, and related email-authentication risks across many client domains quickly. It is useful before onboarding a client, before a DNS migration, or when preparing a monthly technical review. If Inbox Pulse surfaces a missing DKIM signal, the next step is to confirm the sender and selector in the platform admin panel and document who owns the fix.