DMARC enforcement can protect a domain from some forms of impersonation, but an incomplete sender inventory can also disrupt legitimate messages. Start by mapping your real sending systems and proving alignment. Policy changes should follow the evidence rather than a fixed number of days or a checklist score.
Build a sender map
List mailbox services, website forms, billing systems, support platforms and any other system that sends with your domain in the visible From address. For each one, record the envelope domain, DKIM signing domain, provider and responsible owner. Include seasonal or low-volume systems that a short reporting window could miss.
Send controlled test messages through each service to mailboxes you own. Save redacted recipient authentication results. A passing SPF check for a provider's unrelated envelope domain is not aligned with your From domain; a provider's own DKIM signature can have the same limitation. Arrange supported custom authentication before increasing enforcement.
Publish a monitoring policy
A monitoring policy requests reports while expressing no quarantine or rejection request. Receivers still apply their own filtering. The following uses a placeholder reporting address, so it is an illustration rather than a production record:
# Name: _dmarc.example.com
# TXT: v=DMARC1; p=none; rua=mailto:dmarc@example.com
Use an actual reporting mailbox or processing service you control. If reports go to a different domain, the external reporting destination may need to publish authorization. Follow the reporting service's exact instructions. Ensure the mailbox can handle compressed XML reports and that access is limited to people who need the data.
Interpret aggregate reports cautiously
Aggregate reports summarize authentication observations from participating receivers. They can show source IPs, counts, policy handling and evaluated domains. They do not represent every recipient or every message, and they do not provide a complete inbox-placement report. Absence from a report does not prove a sending stream is inactive.
Classify reported sources using your sender inventory and provider evidence. Do not authorize an unknown IP merely because it appears in a report; it could be spoofing, forwarding or an infrastructure change that needs verification. Investigate unexpected sources with the service owner. Remove personal details when sharing examples publicly.
Repair legitimate alignment failures
DMARC can pass through aligned SPF or aligned DKIM. Prioritize signing with a domain aligned to your From address, particularly for mail paths that can be forwarded. Check whether provider-managed DKIM is actually enabled and whether the selector resolves. For supported custom envelope domains, verify their setup as well.
Test mailing lists, forwarding and message modification separately. A message that passes at its first destination may behave differently downstream. Strict alignment is an additional constraint; adopt it only if your sending domain design and service capabilities support it. Do not treat relaxed alignment as an error by default.
Move to enforcement when ready
Choose quarantine or reject only after legitimate streams are accounted for, their alignment has been tested and reporting has covered representative activity. Document how subdomains should behave and whether inherited policy matches the services using them. Receivers ultimately choose their handling, so a published request is not an absolute delivery guarantee.
Older rollout recipes use pct=. The current DMARC specification removes that tag and introduces a testing tag, t=. Do not use a percentage value as a reliable throttle. Confirm support in your receiving ecosystem and use representative tests and monitoring before applying enforcement.
Prepare rollback and ongoing review
Save the previous policy and DNS TTL. Define which legitimate failure would trigger rollback and who owns that decision. Reverting the record remains subject to caching, and it cannot recall a message already rejected. Retain observation after enforcement and review new sending services before they go live.
Keep the report access list, retention practice and provider contracts appropriate for your organization. This site does not collect DMARC reports. For individual failures, use the identity guide and delivery evidence checklist before weakening the domain policy.