A reject policy can be a useful part of protecting a sending domain. It cannot establish that every message a person receives is safe, that every receiver will take the same action, or that an authenticated sender is acting honestly.
The practical question is not whether a domain has reached a particular policy label. It is which impersonation route the control addresses and what evidence supports the next decision. A security programme needs that boundary stated plainly before a dashboard percentage becomes a management claim.
Describe the controlled identity
Under RFC 9989 §5.3.5, DMARC evaluates use of the domain in the visible From address against passing, aligned SPF or DKIM evidence. A policy applies to that domain relationship. It does not authenticate a display name, approve a payment request or judge a linked website; RFC 9989 §5.4 makes clear that validated domain use is not a value assertion about a message.
A policy of reject expresses the domain owner's requested assessment for messages that fail validation. The receiver's final handling also depends on its own analysis. RFC 9989 RFC 9989 §7.4 specifically requires receivers to consider more than a published reject policy, particularly where legitimate indirect mail is involved.
These limits do not make the control unimportant. They make its coverage measurable. Use the policy-selection guide to connect the policy to the domain's actual purpose.
Test four different attack stories
The following scenarios are illustrative. They are not customer incidents or measured attack results.
- Scenario: A sender uses an organisation's exact From domain without a passing aligned identity; What the domain evidence can show: DMARC failure can inform handling under the applicable policy; Control still needed: Receiver analysis, monitoring and incident response
- Scenario: A sender uses a different domain with a convincing executive display name; What the domain evidence can show: That different domain may authenticate successfully; Control still needed: Impersonation detection and user reporting
- Scenario: A legitimate account is taken over and sends through an approved route; What the domain evidence can show: The message may have valid aligned authentication; Control still needed: Account security and investigation
- Scenario: A supplier sends an authenticated message requesting a fraudulent bank-account change; What the domain evidence can show: The supplier's domain use may validate; Control still needed: Independent payment-change verification
A single “phishing blocked” number would hide these differences. Label tests by identity, route and expected control. For a safe exercise, use authorised test accounts and synthetic content; there is no need to expose a real recipient to a fraudulent instruction to establish the protocol boundary.
Check legitimate mail before changing policy
A restrictive policy can affect legitimate communication whose authentication is missing or whose identities are misaligned. Inventory each business service, its owner and the account or route that sends it. Add received-message evidence alongside DNS state.
A synthetic readiness matrix could show billing verified, support verified and a quarterly tax notice still awaiting a sending test. The correct release decision is to resolve the critical missing stream, not average it away because billing accounts for most volume.
Treat unknown sources as unresolved until evidence identifies them. A familiar cloud provider does not prove approval, and a failed report row does not prove an attack. A maintained sender inventory gives those investigations somewhere to land.
Account for forwarding and mailing lists
A message may leave its original route through an alias, forwarder or mailing list. Forwarding changes the connecting source seen by the final receiver under RFC 7208 §10.3; changes to covered content can affect DKIM verification under RFC 6376 §3.7. The resulting failure may concern a legitimate message.
Current RFC 9989 §7.4 cautions against reject for general-purpose domains whose users may post to Internet mailing lists. It also requires domains publishing reject to apply valid DKIM signatures rather than relying solely on SPF. A transactional domain and a staff-correspondence domain can therefore need different policy decisions.
A delivered test through one forwarder is evidence for that route and time. It does not establish that every list, receiver or future modification behaves identically. Record both the working route and the uncertainty.
Keep the change record tied to the claim
Before an approved policy change, preserve the previous record, proposed difference, domain scope, owner, evidence reviewed and recovery action. Afterwards, compare the observed legitimate streams, returned errors and available reports. Record actual results rather than assuming that a successful DNS publication proves successful communication.
For a synthetic exercise, the change note might say that a dedicated receipt domain was considered for stronger assessment after its known services and indirect routes were reviewed. It should not say that all phishing was eliminated. The evidence supports a decision about that domain and its documented mail flows.
Report residual risk in useful language
A clear management statement names the domain, monitored population, verified legitimate services, current policy and remaining weaknesses. It keeps spoofed-domain findings separate from account compromise, lookalike domains and transaction fraud.
Useful follow-up actions include removing stale sending permissions, improving account protection, validating sensitive requests through a known independent channel and maintaining a reporting process for suspicious mail. Those actions address different failure paths; their value should not be attributed to the DMARC record alone.
The outcome to aim for is precise: legitimate use of the chosen From domain is understood and maintained, failures are investigated, and the policy fits the domain's use. Keep the remaining fraud scenarios visible so a stronger domain policy does not become a false promise about every message.
Record a decision that can be reviewed
For the four scenarios, keep separate findings for exact-domain failure, a different authenticated domain, account takeover and an authenticated payment-change request. Do not sum them into an unqualified DMARC success claim. The proposed follow-up controls are operational recommendations, not guarantees or DMARC protocol requirements. No incident, attack simulation or policy deployment was performed.