DKIM Record Not Found: Setting Up DKIM DNS Records

What "DKIM Record Not Found" Means

"DKIM record not found" means no TXT or CNAME record exists at the DNS location where the DKIM public key should be. DKIM keys are published at a predictable path:

selector._domainkey.yourdomain.com

For example, if your domain is example.com and your selector is google, the mxio DKIM Checker looks for a TXT record at google._domainkey.example.com. If that DNS record does not exist, DKIM verification fails for every email signed with that selector.

The fix: identify the correct selector your mail server uses, publish the corresponding public key in DNS, and verify the record resolves.

This does not necessarily mean DKIM is broken for your entire domain — you may be checking a different selector than the one your server uses. But if no DKIM record exists for the selector your mail server signs with, every signed email fails DKIM verification, which degrades deliverability and can cause DMARC failures.

How DKIM DNS Records Work

DKIM uses public-key cryptography. Your mail server holds a private key and signs outgoing messages. The corresponding public key is published in DNS so receiving servers can verify the signature. Three components make this work:

The Selector

DKIM selectors allow a domain to publish multiple DKIM keys simultaneously. This is essential for key rotation (publish a new key under a new selector before retiring the old one) and for supporting multiple sending services (each with its own key pair).

The selector is an arbitrary string chosen by the mail server administrator or email service provider. It appears in the DKIM-Signature header of every signed message as the s= tag:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=selector1;
    bh=...; h=From:To:Subject:Date; b=...

Here, s=selector1 tells the receiving server to look up the public key at selector1._domainkey.example.com.

The _domainkey Subdomain

All DKIM records live under the _domainkey subdomain. This is a fixed convention defined in RFC 6376. The full lookup path is always selector._domainkey.domain.

TXT vs CNAME Records

DKIM public keys can be published as either TXT records or CNAME records:

• TXT records contain the key directly: v=DKIM1; k=rsa; p=MIGfMA0G...
• CNAME records point to a TXT record hosted by your email service provider. For example, Microsoft 365 uses CNAMEs that point to selector1-yourdomain-com._domainkey.yourtenant.onmicrosoft.com

Both approaches work. CNAME records are more common with cloud email providers because they allow the provider to manage key rotation without requiring DNS updates on your end.

How to Find Your DKIM Selector

If you do not know which selector your mail server uses, here are the methods:

Method 1: Check an Email Header

Send an email from the service in question to a Gmail or Yahoo account. Open the delivered message, view the full headers, and look for the DKIM-Signature header. The s= tag is your selector, and the d= tag is the signing domain.

In Gmail: Open the message, click the three-dot menu, select "Show original." Search for DKIM-Signature.

Using the Header Analyzer: Paste the full headers into the mxio Header Analyzer, which parses and highlights the DKIM signature details including the selector.

Method 2: Try Common Selectors by Provider

Each email provider uses predictable selector names. Try these with the mxio DKIM Checker:

Method 3: Query for Common Selectors

Use the mxio TXT Lookup to check each common selector. Query the hostname selector._domainkey.yourdomain.com for each selector you want to test. If a TXT record exists, you have found an active selector.

Setting Up DKIM: Step by Step

For Google Workspace

1. In Google Admin Console, go to Apps > Google Workspace > Gmail > Authenticate email
2. Select your domain and click Generate New Record
3. Choose 2048-bit key length (recommended)
4. Google provides a TXT record value and the selector (usually google)
5. In your DNS, create a TXT record at google._domainkey.yourdomain.com with the value Google provides
6. Return to Google Admin Console and click Start Authentication

Google Admin Console provides the TXT record value and selector directly. Publish the TXT record at the location Google specifies.

For Microsoft 365

1. In the Microsoft 365 Defender portal, go to Email & Collaboration > Policies & Rules > Threat Policies > Email Authentication Settings > DKIM
2. Select your domain
3. Microsoft provides two CNAME records to publish:

selector1._domainkey.yourdomain.com  CNAME  selector1-yourdomain-com._domainkey.yourtenant.onmicrosoft.com
selector2._domainkey.yourdomain.com  CNAME  selector2-yourdomain-com._domainkey.yourtenant.onmicrosoft.com

4. Publish both CNAME records in your DNS
5. Return to the Defender portal and enable DKIM signing

Microsoft uses two selectors (selector1 and selector2) to support automatic key rotation.

For SendGrid

1. In SendGrid, go to Settings > Sender Authentication > Authenticate Your Domain
2. SendGrid provides CNAME records to add to your DNS (two for DKIM, plus additional records for domain authentication):

s1._domainkey.yourdomain.com  CNAME  s1.domainkey.u12345.wl.sendgrid.net
s2._domainkey.yourdomain.com  CNAME  s2.domainkey.u12345.wl.sendgrid.net

3. Publish the CNAME records and verify in SendGrid's dashboard

Each provider's exact steps vary. Always refer to the provider's current documentation for server-side configuration — the DNS records above are the DNS portion only.

TXT Record Format

If you are publishing a DKIM key directly as a TXT record (rather than using a CNAME), the format is:

selector._domainkey.yourdomain.com  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC..."

The key tags:

Key length: Use 2048-bit keys. 1024-bit keys still work but are considered weak, and some security-conscious receivers penalize them. Most modern providers generate 2048-bit keys by default.

Long keys and DNS limits: A 2048-bit RSA key produces a base64 string of approximately 400 characters. Since a single DNS TXT string is limited to 255 bytes, the record must be split across multiple quoted strings within one TXT record:

selector._domainkey.yourdomain.com  TXT  ("v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBA"
    "QUAA4GNADCBiQKBgQC3QEKyU1fSma0Ax...")

Most DNS management interfaces handle this splitting automatically. If you are editing zone files manually, ensure the strings are properly quoted and concatenated.

Common Mistakes

Wrong Selector Name

The most frequent cause of "record not found" is checking or publishing the wrong selector. If your mail server signs with s=selector1 but you published the key at google._domainkey.yourdomain.com, the lookup fails. Always verify which selector your mail server actually uses by checking the DKIM-Signature header on a sent message.

Missing _domainkey Subdomain

Some DNS interfaces require just the subdomain portion (e.g., selector1._domainkey), while others require the full hostname (selector1._domainkey.yourdomain.com). Entering only selector1 without ._domainkey creates the record at the wrong location. Use the mxio TXT Lookup to verify the record is at the correct path.

DNS Propagation Delay

After publishing a DKIM record, DNS propagation can take anywhere from a few minutes to several hours depending on your DNS provider's TTL settings and caching. If the mxio DKIM Checker still shows "not found" immediately after publishing, wait 15-30 minutes and try again. Check with the mxio TXT Lookup to see if the record is being served.

CNAME vs TXT Confusion

Some providers give you CNAME records to publish, while others give you TXT records. Publishing a TXT record when the provider expects a CNAME (or vice versa) does not work. Follow your provider's instructions exactly regarding the record type.

A common error: creating a CNAME record at selector1._domainkey.yourdomain.com that points to the DKIM key value (the v=DKIM1; k=rsa; p=... string) instead of pointing to the provider's hostname. CNAME targets must be hostnames, not TXT content.

Key Mismatch

If you regenerated the DKIM key pair on your mail server but did not update the DNS TXT record with the new public key, the old public key in DNS will not verify signatures made with the new private key. This produces a different error — "signature verification failed" rather than "record not found" — but key rotation is a common trigger for DKIM issues. See DKIM Body Hash Did Not Verify for related troubleshooting.

Prevention and Ongoing Monitoring

After publishing your DKIM record:

1. Check the DNS record — Run the mxio DKIM Checker with your domain and selector to confirm the public key is found and valid
2. Send a test email — Send a message to a Gmail account and check the "Show original" view for dkim=pass in the Authentication-Results header
3. Verify DMARC alignment — Run the mxio DMARC Checker to confirm that DKIM alignment works with your DMARC policy
4. Check all sending services — If you use multiple services (Google Workspace, marketing platform, transactional email), verify each service's DKIM selector independently

Set up domain health monitoring to get alerted if your DKIM records are removed or changed. DNS records disappear during migrations more often than you expect — continuous monitoring catches the problem before it affects deliverability.

Related Issues

• DKIM Body Hash Did Not Verify — DKIM record exists but the signature fails due to body modification
• Why Is DMARC Failing? — Missing DKIM records contribute to DMARC failures
• No DMARC Record Found — Setting up DMARC after DKIM is configured
• Emails Going to Spam — Missing DKIM degrades deliverability
• Email Authentication Guide — Complete guide to SPF, DKIM, and DMARC