Moving to an enforcement policy is an important domain-control decision, not the end of email fraud. Report the achieved boundary precisely: the domain requests stronger treatment of messages that fail DMARC. Then explain the threats that can still authenticate or fall outside that identity boundary, together with the operational work needed to keep legitimate mail functioning.
State the protection without a guarantee
DMARC combines aligned domain authentication with a published handling preference and reporting framework. The receiver's actual handling can involve local policy. Do not promise that every failing message is rejected everywhere or that a pass means the message is safe. RFC 9989.
Lookalike-domain messages, display-name impersonation and compromised legitimate senders can remain dangerous after enforcement. An authenticated supplier can still send an unauthorized payment request. SPF authorization that is broader than intended can also leave an aligned passing route available. These are reasons to maintain complementary controls, not reasons to abandon domain authentication.
Check legitimate routes before the change
Maintain a sender-by-sender matrix with the service, accountable owner, author domain, authenticated domains, alignment evidence, critical recipients and last tested date. Include low-volume systems such as scanners and alerts. A quiet route is not necessarily unused. Resolve unknown senders before treating the inventory as complete.
Document the proposed policy diff and who approves it. A change from p=none to p=reject is an example, not a value to publish blindly. Review the applicable domains and dependencies, plan the observation window and define recovery triggers for important legitimate failures. Use generated service-specific values rather than this article's demonstration identities.
Examine a written readiness ledger
For the proposed p=none to p=reject change below, assume a single valid visible From per message and stipulated receiver authentication evidence. No actual change or receiver test is performed.
- Billing: proposed owner Billing Operations; From invoice@billing.brand.test; SPF pass for bounce@billing.brand.test; DKIM pass with d=billing.brand.test. Both identifiers align exactly, so the hypothetical message passes. Real critical-recipient tests and change approval remain not supplied.
- Support: proposed owner Support Operations; From agent@support.brand.test; SPF pass for bounce@support.brand.test; DKIM pass with d=support.brand.test. Both align exactly, so the hypothetical message passes. Real critical-recipient tests and change approval remain not supplied.
- Legacy scanner: owner unconfirmed; From, SPF, DKIM and recipient coverage unknown. No message verdict can be inferred. Assign an accountable owner and obtain route evidence before declaring readiness.
Overall rollout readiness is not established. Even the two stipulated passes are not observed production evidence. The proposed change owner should keep the change on hold until unknowns, approvals, recovery triggers and route checks are resolved. No code, DNS query or signature verification was executed for this ledger.
RFC9989 section7.4 requires valid DKIM signatures when publishing p=reject and advises against reject for domains whose users might post to mailing lists. Those domains should first assess aggregate data with p=none for at least a month, then p=quarantine for an equally long period. Choose the policy with those interoperability constraints in view; a clean direct-send example does not settle indirect-mail risk.
Verify behavior after an approved rollout
In a real change, capture the published policy, time, approved diff and tests for each critical route. Compare trusted receiver results and actual handling, and review available aggregate reporting with its coverage limits. Missing reports are not proof that no mail was sent or that no failure occurred. RFC 9990. Investigate legitimate exceptions by route instead of broadly weakening protection without an owner.
Explain remaining fraud risk in the same business terms used before enforcement. Payment changes still require independent verification; account compromise still requires account-security response; lookalikes require detection and appropriately scoped reporting. The FBI's payment-verification guidance remains relevant even when the domain authenticates. FBI guidance.
A sound completion statement names the policy observed, routes tested, unresolved exceptions and residual controls. It should not say phishing is solved. Keep ownership and periodic review active as services, keys and business processes change.