Debugging SPF, DKIM, DMARC Failures | Email List Validation

Why Do SPF, DKIM, and DMARC Failures Still Break Deliverability in 2026?

You sent the message. It passed the first checks. But then, out of nowhere, Microsoft’s SMTP server replies with 5.7.13. No explanation. Just a bounce. You’re left wondering: “Why did my perfectly good email get blocked?”

The answer lies not in reputation, not in spam traps, but in a misalignment between your sender identity and your email authentication results. It’s a DNS-level mismatch that stubbornly persists — even in systems with mature email infrastructure.

SPF, DKIM, and DMARC weren't designed to be perfect. They’re only as strong as their configuration, and alignment failures in 5.7.13 are the clearest signal that something’s broken in the chain. Fixing them requires diagnosing the exact mismatch — not guessing, not tweaking blindly.

Key takeaways

SMTP error 5.7.13 is triggered by alignment failure between sender identity (From header) and authentication results from SPF or DKIM.
Even with valid SPF and DKIM records, a mismatch in domain alignment (e.g., sending from [email protected] but using a different domain in SPF) will trigger 5.7.13.
DMARC policy enforcement only applies if SPF and DKIM pass *and* align with the From domain — misalignment here means rejection regardless of reputation.

What Does SMTP Error 5.7.13 Actually Mean?

SMTP error 5.7.13 means your email was rejected by Microsoft’s mail servers—Outlook, Hotmail, or Exchange—because the message failed DMARC policy evaluation. This typically happens when the domains in your email’s From header don’t align with the domains used to authenticate the message via SPF or DKIM. Even if SPF and DKIM individually pass, mismatched domains trigger a rejection. It’s not about technical failure; it’s about alignment.

Alignment: The Hidden Trigger Behind 5.7.13

Let’s be clear: SPF and DKIM must pass independently, but they also need to align with the From domain. That means the domain in the From header—the one your recipients see—must match the domain used in the SPF record and the DKIM signature. If it doesn’t, Microsoft’s receivers flag it as suspicious, even if the authentication tech works.

For example, if your From domain is yourcompany.com but your SPF checks against mail.yourcompany.com or your DKIM signs with sendgrid.net, alignment fails. The DMARC policy doesn’t care how well authenticated you are—only whether the domains line up.

Why Microsoft Enforces This So Strictly

Microsoft’s mail systems use DMARC policy enforcement heavily to protect users from spoofing and phishing. According to RFC 7483—the standard for DMARC—domain alignment is required for strict policy enforcement. Microsoft’s implementations follow this closely, especially for high-value domains.

Even if your email technically passes SPF and DKIM, Microsoft’s filters will still apply 5.7.13 if alignment fails. This is why you might see the error even when your sending infrastructure seems solid. It's not the authentication that's broken—it's the mismatch.

Think of it like a door with three locks: one key for SPF, one for DKIM, and one for alignment. You can’t enter with just two keys—alignment is the third and mandatory one.

For teams running bulk campaigns or using third-party email services, this is especially common. Sending from yourcompany.com while using a service like SendGrid or Mailchimp requires careful setup of SPF and DKIM with the correct organizational domain. Misalignment in these setups is a leading cause of 5.7.13.

If you're debugging this, check your email headers and use MXToolbox or DMARC Analyzer to trace the authentication results. You’ll see if the From domain fails alignment even when the other checks pass.

Prevention starts with clear, intentional configuration. Ensure all authentication records refer to the same domain—typically your own, not a subdomain of a third-party provider—unless you're using a certified alignment setup.

How SPF, DKIM, and DMARC Work Together at the Protocol Level

SPF, DKIM, and DMARC are email authentication protocols that work together to verify sender identity. SPF checks if the sending server’s IP is authorized, DKIM cryptographically signs the message body, and DMARC enforces policies based on SPF and DKIM results—only if the 'From' domain aligns with both. This alignment prevents spoofing even when SPF or DKIM passes independently.

SPF: Validating the Sending Server

SPF uses a TXT record in DNS to list authorized sending IPs or servers. When your email arrives, the receiver checks the sender’s IP against that list. If the IP isn’t on the approved list, SPF fails—common when using third-party ESPs without proper setup.

For example, if you send from a marketing platform like Klaviyo or Mailchimp, you must include their IPs in your SPF record, or delivery breaks. Always validate SPF records using tools like MXToolbox or RFC 7208, which define the standard.

DKIM: Signing the Message Body

DKIM signs the email’s body and headers with a private key, embedding a digital signature in the message. The receiving server uses the corresponding public key—published in DNS under a selector (like d=example.com and s=brisbane)—to verify the signature.

If the signature doesn’t match, DKIM fails. This can happen if you modify any part of the email after signing (e.g., rewrites by forwarders or mailing list software), or if the DNS record is misconfigured. A mismatch usually means the message is altered or forged.

DMARC: The Enforcement Layer

DMARC sits on top of SPF and DKIM. It checks whether both tests pass AND whether the domains align. Alignment means the 'From' domain matches the domain used in SPF (e.g., spf=example.com) and DKIM (e.g., d=example.com).

For instance, if your 'From' domain is [email protected] but SPF checks example.com and DKIM uses d=mail.example.com, DMARC fails even if SPF and DKIM individually pass.

DMARC policies tell the receiver what to do with failing messages—quarantine, reject, or monitor. Without alignment, DMARC enforcement won’t apply, leaving you vulnerable to spoofing attacks.

Use real-time tools like the real-time verification API to catch alignment risks early. It checks domains and headers during send attempts, catching misconfigurations before they hit your inbox.

Real-World Example of a 5.7.13 Failure

You send emails from [email protected]. SPF and DKIM pass, but DMARC fails due to alignment issues when your DKIM domain uses a subdomain inconsistently, triggering a 5.7.13 error. The sender domain (yourcompany.com) doesn’t align with the DKIM domain in the signature, breaking DMARC’s policy enforcement.

The Root Cause: Domain Alignment Breaks DMARC

DMARC requires that either SPF or DKIM (or both) align with the "From" domain. Here, the From header is [email protected] — that’s the domain being validated. SPF passes because your sending domain is yourcompany.com. DKIM passes, but only if the selector and domain match. The key issue? The DKIM signature was signed for mail.yourcompany.com, not yourcompany.com.

Step-by-Step Debugging Process

Verify the From header domain — Confirm the message’s “From” domain is yourcompany.com. This is what DMARC checks for alignment. No deviation here.
Check SPF alignment — Use MxToolbox to validate SPF policy and sender domain. If SPF includes yourcompany.com and the sending IP is authorized, SPF passes. Note: SPF alignment fails if the sender domain in the envelope (MAIL FROM) differs from the From domain. But here, it passes.
Inspect DKIM signature — Retrieve the DKIM signature from your email headers. Confirm the domain used in the DKIM-Signature header (e.g., d=mail.yourcompany.com) does not match the From domain (yourcompany.com).
Confirm DKIM alignment — DMARC alignment requires the DKIM domain to be the same as, or a subdomain of, the From domain. If the From domain is yourcompany.com and the DKIM domain is mail.yourcompany.com, alignment is *usually* acceptable. But only if all email paths consistently use the same root or subdomain structure. Inconsistency breaks alignment.
Check DMARC record policy — Use dmarc.org’s diagnostic tools to validate your DMARC policy. If your policy is set to reject, any misalignment — even small — will result in a 5.7.13 rejection.
Fix the misalignment — Either update your DKIM selector to sign for yourcompany.com, or ensure all mail is sent with consistent subdomain use (e.g., always mail.yourcompany.com). Mismatched signing domains will consistently fail alignment, causing rejection by receiving systems.

If your DKIM domain doesn’t align with your From domain, you may still pass SPF, but DMARC fails — and that's a direct path to a 5.7.13 error. The fix isn’t about changing headers. It’s about ensuring your signing practices align with the domain structure the email system expects.

Before you scale campaigns, verify your sender authentication setup with real email streams. Test inbox placement using a tool like inbox-placement testing to catch alignment failures before they hit your deliverability.

Common Alignment Failure Scenarios in 2026

You're likely hitting SPF, DKIM, or DMARC alignment issues if your sender domain doesn't match the domain in the From header, especially when using subdomains, third-party services, or mixed sending domains. These mismatches trigger rejection at the receiving end—especially in 2026’s stricter mail environments. Let’s break down the real-world scenarios you’re seeing now and how to fix them.

Subdomain and Domain Mismatches

Using a subdomain in DKIM (e.g., mail.yourcompany.com) while sending from the root domain (yourcompany.com) breaks alignment. The receiving server checks if the DKIM signature’s domain matches the From domain, and it doesn’t—resulting in a failure.
Setting SPF on a different domain than DKIM (e.g., SPF on mail.example.com, DKIM on example.com) causes the alignment check to fail. SPF validates sender authorization, while DKIM validates message integrity—both must align with the From domain.
Using marketing.yourcompany.com for marketing mail and support.yourcompany.com for transactional mail without aligning both domains to the From header causes consistent failures. Each sending domain must be explicitly authorized and aligned with the From domain to pass DMARC.

Third-Party Service Misalignment

When you use a third-party email service (like SendGrid, Mailchimp, or HubSpot), they often sign messages with their own domain. If your From header uses your company’s domain ([email protected]), alignment fails unless you configure their service with your domain and properly align the DKIM and SPF records.
Many services allow you to set your own domain for DKIM and SPF, but only if you correctly publish the required DNS records. Failing to update DNS records or using a third-party domain in the From header without proper alignment leads to high bounce rates and poor deliverability.
Some services default to using their own domain in emails, which may appear in the From header or in DKIM signatures. Always double-check the sending domain in your campaign settings and ensure it matches the one used in DNS records and DKIM signing.

For email providers, alignment isn't optional—it’s a fundamental part of mail authentication. Misalignment is one of the top reasons emails land in spam or get blocked outright, even with valid SPF and DKIM. Proper alignment requires consistency across all three: the domain in the From header, the DKIM selector domain, and the SPF include or spf record.

Need to validate your sending setup? You can spot alignment issues before they impact deliverability by testing your email configurations. Use tools like MxToolbox or the SPF specification to audit your DNS records and confirm alignment at every layer.

If you're managing large lists or automating email sends, consider a bulk email list cleanup. Cleaning your list for invalid or misaligned domains reduces the risk of authentication failures and maintains sender reputation over time.

SPF, DKIM, and DMARC: Roles and Misconceptions

You don't need to be a DNS expert to debug alignment issues — you just need to know what each protocol actually does. SPF checks the envelope sender (MAIL FROM), not the visible From header. DKIM signs the message body and headers, but only if the domain matches the From address. DMARC enforces policies based on SPF and DKIM results — but only when alignment is confirmed. Even if SPF and DKIM pass, a mismatched domain can still cause rejection. Let’s clarify how they work — and where things go wrong.

What Each Protocol Actually Does

Many teams assume SPF validates the “From” address. It doesn’t. SPF validates the MAIL FROM address used during the SMTP transaction — the envelope sender. This is often different from the From header you see in an inbox. DKIM signs the message content and selected headers with a private key. When the recipient verifies the signature, it ensures the message wasn’t altered and came from a domain the sender controls. DMARC is the enforcement layer. It tells receivers what to do when SPF or DKIM fails — or when alignment fails. You can have both SPF and DKIM passing, but if the domains don’t align, DMARC may still block the message.

Protocol	What It Verifies	Domain Used	Alignment Required?	Common Pitfall
SPF	MAIL FROM (envelope sender)	Sender’s domain in MAIL FROM	No (but alignment needed for DMARC)	Assuming it checks From header; using a mismatched sender domain
DNSKEY (DKIM)	Message integrity and origin	Domain in DKIM-Signature header	Yes (aligns with From header domain)	Different domains in From and DKIM signature; signing the wrong domain
DMARC	Policy enforcement	Result depends on alignment of SPF or DKIM domains	Yes (strict alignment required)	Setting policy without proper alignment; ignoring reports

The reality is: you can have valid SPF and DKIM signatures, but still fail DMARC if domains don’t align. This is why you see rejections in 5.7.13 — the receiving server sees “pass” from SPF, but the domain doesn’t match the From header, so DMARC fails. The message is rejected. According to RFC 7489, alignment is critical for DMARC enforcement — and it’s often misconfigured.

How to Debug Alignment Failures

Start by auditing your email flows. Check the MAIL FROM in your transactional setup — it should be your primary sending domain. Then verify that your DKIM signature is published for that same domain. Use MxToolbox’s DKIM checker to validate the signature alignment. If both are correct but you still get 5.7.13, check for subdomain mismatches or misaligned sending sources. You can test delivery with inbox placement tools like inbox placement testing to catch alignment issues before sending to real users.

How to Audit Your Email Authentication Setup

You can debug SPF, DKIM, and DMARC alignment failures in 5.7.13 by checking DNS record syntax, ensuring the 'd=' tag in DKIM matches the 'From' domain, verifying SPF’s 'v=spf1' domain, setting DMARC to 'none' or 'quarantine' during monitoring, and confirming all sending sources declare correct domains. This process reveals misconfigurations that trigger authentication failures and inbox filtering.

Step-by-Step Audit Process

Use a DNS lookup tool like MxToolbox to inspect SPF, DKIM, and DMARC records. Verify the syntax is valid and there are no duplicate or conflicting entries. Tools like MxToolbox provide real-time DNS checks and are widely used in enterprise email operations. This step prevents misaligned authentication from blocking delivery.
Check that the 'd=' tag in DKIM matches the 'From' domain. The 'd=' tag identifies the domain associated with the DKIM signature. If it doesn’t match the sender’s domain in the email header, the alignment fails. Misalignment is a common cause of 5.7.13 errors reported by Exchange Online.
Ensure the SPF 'v=spf1' mechanism uses the correct domain. The domain in the SPF record must be the same as the 'From' domain or a trusted subdomain. If third-party senders like Mailchimp or HubSpot send on your behalf, their domains must appear in your SPF via 'include' mechanisms. Otherwise, SPF fails.
Set DMARC policy (p=) to 'none' or 'quarantine' during initial monitoring. Avoid 'reject' until alignment is stable. Sending an enforcement policy too early with unresolved alignment issues leads to email rejection. DMARC reports help track where issues occur, and RFC 7483 outlines best practices for deployment and monitoring.
Verify all email sending sources declare their domains correctly. This includes internal systems, CRM platforms, ESPs, and transactional services. Each must authenticate under the correct domain in SPF, DKIM, and DMARC. A mismatch in any source can cause alignment failures that appear as 5.7.13 messages.

Common Pitfalls to Watch For

Even small oversights break authentication. For example, using a subdomain in DKIM without aligning it in SPF or DMARC can trigger rejection. Likewise, failing to include third-party senders in SPF leads to SPF failures, even when DKIM passes.

Use inbox placement tools to verify whether email is actually landing in inboxes after your fix. Some tools can simulate real-world delivery. You can test this on a sample list using inbox placement testing to confirm alignment changes reduced blockage.

Remember: authentication isn’t a one-time setup. As email sources change, so should your DNS records. Regular audits prevent drift and maintain inbox placement.

How Email List Validation Can Help Catch Misalignment Before Sends

You can prevent SPF, DKIM, and DMARC alignment failures by cleaning your list before sending—validating addresses upfront ensures only deliverable, well-formed emails enter your sending pipeline. This reduces the risk of bounce chains, greylisting, and alignment mismatches, especially when your infrastructure is already correct. Tools like Email List Validation catch invalid, role-based, or disposable addresses that would otherwise trigger DMARC failures even if your authentication is set up properly.

Start with a Clean List—It’s the Foundation

Before alignment can be trusted, your list must be healthy. Role-based addresses like admin@, support@, or sales@ often don’t align with your sending domain and can trigger DMARC rejection—even if the email is technically valid. Bulk verification flags these early, so you’re not sending to addresses that break the alignment check at the recipient’s end. For example, if your sending domain is send.company.com but the email is from [email protected], misalignment can occur even with valid auth, simply due to inconsistent sender-to-recipient domain matching.

Address Quality Impacts Sender Trust

Even if your SPF, DKIM, and DMARC are technically correct, a poor-quality list can still hurt inbox placement. High bounce rates, inactive domains, or no valid MX records mean your sending reputation takes a hit. An address that fails DNS lookups or returns a 5xx error is likely to be flagged by receiving servers as suspicious. Email List Validation identifies these during verification, so you’re not unknowingly sending to a blacklisted or misconfigured domain. This avoids the kind of reputation damage that can indirectly break alignment trusts over time.

While Email List Validation doesn’t configure DNS, it does surface risky addresses in advance—letting you act before they harm your sender reputation. You’re not just validating syntax; you’re assessing whether an address behaves like a real inbox. The longer you wait to clean, the harder it is to recover from a reputation dip that affects all future sends—including aligning properly with DMARC policies.

For teams that send at scale, running a bulk verification before campaign sends is a practical step. It reduces bounce rates, improves inbox placement, and supports the technical integrity of your authentication setup. With 98.9% accuracy, you get a reliable signal on which addresses are likely to pass through email systems, including DMARC gates. Check your list health and ensure your sending infrastructure isn’t being undermined by outdated or incorrect inboxes.

Clean your entire list in minutes and reduce sender reputation risk before you send—because even perfect alignment fails when the recipient doesn’t exist.

Fixing Misalignment in Practice: A Step-by-Step Process

You can resolve SPF, DKIM, and DMARC alignment failures by verifying that your sending domains match the From domain in every email, checking your DKIM selectors, aligning SPF records to pass that check, and validating changes with small test sends before full rollout. Use real-time tools to catch issues early, then monitor DMARC reports for consistency.

Step-by-Step Alignment Fix

Identify the domains used in your email campaigns. Review your sending infrastructure. Are you using a subdomain (like mail.yourcompany.com) or the main domain? Confirm that the domain in your 'From' address matches the one configured in your sending platform. Misalignment often starts here — a mismatch between sending domain and From header is a fundamental red flag.
Check your DKIM selector and public key domain. Look up the DKIM record in DNS. The selector (e.g., default, s1, k1) determines which public key is used. The domain associated with that selector must match the From address domain. For example, if DKIM is published under default._domainkey.yourcompany.com, the From domain must be @yourcompany.com — not a subdomain or third-party service.
Align SPF and DKIM with your From domain. SPF policies should only include domains that pass alignment checks. If your emails come from @marketing.yourcompany.com, your SPF record must explicitly list that domain. Overly broad SPF records often include domains that don’t align, leading to failure. Use tools like MXToolbox to validate SPF records and detect alignment gaps.
Test with a small volume first. After adjusting DNS records, send only a few test emails to known inboxes. Monitor bounces and delivery status. A bulk send after misaligned configuration can trigger spam filters or trigger DMARC quarantine. Use inbox placement testing to confirm your emails land in inboxes, not spam.
Monitor DMARC reports and adjust. DMARC reports (found at dmarcanalyzer.com) show which emails pass or fail alignment. If failures persist, go back to step one — ensure every domain in the email chain aligns with the From address. Consistent failures mean the email flow isn't properly aligned, even if all records are technically correct.

Consistency is Key

Alignment isn’t a one-time task. As your sending domains evolve — adding new campaign subdomains, switching email platforms — recheck alignment. A single mismatched domain in a large campaign can cause widespread delivery issues. Use real-time verification tools to catch alignment problems before sending. Validate your email list with our API to ensure your From domains are consistent and your records are up to standard.

Why You Shouldn’t Skip Alignment Even If Bounces Are Low

Low bounce rates don't mean your emails are landing in inboxes. Even with clean delivery, misaligned SPF, DKIM, or DMARC can trigger filtering in Microsoft’s spam systems—especially Outlook and Exchange—where alignment is now a core inboxing factor. A strong sender reputation helps, but it’s not enough. Silently rejected or junked emails hurt engagement, deliverability, and long-term sender health.

Alignment Isn’t Just for High-Bounce Campaigns

You might think you’re in the clear because your bounce rate is below 1%, but bounce rates only measure hard failures. They don’t catch emails that slip into junk folders or are quietly discarded. Microsoft’s filtering systems—especially in enterprise environments—now use alignment as a key signal. Misalignment flags messages as suspicious, even if the sending IP is trusted and the domain has no reputation history.

Let’s say your newsletter is correctly authenticated, but the "from" address is from a different domain than the one signed in DKIM. That’s a failure in DKIM-DMARC alignment. The message may still deliver, but it lands in the junk folder with higher probability. This isn’t just theoretical—Microsoft’s own documentation confirms that alignment reduces inbox placement, especially for bulk senders.

According to the Microsoft Identity Platform documentation, message authenticity and domain consistency are key to avoiding filtering. That means alignment isn’t optional. It’s a baseline requirement for reliable inbox placement, even with zero bounces.

Reputation Alone Doesn’t Cover for Bad Alignment

A clean sender reputation—low spam complaints, strong engagement—is important, but it doesn’t override alignment failures. Email providers like Microsoft now apply deeper scrutiny when alignment is broken. Even a single misaligned header can trigger additional filtering layers, especially in organizations using strict policy-based filtering.

Think of it like a security checkpoint: a clean ID card (sender reputation) gets you through the gate. But if your name doesn’t match the passport (alignment), the system flags you for closer inspection. That inspection can still end in denial—without a bounce, without a notification.

For marketers, this means engagement metrics can look solid, but actual inbox placement is lower than expected. You’re not getting the open rates you’d expect, and your conversions stall. Diagnosing this issue is tough if you’re only monitoring bounce rates. That's why we recommend a full inbox placement test across multiple providers.

Test your deliverability in real-world inboxes with real inbox placement testing—it shows whether your messages are landing in the primary inbox or being silently filtered. You can catch alignment issues before they hurt campaigns.

Conclusion: Fix Alignment, Not Just Bounces

SPF, DKIM, and DMARC only work together when their alignment is correct. A single misconfiguration breaks the chain, even if all three are technically present.

Error 5.7.13 is a clear signal of protocol-level misalignment, not a symptom of poor sender reputation. Focusing only on bounces misses the root cause — the authentication structure itself is flawed.

Proactive measures for consistent deliverability

Use DNS tools to validate SPF, DKIM, and DMARC records regularly.
Analyze DMARC reports to identify alignment gaps before they impact delivery.
Apply email list hygiene at scale to prevent invalid or misaligned addresses from entering your send queue.

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 indicates that a message failed DMARC policy evaluation due to domain alignment issues between the 'From' header and the SPF/DKIM domains.

Does SPF alone prevent 5.7.13 errors?

No. SPF validity is checked, but alignment with the 'From' header domain is required in DMARC. SPF can pass while DMARC still fails.

Can DKIM pass if alignment is wrong?

Yes. DKIM validation only checks cryptographic signature and public key — it does not enforce domain alignment.

How do I fix DMARC alignment if I use a third-party ESP?

Ensure the ESP uses the same domain in DKIM as your 'From' address, or uses a consistent subdomain policy aligned with your sending setup.

Can a typo in the DKIM selector domain cause 5.7.13?

Yes. A typo in the 'd=' tag (e.g., 'yourcompany.net' instead of 'yourcompany.com') causes misalignment and DMARC failure.

Do all major email providers trigger 5.7.13 for alignment failures?

Primarily Microsoft-based providers like Outlook and Hotmail. Other providers may log such failures but use different error codes.

How often should I audit SPF, DKIM, and DMARC records?

At least quarterly, and after any change to sending sources, domains, or service providers.

Can invalid email addresses cause 5.7.13 errors?

No. 5.7.13 is a sender authentication issue, not address validity. However, bad lists can worsen reputation and increase filter scrutiny.

What does 'alignment' mean in DMARC?

It requires that the domain in the 'From' header aligns with the domains used in SPF and DKIM, either in exact match or through a shared parent domain.

Is domain alignment required for all email campaigns?

Yes — especially when using DMARC policies with 'quarantine' or 'reject'. Alignment is a hard requirement for inboxing in Microsoft environments.

How does Email List Validation help with these errors?

It doesn't fix DNS records, but it identifies invalid and risky addresses early — reducing bounce risk and improving sender reputation, which supports overall deliverability.

Can I use Email List Validation to test DMARC alignment?

No. It focuses on address validity, not DNS-level authentication. You need separate tools for SPF/DKIM/DMARC checks.