Why is your email getting rejected with 550 5.7.20 DKIM validation failed?

You sent a message, everything looked correct, and yet it bounced back with a 550 5.7.20 DKIM validation failed error. You're not alone — this is one of the most common authentication failures in outbound email delivery.

This isn’t about the recipient’s inbox being full or the address being invalid. It’s a signal from the receiving server: “I checked your email’s digital signature, and it didn’t match what it should have.” That signature — the DKIM record — didn’t validate. The fix isn’t in the recipient list. It’s in your domain’s configuration.

Think of DKIM like a tamper-proof seal on a letter. If the seal is broken or missing, the recipient rejects it. This error means the seal failed to verify, regardless of the message’s content.

Key takeaways

  • 550 5.7.20 DKIM validation failed means your email’s signature failed verification at the receiving server level, not due to recipient issues.
  • Common root causes include expired DKIM keys, mismatched signing domains, or DNS record misconfigurations.
  • Proactively verifying domains and email addresses before sending can help identify and fix issues before they cause delivery failures.

What exactly does 550 5.7.20 mean in email delivery?

You’re seeing a 550 5.7.20 error when your email gets rejected by major providers like Gmail, Outlook, or Yahoo because their systems checked your DKIM signature against the DNS record published for your domain and found a mismatch. This is a permanent failure — your message won’t be delivered, and sending again won’t help. The error is not about spam or blacklists; it’s about cryptographic proof of authenticity failing.

Breaking down the error code

The “550” code means the delivery attempt was permanently rejected. It's not a temporary issue — fix the root cause, or the email will never land in the inbox.

The “5.7.20” part is an extended status code defined by SMTP standards, specifically used by large email providers to indicate a security-related rejection. In this case, “5.7.20” means the rejection was due to a failure in DKIM validation — the digital signature on your message doesn’t match the public key published in your domain’s DNS.

Why DKIM validation fails — and how to fix it

Digital signatures are meant to prove your email came from your domain and wasn’t altered in transit. If the receiving server can’t verify that the signature matches your published public key, it treats the message as tampered or forged.

Common reasons for this include incorrect DNS record formatting, a typo in your selector, an expired or invalid DKIM key, or a misconfigured email delivery system that signs messages differently than the one specified in DNS. Tools like MailTester’s inbox placement tester can help you simulate how your messages perform across real inbox environments before sending to your full list.

The RFC 6376 specification for DKIM provides the technical foundation for the check, and you can review it directly via the IETF: RFC 6376. Always verify your DKIM setup using a real mail server checker — not just a quick online test.

Let’s say you use a service like SendGrid or Mailchimp. If they’re handling your DKIM signing, make sure you've published the correct public key in DNS and updated it after any key rotation. Misalignment here is the #1 reason for 550 5.7.20 errors.

If you’re managing your own DKIM, double-check your selector, domain, and key format. Use a tool like MailTester’s bulk verification to test your sender setup against real-world validation checks before sending to live recipients. You don’t want a full campaign to fail on a single failed signature.

How DKIM works: The sender’s authentication layer

You sign every email with a private key held on your mail server. The recipient’s server then checks your domain’s DNS record for the corresponding public key to validate the signature. If the content—body, headers, even whitespace—changes en route, the signature fails, and the email may be flagged or rejected.

Signing and verifying: The digital handshake

When you send an email, your mail server adds a cryptographic signature using a private key. This signature is tied to your domain and acts like a digital fingerprint for the message. The receiving server doesn’t trust the message until it retrieves your public key from your domain’s DNS records—specifically, the DKIM TXT record.

It’s this public key that decrypts the signature and verifies it matches the email’s content exactly. Minor changes—like a routed header or a changed timestamp—can break this match. That’s why consistent email formatting and proper DKIM setup are essential.

Why DKIM matters for deliverability

DKIM is one of three main email authentication standards—alongside SPF and DMARC. It prevents spoofing and shows recipients your messages are genuinely from your domain. Without DKIM, even if SPF passes, many major providers (like Gmail, Outlook) will still treat the email as suspicious or low trust. According to the IETF’s RFC 6376, DKIM is designed to be resilient against content changes during transit, but only if the signature is correctly generated and validated.

Failures like 550 5.7.20 dkim validation failed often point to misconfiguration, mismatched keys, or unintentional alterations to the message body or headers during delivery. These aren’t just technical glitches—they’re red flags to filtering systems, increasing the risk of inbox placement issues or outright blocking.

Use tools like MailTester’s API email verification or inbox placement tester to catch these issues before you send. They validate not just syntax, but whether your DKIM setup holds up in real-world conditions across major providers.

Top 5 causes of 550 5.7.20 DKIM validation failed

When a 550 5.7.20 DKIM validation failed error appears, it means the receiving server couldn’t verify your email's signature. Common causes include a missing or misconfigured DKIM DNS record, mismatched signing and From domains, expired or unrotated keys, content changes in transit, or misaligned SPF/DKIM/DMARC policies. Let's break down each one so you can fix it fast.

DNS records missing or incorrectly formatted

  • Check that your DKIM TXT record is published and correctly formatted. A single typo or missing quote can break validation. Use a tool like MXToolbox to verify the full DNS record.
  • Ensure the record is not truncated — DKIM keys can be long. Some DNS providers limit entry size, so break long records into aligned fragments.
  • Test your record live using RFC 6376, which defines how DKIM signatures are verified in practice.

Signing domain mismatch with From domain

  • DKIM signs with the domain in the From header, not just the Return-Path. If your email is sent from a subdomain like [email protected] but signed with company.com, alignment fails.
  • Use consistent domains across From, DKIM-Signature, and Sender headers. A mismatch triggers DMARC failure even if DKIM passes.
  • Verify your setup with a real inbox-test like MailTester Inbox Placement Test to catch alignment issues before sending to real users.

DKIM key expired or rotated without DNS update

  • DKIM keys have a validity period. If they expire and you don’t regenerate and update the DNS record, signatures fail.
  • Key rotation must be synchronized: generate the new key, update DNS, and confirm before disabling the old one. Forgetting this step is a frequent cause of silent failures.
  • Track key dates in your email operations log. If you use an email service, confirm their key rotation policy and manual override options.

Content altered in transit

  • Automatic email gateways, link shorteners, or forwarders can modify content (like adding a footer or reshaping HTML). That breaks the DKIM signature.
  • Even small changes—even whitespace—invalidated the hash. This is why email apps like Microsoft 365 report this error when modifications are detected.
  • Test your email through a forward or gateway before sending large volumes. MailTester’s inbox placement test simulates real-world delivery paths, catching these edge cases.

Domain policies not aligned across SPF, DKIM, and DMARC

  • DMARC requires both SPF and DKIM to pass. If one fails, the email may still be delivered but flagged.
  • SPF allows sending only from specific IPs. DKIM verifies the domain that signed the message. DMARC enforces policy. If one conflicts, the message may be rejected.
  • Misalignment happens when SPF allows a domain that DKIM doesn’t sign, or when DMARC policy is set to reject, but SPF and DKIM don’t align. Check alignment with RFC 7483, which sets the standards for alignment.
Even one failing signature can trigger a 550 5.7.20 error. It’s not just about passing DKIM—it’s about passing all checks in concert.

How to diagnose DKIM validation failures in real time

When you see a "550 5.7.20 dkim validation failed" error, the sender’s DKIM signature didn’t verify. Use MailTester’s real-time verification API to simulate delivery from your domain and check for DKIM errors before sending. You’ll catch issues like misconfigured DNS records, mismatched selectors, or incorrect canonicalization before your email gets blocked.

Step-by-step diagnosis

  1. Test delivery with MailTester's real-time API
    Send a test email through MailTester’s verification API. It checks DKIM signatures in real time using actual recipient mail servers. This tells you instantly if your DKIM is failing during an actual delivery attempt, not just in a lab environment.
  2. Check for a DKIM-Signature header
    Open the raw email headers of the message that failed. Look for a DKIM-Signature field. If it’s missing, DKIM wasn’t applied — likely due to misconfiguration in your sending system or a routing error. If present but invalid, the signature doesn’t match the published key.
  3. Verify DNS records match the email’s signing data
    Extract the selector and domain from the DKIM-Signature header (e.g., selector1._domainkey.yourdomain.com). Use a DNS lookup tool like dnschecker.org to confirm the TXT record exists, contains the correct public key, and aligns with the signing domain and selector.
  4. Confirm header canonicalization is consistent
    DKIM uses one of two canonicalization methods: simple or relaxed. The sending server and the verifier must agree on the method. Misalignment here causes validation to fail even if the key is correct. Check your email-sending software’s configuration and ensure it matches what your DNS records expect. The DKIM RFC details how canonicalization works.

Common blind spots

  • Using a test selector during production setup — always use your final, active selector.
  • Having multiple DKIM keys active, but only one valid — this confuses mail servers.
  • Failure to re-sign headers after content is modified by intermediaries (e.g., mailing list software).
DKIM failures aren’t always about bad keys—misaligned canonicalization or missing signatures are far more common than you’d expect.

With MailTester’s inbox placement tester, you can verify your DKIM setup across real mailbox providers like Gmail, Outlook, and Yahoo. This shows whether your DKIM is trusted in practice, not just by the spec. Don’t assume alignment works—test it.

Why DKIM validation fails even with correct DNS records

DKIM signatures can fail even with seemingly correct DNS records because email gateways often modify headers during transit, forwarders like Google Groups strip or alter signatures, and inconsistent signing policies across domains or subdomains break alignment. These changes invalidate the cryptographic check, even if your DNS setup is technically sound. It’s not just about publishing keys—it’s about preserving the message’s integrity through every step.

Headers get rewritten in transit

Many email gateways—for example, those used by large enterprises or cloud providers—rewrite message headers during routing or filtering. This includes adding or modifying fields like Received, Subject, or even Content-Type. Since DKIM signs the raw header content, any change invalidates the signature, even if your DNS record is perfect.

For instance, a gateway might add diagnostic metadata or adjust line breaks, which alters the exact byte sequence the signature was calculated over. This is a common reason why DKIM passes in testing tools but fails in production. Tools like RFC 6376 explicitly note that any deviation from the original header set breaks the signature.

Forwarding and third-party services break alignment

When an email is forwarded through services like Google Groups or shared mailing lists, the forwarding agent typically rewrites the From field or re-sends the message as a new envelope. This breaks DKIM alignment, especially when the domain in the From header doesn’t match the domain used to generate the signature.

DMARC relies on alignment between From and the signing domain. If the forwarded message uses a different domain, even with a valid DKIM signature, the receiver may reject it as unaligned. This is why emails sent through group mailing systems frequently fail deliverability checks—even with no DNS errors.

Multiple domains without unified signing policies

If you send from multiple domains or subdomains (like [email protected] and [email protected]) and don’t apply the same DKIM signing policy consistently, receivers may interpret this as inconsistency or potential forgery. Some gateways treat mismatched signing domains as a red flag.

Without synchronized policies, especially when DMARC is enforced, emails may be rejected or quarantined. For example, sending via your marketing platform with one domain but signing with another creates ambiguity. It’s not just about having a record—it’s about enforcing a uniform standard across all sending sources.

SPF and DMARC misconfigurations can override DKIM

If SPF and DMARC are misconfigured, receivers may prioritize those policies over DKIM, especially in defensive settings. For instance, a DMARC policy set to reject with a missing SPF or DKIM can cause emails to fail—even if DKIM is present but not aligned.

Some email providers use SPF failure as a reason to discard DKIM results altogether. This is why it’s critical to maintain coherent policies: a single misconfigured SPF record can undermine otherwise valid DKIM signatures. Always validate your full stack using tools that test multiple protocols together.

Check your entire email ecosystem with inbox placement testing or bulk email list verification to catch hidden issues before they impact delivery.

Best practices for avoiding 550 5.7.20 DKIM rejections

You’re seeing 550 5.7.20 dkim validation failed because your email’s DKIM signature doesn't match what the receiving server expects. This happens when signing domains are inconsistent, DNS records are misconfigured, keys are rotated too abruptly, forwarders strip signatures, or messages aren’t tested under real-world conditions. Fix it by standardizing your signing approach, auditing DNS, rotating keys with lead time, avoiding signature-breaking forwarding, and testing deliverability end-to-end.

Ensure consistent DKIM signing across all systems

  • Use the same signing domain (e.g., mail.yourcompany.com) across all platforms—SendGrid, HubSpot, Mailchimp, and internal systems. Mixing domains confuses receivers and triggers validation failures.
  • Never sign emails with different selector or domain values unless explicitly required by a partner. Inconsistency is a red flag to mail servers.
  • Check your SPF and DKIM alignment: even with valid DKIM, if the from domain doesn’t match the header-from or the signing domain, delivery will fail.

Validate DNS records and manage key rotation properly

  • Use a tool like MxToolbox or RFC 6376 to confirm your DKIM TXT records are correctly formatted and syntactically valid—missing quotes, broken values, or malformed syntax will break validation.
  • Rotate DKIM keys well in advance—ideally 30 days before deactivation. Test new keys with real mail flows before disabling the old one.
  • Update DNS before removing old keys. Leaving keys in DNS without active use causes confusion during verification checks.
  • Avoid forwarders like Gmail or Yahoo that strip DKIM signatures. If you must forward, re-sign the message with your own domain.
  • Use inbox-placement tools to simulate real-world delivery. Test with MailTester’s inbox tester to see how your message passes through major providers’ filters.
DKIM is only effective if the signature matches the content and the DNS record is correct. A single syntax error in a TXT record can block delivery.

Let’s be clear: you can’t rely on intuition. Use real tools. Validate each change. Confirm the signature is preserved through every touchpoint. If you’re managing bulk sends, verify your list before sending—use MailTester’s bulk verification to catch invalid, catch-all, or role accounts early. For developers, integrate our real-time API to verify sender legitimacy on the fly.

DKIM failure is not just about technical setup—it’s about process. Consistency, visibility, and testing are your best defenses. The goal isn’t perfection, but reliability: 99% of emails should reach the inbox, not the quarantine.

How MailTester helps prevent 550 5.7.20 DKIM errors

MailTester stops 550 5.7.20 DKIM validation failures before they happen by verifying email addresses in real time and checking domain authentication records like DKIM and DMARC. If a domain lacks proper DKIM alignment or has misconfigured DNS, MailTester flags it—so you don’t waste sends on addresses that will be rejected.

Check records before you send

When you verify an address with MailTester’s API, we don’t just check if the inbox exists—we examine the underlying DNS records. This includes validating the format and existence of DKIM public keys. A mismatch here can trigger a 550 5.7.20 error, so catching it early prevents delivery failure.

Let’s say you’re sending to a domain with a poorly configured DKIM setup. Without verification, your message might be rejected mid-flight. MailTester catches this during the real-time check, so you either fix the issue or skip that address entirely.

Find risky domains before sending at scale

With bulk verification, you can identify entire domains with missing or invalid DKIM records across your list. This lets you clean up high-risk segments before they hurt your sender reputation.

For example, domains with no DMARC policy are more likely to have DKIM issues, and MailTester detects when DMARC is missing or set to none. Since DMARC is a signal that receivers use to assess email legitimacy, skipping domains with weak alignment improves delivery rates.

We also simulate delivery through major providers—like Gmail and Outlook—via inbox-placement testing. These tests run in real email environments, so if DKIM alignment fails during the test, you’re alerted before you send at scale. This is how we catch issues that might otherwise appear only in production.

For developers, our real-time email verification API integrates directly into your send workflow, catching errors before the first email leaves your server.

As outlined in RFC 6376, DKIM validation requires a cryptographic signature verified against a valid public key. When the key isn’t accessible or the signature fails, the result is a 550 error. This is standard behavior in modern email systems, including those used by Microsoft and Google. Preventing these failures isn't just about reducing bounces—it's about protecting your reputation.

Learn more about how we keep your sends safe: integrations with Mailchimp, HubSpot, SendGrid, and more let you run verification inside your existing workflow.

Is DKIM validation failure always your fault?

You’re not always at fault when you see a 550 5.7.20 dkim validation failed error. Some email providers accept transient DKIM issues if SPF passes and the message shows other legitimate signals. But repeated failures—especially from the same domain—raise red flags with modern spam filters. Even if a third party caused the issue, your sender reputation still takes a hit when messages get rejected.

Why not every DKIM failure is your problem

DKIM signing can fail for reasons outside your control. A third-party email service, an outdated signing key, or a misconfigured DNS record on a relay server can all trigger a valid failure without you doing anything wrong. Some providers, like Gmail and Outlook, tolerate occasional DKIM issues if other alignment checks pass. This is a recognition that systems aren’t always perfect, and minor misalignments don’t automatically signal spam.

But consistency matters. If the same domain repeatedly fails DKIM—especially across multiple emails—spammers and filters interpret that as a sign of poor sender hygiene. According to industry practices, consistent failures are often treated as evidence of compromised infrastructure. Even if one failure is accidental, a pattern signals risk.

Your sender reputation still pays the price

Even when the root failure isn't yours, the outcome is what matters: delivery drops. Filters like those used by Microsoft 365 or Google's Postini don't care who caused the DKIM mismatch—they only see that the message failed alignment. If the message never lands in the inbox, your reputation suffers. And reputation is not just about your domain—it includes sender IP history, engagement patterns, and bounce rates.

One way to spot issues early is to test your list before sending. Tools like MailTester can catch invalid or misbehaving addresses before they impact your deliverability. For instance, bulk verification can flag domains that consistently fail DKIM checks during inbox placement testing. Bulk list verification or the real-time verification API help you find problematic addresses before they hurt your sender reputation.

DNS-based validation, like SPF and DKIM, isn’t just about technical alignment. It’s about trust. The email ecosystem works on signals, not perfection. Still, every failed check costs you credibility. If a domain fails DKIM over and over, even if not your fault, that domain becomes a liability in your list. Cleaning your list regularly—using tools that test actual deliverability—is the only way to keep your reputation intact.

How to recover from a 550 5.7.20 DKIM rejection pattern

When your emails get rejected with a 550 5.7.20 DKIM validation failed error, it’s not just a bounce—it’s a signal that your domain’s cryptographic signature is broken or missing. This means your emails are being flagged as potentially forged. The fix starts with auditing every domain you send from, verifying their authentication, cleaning invalid addresses, and rebuilding trust through verified senders. Let’s walk through it step by step.

Step 1: Audit all your sending domains and sources

Every domain and source sending emails on your behalf needs to be identified. This includes primary domains, subdomains, third-party platforms (like Mailchimp or HubSpot), and transactional senders. A single misconfigured domain can cause a rejection across your entire sending stack. DKIM standards require that each sending domain includes a valid, properly aligned signature.

Step 2: Validate each domain with MailTester

Use MailTester’s bulk verification to check every domain in your sending stack. It tests not just deliverability, but whether DKIM, SPF, and DMARC are correctly configured. Many senders miss misaligned DKIM records because they’re unaware their subdomains aren’t properly signed. MailTester spots these failures in seconds and tells you exactly where the breakdown is.

  1. Run a full list check using MailTester’s bulk verification tool. Upload your sender list and let the tool analyze every email address and its domain. It returns verdicts like “valid,” “invalid,” “catch-all,” or “risky.” A “risky” verdict often points to authentication misconfigurations, including DKIM issues.
  2. Remove or quarantine any address tied to a domain with failed DKIM validation. These domains are likely to trigger rejections. You might also see “invalid” or “catch-all” addresses that don’t represent real users. Cleaning these out improves your sender reputation and reduces bounce rates.
  3. Rebuild sender reputation by sending only to validated, engaged recipients. Stop sending to unverified or dormant addresses. Focus on deliverability by only reaching engaged users—even if it means slower growth. Over time, consistent sending to clean, verified lists improves inbox placement. Email providers like Microsoft, Google, and Apple track sending behavior and penalize poor hygiene.
  4. Revalidate your setup using MailTester’s inbox placement tester. After cleaning and correcting, run a final inbox placement test. This confirms your messages now land in inboxes (not spam) and pass all authentication checks. MailTester’s inbox tester simulates real-world filtering, showing you whether your DKIM is now working across all major providers.

DKIM failures aren’t usually a one-off error—they indicate an underlying infrastructure gap. Addressing them requires consistent auditing and verification. The recovery path isn’t instant, but with precision, you can restore trust with providers, fix your delivery, and improve long-term sender reputation. You don’t need fancy tools—just reliable verification and discipline.

Final takeaway: DKIM is not optional—fix it now

A single 550 5.7.20 rejection won’t halt a campaign, but repeated failures erode sender reputation. ISPs track authentication patterns over time. Consistent DKIM validation failures signal poor sender hygiene, increasing the risk of bulk filtering.

Fixing issues after delivery fails is slower and more costly than preventing them. Real-time email verification catches invalid, malformed, or unauthenticated addresses before they reach the inbox.

What to do next

  • Verify all new and existing lists using a tool that checks SPF, DKIM, and MX records simultaneously.
  • Use high-accuracy verification to eliminate risk — 98.9% precision means fewer false negatives and fewer wasted sends.
  • Integrate verification into your workflow: before onboarding, before campaigns, before list uploads.

Sources

Keep reading

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

Frequently asked questions

Can DKIM validation fail even if the email arrives in the inbox?

Yes. Some providers accept messages despite DKIM failure if other authentication checks (like SPF) pass. However, this is inconsistent and risky for long-term deliverability.

Does DKIM affect spam filtering?

Yes. Missing or invalid DKIM signatures are a known signal for spam filters. While not the sole factor, persistent failure reduces inbox placement.

How long does it take for a DKIM DNS change to take effect?

DNS propagation typically takes 1 to 48 hours, depending on TTL settings. Test changes only after 24 hours to confirm.

Can shared hosting providers break DKIM?

Yes. Some shared environments do not support custom DKIM records or allow multiple domains to share a single DKIM key, increasing failure risk.

Should I use a single DKIM key for all domains?

No. Each domain should have its own selector and key pair. Using one key across domains reduces security and increases the risk of failure.

Is 5.7.20 a common error among email marketers?

Yes. It's frequently seen in campaigns sent from poorly configured ESPs, unauthenticated domains, or domains with outdated DNS records.

How can I verify DKIM before sending?

Use MailTester’s real-time API to verify a recipient’s address—and its domain’s DKIM alignment—before sending. This catches issues before delivery.

Do email clients show DKIM validation status to users?

Most do not. The validation happens behind the scenes at the mail server level, so end users see no trace of it unless viewing raw headers.

Are DKIM failures always visible in bounce messages?

Not always. Some mail servers return only the generic 550 5.7.20 code, while others include a full diagnostic. Check the full bounce report for details.

Can I use MailTester to check DKIM alignment across all domains in my list?

Yes. Our bulk email verification checks DNS records, including DKIM, SPF, and DMARC, and flags domains with missing or invalid configurations.