DMARC Policy Rollout Guide

Moving your DMARC policy from p=none to p=reject is the ultimate goal — it tells receiving mail servers to reject any message that fails DMARC authentication. But getting there safely requires a methodical approach.

Phase 1: Monitor (p=none)

Start with p=none and a RUA address pointed to Safer Sender. This tells receivers to send you reports without taking any action on failing messages. Use this phase to build a complete picture of every sender using your domain.

• Identify all legitimate senders (marketing tools, CRMs, support platforms, etc.)
• Check SPF and DKIM authentication status for each sender
• Verify DMARC alignment (identifier alignment between header-from and SPF/DKIM domains)
• Document unauthorised senders and spoofing attempts

Phase 2: Remediate

Fix authentication issues for every legitimate sender before changing your policy. Common fixes include:

• Adding sending IPs to your SPF record
• Configuring DKIM signing for third-party services
• Fixing alignment by using your own domain in the envelope-from
• Removing unused or deprecated senders from your SPF record

Phase 3: Quarantine (p=quarantine)

Once all legitimate senders pass DMARC, move to p=quarantine. This tells receivers to send failing messages to spam rather than the inbox. Start with a low percentage using the pct= tag (e.g., pct=10) and gradually increase as you confirm no legitimate mail is affected.

Phase 4: Reject (p=reject)

The final step. With p=reject, receiving servers will reject any message that fails DMARC authentication. This provides maximum protection against spoofing and impersonation. Continue monitoring reports to catch any new senders or configuration changes that might cause issues.

Common Pitfalls

• Skipping the monitoring phase — rushing to enforcement without a complete sender inventory risks blocking legitimate email.
• Forgetting forwarded mail — email forwarding breaks SPF. Ensure DKIM is configured for all senders to survive forwarding.
• Ignoring subdomains — use the sp= tag to set a policy for subdomains, or they'll inherit the organisational domain's policy.
• Not monitoring after enforcement — new services, vendor changes, and configuration drift can break authentication at any time.