How to Move DMARC from p=none to p=reject Safely

· Original article ↗

Summary

A practical guide recommends authenticating every legitimate sender, reviewing DMARC reports, and gradually moving through quarantine before p=reject. It also covers enforcement limits, forwarding issues, and related DNS protections.

Key points

  • Before enforcement, inventory all services sending mail from the domain and fix SPF, DKIM, and alignment issues, including for sending subdomains.
  • Use DMARC aggregate reports to identify legitimate and unauthorized senders; the reports may not capture all spoofing activity.
  • Move to p=quarantine before p=reject, using the pct setting for a gradual rollout and monitoring for legitimate mail failures.
  • The article recommends basing each transition on confidence that legitimate senders authenticate successfully, rather than a fixed schedule.
  • Forwarded messages can fail DMARC, and some receiving providers may not honor p=reject; enforcement reduces spoofing but may not eliminate it.
  • The guide presents MTA-STS, TLS-RPT, and DNSSEC as complementary protections for email transport and DNS, not prerequisites for DMARC enforcement.

Article Details

Defense Focus
Safely move email domains from DMARC monitoring to p=reject to reduce spoofing while avoiding disruption to legitimate email.
Detection Methods
  • Parse DMARC aggregate reports and account for each legitimate sending source, checking DKIM and SPF results and alignment.
  • Identify unrecognized sending IP addresses and mail servers, and review their message volumes and reported destinations.
  • Track forwarded messages separately because forwarding can cause SPF or DKIM failures.
  • Use recipient-domain information when available in reports; treat reports as incomplete because some receivers provide limited data or none.
Data Sources
  • DMARC aggregate reports from receiving mail servers, supplied as XML
  • Google Postmaster Tools domain-reputation and spam-complaint data
  • Yahoo Postmaster Tools domain-reputation and spam-complaint data
  • Abuse and postmaster feedback-loop messages
Platforms
  • DMARC report monitoring and analysis services
Defensive Actions
  • Inventory every service sending email using the domain, including infrequent and departmental senders.
  • Configure and verify DKIM signing and SPF for each sender, with alignment for every sending domain and subdomain.
  • Review DMARC reports until all known legitimate sources pass authentication and unexplained sources have been assessed.
  • Move from p=none to p=quarantine before p=reject; use pct to increase enforcement gradually and monitor for legitimate failures.
  • Before and after enforcement, investigate receiver-specific behavior, including cases where third-party gateways may affect enforcement or reporting.
  • Require authentication and DNS configuration before approving new email-sending platforms; continue monitoring as the sending environment changes.
  • Remove obsolete DNS records and consider implementing MTA-STS, TLS-RPT, and DNSSEC.

Vendors

Products

Related Articles