DMARC Enforcement Policy Guidance
Choosing a DMARC Enforcement Policy
According to the latest DMARC specification, RFC 9989, organizations should select a DMARC enforcement policy based on how a domain is used and the potential operational impact of failed DMARC validation. p=reject is no longer the recommended default final state for every domain. Instead, apply the policy that best matches the domain's mail flow, user behavior, and authentication maturity.
-
For domains used by human mailbox users or general-purpose email,
p=quarantineis generally the recommended enforcement target. This approach provides meaningful protection against spoofing and reduces the risk of disrupting legitimate indirect mail flows, such as mailing lists, forwarders, aliases, and some third-party delivery paths. -
For transactional, outbound-only, or tightly controlled sending domains,
p=rejectcan still be appropriate, after validating that all legitimate senders pass DMARC with aligned DKIM, SPF, or both.
As a best practice, organizations should separate human mailbox domains from transactional sending subdomains so that each domain can use the most appropriate DMARC policy.
Reviewing Domains That Already Use p=reject
For domains that are already configured with p=reject, an automatic rollback is not recommended. Instead, organizations should review the DMARC aggregate reports, user complaints, mailing-list usage, and third-party sending paths:
-
If the domain is used by human users and there is evidence of legitimate mail disruption, move the domain back to
p=quarantine. -
If the domain is tightly controlled, and the authentication results are clean, keep the domain at
p=reject.
Recommended DMARC Enforcement Policies
| Domain Type | Recommended End State | Rationale |
|---|---|---|
| Human mailbox / general-purpose domain | Usually p=quarantine |
Reduces the risk of disrupting legitimate indirect mail flows, such as mailing lists, forwarders, aliases, and third-party delivery paths. |
| Transactional / outbound-only subdomain | Often p=reject |
Lower risk of user-driven indirect mail flows. Stronger anti-spoofing enforcement is reasonable after all legitimate senders authenticate correctly. |
| Non-sending domain or unused subdomain space | p=reject, often with sp=reject / np=reject where appropriate |
These domains should not be used in the From header, so failed DMARC is a strong indicator of abuse. |
| Mixed-use apex domain | Prefer p=quarantine at the apex, with stricter policies on dedicated sending subdomains |
Avoids applying one aggressive policy to mail streams with different risk profiles and operational requirements. |