Fix DKIM Error: Public Key Not Found

Why is your DKIM error showing 'public key not found in DNS'?

You sent an email. The receiving server checked the DKIM signature. It failed — and showed "public key not found in DNS." You're not alone. This error means the server couldn’t locate the public key your domain was supposed to publish.

DKIM works like a digital seal: your server signs emails with a private key, and the recipient verifies it using a public key stored in DNS. If that record is missing, misformatted, or tied to the wrong selector, the seal breaks — even if your email content is fine.

A single typo — a space in the key, a hyphen instead of an underscore, an incorrect selector name — can trigger this. It's not a server glitch. It's a DNS misstep.

Key takeaways

DKIM verification fails if the public key isn't published under the correct DNS selector in your domain's TXT records.
Even small errors like extra spaces, capitalization mismatches, or wrong selector names break DKIM validation.
Always verify the exact selector used in your DKIM signature matches the DNS record name (e.g., default._domainkey.example.com).

What does 'public key not found in DNS' actually mean?

You're seeing this DKIM error because the receiving email server couldn’t find your domain’s public key in DNS, even though your email was signed correctly. It’s not a problem with your message body or your mail server’s configuration—this is purely a DNS publication issue. If the DNS record isn’t published where expected, DKIM validation fails, and your email may be rejected or marked as suspicious.

The DKIM validation process, step by step

When your email is sent with a DKIM signature, the recipient’s server checks the signature by retrieving your domain’s public key from DNS. It does this using a specific TXT record under a predefined selector (like default._domainkey.yourdomain.com). If that record doesn’t exist, or has the wrong format, validation fails.

This is why even a perfectly configured email server can fail DKIM checks. The key isn’t in the message—it’s in DNS. A missing or incorrectly formatted selector record breaks the entire chain of trust. This is a common cause of low inbox placement rates, especially with major providers like Gmail or Outlook.

According to RFC 6376, which defines the DKIM standard, the public key must be accessible via DNS TXT records. Any deviation—incorrect selector name, typos in the record, or an expired DNS entry—will cause this exact error. You can validate your current setup using tools like MxToolbox's DKIM lookup or DKIM Validator, both of which are industry-standard checks.

How to fix it: What you should check

Let’s walk through the basics. First, confirm your DKIM selector and domain are correct. Then, query your DNS for the full TXT record using a tool like dig or DNSCheck. The record should start with v=DKIM1; and contain the full public key.

Misconfigurations often come from outdated keys, incorrect TXT record formatting, or DNS propagation delays. If you’re using a third-party email service (like SendGrid or HubSpot), make sure they’ve published the key correctly under your domain. Even a single missing character can cause failure.

If you're unsure whether your setup is correct, verify your domain’s DNS records through a real-time check. MailTester’s email checker can validate individual addresses and help diagnose issues like missing DKIM keys, ensuring your emails are properly authenticated before sending.

How to confirm your DKIM DNS record is correctly published

You can resolve a "public key not found in DNS" DKIM error by verifying your DKIM DNS record is correctly published. Use a real-time DNS lookup tool to check the TXT record at selector._domainkey.yourdomain.com. Ensure it starts with v=DKIM1;, includes k=rsa and p=, and matches your email system’s selector exactly.

Step-by-step verification

Use a real-time DNS lookup tool like MXToolbox or Google’s DNS lookup to query the TXT record at selector._domainkey.yourdomain.com — replace selector with your actual selector (e.g., default._domainkey.yourdomain.com).
Confirm the record begins with v=DKIM1; — this is required by the DKIM standard defined in RFC 6376.
Check that the record includes k=rsa to specify the key type, and p= followed by the base64-encoded public key. Missing or malformed p= values are a common cause of errors.
Ensure the selector name in the DNS record exactly matches what your email provider (e.g., SendGrid, Gmail, Microsoft 365) uses. A mismatch — even a typo or case difference — breaks DKIM validation.
Wait at least 5–10 minutes after publishing the record before rechecking. DNS propagation delays can cause false negatives.

Why this matters: accuracy over assumptions

Even a single incorrect character in a DKIM record — like a missing semicolon or a typo in the selector — leads to authentication failures. This causes emails to be rejected or flagged as spam. The only way to know for sure is to verify the record is published as expected.

Use your email service’s documentation or API to confirm the correct selector and public key format. Many providers expect specific selectors like default, mail, or s1. If you're unsure, double-check with your provider’s support or settings dashboard.

If the record appears correct but the error persists, use MailTester’s inbox placement tester to simulate real-world delivery and validate DKIM compliance alongside SPF, DMARC, and overall deliverability.

Common causes of the 'public key not found' DKIM error

You're seeing the "public key not found in DNS" DKIM error because the DNS TXT record for your DKIM signature is either missing, misconfigured, or hasn't propagated yet. This commonly happens when the record was never created, was typed incorrectly, was deleted during a DNS migration, published at the wrong subdomain, or is still being updated across DNS servers. Let’s go through each.

Missing or misconfigured records

If you never created a DKIM TXT record in your DNS, email recipients can't verify your messages, which triggers the error. You might have skipped the step during email provider setup, or your IT team may not have documented it. Let’s say you’re using a service like SendGrid or AWS SES — both require a specific DNS entry to be added, and forgetting it breaks DKIM validation.

A common mistake is a typo in the selector or domain. For example, if the record should be default._domainkey.example.com but you wrote default._domainkey.exmaple.com, the lookup fails. Even a single letter off breaks the chain. Use tools like MXToolbox to check your DNS records live and spot typos early.

Propagation delays and migration issues

DNS changes don’t update instantly. After you add or edit a TXT record, it can take 5 minutes to 48 hours to propagate across the internet. If you just added the record, wait at least 10–20 minutes before checking. This is why you might see the error right after a change, even if everything else is correct.

If you recently migrated your email hosting or DNS provider, it’s possible the DKIM record was removed accidentally during the move. Some providers don’t carry over custom DNS records. Double-check your new DNS zone file against the old one. You can use RFC 6376 to confirm the correct format and placement of the DKIM DNS record.

If you’re unsure whether your record exists, verify it using an online DNS lookup tool. Also, keep in mind that some email services, like Gmail or Outlook, perform strict DKIM checks — if the public key isn’t found at the right subdomain (like selector._domainkey.yourdomain.com), your emails are flagged as unverified, even if the body is clean.

Before sending bulk campaigns, validate your setup. Use a real-time verification tool like the MailTester API to test if your sender domain resolves correctly and ensure your DKIM signature is properly published.

Step-by-step: how to fix a missing DKIM public key in DNS

If your DKIM error says "public key not found in DNS," you’re missing a required TXT record. Log in to your DNS provider, find the TXT record section, and ensure a record exists with the name selector._domainkey.yourdomain.com (e.g., s1._domainkey.example.com) and a value starting with v=DKIM1; k=rsa; p= followed by your full public key. Save it, wait for propagation—typically 5 to 30 minutes—then verify it’s live with a DNS lookup tool.

Locate and verify your DKIM record

Log in to your DNS provider’s control panel—Cloudflare, GoDaddy, AWS Route 53, or your hosting provider’s dashboard.
Navigate to the DNS settings or zone file section, and find the TXT record list. This is where email authentication records live.
Look for a TXT record with a name like default._domainkey.yourdomain.com, s1._domainkey.yourdomain.com, or mail._domainkey.yourdomain.com. The selector (e.g., s1) is defined by your email sender or email service provider.
If no such record exists, or if its value is incomplete or corrupted, you’ll need to create or update it. A missing or malformed DKIM record can cause delivery failures or spam filtering.

Create or update the DKIM TXT record

Create a new TXT record with the full name: selector._domainkey.yourdomain.com (replace selector with your actual selector).
Enter the full value: v=DKIM1; k=rsa; p= followed by the entire public key—including any newlines or line breaks (most providers trim these; keep the full key as one line or use quotes if allowed).
Save the record. Some DNS providers apply changes instantly; others may take 5–30 minutes to propagate. Propagation can take up to 48 hours on slower networks, especially in large DNS zones.
Verify the record is live using a public DNS lookup tool like MXToolbox or DNSChecker.org. Enter your selector and domain to check if the key appears correctly.

DNS record issues are common after migration or misconfiguration. If you’re still seeing errors, check that your email service provider (like SendGrid, Amazon SES, or Mailgun) has generated the correct selector and key. You can also validate your full email authentication setup—SPF, DKIM, and DMARC—with tools like the MailTester Inbox Placement Test, which checks real-world deliverability and flags failures before they impact your campaigns.

The 4 steps described in “Locate and verify your DKIM record”, in order.

How long does DNS propagation take after updating a DKIM record?

DNS changes typically propagate within 5 to 30 minutes across most networks, but some ISPs or providers may cache records for up to 24–48 hours. You don't need to wait the full window—checking propagation status in real time is faster and more accurate.

Propagation timing across networks

When you update your DKIM public key in DNS, the change doesn’t reach every server instantly. Most modern networks refresh DNS records within 30 minutes, especially if the Time-to-Live (TTL) value was set to a low number (like 300 seconds) before the change. However, older or poorly configured resolvers may hold onto stale data much longer—up to 48 hours in rare cases.

Propagation delay isn’t unique to DKIM—it affects all DNS records. The key issue is that even if your DNS provider shows the record as updated, global visibility isn’t immediate. Waiting 24 hours just to test your DKIM setup is not necessary—and not recommended when you can verify propagation in real time.

How to check propagation without guessing

Let’s be honest: waiting and hoping never worked well for deliverability. Instead, use free online tools designed to check DNS propagation across geographically diverse locations. Tools like MXToolbox or DNSChecker.org query DNS resolvers worldwide and show whether your DKIM record is visible where it needs to be.

For example, if your domain’s DKIM record only appears in North America but not in Europe or Asia, you’ve got incomplete propagation. This is when you know you can’t yet trust your send rate or inbox placement. These tools also let you compare results across multiple providers, which helps isolate local issues versus global propagation.

If your DKIM record is still missing after 2 hours, double-check the syntax. A typo in the selector or the DNS record format can prevent proper lookup. You can validate the full DKIM setup using MailTester’s email checker—it will test whether the DKIM signature is properly parsed and matched to a public key in DNS.

How to verify your DKIM record is working without sending tests

You can check if your DKIM record is correctly published by querying DNS directly using a tool like MailTester’s real-time verification API. Enter your domain and selector to see if the TXT record returns valid DKIM data—no test emails needed. This catches misconfigurations before they cause bounces or deliverability issues.

Verify your DKIM setup in under 30 seconds

Go to MailTester’s verification API and authenticate with your key.
Input your domain (e.g., yourcompany.com) and the DKIM selector (e.g., default, mail, or specific tag from your email provider).
Run the query—results return whether the DNS TXT record exists and contains valid DKIM data.
If the record is missing or malformed, the API will indicate the error (e.g., "record not found" or "invalid format").
Use this feedback to fix your DNS setup—common errors include typos in the selector, missing or malformed public key, or incorrect record type (must be TXT).

Why DNS checking beats sending test emails

Testing DKIM with a real email sends to an inbox and can fail for reasons unrelated to your configuration—like spam filters, temporary network issues, or recipient blacklists. Checking DNS directly isolates the problem: it confirms whether your record is published correctly, regardless of external factors.

The RFC 6376 standard defines DKIM's role in email authentication. Properly published records ensure that receiving servers can validate the signature, reducing the risk of messages being marked as spam or rejected outright. You can validate your setup against this standard using tools that parse and verify the full record format.

Tools like MXToolbox and DNSLeakTest also let you inspect DNS records, but they don’t validate the full DKIM logic—only that a TXT record exists. MailTester’s API goes further by returning structured data, including the public key and signature validity, giving you a clearer picture of what’s working—and what isn’t.

DKIM, SPF, and DMARC: the three roles in email authentication

You can resolve a "public key not found in DNS" DKIM error by verifying your DKIM record is published correctly in your domain’s DNS, includes the right selector, and points to a valid public key. SPF, DKIM, and DMARC each play a distinct role: SPF authorizes sender IPs, DKIM validates message integrity with cryptographic signatures, and DMARC defines enforcement policies for failed checks. Together, they form the foundation of email authentication.

SPF: Authorizing Sender IPs

SPF (Sender Policy Framework) tells receiving mail servers which IP addresses are allowed to send email on your domain's behalf. If an email comes from an IP not listed in your SPF record, it may be flagged as suspicious or rejected.

Let’s say you send from a marketing platform like Mailchimp. You need to include its IP ranges in your SPF record — or use a mechanism like include:mailchimp.com — to avoid rejection. Overly strict or missing SPF records can hurt deliverability, often resulting in soft bounces or inbox filtering.

DKIM: Ensuring Message Integrity

DKIM adds a digital signature to each outgoing email. This signature is verified by the recipient’s server using your public key, which lives in your DNS. If the key is missing, misconfigured, or unreachable, the verification fails — and you'll see a "public key not found" error.

The key must be published under the correct selector (a subdomain like default._domainkey.yourdomain.com) and match the one used to sign the message. Tools like MailTester’s email checker can help you validate the public key’s presence and alignment with the domain.

DMARC: Enforcement and Reporting

DMARC (Domain-based Message Authentication, Reporting, and Conformance) builds on SPF and DKIM. It tells receivers what to do with emails that fail either authentication method — either quarantine them, reject them, or let them through.

DMARC also enables you to receive reports about authentication results. This helps you detect spoofing attempts and identify problems before they impact your sender reputation. A well-configured DMARC policy, starting with p=none and gradually moving to p=quarantine or p=reject, gives you control while protecting your domain.

Authentication isn’t a one-time setup — it’s ongoing. Regular verification ensures your keys, records, and policies remain correct as infrastructure changes.

For organizations managing large email lists, using services like MailTester’s bulk verification can help catch invalid or misconfigured addresses before they hurt your domain’s reputation. Properly aligned SPF, DKIM, and DMARC are not optional — they’re essential for ensuring your emails reach the inbox, not the spam folder.

Why verifying your DKIM record matters even after setup

Even after you publish a DKIM record, it can still be misconfigured, deleted, or overwritten—especially when multiple teams manage DNS. DNS changes are manual, and small errors often go unnoticed. Without verification, you risk sending messages that appear unauthenticated, damaging your sender reputation and hurting inbox placement. Use real-time testing to catch issues before they impact deliverability.

How often do DNS issues slip through?

DKIM setup isn’t a “set and forget” task. A single typo in the TXT record, an incorrectly formatted selector, or a forgotten subdomain can break authentication. Even if your record was valid at one point, changes made by another team—like switching email providers or updating DNS policies—can silently remove it. Tools like MXToolbox can check DNS records, but they don’t tell you whether your DKIM signature is actually working in practice for real-world delivery.

What happens when DKIM fails silently?

If your domain’s DKIM public key isn’t found in DNS, incoming mail servers can’t verify your messages. This doesn’t always trigger an immediate bounce, but it does hurt your sender reputation over time. ISPs like Gmail and Outlook use reputation signals to decide whether to deliver your email to the inbox or spam folder. A missing or broken DKIM record increases the risk of gradual filtering.

Even minor configuration drift—like a missing space or a typo in the selector name—can break the authentication chain from the start. That’s why regular validation is critical. It’s not enough to set up DKIM once. You need proof that it’s still working. The only way to confirm is to verify the DNS record using a real-world check, not a static lookup.

Let’s say you’re sending a campaign via SendGrid. You set up DKIM properly, but the record wasn’t published correctly, or your DNS provider failed to update. The email goes out. No error is returned. But the message isn’t authenticated. Over time, repeated failed checks reduce your sender score. Test inbox placement with real inboxes to confirm delivery isn’t being throttled.

How MailTester helps you avoid DKIM and DNS errors

Before you send, MailTester checks your domain’s DNS records in real time—including DKIM, SPF, and DMARC—to confirm they’re properly configured. If your DKIM public key isn’t found, it’s flagged immediately with clear feedback: “DKIM record not found,” “malformed record,” or “valid.” This lets you fix issues before they hurt deliverability. It’s not about guessing—it’s about verifying.

Check your DNS setup before sending

Use the real-time verification API to test individual addresses or bulk lists before sending, and catch DKIM errors before they hit the inbox.
Every verification includes a DNS check for SPF, DKIM, and DMARC records—no assumptions, no guesses.
Get specific feedback: if your DKIM record is missing, it won’t just say “error”—it’ll say “DKIM record not found,” so you know exactly what to fix.
Use the bulk verification tool to audit thousands of addresses at once, highlighting those with missing or malformed DKIM records.
Verify your domain’s full authentication stack—SPF, DKIM, DMARC—during pre-send testing to spot common issues like incorrect DNS record formats or expired keys.

Fix problems before they affect deliverability

DKIM failures often lead to emails being treated as spam, especially if they’re not properly signed by a key published in DNS. This is common and preventable.
MailTester’s checks align with industry practices: according to the RFC 6376, a DKIM signature must be validated against a public key published in DNS—our tool checks that exact condition.
After identifying a missing or malformed DKIM record, correct the DNS entry and re-test to confirm the fix. No more sending blind.
For regular operations, integrate MailTester with your ESP (like SendGrid or HubSpot) via our native integrations to validate addresses automatically during onboarding or campaign setup.
Test inbox placement with our inbox tester to see how a message with a valid DKIM setup lands in real inboxes—across Gmail, Outlook, and Apple Mail.

Fixing DKIM errors is a small step. Maintaining email deliverability is continuous.

A single missing DKIM record can degrade sender reputation, leading to higher bounce rates and increased spam filtering. Even one misconfiguration can undermine trust in your domain’s authenticity.

DNS audits should be routine

Use tools like MailTester to audit your domain’s DNS records monthly. Catching issues early prevents reputation damage and inbox placement drops.

Deliverability relies on multiple layers

Accurate DNS settings alone aren’t enough. Combine them with clean email lists, proper authentication (SPF, DKIM, DMARC), and consistent sending behavior to maintain inbox placement over time.

Sources

Since May 5, 2025, Microsoft Outlook requires SPF, DKIM, and DMARC from domains sending 5,000+ emails per day, rejecting non-compliant mail outright at the SMTP level with error 550 5.7.515. — Microsoft Outlook requirements (via MailOver bulk-sender requirements guide) (2025)
DMARC adoption among top domains surged 75% between 2023 and 2025 — from 27.2% to 47.7% — in the wake of Google and Yahoo's bulk-sender authentication requirements. — EasyDMARC 2025 DMARC Adoption Report (2025)

Keep reading

Ready to put this into practice? MailTester verifies emails with 98.9% accuracy — start with 100 free verifications.

Frequently asked questions

What happens if my DKIM public key is not found in DNS?

Emails from your domain may be rejected by receiving servers, marked as spam, or fail authentication checks, harming deliverability.

Can a typo in the selector cause a DKIM error?

Yes, even one character off in the selector (e.g., s1 vs. s2) prevents the receiving server from finding the correct DNS record.

How do I know if my DKIM record has been published successfully?

Use a DNS lookup tool or MailTester’s API to query the TXT record at selector._domainkey.yourdomain.com and confirm it returns the full DKIM value.

Is DNS propagation always instant?

No. DNS changes take 5 to 30 minutes to propagate on most networks, but can take up to 48 hours in rare cases.

Can I have multiple DKIM records for a single domain?

Yes, but each must use a unique selector (e.g., s1._domainkey, s2._domainkey). Receiving servers will test each one in sequence.

What if my DKIM record is present but still failing?

Check for missing or incorrect parameters—especially missing 'v=DKIM1' or malformed 'p=' value. Tools like MailTester can validate the full record.

Does DKIM require a private key?

Yes. The private key signs outgoing messages; it must stay secure and never be published in DNS.

How often should I verify my DKIM DNS record?

At least once per month, or after any DNS or email service changes to ensure uninterrupted authentication.

Can MailTester help me set up DKIM records?

No, it doesn’t create DNS records. But it verifies them instantly, helping you catch errors before sending emails.

What is the difference between DKIM and SPF?

SPF validates the sending IP; DKIM validates the message content integrity via cryptographic signature. They serve different layers of email authentication.