Why Email Gets Rejected with 5.7.13 DMARC

What does error 5.7.13 DMARC actually mean?

You sent an email. It bounced. The error code? 5.7.13 DMARC. You’re not getting a spam filter alert. No “blocked by content.” Just a hard rejection with a cryptic status. What went wrong?

This isn’t about your message being offensive. It’s about identity. Receiving servers are rejecting it because your domain failed DMARC, even if SPF and DKIM checks passed. You’re not spamming — you’re just not proving who you are.

DMARC is the final gatekeeper. It doesn’t care about your subject line. It cares about whether your domain’s authentication stack is trustworthy. This code means your sender identity didn’t align with the expected policy.

Key takeaways

SMTP error 5.7.13 means your domain failed DMARC policy enforcement, even if SPF and DKIM appear valid
DMARC rejection is about sender identity integrity, not content or spam score
Fixing 5.7.13 requires checking DMARC records, alignment, and policy enforcement levels

How DMARC works: a technical overview

DMARC (Domain-based Message Authentication, Reporting, and Conformance) blocks emails that can’t prove they’re from a legitimate source. It checks whether the sending domain in the 'From' header aligns with the SPF and DKIM signatures. If alignment fails—say, the sending domain differs from the one used in the authentication records—the email may be rejected outright with error code 5.7.13.

DMARC builds on SPF and DKIM for sender identity

When you send an email, the receiving server checks two things: whether the sending IP is authorized (SPF) and whether the message hasn’t been altered (DKIM). DMARC adds a third layer: it verifies that the domain in the 'From' header aligns with the domains used in SPF and DKIM. If they don’t match, the server treats the message as suspicious.

Let’s say your marketing team sends from [email protected], but the SPF record allows only mail.yourcompany.com to send messages. DMARC will flag that mismatch, even if SPF passes. That’s how DMARC prevents spoofing and phishing.

Why 5.7.13 shows up during delivery

When DMARC alignment fails, email receivers follow the policy set in the sender’s DMARC record. If the policy is set to reject, not none or quarantine, the email gets blocked. Error code 5.7.13 is the standard SMTP response for this rejection.

This is common with third-party senders who don’t configure their domains properly. Sending through a tool like Mailchimp or HubSpot? If the sending domain doesn’t align with the authenticated domain, your message can still be rejected—even if the email address is valid.

DMARC is widely adopted: major providers like Gmail and Outlook use it to filter incoming messages. According to RFC 7483, DMARC was designed to close gaps in email authentication. It’s an industry-standard practice, not optional for large organizations.

Preventing 5.7.13 errors starts with clean email lists and aligned authentication. You can test deliverability in real time before sending. See how your campaign performs in real mailboxes with inbox-placement testing—real inbox testing helps catch alignment and policy issues before they impact delivery.

Why does 5.7.13 happen even when SPF and DKIM pass?

Even if SPF and DKIM pass individually, DMARC can still block your email because it requires both alignment and policy enforcement. A single misalignment—like sending from a subdomain that doesn’t match the domain in the From header—can trigger rejection with error 5.7.13, regardless of individual authentication results.

DMARC alignment is stricter than SPF or DKIM alone

SPF validates the sending server’s IP, and DKIM checks message integrity. But DMARC evaluates whether the domain in the From header aligns with both the SPF domain and the DKIM signature domain. If they don’t match, even with valid SPF and DKIM, the email fails DMARC. This often happens when you send from a subdomain like mail.yoursite.com with SPF set for your main domain, yoursit.com.

Let’s say your email comes from mail.yoursite.com, but SPF is set only for yoursite.com. The SPF check passes because the IP is authorized. DKIM might also pass. But if the From header uses yoursite.com, and the DKIM signature is signed under mail.yoursite.com, the domains don’t align—DMARC fails.

Third-party senders compound the problem

When you use marketing platforms like Mailchimp or HubSpot, your emails get sent from their infrastructure under their domains. If your From domain doesn’t match their sending domain and you haven’t configured proper subdomain policies in DMARC, those messages get rejected with 5.7.13—even if SPF and DKIM validate.

Common missteps: setting a permissive DMARC policy like policy=none that doesn’t block emails, or failing to allow subdomains in your DMARC record. RFC 7050 defines how subdomains should be handled, but many organizations skip this, leaving their emails vulnerable to strict policies.

Even well-meaning configurations can cause issues. If you’re relying on a third-party to send emails on your behalf, ensure their sending domain is explicitly allowed in your DMARC record. Otherwise, alignment fails, and your message gets blocked—often without clear indication beyond the error code.

Tools like real-time email verification API can catch invalid, unverifiable, or misaligned sender addresses early, reducing the risk of sending to domains that enforce strict DMARC policies.

Common causes of DMARC failure leading to 5.7.13

DMARC error 5.7.13 means the receiving server rejected your email because it failed alignment checks between the From domain and the authentication results (SPF/DKIM). You’re likely sending from a subdomain without aligned records, using a service that doesn’t preserve header alignment, or misconfiguring DKIM. These issues trigger DMARC policies that drop the message. Let’s break down how this happens and what to fix.

Subdomain misalignment and missing SPF/DKIM

You’re sending from [email protected] but the parent domain company.com doesn’t have SPF or DKIM records set up to cover the subdomain.
Even if SPF or DKIM exist, they must explicitly allow the sending subdomain. Without proper alignment, DMARC flags the email as unverified.
Check RFC 7483 for how DMARC alignment works: the From domain must match either the SPF or DKIM domain.

Transaction or mailing list services that break alignment

You're using a transactional email service (like SendGrid, Mailgun, or AWS SES) but the From header doesn’t match the domain used in your SPF or DKIM records.
Many services rewrite or override the From header during delivery, which breaks alignment if your authentication is set to the original domain.
Using a mailing list platform that auto-forwards messages can also break alignment, especially when original headers are stripped or altered during resending.

DKIM misconfiguration

You're signing with DKIM, but the selector or signing domain doesn’t align with the From domain.
Your DKIM record might point to mail.company.com, but the email is sent from [email protected]. That mismatch breaks DMARC.
Double-check that your DKIM signing domain matches the domain in the From header and that your DNS records are published correctly for that domain.

DMARC doesn't just check if an email is authenticated—it checks whether the authentication aligns with the sender’s actual domain. A mismatch in any part of this chain triggers rejection with 5.7.13.

You can test alignment and catch these issues early with inbox placement tools. Try inbox placement testing to see how real inboxes react to your messages—with and without header alignment.

How to check if your domain is DMARC-compliant

You can verify your domain’s DMARC compliance by checking the DNS TXT records for a valid DMARC policy starting with v=DMARC1;. Look for the correct policy setting—p=none, p=quarantine, or p=reject—applied to the root domain and subdomains. Use tools like DMARCian or MXToolbox to analyze your setup and detect issues early.

Step-by-step: How to check your DMARC record

Go to DMARCian or MXToolbox and enter your domain.
Review the results to confirm a DMARC TXT record is present—look for v=DMARC1; at the start.
Check that the policy is set to p=reject or p=quarantine if you want to prevent spoofing. A p=none policy only monitors, not blocks.
Ensure the record applies to both the root domain and relevant subdomains. A missing subdomain policy may leave parts of your email flow vulnerable.
Check for common errors: incorrect syntax, multiple conflicting records, or missing tags like rua (reporting address).

What to do if your domain isn’t compliant

If the analyzer shows no DMARC record or an invalid one, you need to create or fix the TXT record in your DNS provider’s control panel. The record must start with v=DMARC1; and include a policy. For example: v=DMARC1; p=reject; rua=mailto:[email protected].

Even if you’re not seeing bounces now, a weak or absent DMARC policy means your emails may be silently blocked by receivers like Gmail or Outlook—especially when sent from third-party tools or shared servers.

Once set up, monitor your reports regularly. You’ll receive aggregate feedback on which senders pass or fail DMARC checks. This helps you catch issues early before they impact deliverability.

While DMARC helps prevent spoofing, it doesn’t guarantee inbox delivery on its own. If you're sending at scale and want to minimize bounces from invalid or risky addresses, clean your list with real-time verification. Bulk email list cleaning with Email List Validation ensures your outreach starts on strong ground—valid, deliverable emails only.

How email verification prevents 5.7.13 DMARC failures

DMARC error code 5.7.13 means your email was rejected because the domain alignment failed—your sender domain doesn’t match the domain used in authentication headers. Email List Validation checks for this during verification by testing domain-level DMARC alignment. It flags domains with strict policy enforcement, so you avoid sending to addresses that will be blocked by receivers whose servers enforce DMARC rigorously.

How DMARC alignment impacts delivery

When a domain enforces DMARC with a policy of reject (p=reject), every email must pass SPF or DKIM alignment. If you send from a domain that doesn’t align—like using a third-party mail server with a different authentication setup—it gets flagged. This triggers error 5.7.13, even if your mail server is otherwise legitimate.

Many modern email providers (including Gmail, Outlook, Yahoo) now apply strict DMARC enforcement. Some senders lose inbox placement simply because their sending infrastructure doesn’t align with the domain they’re claiming. This isn’t about spam—it’s about trust and identity.

Why verification catches 5.7.13 early

Email List Validation doesn’t just check if an address exists—it probes whether that domain has active, enforceable DMARC policies. It uses real-time DNS lookups and reputation databases to identify domains that reject unaligned messages. If a domain requires strict alignment and your sending setup fails to meet it, the email is marked as risky or invalid before you send.

Let’s say you're using a transactional service with a domain like smtp.yourapp.com. If you send from that domain but it doesn’t align with the From: address, DMARC breaks. Email List Validation spots this mismatch during bulk verification, alerting you before you waste sends. You can then either adjust your envelope sender or exclude that recipient.

It doesn’t just help you avoid bounces—it keeps your sender reputation intact. Repeated 5.7.13 failures signal poor sending hygiene to email providers. The result? Your IP or domain gets added to blocklists, even if you’re not spam.

For a deeper look at how DMARC works, see the official specification at RFC 7483. The foundation of email trust is alignment. Tools like bulk email list cleaning help ensure your outbound messages don’t fail at the gate.

What role do sender reputation and list hygiene play?

DMARC error 5.7.13 often isn’t about the email itself—it’s about trust. A weak sender reputation, built over time from poor sending habits, can trigger strict enforcement even for valid addresses. If your domain appears risky due to spam complaints, high bounce rates, or inconsistent sending, mail servers may reject messages outright. Keeping your list clean reduces scrutiny and helps maintain reputation. DMARC's design assumes sender accountability, so poor list hygiene directly undermines that trust.

Sender reputation is earned, not inherited

Even if your email is technically correct, a low sender reputation makes you a target. ISPs and email providers use reputation signals—like bounce rates, complaint volumes, and engagement metrics—to assess whether your messages should be trusted. If your domain is seen as a source of spam due to poor list hygiene, DMARC filtering kicks in aggressively, resulting in 5.7.13 errors.

Imagine you send the same campaign to 100,000 addresses, but 20% are invalid or inactive. This high bounce rate signals to providers you're not managing your list responsibly. That spike in bounces, even if isolated, can set off reputation alerts. ISPs treat sudden volume changes—especially after long inactivity—as red flags, signaling potential abuse or compromised systems.

Regular list hygiene prevents reputation decay

Consistent list maintenance is how you stay under the radar of overzealous DMARC policies. Tools like Email List Validation help you identify invalid, disposable, and role-based addresses before you send. By removing these weak points early, you reduce bounce rates, lower complaint potential, and sustain engagement.

Let’s say you send weekly newsletters. Without verification, your list grows stale. Over time, old addresses become dead ends. When you send to them, bounces increase. Each bounce adds weight to your domain’s risk profile. But with a tool like Email List Validation, you can clean your list in bulk and verify new signups in real time—keeping your send rate clean and predictable.

Reputation isn’t just about what you send—it’s about how well you manage your audience. The moment you start sending to invalid addresses, you erode trust. The moment you clean your list, you begin rebuilding it. DMARC catches the gap between intent and execution. Your job isn’t to outsmart it—just to ensure your practices align with best standards.

Does your email service provider affect DMARC compliance?

Yes — your email service provider (ESP) can break DMARC alignment if it sends mail from a different domain than the one in your From header. If SendGrid, Mailchimp, or HubSpot sends using their own domain while your message says it's from your company’s domain, DMARC will fail. This causes bounces like 5.7.13 and hurts inbox placement. Make sure your ESP supports From address alignment and proper authentication setup.

How ESPs break DMARC alignment

Most ESPs use their own sending domains by default. If you set your From address to [email protected], but the email is sent from sendgrid.net or mailchimp.com, the domain in the MAIL FROM (envelope) and the From header don’t match. DMARC enforcement checks this alignment — if it fails, the message gets rejected.

Let’s say your company uses Mailchimp for newsletters. If Mailchimp sends from mailchimp.com but the From header says your brand’s domain, you’ll lose DMARC alignment. It’s a common mistake, especially during onboarding. The sender’s domain must align with the From domain or the SPF/DKIM domains, or DMARC will block the email.

What to verify before sending

Before sending bulk campaigns or transactional emails, confirm your ESP supports From address alignment. Not all providers do — some only allow alignment with their own domains. Check their documentation or support site for policies around From domain mapping.

Some ESPs like SendGrid and Amazon SES offer "domain authentication" features that let you send from your domain while maintaining proper SPF, DKIM, and DMARC alignment. Use them. If you’re unsure, verify the setup with a tool like dmarcian.com’s DMARC validator or MXToolbox’s DMARC report analyzer. You can test how your messages are aligned even before sending.

To prevent alignment failures from hurting deliverability, use tools that check email validation and sender reputation. Bulk email list cleaning helps you catch invalid or risky addresses early — reducing the chance of rejection due to poor sender practices.

DMARC isn't just about receiving mail — it's about being trusted as a sender. Even a single misconfiguration breaks alignment and triggers rejection codes like 5.7.13. Always verify your ESP’s capabilities and your list quality before sending.

Can you fix DMARC issues after the fact?

Yes, you can fix DMARC issues after the fact—by updating your SPF records to include all sending sources, ensuring your DKIM signing domain aligns with your SPF and From domain, or temporarily setting your DMARC policy to p=none during testing. However, fixes take time to propagate and may not stop damage already done. Prevention is always faster and cheaper than recovery.

How to diagnose and correct DMARC enforcement errors

When you see error code 5.7.13, the receiving server is rejecting your message because DMARC validation failed. This commonly happens when SPF and DKIM don't align with the From domain or when a strict DMARC policy p=reject is in place.

Start by checking your SPF record. If you use multiple sending platforms (like SendGrid, Mailchimp, or a transactional email service), make sure all sending IPs and domains are included. The SPF limit is 10 DNS lookups, so avoid overburdening the record.

Next, verify DKIM alignment. DKIM signatures must be signed with a selector that matches the domain in the From header. If your DKIM domain doesn’t match the From domain, alignment fails—even if the signature is valid.

Use tools like MXToolbox's DMARC Analyzer or RFC 7483 to test your DMARC setup and monitor alignment. These tools show exactly where validation fails, so you can correct the issue before sending to sensitive domains.

Testing and validating fixes before sending

Don’t rely on trial-and-error. Use inbox-placement testing tools to simulate sends to domains with strict DMARC policies. This shows whether your fixes actually pass through the receiving server’s filters.

For example, inbox-placement testing lets you send real messages to major inboxes (Gmail, Outlook, Apple) to see if they land in the inbox or get blocked—without risking your sender reputation.

Even small misalignments can trigger enforcement. A single unaligned DKIM domain or SPF record with a typo can cause rejection, especially with p=reject. Always test before large campaigns.

The smart move? Avoid the error entirely. Clean your email list before sending using a service that flags domains with strict DMARC policies, disposable domains, or poor deliverability signals. A list cleaned before sending reduces bounces, stops you from triggering hard bounces, and prevents wasted sends to domains that will reject your mail regardless of your setup.

Real-world example: When a 5.7.13 rejection happens unexpectedly

One of your campaigns gets rejected with a 5.7.13 DMARC error not because of spam, but because your sending domain didn’t match the SPF record for a subdomain in your From header. A single misaligned subdomain across 10,000 recipients caused high bounce rates and poor inbox placement—without any warning until the results came in. This happens when DMARC policies are strict and authentication fails silently.

The problem starts before the email is sent

Use a domain-level DMARC policy (p=reject) — This is standard for major providers like Google and Microsoft. When set, any email failing SPF or DKIM authentication is rejected outright. If your domain uses p=reject and your email fails one of those checks, the server will block delivery.
Check your From header and SPF alignment — If your From header says [email protected] but your SPF record only includes mail.company.com, the alignment fails. Even one mismatched subdomain can trigger a 5.7.13 rejection.
Test your SPF record with a valid tool — Use MXToolbox to verify that all sending IPs and subdomains are included in your SPF record. Misconfigurations are more common than you think.
Verify all email addresses before sending — Many lists include outdated or poorly formatted addresses. A tool like our bulk email list cleaning checks for malformed syntax, inactive domains, and authentication alignment issues before you send.
Monitor real-time delivery reports — After sending, track bounce reasons. If you see 5.7.13 errors, they point to DMARC or SPF failures—never to content or reputation. This is not spam; it’s validation failure.
Fix the root cause before resending — If a subdomain fails SPF, either update the SPF record or change the From address to align with it. You can’t fix every domain-level issue post-sending—prevention is the only way.

Why this slipped through

You didn't know because you never checked domain-level authentication across your list. Many tools only validate syntax or existence—and miss the alignment gap between the From header and SPF. That’s why we recommend checking for DMARC alignment requirements in your sending setup.

The real damage was invisible until delivery metrics dropped. Bounce rates spiked. Inbox placement plummeted. The root cause? A single domain with a strict DMARC policy and a mismatched subdomain. This isn’t a spam filter issue—it’s a configuration one.

Use email verification to stop 5.7.13 errors before they happen

DMARC-rejected emails often stem from sending to domains with strict enforcement policies. These domains reject messages outright when alignment fails, even if the address is valid.

Email List Validation scans your list in bulk or via API, flagging domains with high DMARC enforcement—before you send. Its 98.9% accuracy identifies not just invalid addresses, but risky ones often overlooked by basic tools.

You can verify your audience without risk. Start with 100 free verifications. Credits never expire, so you can test, refine, and deploy with confidence.

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 SMTP error 5.7.13 mean?

It means the receiving server rejected the email due to a DMARC policy violation, typically because the sender’s domain failed alignment checks.

Can I fix 5.7.13 by changing my email content?

No. The error is technical, not content-based. It’s tied to authentication and domain alignment, not message text or attachments.

Does DMARC only affect large brands?

No. Any domain with a DMARC record, including small businesses and personal domains, can trigger 5.7.13 if authentication fails.

How do I know if my domain is DMARC-protected?

Check your DNS TXT records for a DMARC entry starting with 'v=DMARC1;'. Tools like MxToolbox can verify this.

Why did my email get rejected even though SPF and DKIM passed?

DMARC requires alignment between the From domain and the domains used in SPF and DKIM. Mismatched domains trigger 5.7.13.

Can email verification tools detect DMARC issues?

Yes—tools like Email List Validation include domain-level checks that surface misaligned or highly restrictive DMARC policies.

Do all email providers use DMARC?

Most major providers, including Gmail, Yahoo, and Outlook, enforce DMARC policies and use codes like 5.7.13 to block non-compliant emails.

What’s the fastest way to avoid 5.7.13 bounces?

Use bulk list verification to identify and remove domains with strict DMARC enforcement before sending.

How often should I test my domain’s DMARC setup?

At least quarterly, or after major changes to email infrastructure, to ensure alignment and policy enforcement remain correct.

Does using a shared sending domain cause DMARC issues?

Yes—sending from a shared domain without proper From header alignment can trigger 5.7.13, especially if the domain enforces 'p=reject'.