A practical workflow for reviewing senders and planning a policy change
Quick answer: Before enforcing DMARC, document every service that sends mail as your domain, confirm each one has a passing, aligned SPF or DKIM result, and name an approver who can pause or reverse the policy if legitimate mail breaks. Move to p=quarantine before p=reject, and keep that evidence in one place so no one has to guess what changed if something goes wrong.
An IT team should be able to explain which legitimate mail could be affected before it changes a domain’s DMARC policy. That means keeping evidence for the sending services it relies on, investigating unresolved failures, and agreeing on who can stop or reverse the change. The accompanying workbook (template below) provides a place to record that decision.
Palisade’s State of DMARC 2026 found 20,787 domains at p=none among 57,691 domains publishing a valid DMARC record, or 36.0%. The DNS observations were collected on August 13, 2026. They show published policies, not why those organizations chose monitoring or whether their mail would survive enforcement. The other policy counts were 16,367 at p=quarantine and 20,537 at p=reject.
This workflow starts after aggregate reports are arriving. If that part is still unresolved, first establish a reporting destination and confirm that reports reach it. SentrixHub’s earlier article on the reporting gap covers that starting point. Here, the job is to turn the available evidence into a decision someone can approve and maintain.
Give each sending service an owner
Start with a conversation across the business. Ask finance which system sends invoices, support how ticket replies leave the help desk, and whoever runs the website where form confirmations originate. Include password resets, scheduled exports, employee mail, and services used by regional teams. Record the visible From domain for each stream, including subdomains.
Put a named owner beside each service. An entry such as “marketing platform” leaves the next investigator without anyone to contact. A useful row identifies the person who can confirm the account, access its settings, and arrange a representative test. Record the business purpose and the consequence of a missed message as well. A low-volume billing reminder may deserve more attention than a large stream of routine notifications.
Compare this inventory with the sources in aggregate reports. An unfamiliar IP address is an investigation item. Ask the relevant owner or service provider to explain it before changing authentication settings. Keep a separate list of unresolved sources so they do not disappear into an overall success percentage.
✅ Ownership Before Enforcement: Give every known business sender an owner and a testable mail flow before touching DNS. For an unresolved source, record who will investigate and when the team will revisit it — an unowned sender is the one most likely to break silently.
Keep evidence for individual mail flows
Under RFC 9989, DMARC passes when SPF or DKIM passes with an identifier aligned to the visible From domain. Authentication success alone is insufficient. At least one passing mechanism must also align.
For each service, retain a representative message received in a mailbox you control. Record the test time, recipient system, From domain, and relevant authentication results. Use the receiving system’s trusted results, and restrict access to message samples because headers can contain personal or internal information. A screenshot of a provider setting can supplement the test, but the received message shows what that particular flow actually produced.
Repeat the test for meaningfully different paths. A platform’s ordinary notification and its campaign feature may need separate rows if their sending configuration differs. Include relevant forwarding and mailing-list routes in the test plan. Record an untested path explicitly so another person can distinguish missing evidence from a successful check.
For an illustrative example, imagine invoices leave with From: billing@example.com. A received sample shows a passing DKIM signature for example.com. That provides aligned DKIM evidence for this sample. Record the invoice platform, its owner, the sample reference, and the tested route. Do not use that one result to clear password resets sent by a different service. This is a fictional example, not a measured customer deployment.
Choose an observation window around the business
The aggregate-reporting specification describes receiver feedback about authentication and policy handling. Reports are useful evidence, but they are delayed and coverage is incomplete. A quiet report does not establish that every legitimate sender has been observed, and a DMARC pass does not prove inbox placement.
📌 Quiet Reports Aren’t Proof of Coverage: A fixed number of quiet days does not mean every legitimate sender has been observed — an infrequent workflow (a quarterly invoice run, an annual renewal notice) can simply not have fired yet. List those workflows explicitly and give each one a test or a review date rather than assuming silence means safety.
Choose an observation window that includes the business events you need to protect. For a monthly invoice run, either observe that run or arrange an authorized representative test with finance. Write down which route you chose and what remains unobserved. Avoid treating a fixed number of quiet days as sufficient for every organization.
Compare reporting periods consistently. Record their start and end times and which receivers contributed. If a receiver stops reporting, investigate that gap before interpreting a fall in failures as improvement. Separate known legitimate failures from other failures wherever the evidence allows; an overall rate can conceal the small stream that matters most to a department.
Use the worksheet to record an actual decision
In the accompanying evidence workbook (template below), use one row per service and mail flow that needs a distinct decision. Complete the owner, purpose, authentication evidence, and remediation fields together. Link to a ticket or restricted evidence location rather than pasting sensitive message contents into a shared workbook.
A useful remediation note names the problem, the person responsible, and the evidence needed to close it. “Fix email” gives the next reviewer little to work with. “Service owner to configure the signing domain and attach a new received-message sample” describes work that can be checked. If the team accepts an unresolved exception, record its scope and the approver’s reasoning.
Use the policy-decision sheet to collect the domain-wide judgment. If you’re building this evidence base from scratch, our security report template is a reasonable starting point for structuring the paperwork before you touch DNS. Before approving a change, the responsible person should be able to locate the critical-flow tests, understand the remaining uncertainty, and contact whoever will monitor delivery. If those items are missing, record what must be completed before reconsidering the decision.
Select policy for the domain and its users
Enforcement requires attention to how people use the domain. RFC 9989 advises against p=reject for general-purpose email domains, including those whose users may participate in mailing lists. It also removed the legacy pct tag; do not rely on percentage-based rollout instructions as a universal safety control. See the RFC’s interoperability guidance and Appendix A.6.
⚠️ Don’t Enforce on a Date Alone: A stricter policy should follow a completed sender-and-evidence assessment, not a target date on a project plan. Moving to p=quarantine or p=reject before every legitimate flow has been tested is the single most common way this kind of rollout breaks real mail.
Write the proposed policy and its scope into the change record. Review the effect on subdomains and any separately published policies. Where a move to p=quarantine is appropriate, give that change its own approval and observation step before considering anything stricter. Quarantine can still disrupt legitimate mail, so it needs the same care in testing and ownership.
For a domain dedicated to a tightly controlled transactional service, the evidence and policy decision may differ from those for employee correspondence. Document that distinction. A decision to retain monitoring should include the unresolved work and a review date, so the next person knows whether the policy reflects an active investigation or an old, unattended configuration.
Prepare the rollback before changing DNS
Save the existing record and the exact replacement text in the change ticket. Name the person with DNS access and a backup who can act during the change window. Record the DNS TTL and allow for cached answers when planning verification and recovery. Restoring a record cannot recall rejected messages or guarantee immediate recovery everywhere.
Agree on specific triggers for investigation, a pause, or rollback. For example, the team might stop after a confirmed new failure in its invoice flow or after it loses the reporting coverage needed to assess the change. These are proposed operational triggers, not universal thresholds. The approver should choose conditions suited to the business and its available delivery evidence.
✅ Rollback Contact on File: Put the rollback record and the responsible person’s contact details in the change ticket before the work begins. Keep someone available to assess failures while the new policy is being observed — a rollback plan nobody can reach in the moment is not a rollback plan.
After the change, verify the published record and repeat the critical-flow tests. Review sender logs, bounce information, recipient checks, and support reports alongside aggregate feedback. Compare report periods that actually cover the new policy with the earlier baseline. If a problem appears, preserve its timestamps and evidence before making another change so the team can investigate the cause.
Keep the inventory with the policy record after the rollout. When a department adds a sending service, ask its owner to supply the same evidence before it starts using the domain. Review open exceptions on their recorded dates, and use our security checklists if you’d rather work from a shorter, standing list than rebuild this process from scratch each time.
Evidence Workbook Template
Use one row per sending service or distinct mail flow. Copy this structure into your own tracking sheet.
| Domain | Visible From domain | Sending service | Named owner | Business purpose | Observed messages | SPF aligned | DKIM aligned | Test evidence | Forwarding or list issue | Remediation | Status | Evidence URL | Checked at |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
FAQs About Enforcing DMARC
What evidence do I need before enforcing DMARC?
At minimum: a list of every service that sends mail as your domain, a named owner for each one, and a received message sample showing a passing, aligned SPF or DKIM result for each distinct mail flow. Without that, moving to p=quarantine or p=reject is a guess rather than a decision.
How long should I monitor DMARC reports before enforcing?
Long enough to cover the business events you’re protecting, not a fixed number of days. If a sender only runs monthly or quarterly, wait for that cycle or arrange a representative test with its owner — a quiet week of reports says nothing about a sender that hasn’t fired yet.
Is p=quarantine safer than p=reject as a first enforcement step?
Yes. Quarantine routes failing mail to spam rather than blocking it outright, which gives you a recovery window if a legitimate sender turns out to be missed. RFC 9989 explicitly advises against jumping straight to p=reject on general-purpose domains, especially ones with mailing-list traffic.
What happens to legitimate mail if I skip the evidence-gathering step?
The most common failure is a real business sender — an invoicing platform, a forwarding rule, a mailing list — getting quarantined or rejected because nobody tested its authentication alignment beforehand. That’s exactly what the ownership inventory and mail-flow evidence in this workflow are meant to catch before DNS changes.
Can I roll back a DMARC policy after enforcing it?
You can revert the DNS record, but that doesn’t recall messages already rejected or quarantined elsewhere, and cached DNS answers mean some receivers will keep applying the old policy for a while. That’s why the rollback record, TTL, and a reachable responsible person need to be in place before the change goes live, not after.
Abdul Shakoor writes practical, defensive cybersecurity and networking guides for SentrixHub. He focuses on making API security, mobile app security, authentication, and network concepts simple for beginners and developers.