Why DKIM Signing Failure Causes 5.7.20 Bounces

You sent a campaign. It hit inbox zero. Then—no bounce, no warning, just silence. You check your logs and find a 5.7.20 error: "Authentication failed." It’s not a glitch. It’s DKIM saying, “Nope.”

That code doesn’t mean your message was spam. It means your signature didn’t pass. And if it’s not signed or it’s signed wrong, even one failure locks out your entire send list from Gmail, Outlook, and Yahoo. No grace. No warning. Just block.

DKIM isn’t optional. It’s the digital fingerprint proving your email is really from you—and not a spoof. When it fails, your domain reputation takes a hit. Testing how to test if DKIM is properly signed for 5.7.20 isn’t just technical—it’s survival.

Key takeaways

  • A 5.7.20 SMTP error indicates the receiving server rejected your email due to a missing or invalid DKIM signature.
  • Even one improperly signed message can trigger full campaign blocks from Gmail, Outlook, and Yahoo due to authentication failure.
  • DKIM misconfigurations—like wrong key lengths, incorrect headers, or mismatched algorithms—are common culprits behind 5.7.20 bounces.

How to Test if DKIM Is Properly Signed for 5.7.20

You can test if DKIM is properly signed for 5.7.20 by verifying that your domain’s public key is published in DNS under the correct selector, your server signs messages with the matching private key, the signature digest matches the signed header fields, the signing domain (d=) aligns with the From address, and you validate the actual delivered message using raw headers. Use a tool that checks real delivery attempts, not just static configurations.

Step-by-step DKIM validation process

  1. Check your DNS for the DKIM public key. Use a domain-level DKIM analyzer to confirm the public key is published under the correct selector (e.g., selector1._domainkey.yourdomain.com) in a TXT record. A mismatch here breaks validation before any message even sends.
  2. Verify your email server applies the correct private key. Ensure your mail server uses the matching private key during message generation. The signing process must be consistent across all messages to avoid partial validation failures.
  3. Validate the signature digest matches the signed header fields. The DKIM-Signature header must include a d= (domain), s= (selector), and h= (header fields signed). The h=To:From:Subject:Date list must exactly match what’s signed, and the digest must align with the actual content—any change breaks the chain.
  4. Confirm the signing domain matches the From address. The d= value in the DKIM signature must match the domain in the From header. If it doesn’t, the email fails alignment, especially under strict policies like DMARC. This is what stops spoofing.
  5. Test with a live delivered message (not a template). Use a tool that pulls raw headers from an actual message delivered to an inbox or a test recipient. DKIM can look correct in theory but fail in practice due to headers altered during transit (e.g., by relays or filters).

Why real-world validation matters

Many tools only check DNS records or static headers. But DKIM can fail on delivery due to header rewrites, MIME encoding, or email filtering. The only way to catch these issues is testing against the full, delivered message.

Tools like MailTester’s inbox placement tester let you send a message to real inboxes and pull back the raw DKIM validation result. This confirms not just that the signature exists, but that it passes in the wild—where deliverability actually happens.

For bulk senders, MailTester’s API can validate DKIM consistency across thousands of emails, catching misconfigurations before they harm sender reputation.

Refer to RFC 6376 for the full technical spec on DKIM. While most email providers implement it, differences in how they handle header normalization can still cause validation drift. Checking against actual delivery—especially with tools that replicate real inbox behavior—is the most reliable approach.

What Happens When DKIM Signature Is Invalid

When a DKIM signature is invalid, the receiving server rejects the email with a 5.7.20 error—regardless of whether SPF and DMARC validation passed. This means your message won’t reach the inbox, even if all other authentication checks are clean. The error signals that the cryptographic signature couldn’t be verified, which undermines trust in the message's origin.

Why the Signature Fails

Even if you’ve set up DKIM correctly, the signature can still fail due to a broken signing chain. For example, if you updated your DKIM private key but forgot to publish the new public key in DNS, the receiving server won’t be able to validate the signature. This mismatch happens more often than you’d expect—especially during infrastructure changes or migrations.

Some email providers, particularly those with mobile or enterprise-grade security policies—like Microsoft 365 or Google Workspace—apply stricter validation rules. They’ll flag or block messages with minor DKIM anomalies, even if the core domain is trusted. It’s not a flaw in your setup; it’s just how high-security systems respond to inconsistencies.

How to Prevent and Detect

Let’s not guess. You can test DKIM directly by sending a message from your domain and checking the raw headers in the recipient’s inbox. Look for a DKIM-Signature header and verify that the q=dkim tag exists and resolves to a valid public key. The DKIM specification outlines the exact format, and tools like MXToolbox can help verify the DNS record alignment.

If you’re managing a high-volume email list, you should verify DKIM compliance across your entire sender base. You can use MailTester’s bulk email verification to check the validity of your entire list, including whether domains are properly configured for DKIM, SPF, and DMARC. The service checks 98.9% of domains accurately and flags issues like missing or malformed DKIM records.

For automated workflows, the MailTester API allows you to verify DKIM status in real time during onboarding or campaign preparation. It’s built for developers who need reliable data without clutter.

Remember: a single invalid DKIM signature can tank deliverability across thousands of messages. Catching it early—before it hits a major provider—keeps your sender reputation intact.

Common Causes of DKIM Misconfiguration

DKIM fails for 5.7.20 when the signature doesn’t match the server’s DNS record, a common issue caused by missing or incorrect DNS entries, wrong selectors, unsupported algorithms, improper header signing, or expired signatures. Let’s walk through the most frequent root causes you’re likely to encounter.

DNS and Selector Issues

  • The DKIM DNS record is absent or malformed—check via MXToolbox or your DNS provider’s console.
  • The selector name (like default._domainkey.example.com) doesn’t match what your email server uses. A mismatch here means the receiving server can’t locate the public key.
  • Using a selector that’s not published in DNS, or publishing it with incorrect syntax (e.g., missing period or extra whitespace), breaks the validation chain.

Signing and Algorithm Problems

  • The signing algorithm (e.g., rsa-sha256) isn’t supported by the receiving server or is misconfigured. Use only widely accepted algorithms; avoid proprietary or weak ones.
  • Incorrect padding or key length—some servers reject keys under 1024 bits or fail validation for incorrect padding schemes like PKCS#1 v1.5 vs. PSS.
  • Non-signable headers (e.g., Date, Message-ID) are included in the signature, or headers are signed in the wrong order. Per RFC 6376, only specific headers are intended to be signed.
  • Signing a mail before or after the message body is processed inconsistently. The body must be canonicalized the same way both when signing and verifying.
    • Use tools like DKIM Validator to test signature structure and alignment.

Expiration and Delivery Timing

  • The DKIM signature’s expiration time (expires tag) is set too low. A signature expiring before delivery—especially in long campaigns—results in rejection.
  • Some servers reject messages with expires=0 or missing expires header. Always define a reasonable expiration (e.g., 1 hour or more).
  • Delayed delivery due to queueing or retries can cause signatures to expire by the time the mail reaches the recipient. Test long-running workflows with real delivery timing.

If you're sending bulk mail or testing deliverability, use MailTester’s inbox-placement tool to see whether your DKIM signatures are passing on real inboxes. You can also test individual domains with the real-time verification API to catch misconfigurations before they cause bounce rates or spam flags.

SPF vs DKIM vs DMARC: Roles in Deliverability

You need SPF, DKIM, and DMARC working together to ensure your emails reach inboxes consistently. SPF checks if the sending server IP is authorized by the domain. DKIM verifies the message wasn’t altered and confirms the sending domain. DMARC enforces policies based on SPF and DKIM results and delivers aggregate reports. If any one fails — especially DKIM in the case of a 5.7.20 error — your email may be rejected, even if SPF passes. This is why testing DKIM signature validity is critical for deliverability.

How Each Protocol Works in Practice

Let’s break down the roles, because misunderstanding one can break the whole chain.

Protocol Primary Role How It’s Checked Impact of Failure
SPF Verifies the sending server IP is authorized by the domain’s DNS record Domain’s SPF TXT record lists allowed IPs. Receivers check if the sending IP matches Can cause soft bounces or low inbox placement; less likely to cause hard 5.7.20 failures
DKIM Authenticates that the message content hasn’t been altered and verifies the sending domain Message is signed with a private key. Receiver verifies using the public key in DNS Failure triggers hard bounces in strict mail systems like Microsoft 365 — a direct cause of 5.7.20 errors
DMARC Enforces policies based on SPF and DKIM results and provides reporting Domain’s DMARC record sets policy (none, quarantine, reject) and defines where to send reports Without DMARC, you can’t enforce policy or see if spoofing is happening

Here’s the catch: DKIM failure alone can trigger a 5.7.20 error — a hard bounce — even if SPF passes. This happens because Microsoft’s systems treat DKIM as a strict integrity check. If the signature is missing, malformed, or doesn’t align with the header domain, the message is rejected outright. It’s not about sender reputation alone; it’s about cryptographic proof.

If you’re troubleshooting 5.7.20 errors, check your DKIM signature first. Tools like MailTester’s inbox placement test simulate real-world delivery and can verify DKIM signature validity across major providers.

It’s worth noting that while SPF and DKIM are technical checks, DMARC is the enforcement layer. Without DMARC, you’re flying blind — no visibility into spoofing attempts, no policy enforcement. The IETF’s DMARC specification (RFC 7483) provides a solid foundation for domain owners to control how receivers handle failed messages.

How MailTester Validates DKIM Signatures During Inbox Testing

You can test if DKIM is properly signed for a 5.7.20 bounce by sending a real message to actual inboxes via MailTester's inbox placement tool. It checks DKIM, SPF, and DMARC alignment on delivery, returns SMTP responses and full header analysis, and flags missing, invalid, or misaligned signatures—including expired keys or strict DMARC policies blocking delivery.

Real Inboxes, Real Feedback

MailTester sends test messages to live Gmail, Outlook, Yahoo, and Apple iCloud accounts—not dummy or simulated ones. These inboxes evaluate your message just like real users would, including checking DKIM signatures against the public key published in DNS. If the signature is missing, malformed, or expired, you’ll see a clear indicator in the delivery log.

For example, if your domain’s DKIM record has expired, the receiving server rejects the message with a 5.7.20 error. MailTester captures this exact response, so you know not just that it failed, but why—down to the specific reason in the SMTP code and header details.

Full Context from SMTP and Headers

Each test returns a complete delivery log with the raw SMTP transaction and header analysis. You can see exactly where the failure occurred: whether the DKIM signature was present but invalid, or if the alignment between the signing domain and the From domain failed.

The log also checks DMARC policy enforcement. If DMARC is set to reject or quarantine, and DKIM fails, the message won’t reach the inbox. MailTester flags this condition so you can adjust your configuration before sending to real users.

You can verify this process using tools like the DKIM specification (RFC 6376), which defines how signatures are generated and validated. Misalignment—such as a domain=example.com signing key but a From: [email protected]—is a common trigger for 5.7.20 errors, and MailTester detects it explicitly.

If you're managing a large list, the bulk verification tool lets you check DKIM and other deliverability factors across hundreds of emails at once. For automation, the verification API gives real-time DKIM checks. And if you want to simulate user behavior with inbox placement, the inbox tester gives you visibility into how your emails land across real platforms.

Using the MailTester API to Check DKIM Signatures at Scale

You can test if DKIM is properly signed for 5.7.20 errors by submitting raw email headers to the MailTester API. It checks DKIM, SPF, and DMARC in seconds and returns structured results, helping you catch invalid signatures before sending. This prevents deliverability issues and reduces bounces caused by authentication failures.

How It Works in Practice

  1. Integrate the MailTester API into your send workflow. Use the real-time verification API endpoint at https://mailtester.com/api-email-checker to automate checks during list preparation or campaign dispatch.
  2. Submit raw email headers for analysis. Include the full MIME headers of your outgoing message. This lets MailTester validate the DKIM signature signature against the domain’s public key, as defined in RFC 6376.
  3. Review the response for DKIM validation status. The API returns a clear result: "valid", "invalid", or "missing". A failed DKIM signature is a direct cause of 5.7.20 rejection codes from receiving servers like Microsoft 365.
  4. Automate pre-send filtering. Use the results to remove emails with invalid or missing DKIM signatures from your send list. This proactively avoids 5.7.20 errors across bulk campaigns.
  5. Build validation into your pipeline. Schedule regular checks for high-value or frequently used domains. This ensures consistency, especially when using templates or third-party tools that may not always sign messages correctly.

Scale Without Compromise

For teams managing large or frequent campaigns, manual checks don’t scale. The MailTester API processes multiple messages in parallel, returning results in under 2 seconds per email. You can verify 10,000+ addresses in minutes.

Use this data to clean your list before sending. Tools like bulk verification let you test entire address lists, while integrations with platforms like Mailchimp, HubSpot, Klaviyo, and SendGrid ensure validation happens at the point of use.

When DKIM fails, 5.7.20 is often the result. A valid signature isn’t just a technical formality—it’s a signal of trust from the sender’s infrastructure to the receiver.

Testing DKIM at scale isn’t optional for high-volume or high-criticality sends. With the right tooling, it becomes routine. MailTester’s API gives you the visibility and control you need to prevent deliverability failures before they happen.

Integrating MailTester with SendGrid, Mailchimp, and Klaviyo

You can test if DKIM is properly signed for 5.7.20 errors by syncing your SendGrid, Mailchimp, or Klaviyo mailing list directly into MailTester. It checks headers, validates authentication, and flags DKIM fail reasons — including 5.7.20 — in bulk, so you fix issues at scale without digging through raw emails. No API keys, no debugging, just quick results.

Run Bulk Deliverability Tests with Real-Time DKIM Validation

Let’s say you’re seeing high bounces after a campaign. Instead of guessing, pull your list from SendGrid, Mailchimp, or Klaviyo into MailTester. The app doesn’t just check if an email exists — it simulates send conditions and validates SPF, DKIM, and DMARC in real time. This means you catch 5.7.20 errors (commonly triggered by malformed or missing DKIM signatures) before they hit inboxes.

Each result includes a clear label: “Valid,” “Invalid,” “Catch-all,” or “Risky.” If a message shows a DKIM failure, MailTester specifies whether the signature is missing, malformed, or mismatched. This level of detail helps you trace configuration gaps in your ESP’s settings. It’s not just a pass/fail — it’s diagnostic.

According to RFC 6376, DKIM signing must be applied to all headers involved in email authentication to be effective. When your ESP uses a flawed signing path, receivers like Yahoo or Gmail treat that as a risk. MailTester confirms this in practice, not theory.

Fix Issues at Scale Without Manual Header Inspection

Manually checking DKIM headers for a 10,000-person list? That’s not scalable. With MailTester, you run a bulk test on your full send list and see exactly which domains and emails fail authentication — ranked by error type.

Need to act fast? You can export the data and update your DKIM records in bulk. Or, if you’re using Klaviyo, you can clean your list in-app and resync. The same applies to Mailchimp or SendGrid. You’re not just validating — you’re preventing future failures.

For real-time testing during onboarding, try the MailTester email verification API. For high-volume campaigns, the bulk verification tool handles thousands of emails in minutes. Want to see how your message lands in real inboxes? Run an inbox placement test after fixes.

What You Can Do About Failed 5.7.20 Bounces

If your emails are being rejected with error code 5.7.20, it means the receiving server couldn’t validate your DKIM signature. The most common cause is a misconfigured or mismatched DKIM record. You need to check the full message headers, confirm the DNS record aligns with your signing key, and ensure the selector and domain in the signature match your published DNS entry. Let’s walk through how.

Step-by-Step Diagnosis

  1. Review the full message headers from the failed delivery attempt. Look for the Authentication-Results and DKIM-Signature fields. These show whether the server attempted to verify the signature and where it failed. A missing or malformed signature here is a red flag.
  2. Verify your DKIM DNS record using a public tool. Use MxToolbox or the RFC 6376 specification to check the TXT record published at your domain. Ensure the record includes the correct selector (e.g., selector1._domainkey.example.com), the public key, and valid syntax.
  3. Confirm the private key matches the public key in DNS. The private key used to sign messages must correspond exactly to the public key in your DNS record. A mismatch here—common when keys are rotated or reissued—will trigger a 5.7.20 failure. Double-check the key content in both places.
  4. Re-sign messages with the correct selector and domain. If the selector in the signature (e.g., s=selector1) doesn’t match the DNS record, re-sign your outgoing messages using the correct selector and domain. This ensures the receiving server can locate the proper public key for validation.

When You’re Unsure — Double-Check the Format

DKIM syntax is strict. Even a missing space or a typo in the domain field can break the signature. Use a tool like DKIM Validator to test the signature structure. The RFC 6376 outlines the required fields and format, making it a reliable reference.

Once you’ve corrected the signature, retry sending. Most receivers accept messages within minutes, though some may cache the failure for up to 24 hours. If issues persist, check if your sender reputation or domain was recently flagged.

Use MailTester’s bulk verification tool to scan your mailing list for invalid or malformed addresses before sending. It can catch delivery issues before they trigger bounces. For real-time validation, integrate the verification API early in your send workflow. You can also test inbox delivery with inbox placement to confirm your DKIM is functioning in live environments.

Why Real-Time Testing Beats Static Checks

Static DNS checks only confirm that a DKIM record exists—they don’t prove a message was actually signed during delivery. To truly validate if DKIM is working for a 5.7.20 bounce, you need real-time inbox testing that simulates actual delivery and checks whether the signature passes authentication in live mail servers. Tools like MailTester’s inbox placement tester verify this by sending test emails to real inboxes and measuring delivery, authentication, and inbox placement results.

What Static Checks Miss

Just because a DKIM public key is published in DNS doesn’t mean it’s being used correctly. A misconfigured selector, expired key, or broken signing process means the signature won’t validate—even if the DNS record is present. Static tools won’t catch these issues because they don’t send real messages through real mail servers.

What Real-Time Testing Reveals

Real-time inbox testing does more than verify DKIM—it checks whether the message reaches the inbox, passes spam filters, and avoids blocks. It also detects behavioral red flags like sudden spikes in spam complaints, low open rates, or sender reputation drops that static checks ignore. These signals are critical for diagnosing why a 5.7.20 error occurs, as they often signal broader deliverability problems beyond authentication.

For example, a message might pass DKIM and SPF but still bounce due to a compromised sending reputation. Real-time testing surfaces this issue. Unlike static DNS lookups, tools like MailTester’s inbox placement tester simulate actual email delivery across major providers, giving you insight you can’t get from syntax checks alone.

MailTester's inbox placement service runs tests through real inboxes and reports on delivery success, inbox placement, spam scores, and authentication status—including DKIM and SPF checks. Its 98.9% accuracy ensures results align closely with real-world outcomes. This accuracy comes from testing actual messages through real mail servers, not just querying DNS records.

Let’s say you’re troubleshooting a 5.7.20 error: you check DNS and find the DKIM record is present. But your emails still bounce. A static check won’t explain why. Real-time testing will—and it’ll tell you if the signature is being applied correctly during delivery, whether the sender is flagged, or if the message triggered a spam filter.

For teams needing to validate configurations at scale, MailTester’s real-time inbox tester is accessible via the inbox placement page. You can test single emails or bulk lists with full deliverability scoring, helping you catch issues before they affect campaigns. The tool integrates with platforms like HubSpot, Mailchimp, and SendGrid via the integrations page, allowing automated verification into your workflow.

Conclusion: Fix DKIM Before Every Sending Campaign

A 5.7.20 bounce isn’t just a technical error—it indicates a failure in the email authentication chain. If DKIM isn’t valid, aligned, or published correctly in DNS, your messages won’t reach inboxes, regardless of content quality.

DKIM must be properly configured, aligned with the sending domain, and verified in DNS to prevent delivery failures. Use MailTester’s inbox-placement tests and real-time API to validate sender authentication before every campaign starts.

  • Check DKIM signatures before each send.
  • Ensure SPF and DMARC alignment are correctly set.
  • Run full deliverability checks on test lists.

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 5.7.20 mean in email delivery?

It’s an SMTP error code indicating the receiving server rejected the message due to a failed or missing DKIM signature.

Can DKIM fail even if SPF passes?

Yes. SPF and DKIM are independent checks. A passing SPF does not guarantee DKIM is valid.

How do I check if my DKIM record is correct?

Use a DNS lookup tool to verify the public key is published under the correct selector and domain in your DNS.

Does MailTester test DKIM signing on every message?

Yes — MailTester checks DKIM signatures during real inbox testing and via its API by analyzing message headers.

Why does DKIM fail in bulk emails?

Common causes include misconfigured signing servers, expired keys, or inconsistent signing algorithms across messages.

Can a correct DKIM record still cause a 5.7.20 error?

Yes — if the message isn’t signed with that key, if the selector is wrong, or if headers were modified in transit.

What’s the difference between DKIM and domain alignment?

DKIM signs the message, but domain alignment ensures the signing domain matches the From domain.

How often should I test DKIM configuration?

Test every time you update your email infrastructure, change senders, or after DNS changes.

Can MailTester help with DMARC reporting?

It doesn’t generate DMARC reports, but it validates DMARC policy enforcement and alignment during inbox tests.

Is DKIM required for sending emails?

Not required by all providers, but failure to implement it consistently results in 5.7.20 bounces and lower inbox placement.

Does MailTester support testing on mobile devices?

Yes — tests are conducted on real inboxes across email clients, including mobile platforms like iOS Mail and Android Gmail.

How many free verifications does MailTester offer?

100 free verifications are available to start, with purchased credits that never expire.