Define the domain, mail flows and decision owner
Identify the visible From domains involved, their business owners and who controls DNS and each sending platform. Include staff mail, website forms, invoicing, newsletters and systems that send only periodically. A source that has not sent during the reporting window may still be important. Record its owner and how it will be tested.
Separate the domain-authentication project from account compromise or delivery troubleshooting. Reject policy does not remove an attacker from an authorized mailbox and does not solve every spam-placement issue. Agree the business impact that would trigger a pause, who can authorize the change and which provider or supplier must be available for a correction.
Require message-based evidence for each legitimate source
For each in-scope source, retain controlled received-message evidence identifying the actual SPF and DKIM identities and the DMARC result. A passing aligned SPF route or a passing aligned DKIM route can satisfy DMARC; both are not universally required. An unaligned pass for a provider domain does not supply the same evidence.
If the provider cannot produce the intended identity or result, determine its supported configuration or an appropriate alternative before enforcement. Keep unresolved sources in a hold list with a responsible owner. Do not add unknown IPs to SPF or accept an unsigned sample as validated just to complete the inventory.
Use aggregate reports as one input, with explicit coverage
Reports can help relate observed sources, authentication outcomes and reporting windows to the sender inventory. Check which receivers and periods are represented and whether reports are missing or duplicated. A report is not a complete census of every business message, and absence of a source is not proof that the business never uses it.
Investigate material unknowns rather than automatically treating every unfamiliar source as legitimate or malicious. Connect reports with actual controlled messages and provider ownership. Forwarding and intermediary behavior may require a separate check. The dedicated report-reading guide explains how to build that triage record without confusing reported handling with inbox placement.
| Area | Evidence to proceed | Reason to hold |
|---|---|---|
| Legitimate sources | Named owner and appropriate controlled message for each material source. | An important periodic or third-party sender remains untested. |
| Authentication | A passing aligned route is confirmed for the intended From identity. | Only a key, record or unrelated-domain pass has been observed. |
| Reporting | Receiver/time coverage and material unknowns are documented. | A quiet or incomplete window is treated as proof of readiness. |
| Change authority | Supported values, owner, acceptance checks and recovery access are agreed. | No authorized person can correct a business interruption. |
| After-change acceptance | Relevant real business routes and evidence will be checked. | Completion is defined only as publishing the record. |
Distinguish current policy guidance from legacy rollout recipes
RFC 9989, published in May 2026, supersedes RFC 7489 and removes the old pct tag. Do not promise that a copied pct value will protect a precise percentage of legitimate traffic during a rollout. The newer standard also includes testing-related semantics, but a tag is not a substitute for source verification and actual provider support.
A monitoring-to-quarantine-to-reject sequence may be a planning choice for a particular environment, not a universal requirement or guarantee. Review the policy scope, applicable subdomain handling and current provider implementation. Agree the intended published values and expected receiver behavior without pretending every receiver applies the same local handling.
Make the approved change and test the affected routes
Preserve the current policy and record the exact approved change, timestamp, owner and rollback condition. Avoid combining it with unrelated hosting or mail migrations unless the dependencies are explicitly planned. Confirm DNS visibility, then send controlled messages through the material business sources and inspect trusted receiver results.
Check the observed business outcome separately from the authentication result. If a legitimate route fails, identify the source and evidence before choosing a supported correction or reversing the policy change. A rollback is not an instant recall of all cached answers or previously handled messages. Keep the business owner informed through the agreed operational channel.
Keep the policy maintainable after enforcement
Document who reviews new sender requests, provider changes, reporting access and material failures. A new newsletter or billing service should enter the same acceptance process before it uses the business domain. Store reporting data appropriately and retain only what supports the operational purpose. A successful project is a maintained boundary, not a one-time dashboard color.
CyberFixCrew is an Israeli cybersecurity company serving businesses worldwide with domain authentication and digital-infrastructure services. Our Israeli technical knowledge supports a scoped implementation and evidence-based handover. We can discuss sender mapping and readiness without promising perfect delivery, total impersonation prevention or a fixed external receiver outcome.
