DMARC policies explained: none, quarantine, and reject

You check your domain and find p=none. A checker calls it a warning. Should you change it to p=reject?

First find out which systems send mail for your domain. Your application may be configured correctly while a billing service or support inbox still sends without alignment. A stricter policy can affect that legitimate mail too.

What DMARC checks

DMARC connects email authentication to the From address a recipient sees. A message passes when at least one of these paths succeeds:

• SPF passes, and its authenticated envelope domain aligns with the visible From domain.
• DKIM passes, and the signing domain aligns with the visible From domain.

An SPF pass for an unrelated provider domain is not enough. Under relaxed alignment, the domains can share an organizational domain; strict alignment requires an exact match. See the DMARC specification for the protocol details.

What the three policies request

p=none requests no DMARC-based change to message handling. It is useful while you collect reports and identify senders.

p=quarantine asks receivers to treat failing messages as suspicious, often placing them in spam.

p=reject asks receivers to refuse messages that fail DMARC.

These are requests to receiving systems, which apply their own policies. None guarantees inbox placement. A message can pass authentication and still be unwanted or filtered.

Start with a record you understand

For an example domain, a monitoring record might look like this:

Name: _dmarc.example.com
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc@example.com

Replace the example domain and reporting address with your own. Arrange to receive and process the aggregate reports; a reporting address that nobody monitors will not help you find problems. Some DNS dashboards expect only _dmarc in the name field because they append the domain themselves.

The rua address requests aggregate reports. It is separate from the inbox where customers send replies. Use a reporting service or a mailbox and parser suited to those reports. If you use an external reporting domain, follow its setup instructions, including any required authorization.

Check every legitimate sender before tightening the policy

Make an inventory: product email, billing, support, newsletters, and any service allowed to send as your domain. For each one, send a test message and inspect its authentication results. Compare that with the aggregate reports over a period that includes your normal sending patterns.

Amazon's SES DMARC guide describes a staged rollout: observe with none, resolve legitimate alignment failures, then move toward quarantine and reject. With SES, aligned DKIM or a correctly configured custom MAIL FROM domain can provide the relevant authentication path.

Do not tighten a policy just to turn a checker green. Fix the source of legitimate failures first. Keep a record of your previous DNS value and check delivery after each change.

Use DNS checks and message checks together

A DNS lookup answers “what policy is published?” A received message answers “did this send authenticate and align?” You need both.

Use Hail's email deliverability checker to inspect SPF, DKIM, DMARC, and MX records. The checker examines DNS; it does not process your aggregate reports or certify inbox placement.

Then send a test email through the API to an inbox you control and inspect the headers. This gives you a concrete message to troubleshoot before you increase volume or change enforcement.