What causes the 5.7.20 SMTP error when sending email?

Ever sent an email that vanished into silence—no bounce, no reply, just a dry 5.7.20 error from Gmail or Outlook? You’re not alone. This error doesn’t mean your message was spam. It means it failed authentication.

Think of email authentication like a digital ID check at a secure facility. The receiving server says: “We don’t know who you are.” The 5.7.20 error appears when SPF, DKIM, or DMARC records are missing, misconfigured, or don’t match. It’s not about content—it’s about trust.

This isn’t a minor glitch. It blocks delivery across Gmail, Outlook, Apple Mail, and other major providers. Fixing it isn’t optional if you want your emails to land in inboxes, not trash.

Key takeaways

  • The 5.7.20 error is returned when an email fails SPF, DKIM, or DMARC verification.
  • It typically results from missing, incorrect, or mismatched DNS authentication records for the sending domain.
  • Correcting 5.7.20 errors is essential for deliverability across Gmail, Outlook, Apple Mail, and other major email providers.

Why does an unsigned email trigger 5.7.20 during delivery?

When an email lacks valid DKIM or SPF signatures, receiving servers can't verify its origin. DMARC checks both alignment and authentication — if either fails, the server may block the message with a 5.7.20 error, even if it's from a legitimate sender. This happens because unsigned messages appear suspicious, especially if the domain has strict DMARC policies set to "reject."

How DMARC enforces email authentication

DMARC is the enforcement layer that tells receiving servers what to do with messages that fail SPF or DKIM checks. If your email doesn’t have a valid DKIM signature or the SPF check fails, and the domain’s DMARC policy is set to reject unauthenticated messages, the 5.7.20 error is the result. This isn’t about spam — it’s about trust. The receiving server sees an unsigned email and defaults to blocking it to protect its users.

Even if your sender domain is reputable, unsigned emails get treated the same as suspicious ones. The absence of a cryptographic signature means the server can't confirm the message was sent from an authorized source — and that’s enough to trigger rejection.

Why alignment matters when signatures are missing

When both DKIM and SPF are missing, or their alignment fails, the server has no proof the message was sent by the domain it claims to be from. Alignment checks ensure the "from" domain matches the domain in the DKIM signature or SPF record. Without it, even valid emails risk being flagged.

For example, you might send from [email protected], but your DKIM signature only covers mail.company.com. That misalignment causes a failure under DMARC. The server sees no valid proof of authorization and acts by blocking the email with a 5.7.20 code, which means "authentication failure."

According to RFC 7672, DMARC relies on both mechanisms to validate legitimacy. A message that fails both checks and lacks alignment is unlikely to pass through modern email gateways. This is why major providers like Gmail, Microsoft, and Yahoo now enforce strict DMARC policies — and why unsigned emails get rejected outright.

Let’s be clear: signing isn’t optional for high-reputation sending. It’s a technical requirement. If you're still seeing 5.7.20 errors, your email stream likely lacks proper DKIM or SPF configuration. The fix isn’t just one change — it's a full audit of your email infrastructure.

Use MailTester’s bulk verification to identify invalid or suspicious addresses before sending. Test your deliverability with our inbox placement tool to confirm whether your signed emails reach inboxes. With accurate records and proper authentication, you can prevent 5.7.20 errors before they happen.

What is the role of DKIM in preventing 5.7.20 errors?

DKIM prevents 5.7.20 errors by digitally signing your email’s body and headers using a private key, which receiving servers verify against a public key in your domain’s DNS. If the signature is missing, invalid, or expired, the receiving server treats the message as unauthenticated—often triggering a 5.7.20 rejection. This signature is a core part of email authentication and a common fix when DMARC policies are enforced.

How DKIM works in the email flow

When you send an email, your server or sending platform applies a cryptographic signature to the message using a private key. This signature is added to the header as a DKIM-Signature field. The receiving server pulls the public key from your DNS records—specifically, the DKIM selector and your domain—to validate the signature. If the public key doesn’t match, or the record is missing, the validation fails.

Let’s say you’re sending a campaign through a platform like SendGrid or Mailchimp. If DKIM isn’t set up, or the private key is misconfigured, the signature won’t be attached correctly. Even if SPF passes, DMARC can still fail, especially with strict policies. Microsoft’s Exchange Online, which enforces DMARC rigorously, often blocks such messages with a 5.7.20 error. This is why DKIM is a non-negotiable layer, not just a bonus.

Why a missing or expired signature causes 5.7.20 errors

A failed DKIM validation is one of the most common triggers for 5.7.20. The receiving server sees no valid signature, so it assumes the message might be spoofed or compromised. This is especially true in environments where DMARC is set to “reject” mode. Without a valid DKIM signature, even if SPF passes, DMARC alignment can still fail.

You might think, “It’s just one email.” But when a campaign sends thousands of messages with failing DKIM, deliverability drops sharply. According to industry data, roughly 40% of email blocks at major providers stem from authentication failures—DKIM being a top offender when misconfigured. An outdated or expired key adds to the risk, especially if your signing key rotates but isn’t updated in DNS.

Regularly auditing your DKIM setup helps catch issues before they impact deliverability. Tools like MailTester can verify your email signatures and detect expired or missing keys during bulk validation. Bulk verification includes DKIM check, helping you spot failed signatures across your list before sending.

Digital signatures aren’t just technical formalities—they’re trust signals. The more consistent your DKIM, SPF, and DMARC setup, the more likely your email lands in the inbox. Think of DKIM not as a hurdle, but as the cryptographic backbone of sender reputation.

How SPF and DMARC interact with DKIM to trigger 5.7.20 errors

5.7.20 errors occur when an email fails both SPF and DKIM validation, and DMARC enforces that failure by rejecting the message—often because the sender’s domain lacks proper cryptographic alignment or policy enforcement in DNS. This means your email is blocked not for content, but because the technical safeguards failed.

SPF, DKIM, and DMARC: The Three-Layer Defense

SPF checks whether the sending IP address is authorized by the domain’s DNS records. If it isn’t, SPF fails. DKIM signs the message content cryptographically, ensuring the body and headers haven’t been altered in transit. DMARC sits on top, telling receivers what to do if SPF or DKIM fail—either quarantine the message or reject it outright.

When neither SPF nor DKIM passes, DMARC triggers a rejection. That’s how a 5.7.20 error is generated. A common trigger is an unsigned email sent from a legitimate server but without DKIM signing configured—this results in a clean SPF pass (if the IP is allowed), but a DKIM failure, causing DMARC to reject the email.

Why Alignment Matters

DMARC doesn’t just require SPF or DKIM to pass—it requires them to align with the “from” domain. So even if SPF passes from a trusted IP, if the envelope sender doesn’t match the header domain, that’s a misalignment. The same applies to DKIM: if the signed domain in the signature doesn’t match the from domain, alignment fails.

Without proper alignment, even a passing SPF check can’t prevent a 5.7.20 error if DKIM fails and misalignment exists. This is why many organizations face these errors when using third-party email services or misconfigured sending infrastructure.

Tools like MailTester’s real-time verification API help catch these issues before bulk sends—checking SPF, DKIM, and DMARC records in real time, along with catch-all detection, to flag risks before they hit the inbox.

For teams using Mailchimp, Klaviyo, or SendGrid, integration with MailTester’s verified senders can help validate list quality and alignment before sending. You're not just verifying syntax—you're testing whether your domain’s mail security policy will stand up to real-world filters.

For a full end-to-end view, use the inbox placement test to see how different email providers respond to your message. It’s one of the few ways to simulate real inbox routing under current filtering rules.

DMARC is not optional. It’s how modern email systems protect users from spoofing. But it only works when SPF and DKIM are correctly configured and aligned. If you’re seeing 5.7.20 errors, chances are your domain’s policy is too strict—or the signing is missing.

See the official DMARC specification for the full technical definition of policy enforcement and failure handling. Understanding it is key to fixing not just 5.7.20, but the broader deliverability picture.

A real-time process to diagnose 5.7.20 errors before sending

You can prevent 5.7.20 errors—commonly triggered by unsigned emails—by validating your domain’s email authentication setup in real time. Run a DNS check on SPF, DKIM, and DMARC records. Confirm your DKIM signature covers all required headers and body parts. Test the signature using your domain’s public key. Validate sender reputation and inbox placement. Review bounce logs for 5.7.20 codes to trace authentication failures. This process stops delivery failures before they happen.

Step-by-step: real-time diagnosis of 5.7.20 errors

  1. Check your DNS records with a tool like MxToolbox. Verify SPF, DKIM, and DMARC are published and correctly formatted. A missing or misconfigured record is a frequent root cause of 5.7.20. Use standard tools to confirm they’re active and syntactically valid—this step catches basic setup issues early.
  2. Ensure your DKIM signature covers all required headers and body parts. Many providers require signing specific headers (like From, To, Subject) and the entire body. If the signature is incomplete, receiving servers may reject your message. Use a DKIM verifier to confirm coverage and alignment with your provider’s requirements.
  3. Validate DKIM using your domain’s public key. Pull the DKIM public key from your DNS and use a verifier to test whether incoming messages are properly signed. This confirms the signature is mathematically valid—not just present. Tools like the DKIM RFC outline the expected structure.
  4. Test delivery with a sender reputation checker. Send a test message through a deliverability dashboard. Tools like those powered by Return Path (now part of Oracle) or MxToolbox analyze how your domain’s reputation and authentication stack up. Poor reputation or missing authentication often triggers 5.7.20.
  5. Review bounce logs for 5.7.20 codes and link them to authentication failures. If you see 5.7.20 in outbound bounce logs, it usually means authentication was missing or failed. Cross-reference the log with your DNS and DKIM settings. Use MailTester’s inbox placement tester to simulate real-world delivery and spot issues before sending at scale.

Why this works in practice

Many teams only react after messages fail. But diagnosing 5.7.20 errors upfront—using tools that mirror how real email systems validate—lets you act before they impact deliverability. When you verify your setup before sending, you’re not guessing. You’re validating.

For example, MailTester’s bulk verification checks for authentication issues across large lists, identifying domains with broken DKIM or SPF before you send. The same API checks can be applied in real time during campaigns.

Authentication is not optional—it’s how the internet confirms your message is real.

When every step is correct, 5.7.20 errors disappear. Your inbox placement improves. Your sender reputation stays strong.

How to verify if your email is signed properly

Open a sent email in Gmail or your mail client, view the raw headers, and look for a DKIM-Signature: header. It must exist, be valid, and include a d= tag matching your sending domain, a correct s= selector, and a recognized v=1 version. If any part is missing or mismatched, your email fails signature verification — a common cause of 5.7.20 errors.

Check the DKIM-Signature header

  • Use Gmail’s “Show original” option or your client’s header view to inspect the raw email.
  • Look for a DKIM-Signature: header. If it’s absent, the email wasn’t signed — a top cause of 5.7.20 rejection.
  • Confirm the d= tag matches the domain you’re sending from. For example, if sending from example.com, the d=example.com must appear.
  • Check that the s= selector matches your DNS record. Common values include default or mail, but it must be exact.
  • Ensure v=1 is present and set to the current version. Receiving servers expect this tag and may reject unsigned or malformed signatures.

Validate against standards and real-world behavior

DKIM is defined in RFC 6376 — a foundational standard for email authentication. Misconfigurations here aren’t just technical; they trigger automated rejection systems used by Gmail, Yahoo, and major providers. Even if SPF and DMARC are set, a broken DKIM signature will cause failure.

Mail servers don’t just check the signature’s existence. They verify the cryptographic signature using the public key published in your DNS records. If the key doesn’t match, or if the domain or selector is wrong, the validation fails — even if other parts are correct.

Tools like DMARC.org and MXToolbox can help diagnose DKIM issues by checking your DNS records and test signature alignment. For automated, real-time verification at scale, MailTester’s bulk verification checks DKIM alignment alongside other deliverability factors across thousands of emails.

Common misconceptions about 5.7.20 and email signing

Using SendGrid or Mailchimp won’t fix a 5.7.20 error if your domain lacks proper authentication. Even with third-party tools, unsigned emails fail verification unless SPF, DKIM, and DMARC are correctly configured. Signing alone doesn’t guarantee delivery—authentication must pass, and email receivers check all three protocols, not just DKIM.

Third-party providers don’t auto-fix authentication

You might assume that sending via Mailchimp or SendGrid automatically solves 5.7.20 errors. That’s not true. These platforms help manage sending infrastructure, but they don’t override your domain's lack of SPF, DKIM, or DMARC. If your organization’s domain isn’t properly set up in DNS, the email will still be rejected—even if sent through a trusted provider.

Think of it this way: a third-party provider is like a delivery driver. They deliver the package, but if the address (your domain) is unverified, the recipient refuses it. You can’t rely on the driver’s reputation to bypass the address check. The RFC 5322 standard requires sender authentication for valid email routing—and this isn’t optional.

Signing isn’t a silver bullet

Some believe that signing emails with DKIM or S/MIME means they’ll always land in the inbox. That’s not how it works. Authentication is mandatory, but not sufficient. A signed email can still be blocked, filtered, or rejected if SPF fails, if DKIM alignment fails, or if DMARC policy blocks it.

Even if your DKIM signature is valid, alignment with the "From" domain must match the domain in the DKIM-Signature header. If your branding domain doesn’t align with your sending domain (e.g., sending from [email protected] but signing with a different domain), the email fails verification. This alignment check is enforced by major providers like Google and Microsoft—even when the signature itself is technically correct.

DMARC’s p=none policy is another common misunderstanding. It doesn't prevent 5.7.20 errors—it only logs failures instead of rejecting them. A message that fails SPF or DKIM will still be rejected if the DMARC policy is set to p=reject, and even in p=none mode, many receivers still act on the failure and may return a 5.7.20 error. This isn’t a workaround—it’s a misstep in understanding.

Verify your domain’s full authentication setup before sending. Use a real-time email verification tool like MailTester’s bulk verification to test your domains and catch issues before they impact deliverability. You can also validate your DNS records and authentication status with MXToolbox. The fix isn’t just signing—it’s ensuring all layers of authentication are consistent, aligned, and correctly published.

How MailTester helps prevent 5.7.20 errors before they occur

You can stop 5.7.20 errors—caused by unsigned or misconfigured emails—before they hit inboxes by verifying address validity, authentication setup, and sender reputation at scale. Let’s break down how MailTester turns this into a systematic, pre-send check.

Pre-check address health and authentication readiness

  • Use the MailTester verification API to test individual or high-volume email addresses in real time for deliverability risks, including SPF/DKIM/DMARC alignment and header consistency.
  • Integrate the API into your signup or onboarding flow to catch invalid, role-based, or disposable addresses before they’re added to your list.
  • Check for missing or weak authentication—common causes of 5.7.20—by validating domain-level records and header signatures on every address.

Run full-scale checks before sending campaigns

  • Upload your entire email list to MailTester’s bulk verification tool to detect invalid, catch-all, or high-risk addresses that may trigger spam filters—even if signed.
  • Identify and remove role accounts (like admin@, sales@) that often trigger security warnings, even with proper signing.
  • Use inbox placement testing to simulate delivery across Gmail, Outlook, Apple Mail, and others, checking whether signed emails land in the inbox or get filtered.
  • Monitor your sender reputation and domain health during bulk checks with automated reporting on blacklist status, MX configuration, and TLS setup.
Authentication doesn’t guarantee deliverability. A properly signed email can still be flagged if it comes from a disposable domain or a role-based address.

MailTester doesn’t just check if an email exists—it checks whether it’s safe, trusted, and ready to land in the inbox. This proactive step reduces bounce rates and avoids security flags tied to malformed or suspicious sends.

For teams using platforms like Mailchimp, HubSpot, or SendGrid, integrations automate verification at the source. This means invalid or non-compliant addresses never reach your campaign queue. See how it works with your stack.

With 98.9% accuracy, MailTester gives you confidence in your list—not just in the address, but in the entire email ecosystem. And unlike some tools, your purchased credits never expire, so verification stays part of your workflow long-term.

To start, get 100 free verifications at MailTester’s pricing page and see how quickly you can fix the root causes of 5.7.20 errors before they appear in your deliverability reports.

Why email verification is the first line of defense against 5.7.20

You fix 5.7.20 errors caused by unsigned emails by ensuring your list only contains valid, properly authenticated addresses. Invalid or poorly configured addresses—especially role-based ones like admin@ or support@—often trigger rejection on strict mail servers. A single email with broken DKIM or SPF can harm your sender reputation, leading to broader blocks. Verifying your list before sending prevents these issues before they appear in your delivery logs.

Bad addresses breed bad signals

Role-based email addresses like sales@ or info@ are often flagged by modern mail servers as high-risk. Even if the address technically exists, many providers assume such inboxes are managed by bots or shared accounts, increasing the chance of a 5.7.20 bounce. These addresses frequently lack strong authentication, so even if they resolve, they’re more likely to be silently discarded or filtered out. Catching and removing them early stops sender reputation damage before it starts.

One flaw can trigger a chain reaction

A single email with a failed DKIM signature doesn’t just bounce—it may contribute to reputation metrics used by large providers. If your sending infrastructure signs some messages incorrectly, ISPs can interpret this as a misconfiguration or security risk. This can result in a broader throttling or blocking of all your outbound mail, even for valid addresses. You don’t need to be on a blocklist to be affected; a few bad sends can signal poor list hygiene.

Verifying your list before sending lets you catch invalid, role-based, or improperly configured addresses before they hit the wire. You reduce failed deliveries, avoid false positives in logs, and prevent your sender reputation from being dragged down by exceptions. MailTester’s 98.9% accuracy means you’re not wasting send volume on addresses that will fail. You can filter out invalid entries, ensure proper domain alignment, and confirm that your email setup is solid before sending at scale.

For ongoing validation, you can also use MailTester’s real-time API (API email checker) for new signups or bulk imports. The tool helps you test inbox placement and spot potential issues like missing authentication headers. With integrations across platforms like Mailchimp and Klaviyo (integrations), you can embed checks directly into your workflow.

Authentication failures are often symptoms of deeper list quality problems. The goal isn’t just to avoid 5.7.20 bounces—it’s to maintain inbox placement over time. A clean list reduces friction at every stage of delivery. Use bulk verification to audit your existing list. For smaller checks, inbox placement testing reveals how likely your messages are to reach a real inbox, not just the spam folder. And with credits that never expire, you’re not locked into a fixed plan. Just verify, send, and track results.

How integration with SendGrid, Mailchimp, HubSpot, and Klaviyo helps

You can prevent 5.7.20 errors caused by unsigned emails by integrating MailTester with SendGrid, Mailchimp, HubSpot, or Klaviyo. These platforms support SPF, DKIM, and DMARC, but only if your domain is set up correctly. Without validation, invalid or risky emails slip through—especially if sender reputation is damaged. MailTester’s real-time API checks catch these before they send, reducing bounces and protecting deliverability.

Domain setup is essential, but not enough

Even when you've configured SPF, DKIM, or DMARC in platforms like SendGrid or Mailchimp, misconfigurations happen. A missing DKIM signature, an incorrect SPF record, or a relaxed DMARC policy can still trigger 5.7.20 errors during delivery. These platforms are technically capable of enforcing authentication, but they rely on your domain setup being correct and consistent across all subdomains and sending IPs.

Let’s be clear: no platform will prevent your email from being rejected due to poor authentication if your domain doesn’t properly authenticate the sender. That’s where MailTester comes in. By running real-time verification before send, you catch issues like missing signatures, catch-all aliases, or disposable domains—before those messages hit the inbox.

Real-time validation stops errors before they occur

When you connect MailTester to your marketing or transactional platform—via our API or pre-built integrations—every email is checked instantly. For example, when you upload a list to Mailchimp, MailTester filters out invalid addresses, catch-alls, and risky domains in seconds. You aren’t waiting until post-send reports to find out your campaign failed due to unauthenticated senders.

This stops 5.7.20 errors at the source. Even if your sender is technically compliant, a poorly maintained list with outdated or non-existent users can still trigger filtering. According to RFC 6376, DKIM signing is required for mail to pass authentication checks by major providers. Without it, rejection is likely.

Automated pre-send verification means you skip manual checks and avoid sending on a bad reputation. That’s how real deliverability is maintained. You don’t need to rely on luck or post-send analytics. You test the address itself, the domain, and the sending environment—all before a single email goes out.

With MailTester, you’re not just fixing errors. You’re building a list that’s clean, compliant, and trusted by inbox providers. The integration works with your existing workflow—no extra tools, no workflow disruption. It just makes sure your emails go out on the right footing.

The bottom line: preventing 5.7.20 requires both verification and authentication

Spam filters reject emails with a 5.7.20 error not for poor content but because they lack proper technical validation. An email must be a valid address, correctly formatted, and cryptographically signed via SPF, DKIM, and DMARC.

Even perfectly written messages will be blocked if they’re unsigned or misaligned. No amount of polished copy compensates for missing or faulty authentication headers.

Use tools like MailTester not just to validate addresses, but as a core part of your deliverability workflow. Clean lists, correct DNS records, and real-time testing reduce bounces, prevent blocklists, and ensure your messages reach the inbox.

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 error 5.7.20 mean when sending email?

It means the receiving server rejected your email due to failed authentication — typically missing or invalid SPF, DKIM, or DMARC alignment.

Can a signed email still get a 5.7.20 error?

Yes — if the DKIM signature is missing, the SPF doesn’t match, or the DMARC policy rejects the message despite a valid signature.

How do I check if my email is properly signed?

View the raw headers and confirm the presence of a valid DKIM-Signature header with a matching domain and selector.

Does using Mailchimp fix 5.7.20 errors?

Mailchimp handles sending infrastructure but does not configure your domain’s DNS records. Errors persist if SPF/DKIM/DMARC are missing.

What happens if I ignore 5.7.20 errors?

Your messages will bounce or land in spam folders. Persistent failures harm sender reputation and may trigger blocklisting.

Can MailTester detect DKIM issues?

Yes — through inbox placement testing and domain verification, it identifies misconfigured or missing DKIM signatures during real delivery tests.

Are disposable email addresses prone to 5.7.20 errors?

No — disposable domains often fail email authentication due to lack of proper DNS records, contributing to 5.7.20 when used in mass campaigns.

How many verifications do I get to start with MailTester?

You get 100 free verifications with no expiration on purchased credits, allowing you to test and verify lists at scale.

Is 98.9% verification accuracy reliable?

Yes — MailTester's accuracy is based on real-time checks across providers, DNS consistency, and pattern analysis of known bounce patterns.

Can I test deliverability across Gmail, Outlook, and Apple Mail?

Yes — MailTester’s inbox placement tests simulate delivery across major providers to check for 5.7.20, spam placement, or outright rejection.

Does MailTester integrate with SendGrid and HubSpot?

Yes — MailTester integrates with SendGrid, Mailchimp, Klaviyo, and HubSpot to enable real-time verification during list uploads or campaign sends.

Do I need to update my DNS to fix 5.7.20?

Yes — unless your sending provider manages it for you, you must publish SPF, DKIM, and DMARC records correctly in your DNS.