Why does DKIM matter in email verification?

You send an email. It’s from a real person. It’s on-brand. Yet it lands in spam — not because of content, but because the signature didn’t check out. That’s what happens when DKIM isn’t validated.

Dkim isn’t just a technical detail — it’s proof your email actually came from the domain it claims. Without it, even valid addresses get flagged. Most email validation tools skip this check entirely, relying on basic syntax and mailbox existence. But a real email verification API that checks for DKIM in 5.7.20 context does the heavy lifting: it queries DNS, validates the cryptographic signature, and confirms authenticity during delivery conditions.

Key takeaways

  • A valid DKIM signature is required for inbox delivery in 5.7.20 context, the standard modern email authentication environment.
  • Most email validation tools only check syntax and mailbox existence — they don’t verify DKIM signatures by querying actual DNS records.
  • An email validation API that checks for DKIM in 5.7.20 context ensures that only addresses with properly configured authentication are deemed valid, improving deliverability and sender reputation.

What does ‘5.7.20’ mean in an email verification context?

The SMTP response code 5.7.20 means “5.7.20 SMTP; message rejected: bad sender or authentication failure.” It’s returned by receiving mail servers when they detect a problem with sender authentication—most commonly a DKIM signature failure—even if the recipient address itself is valid. You’ll see this bounce when your message is rejected due to weak or broken authentication, not because the email doesn’t exist.

Why 5.7.20 matters for email deliverability

Let’s be clear: getting a 5.7.20 response doesn’t mean the email address is invalid. It means your message failed to prove it came from a trusted source. This is often due to misconfigured or missing DKIM signatures. Receiving servers use such codes to block sender impersonation and reduce spam delivery.

When a significant portion of your outgoing emails trigger 5.7.20 bounces, it signals that your authentication setup needs attention. This isn’t just a technical hiccup—it harms sender reputation. Even a single failed DKIM check can hurt your standing with providers like Gmail, Outlook, or Yahoo.

DKIM checks are part of a broader authentication chain. SPF and DMARC rely on DKIM to verify message integrity. If DKIM fails, SPF and DMARC are often ignored. This makes 5.7.20 one of the most telling signs of sender risk. According to RFC 6376—the standard defining DKIM—signature validation is mandatory for messages claiming to be from a domain.

How to fix and verify sender authentication

If you’re getting 5.7.20 bounces, your first step is to audit your DKIM setup. Are your keys published correctly in DNS? Is the signing domain aligned with the “From” header? Small mismatches can trigger rejection, even if the address is valid.

That’s where a real-time verification API helps. By checking individual addresses and validating their alignment with authentication mechanisms, you can catch weak sender setups before sending. MailTester’s email validation API includes checks for DKIM viability, helping you identify not just invalid addresses, but poor senders.

Use bulk verification to clean high-volume lists and spot patterns of 5.7.20 bounces. Combine it with inbox placement testing to see how your authenticated messages truly land in real inboxes. With accurate data, you can act—not guess.

How does MailTester check for DKIM in 5.7.20 context?

MailTester checks for DKIM in 5.7.20 context by retrieving the domain’s DKIM public key from DNS, simulating an SMTP transaction with a test message signed using that key, and monitoring for a 5.7.20 bounce response. If the receiving server rejects the message with that code, the address is flagged as high-risk—even if it’s technically deliverable. This detects domains with strict enforcement policies that block messages lacking properly configured DKIM.

Step-by-step process

  1. Fetch DKIM DNS records MailTester queries the domain’s DNS records to locate the DKIM public key published under the selector. This is the first step in verifying whether a domain signs its emails with DKIM, per RFC 6376.
  2. Simulate an SMTP transaction Using a real, temporary email address, MailTester sends a test message through a controlled SMTP session. The message is signed with the retrieved DKIM public key, mimicking a legitimate outbound email from that domain.
  3. Monitor the receiving server’s response The test message is delivered to a monitored mailbox endpoint. If the server rejects the message with a 5.7.20 error—meaning “message rejected due to invalid or missing DKIM signature”—MailTester logs it as a high-risk signal. This response is not a bounce, but a delivery policy enforcement.
  4. Flag high-risk addresses Even if the email address is valid and the domain is reachable, a 5.7.20 response means the target server actively enforces DKIM. If a message fails this check, it gets blocked. MailTester marks such addresses accordingly, helping you avoid sending to servers that will discard your email before it arrives.

Why this matters for deliverability

You might assume a valid email address will always get through. But some domains are set up to reject any message without a valid DKIM signature. If your sender domain is not properly authenticated, even valid emails fail. MailTester identifies those exceptions before you send.

Many enterprise and corporate email systems apply strict policies, such as those from Microsoft, Google, or Salesforce, enforcing DKIM as part of their inbound filtering. A 5.7.20 rejection in SMTP is a clear signal from the receiving server that authentication didn’t pass. It’s a red flag—especially if you’re not yet using DKIM yourself.

By catching this early, MailTester prevents you from sending to domains that will silently block your message. You can fix your email infrastructure or filter these addresses from your list before sending.

For real-time verification, integrate MailTester’s email validation API. Run bulk checks with bulk verification, test inbox placement with inbox placement testing, and connect to your CRM or ESP using our integrations. With 98.9% accuracy and credits that never expire, MailTester helps you build a clean, deliverable list. Check pricing to get started with 100 free verifications.

Why you need a validation API that checks DKIM in 5.7.20 context

You need an email validation API that checks DKIM in 5.7.20 context because many "valid" addresses fail delivery due to authentication misconfiguration—something syntax-only tools miss. Without checking DKIM, you risk sending to addresses that accept mail but reject your message, hurting deliverability and sender reputation. MailTester’s API detects this risk in real time, so you send only to addresses that are both valid and properly authenticated.

Most tools stop at the basics—missing the real delivery blockers

Many email validation tools check for basic syntax, existence, and whether an address is a role account like admin@ or sales@. That’s a start—but it doesn’t tell you if the domain’s DKIM is set up correctly. An address can pass all those checks yet still reject your email because of a failed DKIM signature.

Let’s say your system validates 10,000 addresses and marks them all as "valid." You send to them. But if 30% of those domains have broken DKIM, your messages are likely to be rejected with a 5.7.20 error—meaning the recipient’s server authenticated the message as coming from an unverified source. This isn’t just a bounce; it’s a deliverability red flag.

DKIM is a gatekeeper. You need to check it before sending

SMTP error code 5.7.20 specifically indicates that DKIM validation failed. It’s common in business and enterprise mail systems. The RFC 6376 specification defines how DKIM works, and proper setup is mandatory for trusted delivery. If your sender domain isn't correctly signed, even a valid email will be blocked—regardless of the address existence.

That’s why MailTester’s API doesn’t just check if an address exists. It performs a full authentication check, including DKIM, in the context of standard recipient server behavior. This means you catch risky addresses before they hit your sending platform—cutting bounces and protecting sender reputation.

You’re not just verifying syntax. You’re verifying that your email will be accepted at the inbox level. For teams using SendGrid, Mailchimp, or HubSpot, integration with MailTester’s real-time verification API ensures only authenticated, deliverable addresses get sent.

With 98.9% accuracy, MailTester identifies invalid, catch-all, disposable, and risky addresses—especially those failing DKIM verification. This reduces wasted sends and keeps your sender reputation strong. It’s not just a list cleaner. It’s an inbox-placement safety net.

A few bad messages can trigger spam filters or blacklisting. By detecting DKIM failures early, MailTester helps you avoid those pitfalls. No more guessing. Just verified, deliverable email.

How DKIM, SPF, and DMARC work together in real-world verification

You need all three—SPF, DKIM, and DMARC—to be properly configured and aligned for an email to pass authentication checks and land in the inbox. SPF authorizes the sending server, DKIM ensures the message content hasn’t changed, and DMARC enforces what happens when either check fails. If any one fails, the email risks rejection, filtering, or being marked as spam—even if the address itself is valid.

SPF, DKIM, and DMARC: the foundation of email authentication

Let’s break down how each protocol functions in practice. SPF uses DNS records to list IP addresses authorized to send emails on behalf of a domain. DKIM adds a digital signature to the email header and body, validating that the content was not altered in transit. DMARC sits on top, enforcing policies based on SPF and DKIM results—telling receiving servers what to do if authentication fails.

Protocol Role How It Works Validation Check in API
SPF Server authorization Checks if the sending server’s IP is listed in the domain’s DNS TXT record. Valid if the sending IP matches a published SPF record.
DKIM Content integrity Verifies the message hash matches the signature in the DKIM-Signature header. Valid if the signature is present and mathematically correct.
DMARC Policy enforcement Dictates action (none, quarantine, reject) based on SPF/DKIM results. Valid if the domain has a published DMARC policy and results align.

In real-world verification, a single failure—like a missing DKIM signature—can sink delivery even if the email address exists and the server is legitimate. That’s why tools like MailTester check DKIM specifically in the context of a 5.7.20 bounce response. This code indicates a delivery failure due to policy rejection—often because DMARC failed, meaning SPF and DKIM didn’t align.

Why real-time verification matters

An email might be syntactically correct but still blocked. That’s where an email validation API that checks for DKIM in a 5.7.20 context becomes critical. It doesn’t just confirm an address exists—it simulates the receiving server’s decision process. If SPF and DKIM don’t align under DMARC, the API flags it as risky or invalid.

Use the MailTester API to verify your list with real-time checks for SP, DKIM, and DMARC alignment. The tool integrates with platforms like Mailchimp and Klaviyo, and you can test inbox placement with MailTester Inbox Tester. It’s not just about catching typos—it’s about building sender reputation from the ground up.

What the ‘5.7.20’ error tells you about recipient server behavior

When a server returns the 5.7.20 error, it means the recipient’s mail system detected a mismatch or absence in DKIM authentication—often because the signature doesn’t match the header or the public key isn’t available. This isn’t a syntax or routing issue; it signals the message was rejected due to failed authentication, even if the recipient address is valid. If you’re seeing 5.7.20 consistently, it’s a red flag that your sender authentication isn’t aligned with what receivers expect.

Why 5.7.20 matters for deliverability

DKIM is a key part of email authentication. Servers that enforce strict policies—especially large providers like Gmail, Outlook, or Apple—will block messages with broken signatures. The 5.7.20 code is their way of saying: “We can’t trust this message.” This happens even if the email address exists and the SMTP handshake completes—meaning your message is technically deliverable but is treated as potentially spoofed or compromised.

It’s a common pattern for bulk senders to overlook DKIM alignment during list maintenance or campaign setup. A missing or misconfigured DKIM signature often goes unnoticed until hard bounces start showing up as 5.7.20 in logs. This isn’t a rare edge case—it’s an industry-standard response to failed cryptographic verification. According to the DKIM specification (RFC 6376), receivers are expected to validate the signature and reject messages when verification fails.

How to act when 5.7.20 appears in your logs

If you’re seeing 5.7.20 across multiple sends, don’t assume the issue is on the recipient side. Check your own setup: is your DKIM key published in DNS? Is your signing alignment between your domain and the sending IP or domain? Are you using the right selector and domain in your signature? Tools like MailTester’s real-time API can validate these settings at scale by checking individual addresses, including their DKIM configuration—before you send.

Let’s say you're planning a campaign and want to avoid authentication errors. A pre-send validation step—using a service that checks DKIM, SPF, and MX records—can catch mismatches before deployment. Use bulk verification on your list to identify risky or misconfigured addresses. It’s better to find the flaw in your setup now than face delivery failures in production.

Consistent 5.7.20 errors mean your sender authentication isn’t holding up under scrutiny. It’s not an invitation to adjust content or timing. It’s a signal to audit your infrastructure: verify your DKIM records, check your signing practices, and validate your entire sender stack. That’s how you avoid being flagged as untrustworthy—even when the recipient address is perfectly valid.

How to use the MailTester real-time API for DKIM-aware validation

You can validate email addresses in real time using the MailTester API, which checks for SPF, DKIM, and DMARC alignment — including detecting if a domain rejects messages with a 5.7.20 SMTP error code. Send the sender's address and domain in a JSON payload to the endpoint, and receive one of five verdicts: valid, invalid, catch-all, risky, or blocked by 5.7.20. Use this to filter bad addresses before campaigns.

Send requests to the API endpoint

  1. Call the MailTester real-time API at https://mailtester.com/api-email-checker with your API key in the headers.
  2. Send either a single address or a batch of up to 100 email addresses in the request body as a JSON array.
  3. Include both the full sender address (e.g. [email protected]) and the domain (example.com) in the payload — the API uses both to verify alignment.
  4. The API checks DNS records, including DKIM public keys, and simulates an SMTP transaction to detect 5.7.20 blocking — a common response when a domain rejects messages due to poor authentication or reputation.
  5. Review the response: a valid result means the address is deliverable. A blocked by 5.7.20 verdict means the domain blocks mail from unauthenticated or low-reputation sources — a signal to remove or re-verify the sender.

Interpret and act on verdicts

Not every invalid address is due to a hard bounce — many are risky or fall into grey regions. Use the risky verdict to flag addresses that pass basic checks but have weak signals like missing DKIM or a short sender history.

Domains that send a 5.7.20 error code usually do so intentionally — often to block low-reputation senders. These addresses are unlikely to land in inboxes, even if technically valid. Let's treat blocked by 5.7.20 as a hard filter. If you're sending to a list of 10,000 emails, catching 200 such records early prevents sender reputation damage and wasted sends.

DKIM verification isn’t just about signature presence — it’s about alignment. The API checks whether the DKIM signature is valid and whether the domain in the signature matches the sending domain. If a domain uses DKIM but the selector or key doesn’t align, the API flags it as risky. This mirrors industry-wide practices: according to RFC 6376, DKIM verification requires both technical validity and alignment with the From domain.

Integrate this API into your onboarding or campaign workflow. Use it in tandem with mailbox placement testing — run inbox placement tests afterward to confirm real-world delivery. For large lists, start with bulk verification to clean your database, then use the real-time API to validate at point-of-entry.

You don’t need to guess whether a domain is blocking mail — the 5.7.20 code tells you exactly that. Filter those out early. That’s how you keep deliveries high and sender reputation clean. No guesswork.

How bulk list verification with MailTester improves deliverability

You improve deliverability by identifying invalid, role-based, disposable, and DKIM-failing addresses at scale before sending. MailTester’s bulk verification scans every email against real-time SMTP checks, MX records, and DKIM validation — all in a single pass. This reduces bounces, protects sender reputation, and increases inbox placement. For context, RFC 6376 defines DKIM as a key part of email authentication; failing this check often triggers filtering. You don’t want to send to addresses that fail SPF, DKIM, or DMARC — these are red flags to inbox providers.

Technical validation at scale

Let’s be clear: bulk verification isn’t just checking for typos. It runs a full technical validation on every address in your list — including DNS lookups, SMTP handshake simulations, and, crucially, DKIM signature checks. This means you catch addresses where the domain publishes a DKIM record but the signature fails during delivery. These are often signs of weak or compromised mail systems, or temporary outages. A failing DKIM check doesn’t mean the address is invalid — just that the domain’s authentication is misconfigured or misused. But sending to such addresses still risks spam filtering or hard bounces later.

MailTester handles this in a single API call that processes thousands of addresses simultaneously. You get back detailed results: valid, invalid, catch-all, role-based, disposable, or DKIM-failing. These verdicts are based on real mailbox behavior, not just syntax. Unlike some solutions that only validate syntax or basic reachability, MailTester tests against actual mail servers in the wild — meaning the results are practical, not theoretical. This precision keeps your bounce rate low and your sender reputation healthy.

Accuracy that matters

With 98.9% accuracy, you’re not just reducing noise — you’re minimizing false positives. That means no good subscribers missed, no unnecessary re-engagement campaigns. It also means no wasted sends to addresses that would have bounced anyway. This level of precision matters when you’re sending transactional emails or high-volume campaigns. Every message that lands in the inbox represents an improved user experience and lower long-term cost.

For example, a Spamhaus report notes that poor sender reputation is a top reason emails are blocked, especially when domains fail authentication checks. MailTester’s real-time verification helps you catch those early. Use the bulk verification tool to clean your list before every major send, or integrate the email validation API directly into your signup workflow. You’ll send faster, land in inboxes more consistently, and scale without reputation risk.

Integrating MailTester with SendGrid, Mailchimp, and HubSpot

You can connect MailTester to SendGrid, Mailchimp, or HubSpot using webhooks or direct API calls to auto-verify new contacts in real time. The in-app AI assistant helps you set up each integration step-by-step. Once live, it flags emails at risk of rejection due to DKIM issues—like the 5.7.20 error—before you send, reducing bounces and protecting sender reputation. This prevents wasted sends on addresses with known delivery blockers.

Set up and auto-verify with guidance

  • Start with your preferred integration: MailTester integrations with SendGrid, Mailchimp, and HubSpot are pre-built and tested.
  • Use the in-app AI assistant to walk you through webhook setup or API key configuration—no manual documentation hunt.
  • Choose to verify contacts on import, on signup, or during list cleansing, depending on your workflow.
  • Each verified contact returns a clear status: valid, catch-all, invalid, or risky—especially useful for spotting 5.7.20 risks tied to DKIM misconfigurations.

Stop sending to high-risk addresses automatically

  • Set rules in MailTester to block deliveries to addresses flagged as "risky" due to DKIM issues—common causes include misconfigured signing or expired keys.
  • When an address returns a 5.7.20 error, it’s often because the receiving server rejected mail due to a failed DKIM verification. This happens in RFC 6376, which defines how DKIM works.
  • Prevent manual review of high-risk mail by integrating the API with your CRM or marketing platform to filter out bad addresses before they hit your sending queue.
  • Use the real-time verification API to verify thousands of emails in seconds during list hygiene workflows.

Why 5.7.20 context matters more than ever in 2024 and beyond

Email providers are tightening authentication requirements to combat phishing and spoofing. DKIM failures now trigger rejection or inbox filtering in major inboxes, including Gmail and Outlook.

The 5.7.20 context is a signal, not a formality

A 5.7.20 bounce code indicates a failure in authentication or policy enforcement. When sent at scale, unverified emails with failed DKIM checks can damage sender reputation and trigger long-term deliverability issues.

  • DKIM alignment must match the sending domain.
  • Missing or malformed DKIM signatures are now consistently flagged.
  • Proactive checks at verification time reduce bounce rates and improve inbox placement.

Verifying email addresses with real-time context, including 5.7.20 signals, is no longer a luxury. It’s a necessity for reliable delivery in 2024 and beyond.

Sources

Keep reading

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

Frequently asked questions

Does MailTester verify DKIM signatures in real time?

Yes. MailTester checks the domain’s DKIM public key and simulates an SMTP delivery with the sender’s domain to detect 5.7.20 rejection risks.

What’s the difference between a 'risky' and 'invalid' verdict?

An invalid address fails syntax or existence checks. A risky address exists but may trigger 5.7.20 due to authentication issues.

Can the API detect all DKIM failures?

It identifies DKIM-related 5.7.20 failures with high precision. Some failures may depend on server-side policies not detectable in real time.

Is DKIM verification part of standard email validation?

No. Most tools check syntax and existence only. Advanced validation like DKIM requires live DNS and SMTP interaction, which MailTester performs.

How does MailTester handle catch-all domains?

It detects catch-alls as addresses that accept all incoming mail, meaning they may not fail but also aren’t a real contact. These are flagged as catch-all.

Can I use MailTester with disposable email domains?

Yes. It identifies disposable domains by reputation and pattern matching. These are flagged as disposable or risky.

Does the API check SPF or DMARC?

The API focuses on DKIM in 5.7.20 context. SPF and DMARC are evaluated during inbox-placement testing, not in real-time verification.

How does MailTester maintain 98.9% accuracy?

Through consistent DNS lookup, real SMTP interaction, and machine learning trained on historical delivery outcomes and error codes.

Do purchased credits expire?

No. Credits never expire. You can use them anytime across bulk or real-time verification.

Can I verify emails with a domain that lacks a DKIM record?

Yes. MailTester identifies missing DKIM records and flags such addresses as high-risk, even if they are technically valid.