cyber.hendryadrian.com
Detection & Defense · sh.consulting

Guide Outlines a Staged Move from DMARC Monitoring to Reject

· Original article ↗

Summary

The guide recommends auditing and authenticating legitimate senders, reviewing DMARC reports, and gradually moving from p=none through quarantine to p=reject. It also notes that forwarding can fail and some receivers may not honor reject policies.

Key points

  • Inventory every service sending email for the domain, then ensure each has aligned SPF and DKIM authentication before enforcing DMARC.
  • Use aggregate DMARC reports to identify legitimate and unfamiliar senders, but treat the reports as incomplete because not all receivers provide the same data or send reports.
  • The guide recommends moving to p=quarantine before p=reject, using the pct tag to increase enforcement gradually and checking for legitimate messages that fail.
  • Forwarding can break DMARC alignment, while new sending platforms need authentication configured before they send from the domain.
  • A p=reject policy is a request to receiving servers, not guaranteed enforcement; the article describes cases where some providers accepted mail that failed authentication.
  • The guide recommends continued monitoring and discusses MTA-STS, TLS-RPT, and DNSSEC as complementary email and DNS protections.

Article Details

Defense Focus
Safely enforce DMARC to reduce domain spoofing while preventing legitimate email from being blocked.
Detection Methods
  • Parse aggregate DMARC reports to identify sending IP addresses and mail servers, message volumes, and DKIM/SPF authentication results.
  • Compare report sources with an inventory of legitimate senders and investigate unrecognized sources as potential spoofing activity.
  • Use recipient-domain details in Microsoft reports where available; the article notes that Google reports do not provide this detail.
  • Monitor domain reputation and spam complaints, and review feedback-loop data.
Data Sources
  • DMARC aggregate reports received through the rua tag, provided as XML
  • DKIM and SPF pass/fail results and alignment data
  • Google Postmaster Tools domain reputation and spam complaint data
  • Yahoo Postmaster Tools domain reputation and spam complaint data
  • Abuse@ and postmaster@ feedback-loop data
Rule Types
  • DMARC DNS policy records using p=none, p=quarantine, or p=reject, with rua and pct tags
Platforms
  • DMARC monitoring services
  • Google Postmaster Tools
  • Yahoo Postmaster Tools
Defensive Actions
  • Inventory every legitimate sender, including infrequent and seasonal senders, and configure aligned DKIM and SPF for each domain and subdomain.
  • Correct broken or duplicate DKIM records and clean SPF records, including obsolete entries, multiple records, and configurations exceeding the 10-lookup limit.
  • Monitor aggregate reports until legitimate sources are accounted for and passing authentication before enforcing a policy.
  • Move first to quarantine and use pct for a gradual rollout, increasing enforcement in stages while checking for legitimate delivery failures.
  • Move to p=reject after reports show legitimate senders passing and the quarantine rollout is stable; continue monitoring because some receivers may not honor the policy.
  • Require authentication configuration before allowing new services to send email using the domain, and communicate the process to internal teams.
  • Review DNS records for obsolete entries and consider implementing MTA-STS, TLS-RPT, and DNSSEC.

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, notSo-netWe've seen what that means in practice. So-net, one of Japan's largest ISPs and owned by Sony, accepted messages that failed both SPF and DKIM from a domain at p=reject. When we analyzed spoofing of a look-alikeYahoowhere 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 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 loopGoogle 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 managementYahoo 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

Related Articles