A reporting policy tells you who is using your domain; a rejection policy changes whether their messages can be delivered. Google's October 2026 rollout guidance makes this a useful moment to turn existing DMARC reports into an operational approval process.
1. Account for every legitimate mail stream
Assign an owner to payroll, CRM, helpdesk, website notifications and employee mail. Observe a complete business cycle, including occasional billing runs. Quiet daily reports cannot prove that monthly services are ready.
Read the aggregate XML fields source_ip, count, header_from and policy_evaluated. Compare them with the SPF and DKIM domains under auth_results. A vendor-domain SPF pass is not proof of alignment with your visible sender.
Inspect a decompressed report using an updated XML tool without network access:
xmllint --nonet --format report.xmldig +short TXT _dmarc.example.comKeep external entity expansion disabled and restrict access to reports containing infrastructure details.
| Finding | Required follow-up |
|---|---|
| Known service fails DMARC | Fix signing or the return-path domain |
| Unrecognized source IP | Identify it before granting authorization |
| Forwarded mail fails SPF but retains aligned DKIM | Check the recipient's final DMARC result |
2. Repair alignment, then stage enforcement
Ask each vendor for aligned DKIM signing or an aligned SPF return path. Test real message types, including calendar invitations and automated replies. Include forwarding services and mailing lists that alter content.
Keep one DMARC TXT record. This zone-file example assumes the reporting mailbox exists:
_dmarc.example.com. 300 IN TXT ( "v=DMARC1; p=none; " "rua=mailto:dmarc@example.com")The quoted strings form one record. Join them when using a DNS dashboard's value field.
Move from none to a limited quarantine percentage, expand after review, and then introduce reject. The pct tag relates to treatment of failing messages; it does not promise a precise percentage of total traffic, and receivers retain local discretion.
Avoid changing strict alignment settings during the same rollout. That would introduce a second variable into your acceptance tests.
3. Make rejection a recorded release decision
Require a successful recipient test for every legitimate service and an explanation for remaining failures. Save the previous DNS value, change time and rollback owner.
_dmarc.example.com. 300 IN TXT ( "v=DMARC1; p=reject; pct=100; " "rua=mailto:dmarc@example.com")Review subdomains and any separate policies. Keep collecting reports after enforcement. If legitimate mail breaks, restore the previous policy while accounting for DNS caches; already rejected messages need separate recovery.
Common mistakes
Adding every reported IP to SPF, overlooking a rarely used sender and assuming none prevents all spam filtering are unsafe shortcuts.
FAQ
Must both SPF and DKIM align? DMARC needs at least one passing, aligned mechanism. Preparing both gives more resilience.
Will reject stop all impersonation? No. Lookalike domains and compromised accounts remain separate problems.
Final check
Every sender has an owner, indirect delivery paths have been tested, subdomain behavior is understood and rollback instructions are available before the DNS change.