[ Spoofing & identity abuse ]

Assess a reported DMARC bypass against the actual trust boundary

Test a DMARC-bypass claim by locating the exact policy, authorization or receiver boundary involved.

By the EmailAuth research team · 3 min read

[ Key points ]

  • Test a DMARC-bypass claim by locating the exact policy, authorization or receiver boundary involved.
  • Separate over-authorization, trusted authentication results and receiver handling before assigning a failure.
On this page
  1. Reconstruct the observed decision
  2. Separate over-authorization from rule evasion
  3. Classify three hypothetical findings
  4. Make the finding actionable

The phrase DMARC bypass can describe very different events. A valid pass from an over-authorized source, delivery despite a failing result and an implementation error are not the same failure. Start with a falsifiable claim: which identity was asserted, which evidence was trusted and which decision differed from the expected rule?

Reconstruct the observed decision

Preserve the author domain, envelope domain, signing domains, trusted authentication results and receiver disposition. Record the policy and observation time. A message being delivered does not by itself prove a DMARC pass. Receiver handling includes local policy, and a domain owner's requested treatment is not a universal delivery guarantee. RFC 9989.

Likewise, a copied Authentication-Results string is not proof of the receiving system's decision. Establish the trusted authentication service and relevant hop. RFC 8601. If the only evidence is a screenshot saying pass, preserve the claim as unresolved until the underlying identities and trust context are available.

Separate over-authorization from rule evasion

BreakSPF studies how permissive SPF authorization and access to shared infrastructure can permit spoofing. Its threat model gives the attacker an eligible source path; the receiver may then evaluate the published authorization as written. BreakSPF, Section III.A and Figure 3.

If the attacker-controlled source is within an authorized range and uses an aligned envelope identity, the ordinary pass rule can succeed. The weakness is in the authority granted or the service boundary, rather than a new definition of DMARC. Conversely, if only an unrelated identity authenticates and the author domain is not aligned, a claimed pass needs a different explanation.

Classify three hypothetical findings

Assume a single visible From alerts@brand.test and an otherwise eligible DMARC evaluation. These are written hypotheses, not observed incidents.

  • Authorization case: source 192.0.2.99 is within a stipulated SPF ip4:192.0.2.0/24 range; MAIL FROM bounce@brand.test passes SPF; no DKIM signature. The aligned SPF path yields a message-level DMARC pass. Ask whether that source really is controllable by an unintended sender and which owner granted it authority.
  • Handling case: MAIL FROM bounce@other.test passes SPF and DKIM d=other.test passes, but assume neither aligns with brand.test. DMARC fails. If the trusted receiver record separately says delivered, investigate its handling policy; delivery alone has not changed the failed alignment result.
  • Evidence case: a copied header says pass, but trusted receiver origin, evaluated identities and applied policy are unknown. Neither a protocol violation nor a trustworthy pass is established. Request the original and receiver-side record.

An authorized positive sender 192.0.2.10 and an outside source 198.51.100.10 can provide proposed controls when investigating the first case. A hypothetical ip4:192.0.2.10/32 -all record admits only the former; no real production change follows from this prefix arithmetic. There is no executed parser, signature check or exploit here.

RFC9989 section7.4 requires valid DKIM for domains publishing p=reject. A passing aligned SPF mechanism is sufficient for a particular message’s pass condition, but is not a recommendation for SPF-only enforcement.

Make the finding actionable

Name the reproduced condition and the evidence still missing. A useful finding says that a specified source is admitted by a specified authorization and identifies the accountable owner. It does not say all DMARC protection is defeated. Check whether the real service restricts tenant identities, whether the source is actually controllable and whether the receiver applied the result claimed.

Preserve a harmless authorized positive control when testing a proposed mitigation. Narrowing a range or changing a connector can break legitimate senders. Require route-specific change approval and post-change verification, and keep provider behavior not tested in the lab explicitly unresolved. This supports a precise fix without exaggerating an educational model into a production vulnerability.

[ Takeaway ]

Separate over-authorization, trusted authentication results and receiver handling before assigning a failure.

[ By role ]

What this means for you

Choose your role for practical next steps.

IT / Mail Admin

Preserve negative controls

A useful test distinguishes permitted and unintended routes.

Next steps

  1. Capture evaluated identifiers.
  2. Keep a working legitimate sender case.
  3. Retain the test inputs and outputs.

CISO / SecOps

Scope the finding

Research evidence and organizational exposure are separate.

Next steps

  1. Require a defensible threat model.
  2. Track untested assumptions before risk acceptance.
  3. Require post-change evidence before closing exposure.

Founder / Non-technical

Demand a precise claim

A broad bypass headline can obscure the fixable control.

Next steps

  1. Ask what was actually reproduced.
  2. Separate service risk from protocol semantics.
  3. Assign the owner of the reproduced boundary.

[ FAQs ]

Frequently asked questions

Does inbox delivery prove a DMARC bypass?

No. Separate authentication outcome from receiver disposition and local policy.

Can DMARC pass because SPF authorizes too much?

Yes, if a passing SPF identity aligns with the author domain. Investigate the authorization boundary.

Can unrelated SPF and DKIM passes satisfy alignment?

Not merely because they pass. Their authenticated domains must have the required relationship to the author domain.

What is the first evidence to request?

The original message, trusted receiver results, evaluated identities, policy context and disposition.

What controls should a real authorization test include?

A legitimate approved source and a source outside the permitted set, with retained authorized inputs and observed results.

Was a miniature SPF evaluator run here?

No. The three findings and prefix comparison are written assumptions, not executed authentication or exploit tests.

Was a current provider vulnerability established?

No. Source control and receiver behavior in a real service remain untested.

How should a fix be validated?

Use an authorized positive sender control, targeted negative cases and route-specific post-change observations.

[ Sources ]

Sources

  1. BreakSPF original research NDSS

    Sections III.A Attack model · Figure 3 · VIII Discussion

  2. RFC 7208 SPF

    Sections §2.4 · §5.6

  3. RFC 9989 DMARC

    Sections §4.4 · §5.3.5 · §5.4 · §7.4 · §8

  4. RFC 8601 Authentication Results

    Sections §1.2 · §1.6 · §7

[ Glossary ]

Glossary

Negative control
A test case expected not to satisfy the condition under investigation.
Disposition
The receiver’s handling of a message, separate from its authentication result.

Enterprise provenance

Why top financial institutions and governments retired their email security dashboards.

Traditional email authentication platforms sell you a dashboard and ask your engineers to do the labour. In high-stakes environments, manual oversight means delayed enforcement, configuration drift and unmonitored shadow domains.

EmailAuth is the agentic email provenance platform. Our agents enforce p=reject, keep third-party senders aligned and move your domains to full RFC 9989 compliance, the new DMARC standard,, with human-in-the-loop auditability.

Governments Large enterprises Tier-1 financial institutions

SaaS · Dedicated tenancy · Air-gapped on-prem · BYOK encryption

Knowledge Base