Practical email authentication

DMARC Errors & Fixes — A Practical Troubleshooting Guide

Fix missing or duplicate DMARC policies, invalid tags, reporting authorization and alignment problems. Find the right Maail tool for each issue.

Standards baseline: RFC 9989 and RFC 9990, with RFC 7489 compatibility notes. A DNS policy is not a delivery, protection or compliance guarantee.

No policy found.

Confirm the domain spelling and the TXT name. A quick check tests the exact domain; the inspector also checks inheritance. NXDOMAIN is different from a resolver timeout. Create an explicit monitoring record only after preparing a report mailbox.

Generate a draft

Multiple policy records.

Keep one DMARC TXT policy at each name. Merge intended settings into one record and remove the extra policy through your DNS provider. Do not delete unrelated TXT records such as SPF or ownership verification.

Malformed tags, versions or duplicate tags.

Start with case-sensitive v=DMARC1. Use semicolons between name=value tags and publish each tag once. Check for smart quotes, copy/paste artifacts and an accidental duplicated zone name. Unknown tags are ignored; a typo such as “rue” does not enable reporting.

The tool distinguishes record issues from the policy a current receiver may derive. RFC 9989 can use monitoring fallback when p/sp/np is invalid and a usable rua exists. Fix the record instead of depending on fallback.

Check allowed values

DNS looks correct, but no reports arrive.

Verify the rua URI, exact authorization evidence, mailbox acceptance and spam filtering. Allow reporting cycles; not every receiver reports. A missing report is not proof that no mail or abuse occurred. Failure reports via ruf are much less widely supported and need a privacy review.

Inspect reporting destinations

SPF or DKIM passes, but DMARC fails.

Compare the visible From domain with the SPF envelope domain and passing DKIM d= domain. At least one must align. Forwarding can break SPF; content changes can break DKIM. Do not whitelist a source solely because a pasted Authentication-Results field says pass.

Inspect original headers

pct, ri, rf or t cause a false sense of safety.

Current receivers ignore removed legacy tags. Older receivers can ignore the new t tag. Keep the baseline p=none until you have verified senders, report coverage and operational ownership. The generator labels pct as legacy and omits it at the default 100.

Resolver error or stale DNS answer.

Retry a failed lookup separately. Timeouts and SERVFAIL are not “no record” results. After a DNS change, cached answers can differ until TTLs expire. The public tools use Google Public DNS over HTTPS, not a complete authoritative-zone audit.

Standards and further reading.

Maail’s tools are diagnostic aids, not cryptographic message validators or a universal receiver simulator. Review their data boundaries.

Go from explanation to evidence

Inspect, observe, then decide.