What Does DMARC Report Policy_Evaluated Actually Mean?

You just checked a DMARC report and saw “policy_evaluated” — but you’re not sure what it means. You know it’s not about whether the email reached the inbox, nor about whether SPF or DKIM passed. So what’s this field actually telling you?

Policy_Evaluated reveals whether the receiving domain’s DMARC policy — none, quarantine, or reject — was enforced based on the results of SPF and DKIM checks. It’s the final verdict: did the domain allow delivery, or was the message flagged according to its rules?

Think of it like a security checkpoint: SPF and DKIM are the ID checks. Policy_Evaluated is the gatekeeper’s decision — “let them through,” “flag for review,” or “block entirely.” It’s not about whether the ID was valid — only whether the domain’s policy acted on it.

Key takeaways

  • Policy_Evaluated reflects whether a domain’s DMARC policy (none, quarantine, reject) was applied based on SPF and DKIM outcomes.
  • It’s a final enforcement decision, not a technical result — it shows intent, not delivery success.
  • It does not indicate whether the message reached the inbox; only whether the policy was triggered.

How Auth_Results Differs from Policy_Evaluated in DMARC Reporting

Auth_Results shows whether SPF and DKIM passed or failed for a specific email, revealing technical authenticity. Policy_Evaluated goes further by applying the domain’s actual DMARC policy—reject, quarantine, or none—to the message based on those results, even if authentication passed. A message can pass authentication but still fail policy evaluation if the policy demands stricter compliance.

Auth_Results: The Technical Check

Auth_Results is your email’s technical authenticity report. It tells you, message by message, whether SPF and DKIM checks passed or failed. This is pure mechanics: did the sending domain match the sender’s domain in the email headers (SPF), and was the message digitally signed (DKIM)?

Think of it as a security scan for the email’s identity. If SPF or DKIM failed, the email failed the technical test. This data is critical for diagnosing why messages are being blocked or marked as spam. You can track this in DMARC reports directly from the receiving server’s response.

Policy_Evaluated: The Policy Decision

Policy_Evaluated is where things get operational. It takes the Auth_Results and compares them against the domain’s published DMARC policy (p=none, p=quarantine, p=reject). Even if both SPF and DKIM pass, a message can still fail Policy_Evaluated if the policy says “reject” and the message doesn’t meet all requirements.

For example, a message might pass SPF but fail DKIM. If the domain’s policy is set to reject, the Policy_Evaluated result will be “fail” even though one test passed. This is why you need both metrics. A message can pass technical checks but still be blocked by policy.

Understanding this difference helps you diagnose delivery issues more accurately. For instance, if you see many “pass” Auth_Results but many “fail” Policy_Evaluated results, your DMARC policy may be too strict. This is common with misconfigured sending sources or third-party providers not fully complying with your policy.

For real-time visibility into how your emails perform across domains, use inbox placement testing from MailTester. It shows how your messages are received—whether they pass, fail, or end up in spam—based on actual provider behavior.

How Email Senders Get Misled by Policy_Evaluated Alone

Seeing Policy_Evaluated: pass doesn’t mean your email will land in the inbox—it only confirms compliance with DMARC policy. A message can pass policy checks yet still be blocked by spam filters due to poor sender reputation, risky content, or abusive sending behavior. Let’s break down why relying on policy alone is a gamble.

Policy_Evaluated is Just One Layer

DMARC’s Policy_Evaluated field tells you whether a message passed the sender’s domain policy, not whether it will be delivered. It evaluates SPF and DKIM alignment, but doesn’t account for real-time spam scoring, domain reputation, or mailbox provider behavior. Just because a message passes authentication doesn’t mean it’s trusted.

For example, a high-volume sender using a legitimate domain can still trigger spam filters if their IP is on a blocklist, their content contains spammy patterns, or if recipients frequently mark messages as spam. These are not caught by DMARC policy evaluation. According to RFC 7483, DMARC focuses on policy enforcement—not delivery fate.

What’s Missing in Policy_Evaluated?

DMARC tells you nothing about sender reputation, which is often more critical. A low-reputation sender with a perfectly aligned SPF/DKIM might still end up in junk folders or blocked entirely. Some inbox providers, like Gmail and Yahoo, use their own scoring models that include historical engagement, recipient behavior, and content analysis—none of which DMARC sees.

Even if your domain has 100% DMARC pass rates, you could still have a 20–40% inbox placement failure, especially with large lists or new senders. This gap is where deliverability testing and pre-send verification become essential.

MailTester’s real-time verification detects these risks before you send. By simulating actual inbox delivery across major providers—including Gmail, Yahoo, and Outlook—you catch issues that policy evaluation alone will miss. Our inbox placement tests surface whether an email lands in the inbox, spam, or is blocked entirely.

Use our bulk verification to clean lists before sending, or the real-time API to validate each address at scale. With 98.9% accuracy, you’re not guessing—your data is tested against the actual delivery behavior of receivers.

The True Sequence: How DMARC Evaluates Email Messages

DMARC report policy_evaluated reflects the final decision a receiving server makes based on SPF and DKIM results reported in auth_results. While auth_results show whether individual authentication checks passed, policy_evaluated determines whether the email is accepted, quarantined, or rejected — depending on the domain’s DMARC policy. This sequence ensures only authenticated mail from trusted sources reaches inboxes.

  1. Receiver checks for a valid DMARC record. The receiving server first queries the sender’s domain for a DNS record starting with v=DMARC1. If none exists, DMARC evaluation stops. A valid record is required to apply any policy. This step ensures only domains that have explicitly opted in can enforce authentication rules (see RFC 7483).
  2. Receiver evaluates SPF and DKIM using auth_results. auth_results in the DMARC report contains data from individual checks: whether SPF alignment passed, whether DKIM signature verified, and whether the domain matches. A message may pass one or both, or neither. This is where real alignment issues are revealed — especially when the From domain differs from the SPF or DKIM signer domain.
  3. Receiver applies the policy based on auth_results. Using the results in auth_results, the receiver sets policy_evaluated to none, quarantine, or reject. The policy is defined in the DMARC DNS record (`p=none`, `p=quarantine`, `p=reject`). For example, if SPF passed and DKIM failed but alignment matched, result could still be quarantine if the policy requires both.
  4. DMARC report logs the outcome for domain owners. The final policy_evaluated value is included in the daily DMARC aggregate report sent to the domain owner (via the rua email). This log shows who sent mail, how it passed or failed, and whether it was treated as spam or blocked.

Why This Matters

Many senders assume a passing SPF or DKIM means their email will deliver. But DMARC doesn’t pass the baton — it enforces policy based on the combined score. If your email shows auth_results as pass but policy_evaluated as reject, the issue is alignment or a strict DMARC policy. Even a single failed alignment can sink a message.

Monitor and Verify With Real Tools

Understanding DMARC is only half the battle. You need to verify that your messages consistently align and pass authentication. Use MailTester’s inbox placement testing to simulate real-world delivery, or automate checks with the email verification API. For bulk verification before sending, test your list to catch invalid or risky addresses early.

Why You Need Both Auth_Results and Policy_Evaluated for Deliverability

Auth_Results tells you whether SPF and DKIM passed—whether the technical signatures matched. But Policy_Evaluated shows what actually happened to the message: whether the receiving domain’s DMARC policy blocked, quarantined, or allowed it. Relying only on Auth_Results misses the full picture. A message can pass authentication but still be blocked by policy, which is why you need both fields to understand real deliverability outcomes.

Auth_Results Shows the Technical Check

Auth_Results reports the results of SPF and DKIM validation. If both are “pass,” the email meets technical authentication standards. This is necessary but not enough. Many senders assume a “pass” means inbox delivery. It does not. Some domains apply strict DMARC policies that reject messages even when authentication is technically correct. That’s where Policy_Evaluated comes in.

Policy_Evaluated Reveals the Final Decision

Policy_Evaluated reflects the domain’s actual policy action—block, quarantine, or none. Even if SPF and DKIM pass, a policy set to “reject” will still block the message. This is especially common with large domains like banks or enterprises that enforce strict sender policies. Without checking Policy_Evaluated, you’re blind to why a technically valid email ended up in junk or was rejected entirely.

Let’s say you send a campaign using a valid domain. Auth_Results says “pass” on both SPF and DKIM. But Policy_Evaluated says “fail.” That means the receiving domain blocked the message despite technical compliance. This isn’t a misconfiguration—it’s an intentional policy outcome. It happens more often than you think, especially in high-volume or high-risk industries.

MailTester captures both fields during inbox-placement tests to simulate how real-world mail servers evaluate your messages. We don’t just check if the email passes authentication—we see if it gets delivered. You get a full picture: Was it technically valid? Did the policy allow it? This gives you insight you can’t get from tools that only track Auth_Results.

For a deeper look at how DMARC policy decisions impact real-world delivery, the DMARC specification (RFC 7483) explains how policy evaluation works across domains. Industry reports from organizations like Spamhaus also show that policy enforcement—not just authentication—drives inbox placement for enterprise mail flows.

Use MailTester’s inbox-placement test to validate both Auth_Results and Policy_Evaluated in real-time. See exactly what happens to your emails before you send them to your full list. The result? Fewer bounces, higher deliverability, and fewer surprises in your inbox.

How MailTester Uses DMARC Data to Improve Deliverability

DMARC report analysis reveals a critical gap: a message can pass authentication (auth_results) but still fail policy evaluation (policy_evaluated) due to inconsistent domain policies. This mismatch often means your email passes technical checks but gets filtered anyway. MailTester detects this mismatch during inbox-placement tests, flagging hidden delivery risks before you send.

Why Policy_Evaluated Matters More Than Auth_Results Alone

Just because an email passes SPF and DKIM (auth_results) doesn’t mean it’s trusted by the recipient’s domain. DMARC’s policy_evaluated checks whether the sending domain’s policy aligns with the authentication results. If a domain says "reject" but allows messages passing only SPF, or if the policy is set to "none," that’s a warning sign.

Let’s say your email passes SPF and DKIM, so auth_results shows "pass." But policy_evaluated shows "fail" because the domain’s DMARC policy is set to "none" or "quarantine," and the message doesn’t meet its strict requirements. This is often invisible in basic validation tools — but MailTester surfaces it.

How We Turn DMARC Signals Into Deliverability Insights

During inbox-placement testing, we process real DMARC reports sent by major providers like Gmail and Microsoft. These reports expose if your domain’s policy is misaligned with actual email traffic. We compare the policy_evaluated outcome against auth_results to catch setup flaws — like a misconfigured DMARC record or inconsistent alignment between SPF and DKIM.

For example, if your domain policy says "reject" but we detect messages passed with relaxed alignment or weak authentication, that’s a red flag. We highlight this inconsistency so you can fix the root cause before sending to thousands. This prevents sudden inbox filtering, especially in high-volume campaigns.

These insights come from real email infrastructure behavior. The IETF’s DMARC specification (RFC 7483) establishes this separation between authentication and policy enforcement — and that’s where we focus. We don’t guess. We test against real outcomes.

Use MailTester’s inbox-testing to see how your messages perform in real inboxes — including DMARC policy analysis. Run a full inbox placement test: https://mailtester.com/inbox-tester. Or verify large lists in advance: https://mailtester.com/email-list-verify.

Common Misconfigurations That Impact Policy_Evaluated

Policy_Evaluated depends on correct SPF and DKIM alignment, but many senders misconfigure subdomains, omit authentication, or fail alignment checks. These errors cause DMARC to skip enforcement even when a policy is set to reject. Let’s walk through the top issues that break Policy_Evaluated — and how MailTester catches them before they hurt deliverability.

SPF Misalignment Across Subdomains

  • Using different SPF mechanisms (e.g., include vs. redirect) across subdomains without proper alignment can invalidate policy evaluation.
  • If a subdomain like newsletter.example.com uses a different SPF record than the parent domain, DMARC sees it as unaligned — even if the message passes SPF.
  • DMARC evaluates the domain in the From header, not the sending domain. So a subdomain SPF failure won’t prevent delivery but can stop the policy from being enforced.

Missing or Misaligned Authentication

  • Setting a DMARC reject policy (sp=reject) without properly signing all outbound messages leads to Policy_Evaluated = "none" — meaning no enforcement is applied.
  • Even if SPF passes, DKIM must align with the From domain. If a message uses a DKIM selector for mail.example.org but the From domain is example.com, DKIM does not pass alignment.
  • DMARC does not require SPF or DKIM to pass for Policy_Evaluated to be "none" — it only requires alignment. If either fails alignment, Policy_Evaluated evaluates to "none", which means no policy enforcement occurs.
  • SPF domain alignment fails when the spf part of the From header doesn’t match the sender domain. For example, sending from [email protected] but using a generic SPF record from email.company.com causes rejection.

These misconfigurations are common — especially when using third-party tools or sending from multiple subdomains. RFC 7483 defines alignment rules, but implementation varies. You can catch them early by checking your DNS records and testing sender consistency.

MailTester’s bulk verification and inbox placement tests scan for these issues. It checks SPF and DKIM alignment, flags risky domains, and surfaces whether a domain’s DMARC policy is effective. You can test your entire list — including subdomain senders — before you send.

For real-time validation, use the MailTester API to verify individual addresses and detect alignment risk before delivery. For larger campaigns, test via bulk verification, or analyze results with inbox placement to see how your messages land across providers.

What DMARC Reports Don’t Tell You — And How MailTester Fills the Gap

DMARC reports show whether an email passed or failed policy evaluation, but they don’t reveal whether a sender’s reputation is weak, if content risks exist, or if a message gets flagged based on poor engagement. You can pass policy checks and still land in spam. That’s where MailTester’s real-time verification API steps in, giving you inbox placement scores and sender reputation signals missing from DMARC reports alone.

Policy Evaluated vs. Auth Results: What the Report Actually Shows

DMARC reports break down what happened at the receiving end: did the message pass SPF, DKIM, and alignment checks? The policy_evaluated field tells you if the recipient’s policy allowed delivery, based on domain-level rules. But it doesn’t track whether the message was rejected due to sender reputation, poor engagement history, or content characteristics.

For example, a message can have valid SPF and DKIM signatures, align correctly, and still get blocked because the sender has low reputation or high bounce rates. This is a known limitation: RFC 7483 (the DMARC specification) only defines policy-level feedback — not behavioral or content-based filtering.

According to a 2023 report by Spamhaus, over 40% of email rejections are based on reputation or engagement signals — not technical authentication failures. That means DMARC reports, while useful for technical validation, miss the bulk of real-world delivery issues.

MailTester’s Real-Time View: Reputation, Content, and Inbox Placement

Let’s be clear: passing DMARC doesn’t mean your message reaches the inbox. MailTester’s verification API goes beyond policy checks. It evaluates sender reputation, checks for content red flags, and tests how your email performs in real inboxes — all through actual delivery tests.

For example, our inbox placement tester simulates real delivery to Gmail, Outlook, and Yahoo, giving you a direct preview of where your message lands — spam or inbox. At the same time, our real-time API returns a reputation score, identifying if a domain is known for high bounce rates, poor engagement, or being associated with abuse.

These signals aren’t in DMARC reports. You need them to catch risks before you send. That’s why top deliverability teams use MailTester alongside DMARC. You verify the technical pieces, then test the real-world outcome — no guesswork, no surprises.

How to Read Your Own DMARC Reports: Key Sections Explained

DMARC report fields like policy_evaluated and auth_results are where your email authentication success or failure is recorded. policy_evaluated shows if your domain’s policy (none, quarantine, reject) was applied. auth_results shows whether SPF and DKIM passed or failed. Knowing both helps you debug why emails aren’t reaching inboxes—especially before campaigns.

Checklist: Decoding DMARC Report Fields

  • Check policy_evaluated first — it tells you if your DMARC policy was enforced (e.g., disposition=reject means failing messages were blocked). If the value is none, no policy was enforced, and you’re not protecting your domain.
  • Review auth_results for SPF and DKIM — this section shows exactly which authentication method passed or failed. If spf=pass but dkim=fail, your DKIM signature is broken or not properly aligned.
  • Look at domain to confirm alignment — this is the domain being evaluated. If you're seeing reports for example.com but your emails come from mail.example.com, alignment may be misconfigured.
  • Inspect the reason field when authentication fails — it details why SPF or DKIM failed (e.g., authfail, permerror, temperror). A permerror means a configuration mistake in your DNS; a temperror suggests a transient issue like a DNS timeout.
  • Compare policy vs auth results — even if SPF/DKIM pass, if policy_evaluated shows none, your domain is still vulnerable. If policy says reject but auth results say pass, then messages are being blocked as intended.
  • Use real data to spot patterns — over time, track failures across sending sources. Tools like DMARC.org offer guidance on interpreting common errors and improving delivery.
  • Validate your setup before campaigns — use the inbox placement tester to confirm your domain’s deliverability before sending at scale. This catches issues DMARC alone may miss.

Why This Matters for Deliverability

Understanding policy_evaluated vs auth_results lets you act before you send. A misaligned SPF or failed DKIM isn't just a technical detail — it can send your emails to spam or blocklists. If your policy says reject but auth_results show fail, that’s expected. But if you see pass on auth but still reject in policy, you may be overblocking legitimate mail.

Use our verification API to test real email addresses against DMARC, SPF, and DKIM during list cleanup. This helps prevent bounces and reputational harm from invalid addresses.

“A DMARC report is only useful if you understand what the fields mean.” – From an email security white paper, available via DMARC.org.

Why DMARC Alone Isn’t Enough to Fix Inbox Placement

DMARC reports show whether your emails pass authentication, but that doesn’t guarantee inbox delivery. A message can pass policy_evaluated checks and still land in spam if the sender has poor reputation, low engagement, or triggers filtering rules based on content or volume. You need more than authentication—you need deliverability validation.

Authentication Is Just One Layer

DMARC ensures your domain is authenticated via SPF and DKIM, reducing the chance of spoofing. But passing these checks doesn’t mean your emails are trusted by mailbox providers. Major ISPs like Gmail and Outlook rely on sender reputation, engagement rates, and recipient actions—factors DMARC doesn’t measure.

Let’s say you send a high-volume campaign with a strong brand name but poor open rates. Even if your messages pass policy_evaluated checks, the lack of engagement signals can trigger spam filters. The same message might pass DMARC but still get quarantined. This is why authentication is necessary—but not sufficient.

Deliverability Requires Real-World Testing

DMARC reports tell you whether your email infrastructure is set up correctly. But they don’t tell you if your message lands in the inbox. That requires testing actual delivery under real-world conditions.

MailTester bridges that gap. While DMARC gives you a technical check, our inbox placement tester simulates delivery across real inboxes at Gmail, Outlook, Apple Mail, and other major providers. You get confirmed results: inbox, spam, or blocked—no guesswork. This testing reveals how your message performs based on content, sending volume, and recipient behavior, not just technical correctness.

For example, a message that passes all DMARC checks still fails delivery if it contains known spam triggers or comes from a sender with a recent spike in complaints. MailTester’s deliverability test catches those signals before you send.

Combine DMARC validation with real inbox testing. Use our inbox placement tester to verify results in practice—not just in theory.

Learn more about how email authentication and deliverability intersect at RFC 7483, the standard that defines DMARC. And see how to keep your sender reputation strong with proper list hygiene: bulk email verification with MailTester.

Use MailTester to Validate DMARC and Deliverability Together

DMARC report policy_evaluated and auth_results serve different purposes. Policy_evaluated reflects whether a domain’s DMARC policy was enforced, while auth_results show whether individual messages passed SPF or DKIM. Ignoring either can lead to undetected delivery failures.

MailTester checks both metrics during inbox-placement tests. You’ll see whether your messages pass authentication and whether the receiving provider acted on the DMARC policy. This gives you a full picture of real-world deliverability risks.

  • Test your sending domain across multiple providers using real inboxes.
  • See exactly how policy_evaluated results vary by provider and impact delivery.
  • Identify accounts where auth_results pass but policy_evaluated fails — a common red flag.

Sources

Keep reading

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

Frequently asked questions

What does Policy_Evaluated mean in a DMARC report?

It indicates whether the domain’s DMARC policy (none, quarantine, reject) was applied to the message. A pass means the policy allowed delivery based on SPF and DKIM results.

How is Auth_Results different from Policy_Evaluated?

Auth_Results shows whether SPF and DKIM passed individually. Policy_Evaluated determines if the domain's policy allowed delivery based on those results.

Can a message have passing Auth_Results but fail Policy_Evaluated?

Yes. If the domain’s DMARC policy is 'reject' and the message does not fully comply—even if SPF/DKIM pass—Policy_Evaluated will be 'fail'.

Why does my email pass DMARC but still go to spam?

DMARC only checks authentication. Spam filters also consider sender reputation, content, engagement, and list hygiene. MailTester tests inbox placement beyond DMARC.

Do DMARC reports include sender reputation data?

No. DMARC reports only show policy enforcement based on SPF/DKIM. Sender reputation is evaluated separately using behavioral and delivery data.

How does MailTester use DMARC data for deliverability testing?

We analyze both Auth_Results and Policy_Evaluated during inbox-placement tests to predict delivery outcomes across major providers.

Can MailTester detect DMARC misconfigurations before sending?

Yes. Our bulk verification and real-time API identify alignment issues, invalid policies, and misconfigured records that could lead to failed Policy_Evaluated.

Is DMARC policy evaluation the same for every receiving domain?

No. Each domain sets its own DMARC policy (none, quarantine, reject). MailTester tests across multiple domains to simulate real-world outcomes.

How do SPF and DKIM alignment affect Policy_Evaluated?

If the sending domain and alignment domain don’t match, Policy_Evaluated may fail—even if SPF and DKIM technically pass.

Does a DMARC report show if a message was delivered?

No. DMARC reports only track authentication and policy evaluation. They do not confirm delivery or inbox placement.

Can I use MailTester to test DMARC compliance across a list?

Yes. With our bulk verification and deliverability testing, you can assess DMARC policy outcomes and inbox placement for thousands of addresses.

What's the value of combining Auth_Results and Policy_Evaluated in testing?

It reveals whether messages are both technically authenticated and policy-compliant—critical for achieving high inbox placement rates.