Going straight to p=reject reveals gaps: it does not fix them
Publishing p=reject does not authenticate a website, invoice system or campaign platform. It asks participating receivers to reject messages that fail DMARC, so forgotten legitimate routes become visible through delivery failures. The safe job is to make those routes pass before relying on enforcement.
RFC 9989 expands domain-owner actions into an operational sequence: publish aligned SPF, configure aligned DKIM, receive aggregate reports, remediate unauthenticated streams and then decide about enforcement. The current DMARC specification provides that deployment model. The reframe is to treat policy as the last control in a sender-ownership project.
Start with authority. Name the DNS owner, mailbox administrator, application owners, change approver and person who can pause each route. If nobody can own a system that sends as your domain, it is not ready for a higher policy.
Map every sender first so enforcement never surprises you
Inventory people and systems that originate mail: staff mailboxes, shared inboxes, finance tools, ecommerce, booking, support, recruitment, marketing, monitoring, devices, website forms and outsourced agencies. Use one row per distinct route, even when several belong to one supplier.
For every row record business purpose, accountable owner, visible From domain, MAIL FROM domain, source service, DKIM d= and selector, current SPF, DKIM and DMARC outcomes, a restricted evidence reference and the date last tested. Add “unknown” rows for unexplained aggregate-report sources instead of deleting them from view.
The NCSC recommends protecting all organisational domains and presents SPF, DKIM and DMARC as connected anti-spoofing controls. The NCSC email security collection describes the UK implementation context. Your inventory should also include domains that appear inactive, because hidden forms and supplier accounts are common change risks.
This map is the difference between a DMARC rollout you sleep through and one that suspends your invoicing. Each of your tools: finance, booking, support, marketing, website forms, scanners: is a separate route with its own visible From domain and envelope identity. Recording them before you touch DNS means the change you publish is based on what your business actually sends, which is the core of moving from p=none towards reject later.
Monitoring works only when reports reach an owner
Publish one syntactically valid DMARC TXT record at the precise _dmarc name. For initial observation, v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com illustrates the shape, but replace the address and validate the record for your domain. A copied destination you do not control is a data leak, not monitoring.
In RFC 9989, monitoring mode means p=none with aggregate reports being received for the organisational domain. Receivers are encouraged but not compelled to report. The specification defines monitoring mode and reporting limits. Confirm that the mailbox accepts compressed XML, has enough capacity and is actually reviewed.
If reports go to an external domain, additional DNS authorisation can be required. Use the report processor’s current setup instructions and verify the public record. Do not add failure-report collection merely because an example includes it; per-message data creates greater privacy and handling risk.
If you take one thing from this guide, make it this: monitoring only helps when the reports reach a real inbox that someone reads. A copied example address or an unmonitored mailbox gives you the illusion of control and none of the benefit. Pair your reporting destination with a practical way to read the reports so the data actually informs each next move.
Make each legitimate route pass on purpose: never hope
For staff mail, verify that the mailbox service signs with an aligned domain and that its envelope path is understood. For a marketing platform, enable its custom domain authentication rather than accepting only a provider-domain signature. For a website or application, send through the production workflow and trace the service that actually connects.
Google tells senders to configure authentication for every sending domain and to verify provider support. Google’s current sender guidelines set out SPF, DKIM and DMARC expectations. Follow each provider’s account-specific record names. Preserve a single SPF record at each owner name, and never overwrite an existing DKIM selector without identifying its signer.
Prefer aligned DKIM where forwarding is likely to alter the SMTP path, while keeping SPF accurate for the envelope domains you operate. One aligned passing path is enough for DMARC, but maintaining both gives evidence and resilience. Record which path each route is intended to use.
The convention to remember is that a single DMARC pass needs only one aligned path: but which path is right varies by route. Where forwarding is likely, aligned DKIM tends to survive better; for direct routes, accurate SPF matters. Keeping a live sender inventory is what lets you record the intended path for every system instead of rediscovering it in an incident.
Read reports as route evidence, not a score
Group aggregate rows by source, header From domain, policy result and authentication domains. Reconcile each group with your inventory. A known provider IP is not automatically authorised for every route, and an unknown IP is not automatically hostile. Shared platforms, migrations and forwarded traffic need context.
Classify observations as authorised pass, authorised fail, unauthorised use, unknown or insufficient evidence. For authorised failures, inspect a controlled message and fix the identity or mechanism. For likely abuse, preserve the observation but do not add the source to SPF. Authorising an attacker to make a dashboard quieter reverses the purpose of the control.
Wait long enough to observe infrequent payroll, renewal and monthly billing routes. A calendar period is not proof of completeness; compare reports with contracts, application owners and business events.
Change one policy value with a rollback ready
Before enforcement, save the authoritative record, public answer, TTL, report coverage and list of accepted uncertainties. Define the affected domain and subdomains. Confirm which policy will be inherited and whether any explicit subdomain record changes the result.
- Approve the window. Choose a quiet period with route owners available and no critical campaign or billing run.
- Publish one intended policy change. Keep reporting destinations and alignment modes stable unless the evidence requires a separate change.
- Query the authoritative and public answers. Record values and UTC times.
- Exercise every critical route. Include the changed domain plus an important unaffected control route.
- Review receiver evidence and business queues. Do not rely only on DNS propagation messages.
RFC 9989 removed the former pct tag, so a new rollout should not be designed around percentage sampling in that tag. Use route readiness, subdomain boundaries, controlled policy changes and receiver evidence instead.
If a critical sender starts failing mid-window, the fastest safe response is rolling back the single policy value you changed and pausing that route. That is exactly the discipline this guide builds around, and it pairs with keeping an eye on blocklist signals for a fuller picture of your sending health.
Policy trade-offs belong in the change record
p=none requests no special handling for DMARC failures and supports observation. p=quarantine asks receivers to treat failures as suspicious, often by placing them away from the inbox. p=reject asks receivers not to accept failing messages. Receiver behaviour remains local, so none is a guaranteed placement command.
Quarantine can look safer than reject, but mail delivered to spam can fail silently in a business process. Reject can produce a visible delivery failure yet has a larger immediate impact on an undiscovered route. Choose based on evidence, support coverage and the cost of both spoofing and false handling.
Do not loosen alignment, remove report destinations and change policy in one edit. Simultaneous changes destroy your ability to attribute the result. If monitoring reveals a critical route you cannot repair promptly, document the accepted delay rather than pretending enforcement is complete.
Control the reports and rollout record from the start
A rollout produces more than DNS text. The working evidence includes the sender map, report files, route classifications, policy approvals, saved records and received test headers. Keep that collection in a controlled project area with named access. The ordinary review sheet can show domains, counts, status and owners without carrying message subjects, complete personal addresses or account-recovery details.
The aggregate-report destination deserves a written data decision before it appears in rua=. Confirm who operates the mailbox or processor, where files are held, who can export them and when they are removed. Counts and source addresses can expose business relationships and sending patterns. Share a filtered pattern with application owners rather than giving every owner the entire report set.
Keep private signing keys, passwords and DNS recovery codes out of the rollout folder. Use references to the approved credential system instead. If report collection or controlled testing would send staff or customer data to an unapproved party, postpone that part of the rollout and ask the data or security owner for an acceptable route.
Gate each policy change with route evidence
Before altering policy, capture the current public DMARC answer and a received message from every critical route. After the one approved edit, query the authoritative name and at least one public resolver, then run those same business actions again. Inspect receiver headers for the expected aligned SPF or DKIM path and watch application queues or support channels for rejects and quarantine symptoms.
A rollout gate passes only when the critical authorised routes retain their intended DMARC result and the report review contains no unexplained legitimate failure that the change would expose. Low-volume billing or payroll routes need an explicit owner decision if they cannot be exercised during the window. Also test a route outside the changed policy scope to catch inheritance or root-record mistakes.
Store the policy proposal, previous value, queries, test headers and report-period decision as one change record. TTLs may delay observation, so mark tests with UTC times. If the new policy reveals an unknown legitimate stream, return it to the sender map and pause progression rather than treating delivery loss as successful enforcement.
Once the routes pass reliably, use proportionate authentication monitoring to maintain the setup without chasing every alert.
Hold the rollout when coverage is not credible
Do not move to quarantine or reject while a critical sender has no owner, an authorised failure remains unexplained, reports are not being reviewed, or the rollback record is incomplete. Stop immediately if invoices, password messages or staff mail begin to fail during the window. Restore the previous policy when the approved rollback conditions are met, and pause the affected application while evidence is preserved.
The change approver should receive the exact policy values, covered domains, known exceptions, report classifications and received tests. DNS and application owners can then work on the route that failed. Avoid changing policy, alignment and report destinations together; that makes the cause impossible to isolate.
Do not authorise suspicious sources, remove reporting or lower protection across unrelated subdomains to keep the timetable. Resume only after the sender map explains the traffic, the responsible owner accepts the route, and the next policy change has a supported verification window.
Sources and further reading
- RFC 9989: Domain-based message authentication, reporting and conformance
- Google email sender guidelines
- NCSC email security and anti-spoofing guidance