DMARC Policy Advisor

Start with p=none and an rua address to collect reports without affecting delivery. After 1–2 weeks, analyse reports to identify all legitimate sending sources and ensure they have valid SPF and DKIM. Once confident, move to p=quarantine; pct=10 (apply to 10% of failing mail), then gradually increase pct to 100. Finally, switch to p=reject for full enforcement. This gradual process minimises the risk of blocking legitimate email.

The pct tag specifies what percentage of messages that fail DMARC should have the policy applied. Start at pct=10 when moving to quarantine or reject, monitor reports for unexpected failures, then increase by 10–25% increments every few days. A pct value below 100 allows you to test enforcement on a subset of traffic before full deployment. Once at pct=100 with no legitimate mail affected, your rollout is complete.

DMARC aggregate reports are gzip-compressed XML files sent to your rua address once per day by participating mail providers. Each report shows: the sending IP addresses, the From domain, SPF and DKIM results, DMARC disposition (none/quarantine/reject), and message counts. You can parse them manually or use a DMARC report analyser tool. Look for rows where disposition is quarantine or reject and source IPs are your legitimate sending services — those indicate misconfigured authentication that needs fixing.

At p=none, DMARC does not affect delivery — it only generates reports. At p=quarantine or p=reject, DMARC can cause email to be filtered or rejected if SPF or DKIM fails and is not aligned with the From domain. This can affect transactional email sent by third-party services that send on behalf of your domain without proper authentication. Thoroughly reviewing rua reports and fixing all authentication failures before enforcing p=reject prevents DMARC from breaking legitimate email flows.