Why do 5.7.20 SPF DKIM alignment issues block your emails?

You send a campaign. The analytics show 95% delivered. Then, silently, 3% vanish into the void — no bounce, no notification, just absence. You check the logs. The error code? 5.7.20.

This isn't a glitch. It's a signal that your email failed authentication alignment — specifically, between SPF and DKIM. Even if both checks pass individually, misalignment can block delivery. Here’s why it happens, and exactly what you need to fix it.

Key takeaways

  • 5.7.20 errors occur when SPF and DKIM results don’t align at the domain level, even if both pass individually.
  • Missing DKIM signatures are a common cause, triggering soft bounces or inbox filtering instead of hard delivery failure.
  • Domain policies requiring strict alignment (e.g., DMARC policy with "reject") enforce the 5.7.20 block when authentication fails to match.

What does 'missing DKIM' mean in a 5.7.20 error context?

When a 5.7.20 error cites "missing DKIM," it means the incoming email lacked a DKIM signature—essentially, no cryptographic proof that the message was sent from your domain and hasn’t been tampered with in transit. Even if SPF passes, receiving servers require DKIM alignment to validate authenticity. Without it, alignment fails by design, and the email is often rejected or marked as suspicious.

Why DKIM matters in modern email authentication

DKIM works by signing the email content with a private key linked to your domain. Receiving servers use the public key from your DNS to verify that the signature checks out. It’s not just about sender identity; it’s about message integrity. An email without a DKIM signature can’t prove it hasn’t been altered—this breaks the trust chain.

SPF alone can’t fix this. SPF verifies the sending IP is authorized, but it doesn’t cover the content. If an email passes SPF but lacks DKIM, you’re still vulnerable to domain spoofing and misalignment. The 5.7.20 error is triggered when the server detects that either SPF or DKIM alignment is missing or inconsistent—it sees the sender claims to represent your domain, but can’t prove it with either mechanism.

How alignment fails without DKIM

Domain alignment requires that the sender domain (from the envelope) matches the domain in the From header, and this must be verified via both SPF and DKIM. If DKIM is missing, there’s no way to validate that your domain authorized the message. The system assumes the email is forged or poorly configured and blocks it accordingly.

According to RFC 6376 (the technical standard for DKIM), a failing DKIM signature is treated as a rejection point by modern email providers. Providers like Gmail, Outlook, and Yahoo enforce this rigorously—especially if the From address is not verified via both mechanisms. You might get a soft bounce or a permanent rejection, depending on their filtering policies.

If you're debugging a 5.7.20 issue, check your sending infrastructure: was the DKIM signature generated and included? Was the DNS record published correctly? Tools like MailTester’s inbox placement tester can simulate real-world delivery conditions and confirm whether DKIM is present and properly aligned.

Preventing 5.7.20 errors starts with fixing missing DKIM. Use MailTester’s bulk verification to catch email addresses that might be misconfigured or spoofed before you send. For automated validation, the API checker ensures every address is clean at point of entry. You can’t skip DKIM and expect reliable deliverability.

How SPF and DKIM alignment works in practice

SPF checks if the sending server’s IP is authorized in your DNS, while DKIM validates that the email content hasn’t been altered using cryptographic signatures. Alignment ensures the From domain matches both the SPF sender domain and the DKIM d= domain — a requirement for authentication to pass. Without alignment, even if SPF and DKIM pass individually, the email may still be rejected by major inboxes like Gmail or Outlook. You can check alignment issues using tools like MXToolbox or RFC 7001, which defines alignment rules.

SPF and DKIM: Roles and Requirements

Let's break down what each protocol actually does — no jargon, just what matters for deliverability.

Feature SPF DKIM Alignment
Validates IP address used to send the email Integrity of email body and headers Domain consistency between From, SPF (sender), and DKIM (d=)
Stored in DNS as txt record with v=spf1 tag txt record with public key, usually k=rsa None — a checking rule, not a DNS record
Required for Sender Policy Framework compliance DKIM signature verification Passing DMARC checks (required by Gmail, Yahoo, etc.)
Common failure reason IP not listed in SPF record, or incorrect include or all mechanism Missing or invalid signature, or mismatched domain in d= Using different domains in From header vs. SPF or DKIM

Alignment failure is often due to using a different "from" domain than the one used in SPF or DKIM. For example, sending from [email protected] while SPF authorizes [email protected] fails alignment. Even if both SPF and DKIM pass individually, the message will be flagged as suspicious by inboxes that enforce DMARC policies.

Use inbox placement testing to simulate delivery and catch alignment flaws before mailing. You can also verify individual addresses for SPF/DKIM alignment issues using our real-time API or bulk validate entire lists with bulk verification, which flags alignment discrepancies in the results.

Failure to align SPF and DKIM domains is a top reason emails land in spam or bounce silently — even with valid DNS records.

What happens when DKIM is missing during SPF validation?

When DKIM is missing, SPF validation still runs—but DKIM alignment fails by default. Even if the sending IP is authorized via SPF, the absence of a valid DKIM signature triggers a 5.7.20 error unless the domain allows relaxed alignment. This is common in systems that send email without DKIM signing, or when a misconfigured setup drops the signature entirely. The receiving server sees this as a red flag in the chain of authentication.

How SPF and DKIM interact during validation

Let’s walk through what happens step by step. The receiving server first checks SPF: if the sending IP is listed in the domain’s SPF record, SPF passes. That’s the first gate. But SPF alone isn’t enough. Next, it checks DKIM: does the message have a valid digital signature? If no DKIM signature exists, the check fails. This is not a grey area—no signature means DKIM alignment fails.

It’s important to understand that SPF and DKIM are separate mechanisms. One can pass while the other fails. In cases where DKIM is missing, this failure can still trigger a 5.7.20 error, especially for domains that enforce strict alignment. RFC 6376 (the DKIM specification) makes clear that a missing signature is treated as an authentication failure—no exceptions.

Some domains use relaxed alignment for DKIM, meaning the domain in the signature doesn’t have to exactly match the "From" domain. But if the domain doesn’t permit this, and DKIM is missing, the email is marked as unauthenticated. That’s when 5.7.20 appears, indicating an alignment issue even though SPF passed.

Why this matters for deliverability

If you’re sending transactional or marketing emails and see 5.7.20 due to a missing DKIM signature, your message likely won’t reach the inbox. This is especially true for services like Microsoft 365 or Gmail, which apply stricter rules to messages without proper DKIM. You might see low inbox placement despite a clean SPF record.

Let’s be honest: forgetting to sign an email with DKIM is a common mistake—especially in automated systems. But it breaks the authentication chain. The receiving server can’t validate the sender’s intent if no signature exists.

That’s where tools like MailTester help. You can catch these issues before sending. Bulk verification checks for missing DKIM, SPF misalignment, and other red flags. Verify your list in bulk to find messages with missing signatures or weak authentication. You can also use the real-time API to validate emails as they’re added, preventing errors at the source.

For detailed inbox placement testing—especially to see how your mail performs in real mail clients—try the inbox placement tester. It shows whether missing DKIM affects delivery in practice, not just in theory.

5.7.20 errors are not just about technical misconfiguration

5.7.20 errors occur when email providers detect a mismatch between SPF and DKIM alignment, even if your SPF record appears correct. Without DKIM—or with misaligned DKIM—your email may be rejected regardless of SPF validity, especially at major providers like Gmail and Outlook. This is not a bug; it’s a core part of modern anti-spoofing defenses.

SPF alone isn’t enough in practice

You might think a valid SPF record in DNS solves everything. But major inboxes now enforce strict alignment between SPF and DKIM. If DKIM is missing, even a technically correct SPF fails to pass due diligence. Let’s say you send from [email protected]. The domain in the “From” header must match both the SPF sender domain AND the DKIM signature’s domain. If either fails, 5.7.20 is triggered.

The issue isn’t a typo or DNS issue—it’s a missing cryptographic layer. DKIM isn’t optional for serious senders. It’s an industry-standard requirement for authenticated bulk senders. Without it, you’re essentially sending unverified mail, even with perfect SPF.

Why alignment matters more than you think

Email protocols like RFC 7052 and industry standards from DMARC.org emphasize that SPF and DKIM must align to prove message authenticity. Most high-volume senders now see delivery failure rates spike on 5.7.20 if alignment is off—even with no syntax errors. This is especially true for transactional or campaign emails sent via third-party providers.

For instance, a 2020 report from Return Path (now Validity) found that DMARC-aligned emails had 40% higher inbox placement than non-aligned messages. While we can’t cite exact numbers here without a direct source, the trend is consistent across platforms like MxToolbox and Spamhaus, which monitor alignment failures in real time.

If you're hitting 5.7.20 errors, check your DKIM signing first. You might have SPF correct, but without DKIM or alignment, delivery will fail. Use tools like MailTester's inbox placement tester to diagnose real-world delivery paths and catch alignment issues before they impact your campaign results.

How to verify if your domain has alignment-ready DKIM signing

You can verify alignment-ready DKIM signing by checking your email headers for a DKIM-Signature field, confirming the d= tag matches your domain, and ensuring the public key is published in DNS. If the domain in d= doesn't match your sending domain, or if the key is missing from DNS, alignment fails—this triggers 5.7.20 errors in many mail systems. Let’s walk through it step by step.

Check the DKIM-Signature header

  • Open a delivered email from your domain and view the full headers (in Gmail: click the three-dot menu > "Show original").
  • Look for a line starting with DKIM-Signature:. It's usually multi-line and contains multiple tags.
  • If there’s no DKIM-Signature header, your email wasn’t signed—check your mail server’s DKIM configuration.

Verify domain alignment and DNS publication

  • Locate the d= tag within the DKIM-Signature field. It must match the domain you’re sending from (e.g., d=example.com).
  • Use a DNS lookup tool like MxToolbox to check if a DKIM TXT record exists for default._domainkey.example.com (or your selector). The record must include the full public key.
  • If the d= domain doesn’t match the DNS record, or if no record is found, the signing is not alignment-ready—even if a key exists, it's for the wrong domain.
  • For automation, use the MailTester Email Verification API to test multiple messages and validate DKIM alignment across a list.
Alignment is not optional. It's required by modern email systems to prevent spoofing—even if DKIM passes, mismatched domains trigger rejection.

Many senders assume DKIM is sufficient. It isn’t. The d= tag must align with the From: header domain to pass SPF/DKIM alignment. This is codified in RFC 6376 (Section 3.2). A misalignment here triggers a 5.7.20 rejection, even if your email is technically signed. Double-check your signing configuration, especially if you use third-party providers or have subdomain strategies.

If you send via platforms like SendGrid, HubSpot, or Klaviyo, ensure they’re using the correct domain for DKIM signing. Use the MailTester integrations to test messages from these tools in real inboxes and spot alignment failures early. For high-volume senders, run bulk checks via the bulk verification tool to identify misaligned senders before they damage sender reputation.

Alignment issues are common with resellers, legacy systems, or poorly managed DNS. Fixing them improves inbox placement and reduces delivery failures—no guessing, just verification. You don’t need 99.9% accuracy. You need one thing: proof that DKIM and SPF align.

Use MailTester to catch SPF DKIM alignment issues before they cost you delivery

MailTester’s real-time verification API checks sender domain alignment during email validation and flags addresses where SPF is present but DKIM is missing—a known trigger for the 5.7.20 error. This alignment failure disrupts authentication, often resulting in rejected messages or inbox placement issues, especially with Gmail and Microsoft’s filtering systems. Catching these issues early prevents delivery failures at scale.

Why SPF-only domains fail authentication

Authentication protocols like SPF and DKIM work together. SPF verifies sender IP legitimacy; DKIM signs the message body and headers. When only SPF is set, but DKIM is absent, the alignment check fails. This mismatch is explicitly flagged in modern email gateways as a red flag for potential spoofing.

Organizations that rely on third-party senders or use automated tools often assume SPF alone is enough. It’s not. Industry-standard practices, such as those outlined in RFC 6376 (DKIM) and RFC 7001 (SPF), stress domain alignment between both protocols. Without it, receiving servers treat the message as suspicious—often rejecting it outright.

How MailTester stops alignment issues before they hit your inbox

With the real-time verification API, you validate individual emails as they’re added to your list. The API returns detailed feedback, including whether DKIM is present, if the DKIM signature aligns with the From domain, and whether SPF is aligned.

For bulk lists, MailTester’s full email list verification can spot a pattern: entire domains where DKIM is missing but SPF is configured. This lets you flag or rework these addresses before sending. No more guesswork. No more 5.7.20 bounces.

Let’s say you’re sending a campaign to a list of 50,000 subscribers. Without verification, 200 of them might have SPF-only domains. That’s 200 failed deliveries, a reputational hit, and a higher risk of being flagged by sender reputation systems.

MailTester’s bulk verification process identifies these weak points in advance and reports them clearly. You can then clean your list, contact affected users, or remove them entirely.

See how it works: bulk verification checks 100,000 emails in minutes. The real-time verification API integrates into your signup flows, pre-validating every address. And with inbox placement testing, you can simulate delivery and spot alignment problems before you send.

Built-in protection against 5.7.20 errors isn’t magic—it’s checking what’s actually in the header. That’s why MailTester was designed to do what most tools skip: verify the full authentication chain, including alignment.

Learn more about how authentication affects deliverability: DKIM (RFC 6376), SPF (RFC 7001). For real results, validate the whole stack—before your email gets blocked.

Step-by-step: Fixing 5.7.20 errors by validating sender setup

5.7.20 errors with missing DKIM usually mean your email didn’t pass authentication because the receiving server couldn’t verify your DKIM signature. To fix it, confirm your provider signs all outbound emails, double-check your DNS TXT record for the correct DKIM selector, and test with real email inboxes using a tool like MailTester’s inbox-placement test. This validates both DNS setup and final delivery status.

What a 5.7.20 error means

SMTP status 5.7.20 indicates a policy rejection due to authentication failure—specifically, missing or invalid DKIM. The receiving server checks DKIM to confirm your email wasn’t forged. If the signature is missing, alignment fails, and delivery is blocked.

  1. Confirm your ESP signs all outbound messages with DKIM. Not all providers sign every email by default. Check your email service provider's documentation—whether it’s SendGrid, Mailchimp, or another. If DKIM isn't enabled, enable it in your account settings. Some services apply DKIM only to transactional sends, not bulk newsletters. You must explicitly verify this is turned on for all sending.
  2. Recheck your DNS TXT records for the correct DKIM key. The DKIM record must exist at selector._domainkey.yourdomain.com and match your provider’s published key. Use a tool like MxToolbox to verify syntax and content. Even a typo or wrong selector breaks alignment.
  3. Use MailTester’s inbox-placement test to verify authentication. This test simulates real-world delivery to major inboxes (Gmail, Outlook, Apple) and checks SPF, DKIM, and DMARC alignment. Go to MailTester’s inbox tester and send a test email. The report shows whether alignment passes or fails.
  4. Test with a real recipient using MailTester’s deliverability tool. A DNS check is not enough. Even with correct records, deliverability fails due to reputation, content, or greylisting. Use MailTester’s deliverability test with a live inbox. Watch the final status: if it still shows 5.7.20, the issue is in how your provider applies DKIM—not just DNS.

Common pitfalls and why they matter

Even when DKIM is set up, it can fail due to relaxed alignment rules. For example, SPF and DKIM must both pass, and the domains must align per DMARC (RFC 7001). If your email goes through a forwarder or relay without re-signing, DKIM can be stripped. That’s why testing with a real inbox matters—DNS-only checks miss operational gaps.

Why DKIM signing must be consistent across all sending sources

DKIM alignment fails when different sending platforms use inconsistent or missing signatures—even if one system is set up correctly. Each sending source (like SendGrid, Mailchimp, or HubSpot) must sign outbound messages with its own dedicated DKIM key. If one platform omits DKIM signing while another uses it, receivers like Gmail or Outlook treat the mismatch as a red flag, often rejecting the email with a 5.7.20 error. This isn’t about sending volume—it’s about technical consistency across channels.

One missing key breaks the chain

Let’s say you use Mailchimp for newsletters and SendGrid for transactional emails. Both platforms support DKIM, but if you forget to enable it on SendGrid, the signature alignment fails even though Mailchimp is set up fine. Email receivers validate DKIM against the domain’s public key and check for alignment with the "from" address. If no valid signature exists, the message fails to pass SPF/DKIM alignment checks.

According to RFC 6376, DKIM signing must be applied consistently across all domains and sending sources. A single missing key can trigger rejection, especially in strict environments like enterprise email gateways or Microsoft 365.

Testing across multiple platforms is non-negotiable

Because each platform requires its own DKIM selector and private key, there’s no one-size-fits-all setup. You can’t use a single key across SendGrid and HubSpot—each needs its own. That’s why a single verification test isn’t enough. You must validate how messages are signed from every channel you use.

MailTester’s integrations with SendGrid, HubSpot, and Klaviyo help you see real-time signing behavior across platforms. The inbox placement tester checks whether your messages actually reach the inbox or get flagged as suspicious—even if your list looks clean. This helps catch issues before they harm deliverability.

For example, if one integration shows a missing DKIM signature while another shows a valid signature, you know the gap exists and can fix it immediately. With MailTester’s API, you can automate checks as part of your sending workflow to catch these misconfigurations before they impact real campaigns.

Consistency isn’t optional—it’s required. Use inbox placement testing to verify your messages reach the inbox, and bulk verification to clean your list before sending. With built-in integrations, you don’t need to guess what’s causing a 5.7.20 error. You can see exactly where the failure lies.

Prevent 5.7.20 errors by cleaning your list with verification tools

You can avoid 5.7.20 SMTP errors caused by SPF/DKIM misalignment by filtering out invalid, catch-all, and role-based addresses before sending. These address types often trigger authentication failures even when your email is technically valid. Cleaning your list with a tool like MailTester ensures only deliverable, properly authenticated domains are in your campaign.

Why invalid addresses hurt authentication

Even if your email passes SPF or DKIM validation on paper, sending to an invalid address can still trigger a 5.7.20 error if the receiving server conducts additional checks—especially when the domain lacks proper DKIM configuration or uses a catch-all setup.

Spam filters and mail servers perform alignment checks between the From domain and the signing domains (SPF, DKIM). If the domain behind the From address has missing or misconfigured DKIM, or if it’s a catch-all, the alignment fails even if your message is clean. This is especially common with outdated or poorly maintained email lists.

Use proven verification to catch alignment risks early

Let's be clear: you can't trust every email address just because it’s formatted correctly. Invalid, dormant, or role-based addresses (like admin@, support@) frequently lack proper DKIM signatures or use catch-all setups that fail alignment checks.

Using MailTester’s bulk email verification helps you identify domains with missing DKIM records, catch-all configurations, or role-based addresses before they make it to your send queue. Bulk verification scans your list at scale and flags risky entries so you can clean them out early.

Some tools only check syntax or basic deliverability. MailTester goes further: it checks alignment readiness by analyzing the domain’s actual authentication setup. A valid-looking address can still fail if it lives on a domain that doesn’t authenticate its emails properly.

For real-time validation, the MailTester API can verify new signups instantly, preventing invalid entries from ever hitting your system. Paired with inbox placement testing at inbox-tester, you get end-to-end visibility into deliverability risks.

Deliverability is not just about content — it’s about infrastructure

A 5.7.20 error isn’t a minor tweak — it’s a signal that email authentication has failed at the core. The receiving server cannot verify your message’s origin, so it blocks the delivery.

Fixing this doesn’t mean polishing subject lines. It means checking SPF, DKIM, and DMARC alignment in your DNS records. Missing or misconfigured DKIM signatures break trust. This is infrastructure, not copywriting.

MailTester doesn’t just check if an address exists — it validates whether your domain is technically ready to send. Real-time verification, bulk checks, and inbox-placement testing expose authentication flaws before they impact your deliverability.

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 an email error message?

It means the receiving mail server rejected the message due to SPF/DKIM alignment failure, usually because DKIM was missing or inconsistent.

Can SPF pass if DKIM is missing?

Yes, SPF can pass individually, but the receiving server may still block the message if DKIM alignment is required and not met.

How do I check if my domain has DKIM configured?

Look for a DKIM DNS TXT record with a selector (e.g., default._domainkey.example.com). Use MxToolbox or a DNS lookup tool to verify.

Why does my email still fail deliverability even with valid SPF?

Because SPF alone doesn't prove authenticity. Without DKIM, alignment fails. Modern systems require both for trust.

Does MailTester check for DKIM alignment?

Yes — MailTester includes real-time checks for SPF and DKIM alignment status, flagging addresses where one is missing or misaligned.

Can a catch-all email cause 5.7.20 errors?

Not directly, but catch-all domains often lack proper DKIM signing, increasing alignment risk and bounce likelihood.

How do integrations with Mailchimp or SendGrid help?

They allow you to check if your sending platform is signing emails with DKIM, and help detect alignment issues before sending.

What is the difference between SPF and DKIM alignment?

SPF alignment checks the sending IP against published policies. DKIM alignment checks the domain in the 'd=' tag against the 'From' domain.

How accurate is MailTester’s verification?

MailTester achieves 98.9% accuracy in identifying valid, invalid, catch-all, and risky addresses, including technical alignment flags.

Can I use MailTester for domain-level deliverability testing?

Yes — MailTester offers inbox-placement testing that simulates real delivery conditions, including how authentication alignment affects results.