[ Start here ]

DMARC troubleshooting: choose the next check from the observed symptom

Use the observed failure to choose a focused DMARC check instead of changing every DNS record.

By the EmailAuth research team · 3 min read

[ Key points ]

  • Use the observed failure to choose a focused DMARC check instead of changing every DNS record.
  • Start with all available authenticated identities and one precise symptom before changing DNS.
On this page
  1. Preserve evidence before changing DNS
  2. Choose the next check from the symptom
  3. Separate authentication from receiver disposition
  4. Use a hypothesis and a stop condition
  5. Preserve an indeterminate case

Begin a DMARC investigation with one reproducible message and a precise symptom. “Mail is broken” can mean a failed aligned authentication result, a malformed policy, a rejected SMTP transaction or a message delivered to spam despite passing DMARC. Those situations do not have the same remedy.

Preserve evidence before changing DNS

Record the affected From domain, sending application, recipient, time and exact error. Obtain the received original source when delivery occurred, or the SMTP response and sender logs when it did not. Treat Authentication-Results as trustworthy only when its origin belongs to the receiving boundary you are investigating. Preserve a redacted working copy and restrict the original if it contains personal data.

Build an identity table with visible From domain, SPF-evaluated identity and result, every DKIM d and s value and result, and the receiver's DMARC result. Add the alignment modes and policy information relevant to that observation. Current DNS is useful, but it cannot prove what a resolver saw before a recent change.

Choose the next check from the symptom

If SPF passes and DMARC fails, compare the SPF identity with From before editing SPF. A pass for an unrelated envelope domain is not aligned. Then inspect every DKIM signature for a passing aligned path.

If DKIM passes and DMARC fails, compare its d domain with From and confirm the applicable alignment mode. Do not confuse the selector with the signing domain. A receiver may evaluate more than one signature, so avoid stopping at the first failing one.

If DKIM fails cryptographically, inspect the exact selector record, public key and message transformations. A missing key, an obsolete selector and a modified body require different changes. If there is no signature, investigate the outbound signer or a route bypass rather than publishing a guessed selector.

If SPF reports an error, inspect the actual evaluated domain's policy, lookup dependencies and syntax. Multiple SPF records at one owner are not a safe way to combine services. Do not add broad address ranges merely to make a test pass.

Separate authentication from receiver disposition

A DMARC pass does not guarantee inbox placement. If the receiver reports a pass but sends the message to spam, preserve that result and investigate reputation, content or the receiver's other controls. Conversely, delivered mail is not proof of a pass because receivers can apply local handling decisions.

For forwarded or mailing-list traffic, identify the intermediary and its modifications. SPF can change at forwarding, while DKIM may survive only if the signed material remains valid. Do not weaken an entire domain's policy simply because one indirect path needs investigation.

Use a hypothesis and a stop condition

Illustrative case: From billing@example.org, SPF pass for bounce.example.net, and DKIM pass for example.net. Assume these are the only authenticated identifiers available. Both authentication results pass, yet neither domain exactly matches example.org, and the unrelated domains do not provide relaxed alignment either. The next action is to investigate a supported aligned identity at the sender, not to add the recipient to SPF. This is a synthetic identity comparison, not an observed incident.

Write down the suspected cause, proposed change, expected evidence and rollback. Change one relevant element, send through the same route and compare results. Keep unrelated senders working. Close the incident only when the original symptom is resolved and representative legitimate flows remain healthy. Retain the before-and-after evidence and schedule a documentation update if a provider or standards change contributed to the fault.

Preserve an indeterminate case

If the received original is unavailable and a screenshot shows only one DKIM result, do not conclude that all DKIM paths failed or that DMARC must fail. Request the trusted receiver result and complete identity evidence. A missing SPF result is unknown, not a recorded fail. RFC 9989 Sections 4.4 and 5.3.5 require evaluation of the applicable authenticated identifiers; Section 5.4 keeps final handling distinct. No diagnostic command or live message test was executed for this example.

[ Takeaway ]

Start with all available authenticated identities and one precise symptom before changing DNS.

[ By role ]

What this means for you

Choose your role for practical next steps.

IT / Mail Admin

Keep operational evidence

Build an identity table first, then test one hypothesis at a time. Preserve receiver evidence and the change timeline.

Next steps

  1. Build an identity table first, then test one hypothesis at a time.
  2. Preserve receiver evidence and the change timeline.
  3. Retest the same route after one change.

CISO / SecOps

Review the trust boundary

Distinguish domain authentication from trust in the message content. Require a narrow rollback and evidence that the repair did not broaden sending authority.

Next steps

  1. Distinguish domain authentication from trust in the message content.
  2. Require a narrow rollback and evidence that the repair did not broaden sending authority.
  3. Reject unnecessary expansion of SPF authority.

Founder / Non-technical

Own the business decision

Keep the incident focused on the affected business flow. Avoid broad domain-policy changes that create risk for unrelated messages.

Next steps

  1. Keep the incident focused on the affected business flow.
  2. Avoid broad domain-policy changes that create risk for unrelated messages.
  3. Name the affected business process.

[ FAQs ]

Frequently asked questions

SPF passes, so why does DMARC fail?

The SPF domain may not align with From. Check its relationship and then look for any passing aligned DKIM signature.

Should I inspect only the first DKIM signature?

No. Record every signature and identify whether any passing signature supplies the required alignment.

Can a selector name establish alignment?

No. DKIM alignment uses the signing domain, not the selector label.

Does spam-folder delivery prove DMARC failure?

No. A message can pass DMARC and still be filtered for other reasons.

Should I add a second SPF record?

No. Combine authorised sending mechanisms into one valid SPF policy at the evaluated owner, after checking its dependencies.

What if current DNS looks correct?

Compare the change timeline and available historical evidence. Current records do not prove what the receiver saw earlier.

What is different about forwarding?

The receiving connection and sometimes message content change. Evaluate the final hop and surviving signatures rather than the original submission alone.

When is the incident closed?

When the original failure is no longer reproduced, the expected authentication evidence is present and representative legitimate routes still work.

[ Sources ]

Sources

  1. RFC 9989: DMARC

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

  2. RFC 7208: SPF

    Sections §2.4 · §4.5 · §4.6.4

  3. RFC 6376: DKIM

    Sections §3.4 · §3.5 · §3.7 · §6.1 · §6.3

[ Glossary ]

Glossary

Aligned authentication
A passing SPF or DKIM identity that meets the applicable relationship to the visible From domain.
Authoritative DNS
The DNS service responsible for publishing records for a zone.
Evidence boundary
The scope of what the cited documentation or a particular test can establish.

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