Why Is Your DKIM Signing Failing with 'a=rsa-sha256 but Public Key Not in DNS'?

You sent a campaign. It looked right. Your SPF and DMARC were set. But Gmail marked it as unverified. Why? One line in the error says: a=rsa-sha256 but public key not in DNS. That’s not a typo. It’s a break in the chain of trust.

DNS is where email receivers go to check if your signature is real. If your email server signs with rsa-sha256 but the corresponding public key isn’t in DNS, they can’t validate it. No validation means rejection or spam tagging, even if your domain has a clean reputation.

You won’t fix deliverability with better subject lines or higher sender scores if the cryptographic handshake fails at the very start. The error isn't vague — it points to a missing, misformatted, or unreachable DKIM DNS record. We’ll show you exactly how to fix it, step by step.

Key takeaways

  • DNS must contain the public key for any DKIM signature using a=rsa-sha256.
  • Even a single misconfigured DKIM record breaks verification, leading to inbox placement failures.
  • Verification tools can detect missing or malformed DKIM DNS records before they impact deliverability.

What Does the DKIM 'a=rsa-sha256' Tag Actually Mean?

The a=rsa-sha256 tag in a DKIM-Signature header means the email was signed using the RSA algorithm with SHA-256 for hashing—a modern, secure standard accepted by Gmail, Outlook, Apple Mail, and all major providers. The issue isn’t the algorithm; it’s that the public key required to verify the signature isn’t available in your domain’s DNS TXT record, even though the header says it’s using this method.

Why 'a=rsa-sha256' Isn’t the Problem

Let’s be clear: a=rsa-sha256 isn’t broken. It’s the gold standard for DKIM today. Unlike older options like a=rsa-sha1, which was deprecated due to cryptographic weaknesses, SHA-256 is still considered secure and is required by modern email security standards. If your emails are failing DKIM validation, it’s not because you’re using a modern algorithm—it’s because the system can’t find the key to validate it.

Think of it like a digital lock. The header says, “I used a key made with RSA and SHA-256.” But when the receiving server tries to check the lock by looking at your domain’s public key in DNS, it finds nothing. The key wasn’t published correctly, or it’s missing entirely. That’s why your email appears to fail DKIM validation, even though the signing process was correct.

The Real Fix: Publish the Public Key Correctly

The fix is simple in theory, but easy to get wrong in practice. You must ensure the DKIM selector (like default or mail) and the domain match exactly in your DNS TXT record. The record should look like this:

default._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgC..."

Make sure the p= value contains the full public key and is properly formatted. Even a single character error—like a missing space or an escaped quote—can break validation. Use a tool like MXToolbox’s DKIM Checker to test DNS records in real time.

Once published, email providers will be able to verify the signature using the public key. You can test this before sending by validating individual addresses—try our email checker to review how your domain’s email behavior affects deliverability.

How DMARC and DKIM Work Together to Secure Your Domain

You can’t fully secure your domain with DMARC unless DKIM is properly set up. DMARC relies on DKIM to verify message authenticity. If DKIM uses a=rsa-sha256 but the public key isn’t published in DNS, DMARC will fail—no matter how valid the rest of the message is. That failure triggers spam filters, harms your sender reputation, and leads to lost inbox placement. The system doesn’t assume trust; it checks signatures against published keys.

How DKIM and DMARC Interact in Real-World Deliverability

DKIM signs each email with a cryptographic fingerprint using your domain’s private key. When the recipient’s mail server receives the message, it fetches your domain’s public key from DNS to verify that signature. That’s where the a=rsa-sha256 part comes in—it tells the receiver what algorithm to use. But if the key isn’t there, the validation fails.

DMARC doesn’t act alone. It’s the enforcement layer. You set a policy—like reject or quarantine—and DMARC uses DKIM (and SPF) results to decide what to do with a message. If DKIM fails because the public key is missing, DMARC also fails. Even if the message looks otherwise legit, it’s treated as suspicious or forged.

This is why a missing or misconfigured DKIM public key matters so much. It doesn’t just break one check; it breaks the entire chain that protects your domain’s reputation. Receiving systems like Gmail and Outlook use DMARC reports to assess sender trust. A consistent pattern of DKIM failures leads to higher spam scores and reduced deliverability over time.

Let’s make it concrete: if you’ve set up DKIM with a=rsa-sha256 in your DNS but forgot to publish the public key, your emails will pass SPF but fail DKIM. DMARC sees the failure and blocks or quarantines mail. This happens even if your content is clean, your IP is healthy, and no other red flags exist. It’s a technical detail with real consequences.

One way to catch this early is to simulate incoming messages with real inbox testing tools. You can see how your emails perform across different providers, including whether DKIM is being verified correctly. This kind of testing helps prevent reputation damage before it starts.

Once you’ve verified your DNS records, a simple way to test if an email address will receive your messages successfully is to use a real-time verification tool. You can check individual addresses to catch delivery issues before you send. Some tools also test deliverability across major inboxes, showing you where your messages land.

For organizations sending at scale, validating your full email list in bulk helps you identify domains and addresses that won’t accept your messages due to misconfigurations or policies. You can filter out these addresses before sending, saving time and protecting your sending reputation.

Drafts may include DKIM signatures, but if the keys are missing, they’re essentially invisible to validation systems. The internet doesn’t trust what can’t be verified. So fix the DKIM record—ensure your public key is published and aligns with the algorithm you’re using. You’ll keep DMARC happy, maintain inbox placement, and avoid long-term deliverability headaches.

Step-by-Step: Verify and Fix Your DKIM Record in DNS

You can fix a DKIM signature using a=rsa-sha256 with a missing public key by locating your domain’s DKIM TXT record in DNS, confirming it contains the full public key in p=-----BEGIN PUBLIC KEY----- format, and ensuring the record is published and active. If it’s missing or malformed, update it with the correct key and verify propagation. Use a real-time DNS lookup tool to check immediately.

Check Your DNS TXT Record

  1. Log in to your domain registrar or DNS hosting service—Cloudflare, AWS Route 53, GoDaddy, or your email provider’s portal.
  2. Navigate to the DNS management section and search for a TXT record with a selector name like default, mail, or google. This is your DKIM selector.
  3. Verify the record includes the p= tag followed by the full public key in PEM format: p=-----BEGIN PUBLIC KEY-----... and -----END PUBLIC KEY-----. Many tools generate this incorrectly by omitting lines or adding extra characters.
  4. If the key is truncated or missing, re-add it with the correct format. The key must match the private key used by your mail server to sign outbound emails.

Confirm the Record is Live

  1. Use a real-time DNS lookup tool, such as DNS Checker or MxToolbox, to verify the TXT record resolves correctly across multiple global locations.
  2. Wait up to 48 hours for DNS propagation if you just updated the record—though some providers apply changes instantly.
  3. If the record is not found, check for typos in the selector name or domain. Some systems, like Google Workspace, auto-remove unused keys after a period—ensure yours hasn’t been purged.
  4. Once published, test email deliverability using a tool like MailTester’s inbox placement tester to confirm authentication is now working at scale.
DKIM failures due to missing or malformed public keys are a common reason for emails landing in spam folders, even when your domain has valid SPF and DMARC.

You can validate your full email sending infrastructure—including DKIM, SPF, and DMARC—using MailTester’s real-time verification tools. Whether you're checking individual addresses or testing bulk lists, the platform confirms DNS records and deliverability health in seconds.

How to Test If Your DKIM Record Is Correct and Accessible

You can confirm your DKIM record is correctly published and accessible by querying your DNS using a command-line tool like dig. Run dig TXT selector._domainkey.yourdomain.com, then check that the response contains a complete p= entry with your public key—starting with MIGf...-----END PUBLIC KEY-----. Use this output to verify the key matches what your email server uses to sign messages. If the record is missing, truncated, or doesn’t contain the full key, your DKIM setup is broken and may cause delivery issues.

Check Your DNS TXT RecordThe 4 steps described in “Check Your DNS TXT Record”, in order.1Log in to your domain registrar or DNS hosting service—Cloudflare, AWSRoute 53, GoDaddy, or your email provider’s portal.2Navigate to the DNS management section and search for a TXT record witha selector name like default, mail, or google. This is your DKIMselector.3Verify the record includes the p= tag followed by the full public key inPEM format: p=-----BEGIN PUBLIC KEY-----... and -----END PUBLICKEY-----. Many tools generate this incorrectly by omitting lines oradding extra characters.4If the key is truncated or missing, re-add it with the correct format.The key must match the private key used by your mail server to signoutbound emails.
The 4 steps described in “Check Your DNS TXT Record”, in order.

Step-by-Step: Validate Your DKIM Record

  1. Open your terminal or command line. Run dig TXT selector._domainkey.yourdomain.com, replacing yourdomain.com with your actual domain and selector with your actual DKIM selector (commonly default or google). This fetches the DNS TXT record your mail server uses to publish the public key.
  2. Check the output for a line that begins with p= and contains a base64-encoded public key. It must start with MIGf... and end with -----END PUBLIC KEY-----. If the key is cut off or missing, your DNS record is incomplete.
  3. Compare the retrieved key with the one your email service provider (ESP) or mail server is using to sign outgoing messages. Even a single character mismatch—like a missing space or extra newline—breaks signature verification. The key must match exactly.
  4. If the record doesn’t return or is returned with too long warnings, your DNS TXT record is likely truncated. This happens when it exceeds 255 characters, which is the DNS limit for a single record. You must split it into multiple quoted strings or use DNS over HTTPS (DoH) tools to check fully.
  5. Use tools like RFC 6376 or DNSDumpster to double-check the record across public resolvers, especially if you’re using cloud-based DNS providers. Some providers like Cloudflare or AWS Route 53 apply automatic truncation or caching that may hide issues.

What to Do If Your DKIM Record Fails Verification

If the p= tag is missing, incomplete, or doesn't match your signing key, your messages will fail DKIM checks. Even if SPF and DMARC pass, a broken DKIM signature can still land your emails in spam folders. Most ESPs (including Gmail, Outlook, and Yahoo) require valid DKIM to trust incoming mail.

Use a real-time verification tool like the MailTester API to test how your DKIM-signed messages behave in real inbox environments. It checks not only whether the key is published but whether it’s accepted by major email providers during actual delivery. This helps catch issues that DNS checks alone might miss.

Common Causes of 'Public Key Not in DNS' Despite Correct Settings

You're seeing "DKIM signature uses a=rsa-sha256 but public key not in DNS" because the public key published in DNS doesn’t match the one expected by the receiving server, even if you think your configuration is correct. This usually happens due to DNS propagation delays, accidental edits, un-synced key rotations, or misconfigured third-party services. Let’s walk through the most common culprits.

DNS Propagation Delays

After updating your DNS records, changes can take up to 48 hours to propagate globally. Even if you've set the record correctly, some resolvers might still be serving old data. This delay often leads to temporary DKIM verification failures. Use tools like MXToolbox to verify if your record is visible from multiple locations.

Manual Configuration Errors

  • Accidentally pasted or typed the public key incorrectly in the DNS TXT record.
  • Used the wrong selector (e.g., “default” instead of “brisbane”) in the DKIM header, but published the key under a different selector in DNS.
  • Left trailing spaces or special characters in the TXT record value, breaking the parsing.

Key Rotation Without DNS Update

When you regenerate DKIM keys—common during security audits or compliance checks—you must also update the DNS record. Forgetting to do so means the published key no longer matches the one in the signature. This is especially common in automated environments where key rotation is separate from DNS management.

Third-Party Email Service Misalignment

If you use SendGrid, Mailchimp, or another ESP, they manage DKIM keys on your behalf. However, you still need to ensure the correct selector is published in DNS. Some providers auto-configure this, but others require manual setup—especially when using custom domains. If your ESP generated a key for selector mail, but DNS has a record for default, the signature will fail inspection.

Even with correct settings, a misalignment between the signature’s selector and DNS record will trigger a "public key not in DNS" error. Always double-check the exact selector in the DKIM signature and confirm it matches the DNS TXT record name.

How to Verify and Fix

Check the full DKIM signature in a received email header (look for DKIM-Signature:). Copy the h= and s= values to identify the domain and selector. Then query DNS for that TXT record. Use RFC 6376 as a reference for the expected format. If it’s missing, verify your provider’s documentation or test your setup with a real email checker before sending to real users.

Before sending campaigns, test your setup with an inbox placement tool to catch issues early. Use MailTester’s Inbox Placement Test to validate that your DKIM signature is recognized and trusted across multiple mail providers.

How MailTester Can Help You Catch DKIM Misconfigurations Early

DKIM signature mismatches happen often—especially when the algorithm listed in the signature (like a=rsa-sha256) doesn’t match the key published in DNS. MailTester’s real-time verification API checks this exact issue by validating signatures against published DNS records, catching errors before they harm your sender reputation. You don't need to wait for bounces or blacklists to find these flaws.

How We Verify DKIM Signatures in Real Time

  • Our API checks the full DKIM signature, including the algorithm (a=rsa-sha256 or a=rsa-sha1), and compares it directly to the public key in DNS.
  • If the key in DNS doesn’t match the expected format or is missing, we flag it as a DKIM mismatch or missing public key during testing.
  • This process happens during inbox placement tests and real-time checks, so you see the issue immediately—not after sending a campaign.

Scale Your Verification to Prevent Deliverability Failures

  • Use our bulk list verification to scan thousands of emails at once and detect DKIM errors across your entire list before sending.
  • Integrate MailTester with Mailchimp, SendGrid, HubSpot, or Klaviyo to auto-validate your domain’s DNS records and DKIM configuration during setup.
  • Our verification engine checks not just DKIM, but SPF, DMARC, and other common delivery roadblocks—preventing a cascade of rejection issues.
  • With 98.9% accuracy, MailTester gives you a reliable signal on whether an email will pass authentication on major provider networks.

According to RFC 6376 (the DKIM standard), a valid signature must be verifiable against a published public key in DNS. When it’s not, the message is rejected or marked as suspicious. This isn't a minor quirk—it's a red flag for deliverability. You can test the validity of a single address with our email checker and use the results to fix misconfigurations before they hit production.

Let’s say you’re onboarding new leads. You run a batch through our API. Two domains show DKIM verification failed—even though the keys were published. On closer look, one was using a=rsa-sha256 but the key in DNS was encoded for a=rsa-sha1. That mismatch caused validation failure on Google and Yahoo. Fixing it took five minutes; catching it early saved 450,000 potential bounces.

DKIM misconfigurations don’t always surface in sender reputation tools—they show up in DNS checks. MailTester finds them, so you don’t have to.

What Happens If You Ignore This DKIM Error?

If you ignore a DKIM signature error where the algorithm is rsa-sha256 but the public key isn't in DNS, your emails are at high risk of being blocked, marked as spam, or quarantined by major providers like Gmail and Yahoo. This breaks email authentication, and over time, it damages your sender reputation, leading to poor deliverability even for future, properly signed messages.

Immediate Deliverability Risks

When a DKIM signature uses rsa-sha256 but the corresponding public key isn't published in DNS, receiving servers cannot validate the signature. This fails the verification process, and most major email providers—including Gmail and Yahoo—treat this as a red flag. They may reject the message outright, send it to the spam folder, or hold it for inspection. According to reports from the Messaging, Malware, and Mobile Anti-Abuse Working Group (M3AAWG), inconsistent or invalid DKIM signatures are among the top technical triggers for email rejection.

Long-Term Reputational Damage

Consistently failing DKIM checks does not go unnoticed. Email providers track sender behavior over time. A history of failed validations signals poor technical hygiene, which gradually lowers your sender reputation score. Once your reputation drops, even legitimate emails may get filtered or withheld. Recovery isn’t automatic—providers may require you to authenticate properly for weeks before restoring trust. This delays campaigns and can hurt customer engagement.

Fixing the issue isn’t just about restarting delivery—it also requires re-authentication with the receiving side. That means sending test emails, waiting for feedback, and verifying the fix across multiple inbox providers. All of this takes time and can cause reputational strain, especially if you're sending urgent messages.

Let's be clear: this isn't a one-time glitch. It's a persistent vulnerability that undermines trust in your entire sending domain.

Before sending to any list, validate your DKIM setup. You can check how your domain signs messages and whether the public key is correctly published using tools like MXToolbox or MailTester's inbox placement tester, which can simulate real-world delivery conditions and highlight authentication failures early.

Fixing DKIM errors before sending helps avoid costly delays and protects your long-term email performance.

Best Practices to Prevent Future DKIM Failures

Fixing a DKIM signature issue where the algorithm is rsa-sha256 but the public key isn't found in DNS requires verifying the DNS record alignment, ensuring the selector is correctly published, and confirming key freshness. You can avoid this entirely by documenting key details, monitoring changes, and testing before deployment. Let’s walk through how.

Document and Monitor Key Configuration

  • Keep a centralized log of your DKIM selector names, associated email services, and public key locations. This eliminates guesswork during troubleshooting.
  • Use automated DNS monitoring tools—like those from MxToolbox or cloud-based health checks—to detect accidental removals, expiration, or misconfigurations of your DKIM records.
  • Set up alerts for DNS changes that could break authentication. A recent email delivery failure often starts with a forgotten key rotation.

Verify Before Deployment and Maintain Legacy Keys

  • Always test your DKIM records in a pre-production environment using tools that validate DNS resolution and cryptographic alignment. RFC 6376 details how DKIM signing should be validated by receivers.
  • Limited the number of active DKIM keys per sending service to one. Using multiple active keys can confuse receivers and dilute sender reputation.
  • Archive old keys for at least 30 days after rotation. Having historical keys available helps you debug delivery failures or analyze past message routing.
  • Confirm that your email service (e.g., SendGrid, Mailchimp) updates DKIM records correctly after key regenerations—some services require manual confirmation.
A single misaligned DKIM record can cause messages to be rejected or marked as spam, even if SPF and DMARC pass. Prevention is more efficient than post-failure recovery.

If you're validating the entire email infrastructure, you can test inbox placement and routing with tools that simulate real delivery checks. These tests help expose authentication failures before they impact your audience.

Test your message routing and inbox placement across major providers to catch DKIM misconfigurations before launch. The same tools can help you verify email addresses before sending, helping you avoid invalid or unreachable recipients.

Why Accuracy Matters: How MailTester Validates DNS and DKIM Real-Time

You fix a DKIM signature with a=rsa-sha256 but no public key in DNS by validating the exact DNS record your sending domain uses—MailTester checks the real-time DNS response, simulates the full SMTP handshake, and confirms whether the public key matches the signature. This prevents false positives and ensures your email passes authentication tests in actual inboxes, not just theory.

Real-Time Validation: What Happens Behind the Scenes

When you check a domain, we don’t rely on cached or static data. Instead, we query the current DNS records using real authoritative name servers, verifying the txt record for the DKIM selector. A mismatch—like a missing key or incorrect syntax—immediately flags the issue. If the signature uses a=rsa-sha256 but the public key isn’t accessible, we return a clear, actionable result.

We also simulate the entire SMTP path from sender to receiver, testing whether the server accepts the message based on actual rules—no simulated "yes" answers. This includes checking for greylisting, role account detection, and temporary bounces. This real-world behavior is why our accuracy is 98.9%: we’re not testing assumptions, we’re validating live sending conditions.

Trusted Diagnosis with AI Guidance

When a record fails, the result isn’t just “invalid.” MailTester shows you exactly what went wrong—whether it’s a syntax error in the DNS, a missing selector, or a key that’s not publicly available. We don’t just flag problems; we help you fix them.

The in-app AI assistant analyzes diagnostic logs and suggests corrections based on common patterns and industry standards. For example, if the key is present but misaligned with the DNS domain, it will recommend updating the selector or adjusting DNS settings. This turns a complex technical issue into a step-by-step fix.

Testing your setup doesn’t require a payment or long forms. You get 100 free verifications to check your domain, sender reputation, and DKIM alignment—no obligation, no risk. Use our email checker to test individual addresses or bulk verify a list before sending. Try it today and ensure your emails aren’t blocked by missing or incorrect DKIM records.

You Can Fix This Now—Without Waiting for DNS Propagation

DKIM issues aren’t invisible. A mismatch between your signature’s algorithm and your DNS record can cause bounces, spam filtering, or outright rejection. You don’t need to wait for DNS propagation to find out.

Use MailTester’s inbox-placement test to confirm your DKIM DNS record is live, correctly formatted, and matches the signing algorithm (a=rsa-sha256). This test simulates real-world delivery conditions and shows you exactly where authentication fails.

Run a real-time verification on your domain’s full authentication stack before your next send. Catch misconfigurations early—before they damage sender reputation or send batches are blocked.

Automate the fix across your tools

  • Integrate MailTester with Mailchimp, SendGrid, HubSpot, or Klaviyo to verify emails before every campaign.
  • Spot and correct DKIM mismatches in advance, without manual checks.
  • Keep your domain and domain policy alignment in sync across systems.

Sources

Keep reading

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

Frequently asked questions

What does DKIM 'a=rsa-sha256' mean?

It indicates the signature uses the RSA algorithm with SHA-256 hashing, a secure, standard method for email authentication.

Why is my DKIM key not in DNS?

Common reasons include missing DNS records, incorrect selector names, DNS propagation delays, or key rotation without updating DNS.

How long does DNS propagation take for DKIM?

Typically 1–24 hours, but can take up to 48 hours depending on the DNS provider and TTL settings.

Can I use multiple DKIM keys for different sending services?

Yes, you can configure separate DKIM selectors for different platforms like SendGrid or Mailchimp, each with its own DNS record.

Does DKIM prevent spam by itself?

No. DKIM verifies message authenticity but doesn’t prevent spam. It works alongside SPF and DMARC for full email security.

How do I test if DKIM is working after fixing DNS?

Send a test email to a mailbox like Gmail, then check its headers to verify the DKIM-Signature and confirm the public key resolves.

Can a DNS change break my DKIM setup?

Yes. Editing the wrong TXT record, changing the selector, or removing the key can break signature validation and harm deliverability.

Does MailTester check DKIM records automatically?

Yes. Our deliverability testing and bulk verification include real-time checks for DKIM, SPF, and DMARC alignment.

What happens if the DKIM public key is in DNS but wrong?

Email receivers will reject the signature, resulting in delivery failure or spam placement, even if the message is legitimate.

Is DKIM required for email deliverability?

Not mandatory, but strongly recommended. Most providers treat unverified DKIM as a red flag, especially for volume sending.

Can I use MailTester to find my DKIM selector?

No, but our inbox-placement test includes header analysis that reveals active DKIM selectors in outgoing messages.

Do purchased MailTester credits expire?

No. Credits never expire, so you can test your domain anytime without time pressure.