Quarantine and reject communicate different domain-owner assessments of mail that fails DMARC. Choosing between them requires evidence about the domain's legitimate messages and the consequences if those messages are handled incorrectly.
Treat the decision as a controlled change. Identify which flows can fail, why they fail and what the receiving systems actually do. A more restrictive-looking record is not a substitute for that investigation.
Keep evaluation separate from handling
Under RFC 9989 §5.3.5, DMARC evaluates whether a passing SPF or DKIM identity aligns with the visible From domain. A policy expresses the domain owner's assessment when that validation fails.
Under RFC 9989 §4.7, quarantine classifies failing use as suspicious. Reject expresses the assessment that failing use is invalid. Under RFC 9989 §5.4, receivers retain responsibility for their disposition decisions and can use other information.
Consequently, quarantine does not promise one universal spam-folder result, and reject does not prove that every participating receiver rejected every failure. Confirm the actual receiving evidence for the case under investigation.
Investigate legitimate failures first
For an approved application, compare the visible From domain with the SPF identity and every relevant DKIM signing domain. Establish the supported configuration and test a new message through the same route.
Do not add broad sending permissions simply because a policy change exposed a failure. First determine which account, workflow and identity the business actually authorised.
Forwarding and mailing lists can affect the authentication paths that survive. An indirect failure may require analysis of message changes and receiving behaviour rather than another include in the source domain's SPF record.
Use domain purpose to assess the trade-off
A dedicated transactional identity can have a smaller and more controlled sending population than a staff correspondence domain. Review each accordingly.
RFC 9989 §7.4 cautions against reject for general-purpose email domains and discusses domains whose users post to Internet mailing lists. It sets out observation and comparison guidance for that situation, as well as implications for user participation.
Apply the relevant guidance instead of treating quarantine as a compulsory waiting room on an automatic journey to reject. The policy-selection guide sets out the broader decision record.
Review a concrete failure, not just a global percentage
Consider a synthetic example in which employee messages pass but a monthly invoice system fails alignment. The invoice stream is small enough to barely affect the overall rate.
A stronger requested policy can still have a significant business effect if receivers act on those failures. Identify the invoice service, fix its supported identity and test its actual workflow.
Unknown failing traffic requires a different investigation. Preserve uncertainty until evidence establishes whether it represents legitimate mail, an indirect route, unauthorised use or another cause. Do not count every unknown row as a prevented attack.
Plan the change and its acceptance evidence
Save the current policy and define the proposed scope. Record the services tested, remaining exceptions and conditions that would require escalation or restoration.
After an approved change, verify the authoritative record and representative received messages. Examine report observations with their reporting intervals and policy context. Policy-change reporting is addressed in RFC 9990 §3.3. Current DNS does not reconstruct the policy a receiver saw earlier.
Use separate evidence for authentication, handling and business impact. Under RFC 9990 §3.1.6, a report disposition and any override reason are useful context, but it is not proof of final inbox placement or the outcome of a payment or notification workflow.
Keep the operating process after the decision
Continue monitoring for new applications, changed routes and stale permissions. A valid policy decision can become unsuitable when the organisation changes how it uses the domain.
The meaningful outcome is a documented choice supported by verified legitimate flows, understood limits and a recovery process. For message-level diagnosis, use the alignment guide; for evidence interpretation, use DMARC aggregate reports.
Record the decision and its limits
Suppose, solely as a planning example, 9,900 employee messages pass and 100 invoice messages fail. The total pass rate is 99%, but the invoice route has a 100% failure rate. These invented counts illustrate why the critical route needs repair; they are not campaign measurements or a promised policy outcome.