DMARC Policy Levels Explained

Policy is the action a receiver is asked to take

DMARC publishes a policy for messages that fail DMARC evaluation. The receiver still makes the final delivery decision, and the result depends on SPF or DKIM alignment as well as the provider’s handling.

Policy	Meaning
p=none	Ask receivers to send reports but do not request enforcement
p=quarantine	Ask receivers to treat failing mail with caution, commonly by sending it to spam
p=reject	Ask receivers to reject failing mail

p=none is useful for understanding an existing sending setup. It is not enforcement. p=reject can be appropriate once the known sending services are configured and aligned. Neither policy removes the need to secure mailboxes, review lookalike domains, or communicate with customers clearly.

Inventory senders before increasing enforcement

The risky part of a DMARC change is usually not the record itself. It is the overlooked service that sends mail using your domain. Build an inventory that includes transactional mail, marketing, help desk, returns, internal mail, invoices, and any agency or legacy platform.

For each service, confirm:

• Which visible From domain it uses
• Whether SPF and/or DKIM pass
• Whether the passing identifier aligns with the visible From domain
• Who owns the configuration and where changes are made
• How to send a safe test message

Use message headers and aggregate reports to verify behavior. A generic SPF include from another guide is not a substitute for the sending provider’s current instructions.

Use a controlled progression

Move at the pace the evidence supports:

1. Publish monitoring with an aggregate-report address that someone actually owns.
2. Review reports and test the real mail produced by each approved sender.
3. Correct authentication or alignment failures before asking recipients to quarantine or reject mail.
4. Increase enforcement when the legitimate flow is understood and verified.
5. Keep reviewing after provider, domain, or campaign changes.

The pct tag can be used where suitable to request enforcement for a portion of failing mail. Its behavior is governed by the receiver, so treat it as a gradual operational change, not a schedule you can predict precisely.

Use subdomain policy intentionally

The sp tag lets a domain owner publish a separate requested policy for subdomains. Before applying it, check whether any marketing, support, or transactional service sends from a subdomain. A restrictive subdomain policy is useful only when it does not break legitimate mail.

Troubleshoot by finding the actual sender

If a legitimate message is affected after an enforcement change, collect the full headers, identify the sending service, and check SPF, DKIM, and alignment. Common causes include a platform sending with an unaligned domain, a mailing list that modifies content, a forwarding path, or a sender that was never included in the inventory.

Do not weaken policy permanently to work around an unexamined failure. Fix the sending path or document why an exception is necessary.

How Recon fits

Recon can show policy and authentication signals that may need review. It does not receive, parse, or act on your DMARC reports for you, and it cannot certify that a policy change is safe for every sender.

FAQ

Is p=reject right for every domain?

It is a strong goal for a domain with understood, aligned legitimate senders. The right progression depends on your mail inventory and evidence.

Will p=quarantine send all suspicious mail to spam?

It is a request to receivers, not a universal delivery rule. Test real mail and review the receiving provider’s behavior.

Do we need an aggregate-report mailbox?

If you publish an aggregate-report address, assign an owner and a retention plan. Reports that no one reviews are not useful monitoring.