What causes the 5.7.13 SMTP rejection and why it matters

You sent an email. It didn’t bounce. It didn’t fail. But it never showed up in the inbox. Instead, it vanished—replaced by a silent 5.7.13 rejection. This isn’t a glitch. It’s a delivery policy enforcement, and it’s triggered by a conflict in your email’s SPF and DMARC alignment.

This rejection doesn’t mean your message failed to reach the server. It means the server received it, validated it, and then rejected it because your authentication setup doesn’t align with the domain’s policy. Providers like Microsoft 365 and Gmail enforce this rule aggressively—they’re designed to stop spoofing, but they can trip up legitimate senders who haven’t checked alignment carefully.

Even a single undelivered message can weaken your sender reputation. Repeated 5.7.13 rejections mean lower inbox placement, higher spam complaints, and long-term deliverability damage. Preventing 5.7.13 rejection due to SPF and DMARC alignment conflict isn’t just technical—it’s critical for trust, visibility, and volume.

Key takeaways

  • 5.7.13 rejection occurs when SPF and DMARC alignment policies conflict, not due to invalid addresses or connectivity issues.
  • Even if messages reach the server, misaligned SPF/DMARC can lead to silent rejection, harming sender reputation and inbox placement.
  • Preventing 5.7.13 errors requires verifying both SPF and DMARC alignment in your email setup before sending bulk campaigns or transactional messages.

How SPF and DMARC alignment conflict creates 5.7.13 rejections

When your email passes SPF validation but the domain in the From address doesn’t align with the domain used in the SMTP envelope (like sending from @company.com but the sending domain is @mail.company.com), DMARC fails. This misalignment triggers a 5.7.13 rejection, even if SPF says the server is authorized. You’re authorized to send from one domain, but the user sees a different one — and that breaks DMARC’s alignment rules.

SPF: Who’s allowed to send

SPF checks whether the IP address sending the email is listed in the domain’s published SPF record. If it matches, the envelope sender (RETURN-PATH) passes. But SPF only validates the sending domain, not the visible From address your audience sees.

DMARC: Who’s it really from

DMARC combines SPF and DKIM results to decide whether an email is trustworthy. It requires strict alignment between the From address (what the user sees) and the domain used in the SMTP envelope (what SPF checks). If they don’t match — even if SPF passes — DMARC fails. This is a common issue when using third-party services with subdomains like mail.company.com, but sending from company.com.

For example: your email server is authenticated via SPF using mail.company.com, but you send from [email protected]. The From domain and the envelope domain don’t align. DMARC sees this mismatch and blocks the message, resulting in a 5.7.13 bounce. This isn’t about technical error — it’s about policy enforcement. According to the DMARC specification (RFC 7483), alignment must be strict or relaxed, but it cannot be ignored.

Even if your sender reputation is solid and your IP isn’t on a blocklist, DMARC can still reject your message if alignment fails. This happens more often than you think — especially with marketing platforms or email templates that hardcode the From address without considering envelope alignment.

Let’s say you’re using a tool to send transactional emails. The platform sets the envelope from to your sender domain, but the actual From address reflects a different domain in your campaign. Without alignment, even a clean SPF check means nothing. That’s why DMARC fails — and 5.7.13 rolls in.

Preventing this starts with alignment. Confirm your SPF, DKIM, and From address domains match. Use tools that validate alignment in real time, before you send. Clean your list with validation tools that can flag misaligned domains early, so you know before delivery.

Why your valid-looking email list can still trigger 5.7.13 issues

Even if your email list passes basic syntax and existence checks, it can still trigger a 5.7.13 rejection if the sending domain doesn’t align with the recipient’s SPF and DMARC policies. Many list hygiene tools stop at "is this email address real?"—they don’t check whether the sending domain matches the authentication policies set by the recipient’s mail server. This mismatch is what causes rejection, even with a clean, valid list.

Most tools don’t check domain alignment

Let’s say your list includes [email protected]. That email exists, passes syntax checks, and seems perfect. But when you send from [email protected], the domain used for sending isn’t the same as the one listed in the email’s From header. SPF and DMARC validation require alignment: the sender domain must match the From domain, or the organization domain in the email headers. If it doesn’t, even a 100% valid list will fail authentication during delivery.

Mail servers that enforce DMARC policies, like Gmail and Outlook, use the 5.7.13 error code to reject messages where alignment fails. This is a real-world gatekeeper—your email might reach the server, but it’s blocked before even being considered for delivery. The problem isn’t the address; it’s the mismatch in the authentication layer.

Alignment issues come from misconfigured campaigns

It’s common for marketers to use a common sending domain (like [email protected]) while listing individual recipients with different From headers. This setup often passes basic list checks but fails SPF/DKIM alignment when the receiving mail server verifies policy. The result? Repeated 5.7.13 rejections even after cleaning. It’s not just one bounce—it’s consistent rejection across multiple recipients, which damages sender reputation over time.

Even if your list has a 99% deliverability rate and no invalid addresses, a single misaligned sending domain can tank your overall inbox placement. This isn’t a syntax issue—it’s a policy issue. You need to verify not just the address, but how it’s being sent. As outlined in RFC 7660, alignment requirements are part of the DMARC specification. Tools that ignore this oversight are missing critical verification layers.

To catch these issues early, test your list using an inbox placement service that evaluates real-world routing, not just syntax. You can verify both address validity and alignment at scale with inbox placement testing—which also catches issues like greylisting, rate limiting, and server-side filtering that static tools miss.

How to test for SPF and DMARC alignment before sending

Run inbox-placement tests across real inboxes using tools that simulate delivery conditions. Check whether 5.7.13 rejections occur when sending from each sender domain, and validate SPF and DKIM alignment before sending. Combine real-time verification to catch misconfigurations early.

Test delivery conditions before sending

Before you send, test how your messages behave in live inboxes. Tools that emulate real-world delivery—like those used by email providers themselves—can surface alignment issues you’d otherwise miss.

Let’s say you’re sending from multiple domains. Each one must pass alignment checks independently. Even if SPF allows your server, DMARC can still reject the message if the From domain doesn’t align with either SPF or DKIM. Inbox placement tests catch this in advance.

Verify configuration and alignment simultaneously

Don’t rely on DNS records alone. Test whether your sending domain’s SPF and DKIM records are not only present but correctly aligned.

Use real-time verification to confirm that the From domain, SPF domain, and DKIM signature all match as expected. If they don’t, DMARC will flag it as a failure—often triggering a 5.7.13 rejection.

  1. Run inbox placement tests on all sender domains. Use a service that sends to hundreds of real inboxes (not just test accounts). Look for 5.7.13 rejections during the deliverability check phase. This mimics what happens when you send to Gmail, Outlook, or Yahoo.
  2. Check alignment during each test. Observe whether SPF and DKIM results align with the From domain. A mismatch—even if technically valid—can cause rejection. The RFC 7672 standard defines alignment requirements explicitly; tools that follow it can detect mismatches early.
  3. Validate records using a real-time verification API. Integrate the real-time verification API to scan each sending domain’s DNS setup. It checks SPF, DKIM, and DMARC values in real time, flagging misconfigurations like overly broad SPF includes or missing DKIM signatures.
  4. Test the full flow end-to-end. After fixing any detected misalignments, run another inbox placement test. Confirm that 5.7.13 rejections no longer appear. Only then should you proceed with full sends.

Remember: alignment isn’t just about compliance—it’s about proving a sender control. When SPF, DKIM, and the From domain point to the same entity, email providers trust the message. Without it, even well-delivered emails can be blocked.

For teams managing large or multi-domain lists, bulk verification tools help test all domains at once. Bulk email list cleaning catches alignment issues across your entire sending infrastructure—before they hurt deliverability.

The three layers of sender authentication and what each does

SPF, DKIM, and DMARC are the three technical layers that verify your emails are legitimate, prevent spoofing, and ensure your messages reach inboxes. SPF checks which servers are authorized to send for your domain. DKIM adds a digital signature to confirm the message wasn’t altered. DMARC uses both SPF and DKIM results to enforce policies and report alignment issues—key to avoiding rejections like 5.7.13 due to misaligned authentication.

SPF: Your domain’s authorized IP list

SPF defines which IP addresses are allowed to send emails on behalf of your domain. Without it, receiving servers can’t verify if an email actually came from your infrastructure. But SPF has limitations—it doesn’t cover forwarders or third-party email services unless explicitly listed, and strict enforcement can break legitimate delivery if not managed carefully.

For example, if you use multiple ESPs (like Mailchimp, HubSpot, and SendGrid), you need to include all their IPs in your SPF record. If you don’t, emails may fail SPF checks and be rejected. You can manage this more cleanly with SPF alignment policies or use a tool like bulk email list cleaning to ensure your sending infrastructure matches your published records.

DKIM: The cryptographic origin check

DKIM adds a digital signature to each email, proving it was sent from your domain and hasn’t been tampered with. Receiving servers validate this signature using your public key via DNS. It’s independent of IP addresses, so it works across different sending environments—even when emails are forwarded or routed through third parties.

However, DKIM alone doesn’t confirm the sender’s identity. A message can pass DKIM but still be sent from an unauthorized source if SPF is bypassed. That’s why DKIM works best alongside SPF and DMARC.

DMARC: The policy enforcer

DMARC puts the final decision into play. It tells receiving servers what to do if SPF or DKIM fails—either quarantine, reject, or allow. It also requires alignment: the "from" domain in the email must match the domains used in SPF and DKIM. Misalignment causes rejections like 5.7.13, especially when sending from a subdomain or using third-party platforms with weak alignment.

DMARC is the linchpin. It combines SPF and DKIM results, verifies alignment, and reports back to you. Setting it up properly reduces deliverability risk. You can test your current setup with real-world inbox placement tools—visit inbox placement testing to check how your emails appear in major inboxes like Gmail and Outlook.

For deeper insight, the IETF’s RFC 7483 and RFC 7050 explain how DMARC policies are evaluated across the email ecosystem. These standards are the foundation of modern sender authentication.

How email verification reveals alignment risks before they trigger 5.7.13

Preventing a 5.7.13 rejection starts before sending: Email List Validation checks not only if an address exists but also whether the domain’s SPF and DMARC policies align properly. It identifies mismatches—like SPF allowing a sender domain that DMARC doesn’t authorize—before they trigger delivery blocks. This catches alignment conflicts early, so you don’t get rejected after you’ve already sent.

Authentication checks are part of the verification process

Most basic verifiers only confirm whether an email address is valid. But Email List Validation goes further. It queries the domain’s DNS records to validate the presence and consistency of SPF and DMARC policies. A mismatch here—say, SPF permits a third-party sender while DMARC requires alignment with the "From" domain—can trigger a 5.7.13 error even if the address itself is deliverable.

During bulk verification, it flags domains with misaligned authentication, shared IPs, or catch-all configurations. These are common red flags that mail servers reject during the final validation step. Without this pre-check, you're sending blind: you might think you're safe, but your message fails at the receiving end.

For example, if your campaign uses a sender domain like [email protected] but your SPF record allows mailing.example.com to send on your behalf without proper alignment, DMARC will fail. This is a classic 5.7.13 trigger. Our system surfaces this issue during verification, so you can fix it before sending.

Risky verdicts surface hidden problems

When we return a "risky" verdict, it’s not a guess. It means we detected an inconsistency—like SPF validating but DMARC failing alignment, or one policy permitting a sender the other doesn’t. These domains are high-risk for rejection, even if the address is otherwise valid.

According to RFC 7672, alignment checks ensure the "From" domain matches either the SPF or DKIM author. Violating this increases the chance of rejection. You’re not protected by valid email addresses alone—authentication must be consistent across all layers.

Let’s say your list includes [email protected], but acme.com’s SPF allows mail.acmeservices.com to send on behalf of it, while DMARC requires alignment with the actual sending domain. Even if the address is real, that’s a conflict. We flag that. You fix it. You don’t get blocked.

See how this works at scale: clean your list in bulk, with checks embedded across DNS, SPF, and DMARC. You’re not just validating addresses—you’re validating the entire delivery chain. This reduces the number of 5.7.13 rejections, lowers bounce rates, and maintains sender reputation over time.

Best practices to avoid SPF and DMARC misalignment in campaigns

You prevent 5.7.13 rejections by ensuring your email’s From address domain aligns with both your SPF and DMARC policies. Only send from the domain that controls your SPF record, or use subdomains explicitly included in SPF and aligned in your DMARC policy. Avoid third-party sending domains (like @sendgrid.net) unless they’re verified and aligned with your brand. Misalignment is a common cause of rejection — fix it at the source.

Core alignment rules for email sending

  • Always send from the same domain that owns the SPF record. If your SPF is set on yourcompany.com, do not use [email protected] as the From address without proper alignment.
  • If you use a subdomain for campaigns (e.g., campaigns.yourcompany.com), make sure it’s listed in the SPF record and configured to pass DMARC checks under the same policy domain.
  • Never rely on third-party domains like @sendgrid.net or @mailchimp.com as the From address unless the domain is explicitly authorized in your SPF record and the DMARC policy allows it. Even with proper SPF, DMARC enforcement can still block your email if the From domain doesn’t match.
  • Use a consistent From address across campaigns and avoid mixing domains or using aliases that don’t reflect your brand's sending domain.
  • Monitor your DMARC reports regularly. They show you which domains are failing alignment, including those that pass SPF but fail DMARC due to From address mismatch.

Testing and validation

Even if everything looks correct in theory, real-world delivery can still fail. Let’s walk through the verification step.

  • Use a real-time email verification API to test domain alignment and detect risky From addresses before sending. It checks SPF, DMARC, and other deliverability flags — helping catch issues early. See how it works at real-time verification API.
  • Run inbox placement tests with real emails sent from your configured domain to see if filters drop messages due to alignment issues.
  • Check your SPF record length. Each mechanism (include, a, mx, ip4, ip6) counts toward the 10 DNS lookup limit. Exceeding it breaks SPF.
  • Use DMARC reports (via DMARC.org or your email provider) to see if your campaigns are aligning correctly in practice.
  • When sending in bulk, clean your list first. Invalid or misaligned domains increase bounce rates and hurt sender reputation. Bulk email list cleaning helps you remove problematic addresses before they trigger rejections.
Alignment isn’t just about policy — it’s about trust. Even a single From address that doesn’t match your SPF and DMARC domains can trigger filtering at the receiving end.

Real-world example: how a 5.7.13 rejection was stopped before it caused sender reputation damage

You can stop a 5.7.13 rejection before it damages your sender reputation by catching alignment issues in your email list early. A company using an SPF-aligned domain but without DMARC alignment saw 5.7.13 rejections in 80% of Microsoft 365 inboxes. After verifying their list with Email List Validation, 27% of previously labeled “valid” addresses were flagged as risky due to authentication misalignment. Fixing the domain configuration and cleaning the list reduced rejections to zero within seven days.

The problem: 5.7.13 rejections from Microsoft 365

Microsoft 365 uses strict authentication checks. A 5.7.13 rejection means the receiving server rejected your message due to a failure in SPF or DKIM alignment with DMARC policies. Even if SPF passes, a missing or permissive DMARC policy can trigger rejection for non-aligned senders.

This company’s SPF records allowed multiple IP ranges but set DMARC to either p=none or p=quarantine with no alignment enforcement. The result? Microsoft’s filters flagged messages as suspicious—even when SPF passed—because the domain’s DMARC policy didn't require alignment between the From header and the authenticated sender. This led to widespread delivery failures.

Cleaning the list: how validation caught the real issue

They ran their email list through Email List Validation’s bulk verification tool, which checks both syntax and authentication alignment. Out of 10,000 “valid” addresses, 2,700 were flagged as “risky”—not because they were invalid, but because their domain’s DMARC alignment failed when validating sender authentication.

For example, one domain allowed SPF through a third-party email service but had no DMARC enforcement. The sender’s address (e.g., [email protected]) didn’t match the authenticated domain in the email header. This violates DMARC’s alignment rule, even if SPF validates.

Email List Validation detects this inconsistency automatically. The result? A real-time report showing which domains in a list fail alignment, enabling pre-send cleanup without waiting for bounces or hard failures.

The fix: aligning authentication, reducing rejections

After identifying the 2,700 risky addresses, the team either updated the sending domain or removed those recipients from the list. They then enforced a DMARC policy with alignment (p=quarantine or p=reject) and ensured all sending IPs were correctly listed in SPF.

Within a week, Microsoft 365 delivery rates returned to normal. No more 5.7.13 rejections. The key was catching the issue before it triggered sender reputation penalties—a problem common in brands using multiple email services or poorly configured domains.

Authentication alignment isn’t optional. It’s required for reliable inbox placement. Check your list’s alignment with a tool built for this purpose: verify your list at scale and prevent 5.7.13 rejections before they happen. For context on domain policies, refer to the DMARC specification.

How Email List Validation blocks 5.7.13 at the source

You prevent 5.7.13 rejections by catching SPF and DMARC alignment conflicts before sending. Our bulk verification checks domain configurations in real time, flagging misconfigurations that cause policy rejections—before a single email is delivered. This stops bounces and blocks before they happen, not after.

Domain-level checks happen before delivery

Most tools only check if an email exists when sending. Email List Validation goes further: it validates domain records like SPF and DMARC during bulk verification. If a domain’s SPF policy doesn’t align with the sender’s domain in a DMARC policy, we flag it as a risk. This is critical—because 5.7.13 isn't a typo; it’s a policy rejection triggered by alignment failure.

These checks run on the same infrastructure that verifies millions of addresses monthly. You’re not relying on guesswork or post-delivery feedback. Instead, every address is evaluated against current DNS records, including alignment rules defined in DMARC policies. This includes checking if the "mail from" and "sender" domains are properly aligned per RFC 7001.

Accuracy and integrations reduce the risk at scale

Our 98.9% accuracy rating includes detection of these alignment conflicts. While no system can guarantee 100% due to dynamic DNS changes, we catch the vast majority of configuration issues that lead to policy rejections. The difference? You’re not waiting for a bounce or block to learn it was avoidable.

With integrations for Mailchimp, SendGrid, and HubSpot, you can validate lists just before sending—automatically. The pipeline doesn’t send unless the recipient’s domain passes the check. This means no surprise 5.7.13 rejections during campaigns. If a domain has a known misalignment, it gets flagged upfront.

Learn how real-time verification works across your stack: verify emails before they enter your campaign. Or explore how to clean entire lists in advance: clean your list with precision. These tools turn deliverability into a proactive step, not a reactive fix. For context on how alignment affects delivery, see the IETF’s guidance on DMARC at RFC 7001.

What to do when you receive a 5.7.13 rejection from a provider

If your email is rejected with a 5.7.13 error, it’s likely due to a mismatch between SPF and DMARC alignment. This means the sending domain in your email doesn’t match what SPF and DMARC policies require. The fix starts with checking your DNS records, validating alignment, and testing delivery under real inbox conditions before sending to your audience.

Step-by-step resolution process

  1. Inspect the full delivery trace to confirm the 5.7.13 error and identify the source domain. This trace reveals whether the issue is on your side (misconfigured SPF or DMARC) or if the receiving provider’s policy is blocking the email based on alignment rules. Use tools like RFC 7073 to understand how alignment is defined by the receiving system.
  2. Verify your DMARC policy is correctly published for the sending domain. A DMARC policy set to reject or quarantine will cause delivery failure if SPF or DKIM alignment fails. Check it using DNS lookup tools such as MxToolbox or Spamhaus. If no policy is published, set one up to prevent future issues, even if temporary.
  3. Test SPF and DMARC alignment using a domain diagnostics tool. Run checks via MxToolbox (https://mxtoolbox.com) or Spamhaus (https://spamhaus.org) to confirm that your SPF record authorizes the sending server and aligns with the From domain. If your email comes from a third-party service (like SendGrid or Mailchimp), ensure the service’s SPF record includes your domain’s authorization or uses a strict SPF mechanism.
  4. Reproduce the issue with real inbox testing. Use Email List Validation’s inbox placement service to simulate delivery to major providers—Gmail, Outlook, Yahoo—and see if 5.7.13 appears under real conditions. This reveals alignment conflicts before your full campaign sends. It tests both technical setup and provider reputation.
  5. Fix and verify. Adjust your SPF record to include authorized senders or switch to a more modern approach like SPF 2.0 (where supported). Ensure your From domain matches the envelope sender (MAIL FROM) and the DKIM signature’s domain. After changes, retest in the inbox placement service to confirm the rejection is resolved.

Prevention is part of the fix

Once you’ve resolved the issue, don’t stop there. Prevent recurrence by including email validation in your workflow. Use the inbox placement testing feature before every major campaign to catch alignment or deliverability issues early—before they impact sender reputation.

Conclusion: prevention beats correction for 5.7.13 rejections

5.7.13 rejections due to SPF and DMARC alignment conflicts are not inevitable. They’re preventable by validating domain authentication alignment before any email is sent.

Email List Validation catches these risks early—both in bulk and via real-time API—so you don’t send to domains with broken or misaligned records. This avoids wasted sends, protects sender reputation, and maintains consistent inbox placement.

Clean lists, properly aligned domains, and verified authentication records are not optional. They’re the baseline for reliable email delivery.

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?

The 5.7.13 error means the receiving server rejected your email due to a failure in SPF or DMARC alignment, typically from Microsoft 365 or Gmail.

Can a valid email address still cause a 5.7.13 rejection?

Yes — even if an address exists, misaligned authentication policies (SPF/DKIM/DMARC) can trigger 5.7.13, especially when sending from a different domain.

How can I test if my domain is aligned for SPF and DMARC?

Use DNS record tools like MxToolbox or test delivery via inbox-placement services like Email List Validation’s deliverability testing.

Does Email List Validation check SPF and DMARC records?

Yes — it checks domain-level authentication during verification and flags domains with misaligned or inconsistent policies.

Why should I verify email lists before sending?

To reduce bounces, avoid spam traps, detect disposable and role accounts, and catch authentication mismatches that cause 5.7.13 rejections.

Can I fix 5.7.13 after it happens?

Fixing after the fact is slow and reactive. Prevention through list validation and domain alignment is faster and more reliable.

How does sender domain alignment affect deliverability?

Misalignment triggers policy rejections like 5.7.13, even if the email technically reaches the server, which lowers inbox placement and damages sender reputation.

What’s the difference between SPF and DMARC alignment?

SPF checks if the sending IP is authorized; DMARC checks if the From address domain aligns with the sender's domain in SPF or DKIM.

Does SPF conflict with DMARC always cause 5.7.13?

Not always — but when DMARC policy is set to 'reject' or 'quarantine', and alignment fails, the receiving server acts on that policy, often returning 5.7.13.

How do integrations with Mailchimp and SendGrid help prevent 5.7.13?

They allow pre-sending list validation, so domains with alignment issues are caught before sending, minimizing delivery failures.