Guide: How to Move DMARC from p=none to p=reject Safely
Summary
The guide recommends auditing and authenticating every legitimate sender, monitoring DMARC reports, then gradually moving through quarantine to reject. It cautions that forwarding and some non-compliant receivers can limit enforcement.
Key points
- At p=none, DMARC does not instruct receivers to block messages that fail authentication; aggregate reports can reveal spoofing but do not cover all receivers or traffic.
- Inventory every legitimate sending platform, configure aligned DKIM and SPF, clean up invalid or obsolete SPF entries, and authenticate each sending subdomain.
- Use aggregate reports to confirm legitimate sources pass authentication; account for seasonal and infrequent senders before enforcing.
- Move to p=quarantine first, gradually increasing the pct setting from 10% to 25%, 50%, and 100%; the author recommends two to four weeks at full quarantine before moving to reject if reports remain clean.
- At p=reject, receivers are asked to reject messages that fail DMARC, but some providers may not honor the policy; forwarding can also break authentication alignment.
- The guide recommends considering MTA-STS, TLS-RPT, and DNSSEC as complementary email and DNS protections.
Article Details
- Defense Focus
- Safely move a domain from DMARC monitoring (p=none) to enforcement (p=reject) to reduce spoofing while avoiding disruption to legitimate email.
- Detection Methods
- Review aggregate DMARC reports to inventory sending sources and verify DKIM and SPF results and alignment for legitimate mail.
- Identify unrecognized sending IP addresses and mail servers, and track their volume and reported destinations as possible spoofing activity.
- Compare report data with known sending platforms; account for gaps because not all receivers provide reports or recipient-domain details.
- Monitor domain reputation and spam complaint rates, and review feedback-loop reports.
- Data Sources
- DMARC aggregate reports in XML, including sending IPs, message volumes, and DKIM/SPF results.
- Recipient or envelope-to domain data where receiving providers include it.
- Google Postmaster Tools and Yahoo Postmaster Tools reputation and complaint-rate data.
- Abuse@ and postmaster@ feedback-loop messages.
- Rule Types
- DMARC DNS TXT policy records, including rua, p, and pct tags.
- SPF DNS records and DKIM signatures used to assess authentication and alignment.
- XML-formatted DMARC aggregate reports.
- MTA-STS policies and TLS-RPT reports for email transport security monitoring.
- DNSSEC-protected DNS responses.
- Platforms
- DMARC monitoring services that collect, parse, and visualize aggregate reports.
- Receiving mail servers that evaluate DMARC policy.
- Defensive Actions
- Inventory every legitimate service sending mail from the domain, including infrequent and subdomain senders.
- Configure and verify aligned DKIM and SPF authentication for each legitimate sending source before enforcement.
- Monitor reports until legitimate sources are accounted for and passing authentication; use a longer observation period for complex environments.
- Move to p=quarantine before p=reject and gradually increase pct, monitoring for unexpected failures at each stage.
- Maintain ongoing report monitoring and require DNS authentication configuration before new sending platforms go live.
- Clean up obsolete DNS records and consider implementing MTA-STS, TLS-RPT, and DNSSEC.
- Do not downgrade DMARC to p=none merely to accommodate a provider that has not configured authentication correctly.
MITRE ATT&CK
Vendors
GoogleInventory every sender. Google Workspace or Microsoft 365 for corporate email. Your CRM. Your marketing automation platform. Your transactional email service. Your helpdesk. Your billing system. Your project managementMailerLiteAnother thing p=reject won't stop: an ESP that forces include:_spf.mlsend.com on your root domain — MailerLite prescribes exactly this configuration, and it lets their entire shared pool pass your DMARC.MicrosoftInventory every sender. Google Workspace or Microsoft 365 for corporate email. Your CRM. Your marketing automation platform. Your transactional email service. Your helpdesk. Your billing system. Your project managementMimecast365 silently overrides DMARC as oreject when tenants run behind third-party gateways like Proofpoint or Mimecast, with no aggregate report telemetry to surface the bypass. That's a gap to be aware of, not a reason toProofpointMicrosoft 365 silently overrides DMARC as oreject when tenants run behind third-party gateways like Proofpoint or Mimecast, with no aggregate report telemetry to surface the bypass. That's a gap to be aware of, notYahoowhere aggregate reports are sent. These reports come from receiving mail servers (Gmail, Microsoft, Yahoo, etc.) and tell you which IP addresses are sending email using your domain, whether those messages passed
Products
Google WorkspaceInventory every sender. Google Workspace or Microsoft 365 for corporate email. Your CRM. Your marketing automation platform. Your transactional email service. Your helpdesk. Your billing system. Your project managementMicrosoft 365 Apps for EnterpriseInventory every sender. Google Workspace or Microsoft 365 for corporate email. Your CRM. Your marketing automation platform. Your transactional email service. Your helpdesk. Your billing system. Your project management
Tools
Google Postmaster ToolsBeyond DMARC reports, set up Google Postmaster Tools and Yahoo Postmaster Tools to monitor domain reputation and spam complaint rates. Create standard abuse@ and postmaster@ email addresses to receive feedback loopYahoo Postmaster ToolsBeyond DMARC reports, set up Google Postmaster Tools and Yahoo Postmaster Tools to monitor domain reputation and spam complaint rates. Create standard abuse@ and postmaster@ email addresses to receive feedback loop