How to Verify DKIM Signature for 5.7.20 Compliance

Why 5.7.20 Bounces Are Blocking Your Emails

You’re sending to a key client. The message looks perfect. SPF passes. DMARC passes. But the inbox is empty. Instead, you get a 5.7.20 bounce — a clear signal from Microsoft’s servers that your DKIM signature failed to verify.

Even if everything else is correct, a single misaligned or expired DKIM signature can block your email. This error doesn’t care about your reputation or volume. It only cares about alignment and correctness — and it’s not hard to get wrong, especially when managing multiple domains or scaling campaigns.

Let’s be clear: 5.7.20 is not about spam. It’s about authenticity. Microsoft checks your DKIM signature to confirm the message wasn’t altered in transit. If the check fails, your email doesn’t get delivered — no exceptions.

Key takeaways

• 5.7.20 bounces stem from DKIM signature verification failure, even when SPF and DMARC pass
• DKIM alignment issues — like incorrect selector or domain mismatch — are a common root cause
• Automated tools can verify DKIM signatures in real time, preventing delivery failures before they occur

How to Verify DKIM Signature for 5.7.20 Compliance

To verify DKIM signature compliance with error code 5.7.20, check that the DKIM-Signature header is present, correctly formatted, and cryptographically valid—failing any of these triggers rejection. The error specifically flags missing, malformed, or unverifiable signatures, so alignment, syntax, and key consistency must all be confirmed.

What 5.7.20 Actually Checks

When a receiving server returns 5.7.20, it means the email failed DKIM verification—either the signature is absent, improperly structured, or doesn’t match the public key. This error is common in systems that enforce strict authentication policies, especially with Microsoft 365 or Outlook.com. The validation process includes checking domain alignment, signature format compliance, and the cryptographic signature’s validity against the published DKIM public key.

Let’s walk through what you need to verify step by step.

Key Checks to Confirm DKIM Compliance

Start with domain alignment: ensure the signing domain (d=) in the DKIM-Signature header matches the sender's domain in the From header. Misalignment breaks authentication even if the signature is technically valid. This is verified through DNS records—check that your DKIM TXT record is published correctly at the expected selector and domain.

Next, examine the signature format. The DKIM-Signature header must follow the standard format outlined in RFC 6376, with proper field order and encoding. A missing or incorrectly ordered field, like `b=`, can cause the signature to fail. Tools like MXToolbox’s DKIM Checker can help validate syntax.

Verify signature validity by performing a cryptographic check against the public key stored in your DNS TXT record. Any deviation—such as a mismatched hash or expired key—leads to verification failure. Use a tool that performs this check automatically to avoid manual errors.

Finally, confirm key consistency. If your key has been rotated, but the old key is still referenced in an email, that email will fail. Ensure only one valid key is in use at a time, and update your infrastructure to reflect key changes immediately.

If you’re running a large campaign and need to verify thousands of emails, tools like MailTester’s bulk verification can catch these issues before you send. For real-time validation, integrate with our email verification API. You can also test inbox placement directly with MailTester’s inbox tester.

Step-by-Step: How to Verify DKIM for 5.7.20 Compliance

You can verify DKIM for 5.7.20 compliance by retrieving the raw email source, extracting the DKIM-Signature header, fetching the public key from your domain’s DNS TXT record using the selector, then re-signing the message headers (excluding the DKIM-Signature) and comparing the resulting signature. Ensure the 'd=' domain matches your sender domain, 'q=' is 'DKIM', and the 'h=' list exactly matches the actual headers. A mismatch here fails 5.7.20 validation, which checks for proper authentication alignment and signature integrity.

1. Get the raw email source from your mail server or client—look for "View Original" or "Show Source." This reveals the full email structure, including authentication headers required for verification. Without the raw source, you can’t reliably examine DKIM or other headers.
2. Locate and decode the DKIM-Signature header. Find the DKIM-Signature header and extract the b= value. This is a Base64-encoded digital signature. Decode it using a standard Base64 decoder to get the raw signature bytes used in validation.
3. Fetch the public key from DNS. The s= value in the DKIM-Signature header indicates your selector. Use it to look up the public key in your domain’s DNS as a TXT record at selector._domainkey.yourdomain.com. This is where email receivers verify the signature.
4. Re-sign the headers and compare. Use a DKIM validator tool to re-sign the message headers (excluding DKIM-Signature) with the public key you fetched. The tool should output a new signature. Compare it to the original b= value—any difference means the signature is invalid or has been altered.
5. Check the 'd=' and 'q=' values. The d= must match your verified sender domain (e.g., example.com). The q= value must be DKIM (common on compliant systems). If q= is missing or set to something else, the authentication fails to align with 5.7.20’s rules.
6. Confirm the 'h=' header list matches. The h= value lists the headers included in the signature. It must exactly match the headers present in the message body, including order and spelling. Missing or extra headers break the signature.
7. Validate expiration and key status. The signature must not be expired—noted by the t= (timestamp) and x= (expiration) values. Also, ensure the DNS TXT record is still active and not outdated. A missing or expired key fails compliance.

Why This Matters for 5.7.20

Microsoft’s 5.7.20 error occurs when a message fails DKIM authentication due to alignment issues, mismatched domains, or invalid signatures. The protocol requires strict header alignment and correct cryptographic validation. Even minor gaps—like a missing h=From—trigger rejection. This process confirms compliance before you send to critical recipients.

Automate Verification with Tools

You can streamline this with tools like MailTester’s email verification API, which checks DKIM, SPF, and DMARC in real time. Or use inbox placement testing to verify delivery and authentication success across major inboxes. For large lists, the bulk verification tool can audit thousands of emails in minutes.

Detailed standards are defined in RFC 6376, which describes DKIM’s cryptographic framework. Follow it closely—this is not optional.

Common Causes of 5.7.20 Failures in DKIM

5.7.20 errors typically happen when a DKIM signature fails validation because of a misconfigured DNS record, expired key, mismatched selector, or header alignment issues. You’re likely hitting this error if your message fails SPF or DKIM checks at the receiving end, even if the sender appears legitimate. Let’s break down the most common technical reasons and how to fix them.

DNS and Key Configuration

• Check your DNS TXT record for the DKIM public key — it must be correctly formatted and published. Missing or malformed records cause immediate validation failure.
• Ensure your DKIM key hasn’t expired. Keys older than 365 days typically fail, especially with strict enforcement from providers like Microsoft and Google. Rotate keys before they expire.
• Verify the selector in the DKIM-Signature header matches the one in your DNS TXT record exactly. A mismatch — like using default vs mail — breaks validation.

Signature and Alignment Issues

• Review the 'h=' parameter in the DKIM-Signature header — it must list all headers being signed and should not include unsigned headers. Including an unsigned header like DKIM-Signature causes alignment failure.
• Some systems reject messages with multiple DKIM signatures. If you’re using third-party tools, they might add extra signatures — reduce to one per message.
• Confirm you're not using weak algorithms like SHA-1. Modern systems require SHA-256. Using SHA-1 is increasingly flagged as a security risk and can trigger 5.7.20 rejections.

For a real-time check, validate your DKIM setup against actual inbox environments using inbox placement testing. This reveals whether your DKIM is accepted by major providers before you send to real users.

DKIM is only as strong as its deployment — a single missing or malformed TXT record can break deliverability across major email platforms.

Many email providers, including Microsoft’s Office 365, mandate strict DKIM alignment. If you’re seeing 5.7.20 errors in logs, it’s rarely a delivery issue — it’s a signing or DNS issue. Review your setup against RFC 6376 for full correctness.

Use the MailTester API to validate DKIM signatures at scale during list cleansing or pre-send checks. You can also integrate it with Mailchimp, HubSpot, Klaviyo, or SendGrid to catch issues before they hit your audience.

How MailTester Validates DKIM for 5.7.20 Compliance

MailTester checks DKIM signatures in real-time during inbox-placement tests simulating delivery to Hotmail, Outlook, and Microsoft 365. It validates signature authenticity, header alignment, and key freshness—key requirements for 5.7.20 compliance—using actual Microsoft infrastructure.

Real-Time DKIM Checks in Simulated Inboxes

When you send a test email through MailTester’s inbox placement tool, it doesn’t just check if an address exists. It runs the full delivery simulation to Microsoft’s mail servers, including verifying the DKIM signature as it would be seen in a real inbox.

This means you’re not just testing an email address—you’re testing whether your message will be accepted, authenticated, and delivered without being flagged or rejected due to weak or malformed DKIM.

The system checks for valid cryptographic signatures, proper header alignment (From, Return-Path), and whether the public key is current—key factors Microsoft scrutinizes in its 5.7.20 delivery rejection notices.

What You Get: Actionable Verification Results

After each test, you get a clear status: valid, failed, or risky—along with detailed feedback on what went wrong. For example, if the DKIM signature is expired or the selector was misconfigured, MailTester will call it out.

You can verify individual emails or run full list checks across multiple domains, all without leaving the tool. The bulk verification option (available at mailtester.com/email-list-verify) lets you clean hundreds of addresses at once.

If you're unsure why a signature failed, use the in-app AI assistant. It interprets the error and suggests a fix—like regenerating the DKIM key or adjusting your DNS records.

For developers, the real-time verification API integrates DKIM checks directly into your workflow, ensuring every email sent meets compliance standards before delivery.

Microsoft’s 5.7.20 policy is rooted in RFC 6376, which defines DKIM and its role in email authentication. Misconfigured or missing DKIM is one of the top reasons emails get blocked or marked as spam. Validating DKIM early prevents these issues.

Tools like Spamhaus and RFC 6376 confirm that DKIM is foundational to modern authentication. MailTester doesn’t just check the box—it tests it under real-world conditions.

DKIM vs SPF vs DMARC: Their Roles in 5.7.20 Compliance

You need all three—SPF, DKIM, and DMARC—properly configured and aligned to avoid 5.7.20 blocks. SPF checks the sending IP, DKIM validates message content integrity, and DMARC enforces policy when either fails. A single DKIM failure can trigger 5.7.20, even if SPF and DMARC are correct. According to RFC 6376, DKIM’s cryptographic signature must match the message body and headers exactly; otherwise, the email fails authentication.

How Each Protocol Contributes to 5.7.20 Compliance

Let’s walk through the three protocols, not in order of importance, but in order of how they affect deliverability.

SPF ensures your server is on the approved list. DKIM ensures your email wasn’t altered in transit. DMARC decides what happens when either fails. If all three are in place but not aligned, you still get blocked. Misalignment can be subtle—e.g. your SPF uses example.com, but DKIM signs with mail.example.com. That’s a common misstep.

DKIM failures happen more than you’d think—not because of broken keys, but because tools like CDNs, marketing platforms, or email forwarding services alter content, breaking the hash. Even a single extra space in a header can invalidate the signature. The result? 5.7.20.

That’s why we recommend validating DKIM signatures early and often. Use tools that check both alignment and cryptographic validity. MailTester’s inbox placement tests include DKIM checks across major providers and can surface alignment problems before they cause delivery issues.

Prevent 5.7.20 Errors Before Sending

You prevent 5.7.20 errors by validating DKIM signatures in real time before sending high-value emails. This catches misconfigured or expired keys, alignment mismatches, and missing signatures before they hit Microsoft’s mail infrastructure. Tools that simulate Microsoft’s validation behavior help catch subtle issues that standard checks miss. Use automated checks and proactive monitoring to stay ahead of delivery failures.

Run real-time DKIM checks on critical campaigns

• Verify DKIM signatures before every high-volume or high-stakes send using a real-time API like MailTester’s verification API.
• Don’t trust static list validation — DKIM can fail even with a valid email address if the signature doesn’t match the current key.
• Use tools that emulate Microsoft’s validation process, including header and body hash matching and domain alignment checks.

Keep DNS and key configurations up to date

• Monitor your DKIM key rotation schedule. When keys expire, signing fails, leading directly to 5.7.20 rejections.
• Update DNS records proactively — don’t wait for a bounce to realize the key is no longer valid.
• Ensure every sender in your campaign uses consistent header signing and domain alignment. Misaligned or missing headers trigger authentication failures.
• Test across major provider infrastructures using inbox placement tools like MailTester’s inbox tester to see how your email performs in real-world conditions.

Let’s be clear: DKIM isn’t a one-time setup. Microsoft’s mail servers check every signature in real time, and even a minor misalignment or expired key can result in rejection. The best defense is continuous validation. According to RFC 6376, DKIM verification must account for header and body canonicalization, key selection, and domain alignment — all of which must be consistent across your campaign.

“A single invalid signature in a batch can trigger rejection across the entire message.”

Use tools that let you test full delivery paths — from DNS to inbox. MailTester’s inbox-testing tools simulate how Microsoft, Gmail, and other providers treat your email based on SPF, DKIM, DMARC, and content signals. These checks run against real mail server behavior, not just theoretical rules.

For bulk sending, run a full list verification with MailTester’s bulk verification to clean your list and flag domains that don’t support DKIM consistently. This reduces the risk of sending to domains where your signature will be rejected before delivery begins.

Remember: prevention beats cleanup. The cost of a single failed 5.7.20 attempt is high — lost conversions, damaged sender reputation, and wasted sends. Catching it early saves time, resources, and credibility.

Why Manual DKIM Checks Aren’t Enough

You can’t reliably verify DKIM signatures for 5.7.20 compliance with manual tools alone. Microsoft’s validation pipeline includes real-time checks across its mail infrastructure, including reputation scoring, header normalization, and pattern analysis—none of which simple online checkers replicate. Only testing under actual production conditions, like those used by Microsoft, will expose issues that lead to 5.7.20 rejections.

Manual Tools Miss Critical Validation Layers

Running a basic DKIM verifier in your browser or using a free online tool only checks if the DNS record exists and the signature math matches. That’s just the first step. Microsoft’s systems also evaluate how the signature aligns with other authentication signals like SPF, DMARC, and sender reputation—factors you can’t simulate with a standalone tool.

Even if your DKIM signature passes a syntax check, it might still fail in production due to minor header modifications, non-standard line endings, or signature timing—errors that only emerge during real mail flow. Tools like RFC 6376 define DKIM standards, but they don’t account for how systems like Outlook or Exchange apply those standards in practice.

Real-Time Testing Is the Only Way to Catch 5.7.20 Issues

Microsoft doesn’t validate DKIM in isolation. The entire message flow—including envelope-level checks, IP reputation, and historical sending patterns—determines whether a 5.7.20 error appears. A message that passes all manual tests might still be blocked if the sender has a weak reputation or if the domain has been involved in abuse.

That’s why you need inbox placement testing that runs on Microsoft’s infrastructure. MailTester’s inbox placement tests replicate how the Outlook ecosystem validates mail in real time, including DKIM signature checks within the full delivery chain. This reveals exactly why a message was rejected—whether it's a malformed header, a misaligned DMARC, or a signature that passes in theory but fails under live conditions.

Let’s be clear: You can’t debug 5.7.20 problems with a static, one-off check. You need to send actual messages through the system and observe the outcome. With MailTester’s inbox placement tests, you can validate DKIM compliance not as an isolated check, but as part of the full delivery process Microsoft uses to assess sender trust.

Integrate DKIM Verification into Your Workflow

You can verify DKIM signatures for 5.7.20 compliance by using MailTester’s real-time API to validate alignment during list hygiene or automation, integrate with platforms like SendGrid or Mailchimp to test sender infrastructure on every send, run bulk checks to catch expired or invalid DKIM records, and combine results with inbox placement tests to ensure full end-to-end deliverability. Let’s walk through how.

Automate DKIM Checks in Your Email Workflow

• Use the MailTester verification API to validate DKIM alignment on every email send or list import—no manual work required.
• Integrate with Mailchimp, SendGrid, HubSpot, or Klaviyo via the MailTester integrations to auto-validate sender infrastructure, reducing the risk of failure due to misconfigured DKIM records.
• Run bulk verification on your email list using MailTester’s list verification tool to identify domains with expired, invalid, or missing DKIM records—common causes of 5.7.20 rejection.
• Combine DKIM checks with deliverability tests using MailTester inbox placement testing to simulate real-world delivery across Gmail, Outlook, and other major inboxes.

Why It Matters: 5.7.20 and Real-World Outcomes

Authentication failures—especially DKIM misalignment—are often flagged by receiving systems like Microsoft or Google with error 5.7.20. This message typically means the DKIM signature didn’t validate or the alignment between the From domain and the signing domain failed. According to RFC 6376, proper DKIM signing and alignment are required for trusted email delivery, and receiving servers now apply strict enforcement.

Without regular verification, your sender infrastructure can drift. A domain might lose its DKIM key, a record could expire, or a new subdomain might be added without proper alignment. These issues go unnoticed until emails start bouncing or landing in spam folders.

By embedding DKIM verification into your workflow—whether via API, bulk process, or automated integrations—you’re not just chasing compliance. You’re ensuring that every email meets the technical standards that determine inbox placement. MailTester’s 98.9% accuracy rate is based on real SMTP and DNS validation, not guesswork.

Start with 100 free verifications at MailTester pricing. Credits never expire, and you can test any domain at scale—no matter how long your list or how complex your infrastructure.

How to Improve DKIM Signatures Over Time

Regularly auditing and refining your DKIM setup ensures long-term compliance with standards like 5.7.20. You should use consistent selectors, rotate keys on a 6–12 month cycle with DNS updates in advance, avoid multiple selectors unless required, monitor signature failures in real time, and verify DNS records with trusted tools. These steps reduce fragmentation, prevent delivery drops, and maintain sender reputation.

Maintain Consistency in Selector Usage

Stick to a single, long-lived selector like default or v1 across all your domains. Changing selectors frequently creates signature fragmentation, which harms authentication consistency and can confuse mail clients. If you must use multiple selectors, document the reason and ensure they’re properly managed in DNS. The DKIM RFC 6376 defines selector behavior and emphasizes the importance of predictable, stable configurations.

Plan Key Rotation and DNS Updates Proactively

Rotate your DKIM keys every 6 to 12 months. Never wait until the current key expires — update DNS records before expiration to avoid a gap in authentication. A misaligned expiration window is a common cause of authentication failures. Use real-time DNS monitoring tools to confirm propagation across networks. You can validate your DKIM configuration with inbox placement testing, which checks how your authenticated messages are received across major providers.

When monitoring DKIM verification, focus on failure trends rather than isolated events. Logging signature failures lets you catch misconfigurations early — like incorrectly signed headers or missing DNS entries. Tools like Spamhaus and MXToolbox offer free query interfaces to check DNS record visibility and propagation status.

Finally, avoid deploying multiple selectors per domain unless absolutely necessary — each adds complexity, increases the risk of error, and makes signature tracking harder. Keep the system simple: one selector, one key lifecycle, clear DNS records. Over time, this approach scales better, reduces bounce rates, and supports consistent inbox placement.

Consistency in DKIM configuration is not a minor detail. It’s foundational for deliverability.

Conclusion: Fix DKIM to Avoid 5.7.20 Bounces

The 5.7.20 error is not a spam filter failure. It’s a technical rejection due to missing or malformed DKIM signatures during SMTP handshake.

Verifying DKIM without testing delivery in a real pipeline gives false confidence. You need to validate both the signature and its impact on inbox placement.

MailTester’s real-time API, bulk verification, and inbox-placement testing deliver measurable proof of compliance across domains and campaigns.

With 98.9% accuracy and credits that never expire, you can trust the results to fix authentication issues once and for all.

Sources

• 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)
• 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)

Keep reading

• Email authentication: SPF, DKIM, DMARC, BIMI and MTA-STS (complete guide)
• Measuring DNS Reputation Shifts After Infrastructure Relocation
• Shopify Email Domain Setup with DKIM and SPF for Inbox Placement 2026
• Avoiding DMARC Failures from DKIM Expiry and X-Tag Misconfig
• PTR Record Generic Hostname Looks Dynamic Rejected

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

Frequently asked questions

What does the 5.7.20 error mean in email delivery?

The 5.7.20 error means Microsoft’s mail servers failed to verify the DKIM signature, typically due to misalignment, expired keys, or malformed headers.

Can I verify DKIM signatures without access to the raw email?

No. Full verification requires the raw source, including headers and the DKIM-Signature field. Tools like MailTester can extract and validate this during inbox tests.

How often should I rotate my DKIM keys?

Every 6 to 12 months. Always update DNS records before expiration to prevent delivery failures.

Does DKIM need to align with SPF and DMARC?

Yes. For DMARC to pass, both SPF and DKIM must align with the From domain. Mismatched alignment causes delivery failure.

Can a valid SPF fail and still trigger 5.7.20?

No. 5.7.20 is triggered only by DKIM failure. SPF issues cause different error codes.

How does MailTester test DKIM for 5.7.20 compatibility?

It uses real Microsoft email infrastructure in inbox placement tests, checking DKIM signature validity, header alignment, and key freshness.

Is DKIM verification required for all emails?

Only if you’re sending through Microsoft services or want to pass DMARC policies. It’s the standard for deliverability across modern email providers.

What happens if I ignore 5.7.20 errors?

Emails will be blocked, delayed, or marked as spam by Microsoft services, especially in B2B or B2C mail flow.

Can I automate DKIM verification in my pipeline?

Yes. MailTester offers an API for bulk and real-time verification, with integrations for Mailchimp, SendGrid, and HubSpot.

Does MailTester support DKIM verification for multiple domains?

Yes. You can verify DKIM alignment for any domain using the API, bulk tool, or inbox tests.

Are there free tools to verify DKIM signing?

Some domain tools show basic DKIM records, but only tools like MailTester that simulate actual inbox behavior can test delivery compliance like 5.7.20.

What’s the difference between DKIM and DMARC?

DKIM validates message integrity and origin. DMARC defines what to do if SPF or DKIM fails—it’s a policy layer built on top of them.