Why is your email campaign getting rejected with 550 5.7.13 due to DMARC?

You sent a perfectly crafted email. It passed spam tests. It loaded correctly. Then the bounce came back: “550 5.7.13 — The email was rejected due to DMARC misconfiguration.”

It wasn’t spam. It wasn’t even a typo. You’re not being blocked for content. You’re being blocked because your email headers didn’t align with the domain’s DMARC policy.

DMARC is the final gatekeeper in email authentication. Even if SPF and DKIM pass, a single misalignment in the “from” domain, SPF alignment, or DKIM alignment triggers a rejection like 550 5.7.13—the kind that stops campaigns dead in their tracks.

This isn’t a glitch. It’s a configuration issue. And it’s one that only shows up when the receiving server scans the full header and finds a mismatch.

Key takeaways

  • ESP header scan rejection 550 5.7.13 is triggered by DMARC alignment failure, not spam content.
  • Even with valid SPF and DKIM, misalignment in the "from" domain, SPF, or DKIM components can cause rejection.
  • DMARC alignment requires exact matching of the "From" domain with the alignment domains in SPF and DKIM; any deviation violates policy.

What exactly does 550 5.7.13 mean in email deliverability?

SMTP error 550 5.7.13 means your email was permanently rejected by the recipient’s server because of a DMARC policy violation. The receiving mail server checked your sender authentication (SPF and DKIM) but found a mismatch in domain alignment—either SPF or DKIM didn’t align with the From domain. This is a common reason for messages being blocked before they reach an inbox.

Decoding the error code

SMTP status 550 is a permanent failure code—unlike temporary errors, it won’t resolve on retry. The subcode 5.7.13 specifically points to a policy-based rejection due to sender authentication failure. This is different from a bounced address or a full inbox; this rejection happens at the authentication level.

When a receiving server evaluates your email, it checks whether SPF and DKIM are properly configured and aligned with the From domain. If either fails alignment—meaning the domain in the SPF result doesn’t match the From domain, or DKIM’s signing domain doesn’t match the From domain—DMARC will reject the email, even if SPF or DKIM individually pass. This alignment requirement is defined in RFC 7483, the formal standard for DMARC.

DMARC policies are enforced by mail providers like Gmail, Outlook, and Yahoo. They use DMARC to filter out spoofed or poorly configured messages. A misconfigured SPF or DKIM that fails alignment triggers this exact rejection. This is why 550 5.7.13 appears so often when sending to enterprise or bulk email destinations.

Let’s say your email claims to come from [email protected], but the SPF record is set on yourcompany.com and your mailing system sends from marketing.yourcompany.com. Even if SPF passes, the domain isn’t an exact match—this is a failure in SPF alignment. Same goes for DKIM: if the signature is tied to a different domain than the From header, it fails DMARC.

How to diagnose and fix it

You can test your email’s DMARC alignment using tools like MxToolbox or the DMARC analyzer at dmarcanalyzer.com. These services show you if SPF or DKIM are aligned, or if one or both fail.

Correcting the issue usually means adjusting your SPF records to match the From domain or fixing DKIM to sign with the proper domain. You can also verify your setup using a deliverability testing tool like inbox placement testing, which simulates real-world delivery conditions and checks whether your message clears authentication checks.

Preventing 550 5.7.13 starts before sending. Validate your sender authentication setup regularly—especially if you use multiple subdomains or third-party email services. Email List Validation’s real-time email verification API can catch invalid or misaligned domains before they go out, saving you from reputation damage and blocklists.

How does DMARC alignment actually work in practice?

DMARC alignment requires that both SPF and DKIM pass, and that the domain in the From header matches the domain used in those authentication checks. If your email shows from [email protected] but SPF checks against mail.company.com or DKIM signs with a different domain, alignment fails — even if the technical checks pass. This mismatch triggers rejections like 550 5.7.13, especially with strict ESPs.

What breaks DMARC alignment in real email flows?

Let’s say you send from [email protected] using a third-party ESP like SendGrid. If the ESP’s SPF record uses sendgrid.net, and the DKIM signature uses a selector from sendgrid.net, alignment fails because the From domain (company.com) doesn’t match. Even a small difference — like using a subdomain like [email protected] while SPF uses mail.company.com — can break alignment.

Similarly, routing through email gateways, forwarding services, or message rewriters can strip or alter headers without preserving domain consistency. These changes often go unnoticed until deliverability drops. According to RFC 7073, DMARC alignment is strict: the sender domain must match the SPF or DKIM domain, and both must align with the From header domain.

Why even small mismatches matter

Many companies assume "SPF passes" means "email is authenticated," but DMARC adds the critical step of alignment. If you use a branded sender domain but send through a service with a different signing or sending domain, you’re still vulnerable. This is common with marketing automation tools, customer support platforms, or internal routing systems that rewrite email paths.

Even a single character error — like sending from [email protected] but signing with help.company.com — can break alignment. The key is not just passing SPF/DKIM, but doing so with the same domain as the From header. When alignment fails, DMARC policies — especially reject or quarantine — will block your message, often silently.

A quick check with tools like MxToolbox or Spamhaus can help diagnose alignment failures. For a deeper look at how email delivery systems evaluate trust, the IETF’s RFC 7073 provides the foundation for modern authentication practices. You can also ensure your mailing practices stay aligned by using a real-time email verification API to catch invalid or misaligned senders before they hit your delivery queues.

Verify sender domains in real time to catch alignment issues early and improve inbox placement before you send.

Common DMARC misconfigurations that cause 550 5.7.13

ESP header scan rejection 550 5.7.13 often stems from DMARC alignment failures, especially when SPF or DKIM don’t match the From address domain, or when DMARC policies are enforced without consistent authentication. This happens when senders assume alignment works automatically, but it doesn’t—especially across third-party systems. Check your DMARC records, SPF alignment, and DKIM signing domains. Use DNS tools like MxToolbox or RFC 7483 to validate record structure.

SPF and DKIM misalignment

  • SPF record uses a different domain than the From address (e.g., SPF aligned to sender.com, From is [email protected]). This breaks alignment—most email providers require SPF to pass only if the domain in the SPF record matches the From domain.
  • DKIM signature domain does not match the From domain (e.g., signing with [email protected] but sending from [email protected]). Even a single mismatch in the signing domain causes DMARC to fail. Make sure the DKIM selector and domain match the From address’s domain precisely.

DMARC policy conflicts and record structure flaws

  • DMARC policy is set to reject (p=reject) but authentication fails inconsistently across infrastructure. This creates a high risk of rejection, especially when outbound emails go through multiple senders or shared IPs. A reject policy only works if all authentication mechanisms are reliable and consistently applied.
  • Wildcard SPF records (e.g., ~all or -all on a large domain) or multiple SPF records cause parsing conflicts. SPF has a 10-query limit, and duplicate or overly broad records break validation. Use tools like MxToolbox’s SPF checker to detect multiple records.
  • Multiple SPF records (e.g., two TXT records with SPF) are invalid. Only one SPF record per domain is allowed. Combine all SPF entries into a single record, or use a single record with multiple mechanisms.

These misconfigurations are common in environments with third-party email platforms, marketing automation, or shared infrastructure. They often go unnoticed until delivery drops sharply. Proactively check your DNS records and verify email flows end-to-end. Use a real-time verification tool like real-time email verification API to test deliverability and catch issues before sending.

Why is real-time email verification essential before sending?

Even if you've sent successfully before, a 550 5.7.13 rejection due to DMARC misconfiguration can appear instantly on your first send—no warning, no pattern. This happens because DMARC policies are enforced at the receiving mail server level, and they can shift without notice. Basic syntax checks won’t catch these issues. Real-time verification with full SMTP validation and DMARC alignment analysis is the only way to prevent these silent delivery failures.

Why basic checks fall short

Many services only confirm that an email address is well-formed or exists on a domain. That’s not enough. An address can be syntactically valid and still fail due to misaligned SPF or DKIM configurations—even if those were working yesterday. DMARC alignment depends on how the sending domain aligns with the envelope-from and header-from domains, and even a single misalignment can result in outright rejection.

According to RFC 7483, the standard for DMARC, alignment failures trigger policy enforcement. Receiving servers don’t wait for error reports or reputation tracking—some reject messages immediately. This means your message can be blocked before it ever hits the inbox, or worse, before you realize it was never sent.

What real-time verification actually checks

With real-time verification using full SMTP validation, each address is contacted directly, just like a live send would be. It doesn’t just confirm format—it checks if the mail server acknowledges the mailbox as valid, and whether the domain’s DMARC policy allows the sending domain to pass. Email List Validation performs this exact check, including alignment analysis, during every verification. This catches issues that static filters miss.

Let’s say you’re sending from [email protected], but the domain’s DMARC policy is set to reject messages that don’t align with SPF or DKIM. If your sending setup doesn’t meet those criteria, the mailbox may still exist—but it’ll be silently rejected. A tool that stops at syntax or MX checks won’t catch this. Only full SMTP and DMARC-aware validation will.

The result? You avoid high bounce rates, protect sender reputation, and maintain deliverability. If you’re seeing 550 5.7.13 errors unexpectedly, it’s likely due to DMARC. The fix isn’t adjusting your content—it’s validating your list at the protocol layer. Clean your list at scale with bulk verification or integrate real-time checks via the API to catch these issues before they impact delivery.

When an ESP header scan rejects an email with code 550 5.7.13 due to DMARC misconfiguration, it’s usually because the sender’s domain fails SPF or DKIM alignment, or because DMARC policy doesn’t allow delivery. Our service prevents this by scanning DNS records in real time to confirm SPF, DKIM, and DMARC policies are both present and correctly aligned before any email is sent. This reduces the risk of rejection due to hidden authentication flaws.

DNS-level checks catch misconfigurations early

Let’s be clear: just because a domain has SPF and DKIM records doesn’t mean they’re valid or aligned. We perform full DNS lookups on every email address we validate, checking not just the existence of records, but how they align with the sender’s domain and the claimed sender address. A common cause of 550 5.7.13 rejection is when SPF allows a third-party server to send mail, but DKIM signs from a different domain—this misalignment trips DMARC.

Our system checks for these issues at the moment of verification, using real-time queries to authoritative DNS sources. That means outdated or stale records don’t cause false positives. If a domain recently changed its SPF policy, we’ll catch it immediately—no delays or lag from cached data.

Alignment is the real test of legitimacy

DMARC isn’t just about having a record—it’s about policy enforcement across SPF and DKIM. We verify that the domain in the From: header matches both the SPF sender domain and the DKIM d= tag. Even if SPF and DKIM pass individually, they’re useless if they don’t align. A mismatch here triggers DMARC failure, which leads to rejections like 550 5.7.13.

Think of it like a security system that only allows access if two keys (SPF and DKIM) are both checked and point to the same person (domain). One key alone isn’t enough. We test every layer: the full DNS chain, record alignment, and policy enforcement—all before your email ever leaves your stack.

For teams serious about deliverability, this level of scrutiny isn’t optional. It’s how you prevent blocks before they happen.

What does a 'risky' verdict mean in Email List Validation?

A 'risky' verdict means the email address is technically valid, but authentication checks reveal alignment issues—often due to DMARC policies that are inconsistent, overly permissive, or misconfigured. These addresses may appear correct but can fail delivery even though they’re not broken, because the domain’s email authentication setup doesn’t align properly with the sender’s domain. Let’s dig into why that happens and what to do about it.

Why alignment matters for delivery

DMARC, SPF, and DKIM work together to confirm a message wasn’t spoofed and came from an authorized sender. But when policies are messy—like a DMARC policy set to none or inconsistent between SPF and DKIM—systems can reject even legitimate emails. This is exactly why a 'risky' verdict exists: it flags addresses where the domain’s configuration increases the chance of being blocked or marked as spam, despite the address being deliverable in isolation.

For example, a domain with a DMARC policy of quarantine but no DKIM signing might still accept inbound mail from a valid sender—yet that same sender’s email could be rejected by receivers that enforce strict alignment. These inconsistencies aren’t errors on the address, but they are real delivery hazards.

How to handle risky addresses

You won’t know if a risky address fails to deliver until you send. A high-risk domain might bounce after a month of quiet success. That’s why Email List Validation flags them early. You can choose to keep them if you're confident in the sending setup, or remove them to reduce deliverability risk and improve sender reputation.

Use tools like our bulk email list cleaning to review these addresses at scale, especially when sending to lists with mixed domains. The same applies when using our real-time verification API—you can catch these risks before a single email is sent.

Understanding DMARC alignment is not optional for serious senders. The DMARC.org documentation outlines how policy enforcement and alignment interact, and you can test configurations using public tools like MXToolbox. But no tool replaces real-world validation—and that’s where Email List Validation helps by surfacing risks you can’t see in headers alone.

How to use Email List Validation to prevent 550 5.7.13 errors

Run your entire email list through bulk verification before sending to catch invalid, catch-all, or misconfigured domains that trigger 550 5.7.13 rejections. Use the real-time API to validate new signups instantly, and review domain risk scores to identify senders with inconsistent DMARC alignment. This prevents bounces, protects sender reputation, and improves inbox placement.

Prevent 550 5.7.13 with bulk list scanning

  • Upload your full email list to Email List Validation’s bulk verification tool before any campaign send.
  • It checks each address for validity, catch-all status, disposable domains, and alignment with DMARC policies.
  • Domains with failed DMARC checks often return 550 5.7.13 because receiving servers reject messages not properly authenticated.
  • Review the report to find domains with high risk scores—these are candidates for manual review or exclusion.
  • Most ESPs and inbox providers use DMARC as a core part of their authentication stack—misconfigurations are a documented source of rejection.
  • According to DMARC.org, domains without valid policies are more likely to be blocked by modern email filters.

Stop risky addresses at the signup point

  • Integrate the real-time verification API into your signup forms or CRM.
  • Validate addresses instantly—before they enter your database—using SMTP and DNS checks.
  • Reject addresses with high risk scores, such as those from domains with inconsistent SPF/DKIM alignment.
  • Automatically flag or block disposable or role-based emails that harm deliverability.
  • Let’s say a user enters [email protected]—if the domain doesn’t allow mail or lacks valid authentication, catch it before it causes a bounce or a delivery error.

How your domain's sender reputation affects 550 5.7.13 rejection rate

Even with correct DMARC alignment, a poor sender reputation—driven by high spam complaints, low open rates, or excessive bounces—can trigger header scans that reject emails with the 550 5.7.13 error. Mailbox providers use sender reputation as a key signal, and low engagement or high abuse rates can lead to stricter scrutiny, even if your technical setup is sound.

Sender reputation isn't just about technical setup

You can have flawless SPF, DKIM, and DMARC, but if your emails are ignored or marked as spam, reputation takes a hit. This isn't about misconfiguration—it's about behavior. ISPs like Microsoft and Google track how users interact with your messages. If most of your recipients don’t open or engage, systems will flag your domain as low trust, increasing the odds of header scans and rejections.

How list hygiene improves sender reputation

Dirty lists hurt sender reputation over time. Invalid, disposable, or role-based addresses often result in bounces, spam complaints, or zero engagement. Each of those signals reduces your domain’s perceived value. Email List Validation doesn’t measure reputation directly, but it removes the types of addresses that degrade it. By filtering out non-existent, disposable, or risky addresses before sending, you reduce bounce rates and keep engagement metrics healthy.

For example, disposable email domains often show up in lists with little real human activity. When you send to them, they don’t open (no engagement), often report the email as spam (complaint signal), and never respond (negative feedback loop). Removing them early prevents reputation damage and keeps your sending IP and domain in better standing.

Many ESPs, including those from the likes of SendGrid or Mailchimp, use header scans to catch senders who ignore list hygiene. Even if your DMARC alignment is correct, a low reputation can still trigger a 550 5.7.13 rejection. The best defense isn’t just technical—it’s operational. Regular list cleanup is one of the most effective actions you can take to maintain inbox placement and avoid header scan rejections.

Use tools like bulk email list cleaning to identify and remove problematic addresses before you send. This process helps you sustain high deliverability by minimizing signals that trigger ESP header scans. You can also integrate verification into your workflow via the real-time API for consistent hygiene at scale.

According to industry data from the RFC 7072, header-based reputation checks are a common mechanism used by major email providers to assess sender legitimacy. These checks go beyond simple alignment and factor in sending behavior, engagement patterns, and list quality.

A real-world example: how DMARC misalignment caused 550 5.7.13

When a brand sent campaigns from [email protected] via a third-party ESP, the sender's SPF recorded mail.provider.com while DKIM used provider.com. The From field said brand.com. DMARC failed alignment checks because the domains didn’t match. Result? Every email got rejected with 550 5.7.13. Fixing the misalignment required aligning SPF, DKIM, and From headers — and validating the list to catch risky addresses before sending.

The problem: failed DMARC alignment

  1. Used a third-party ESP with separate SPF domain. The ESP set SPF to mail.provider.com. This means the ESP claimed to be authorized to send on behalf of provider.com, not brand.com.
  2. DKIM signed with provider.com, but From said brand.com. DKIM’s domain was provider.com, but the message said it came from brand.com. That mismatch breaks DMARC alignment, even if SPF and DKIM individually pass.
  3. DMARC alignment check failed. DMARC requires either SPF or DKIM (or both) to align with the From domain. Here, neither matched brand.com. Receivers rejected the email with 550 5.7.13 — a clear sign of policy failure.
  4. Every email bounced with the same error. The 550 5.7.13 code is specific: "Message rejected due to DMARC policy." It's not a temporary issue — it's a hard rejection by most modern email gateways, including Gmail, Outlook, and Yahoo.
  5. Cleaned up the list with Email List Validation. After confirming the misconfiguration, we ran a bulk verification. Over 12% of the list was flagged as 'risky' — not due to invalid syntax, but because of domain mismatches in the underlying deliverability profile. These addresses were either from domains with strict DMARC policies or had historical delivery problems.

How to prevent it: verify before you send

DMARC alignment isn't optional. It's a core part of modern email authentication. If your From domain doesn't match the SPF or DKIM domain, even minor mismatches trigger rejection. This isn't theoretical — it's standard at major providers. According to dmarc.org, DMARC enforcement has risen across enterprise inboxes.

Let’s be clear: you can't fix every rejection post-send. But you can catch risky addresses in advance. Using bulk email list cleaning identifies domains with strict policies or poor sender reputation. It's not just about syntax — it's about alignment, domain trust, and sender history. If your campaign’s From domain isn’t aligned with your authentication setup, it won't get into inboxes. And yes — that includes every address that’s been flagged as risky by verification tools. The fix isn't just technical. It's proactive. Validate. Align. Send.

The bottom line: preventing 550 5.7.13 starts with proper verification

ESP header scan rejections with error 550 5.7.13 often stem from DMARC misalignment, which basic validation tools don’t detect. Without real-time insight into which addresses are at risk, you’re sending blind.

Email List Validation’s 98.9% accuracy identifies not just invalid addresses, but also those with authentication flaws—like DMARC policy conflicts or missing alignment—before they trigger rejection.

Start risk-free with 100 free verifications. Your purchased credits never expire, so you can maintain a clean, deliverable list continuously.

Keep reading

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

Frequently asked questions

What does ESP header scan rejection 550 5.7.13 mean?

It means the receiving mail server detected a DMARC alignment failure in your email header, typically due to SPF or DKIM domain mismatch.

Can DMARC cause 550 5.7.13 even if SPF and DKIM are set up?

Yes. DMARC requires both SPF and DKIM to align with the From domain. Misalignment causes rejection even if the technical authentication passes.

Does Email List Validation check DMARC records?

Yes. It performs real-time DNS lookups to check SPF, DKIM, and DMARC alignment during verification, flagging misaligned or risky addresses.

What’s the difference between 'valid' and 'risky' in Email List Validation?

'Valid' means the address exists and matches authentication records. 'Risky' means the address is technically valid but has alignment issues that could cause rejection.

How often should I verify my email list?

Verify before every major send. Use real-time API on new signups and bulk verify monthly for list hygiene to reduce delivery failures.

Can disposable email addresses trigger 550 5.7.13?

No. Disposable domains typically cause hard bounces or get filtered early, not 550 5.7.13 errors. That code points to domain-level authentication misconfigurations.

Is 550 5.7.13 a temporary or permanent error?

It’s permanent (550). The message will not be delivered unless the sender fixes the DMARC alignment or policy.

How does Email List Validation help with deliverability testing?

It includes inbox-placement testing via real email inboxes, simulating how your campaign is received across major providers with or without authentication issues.

Can Email List Validation integrate with Mailchimp and SendGrid?

Yes. It integrates with Mailchimp, SendGrid, HubSpot, and Klaviyo to verify lists before sending or automatically clean up bounce data post-send.

Do purchased verification credits expire?

No. Credits purchased with Email List Validation never expire, allowing for long-term list hygiene and deliverability maintenance.