none

Emails that fail DMARC are delivered normally. You only receive reports.

quarantine

Failing emails land in the spam folder instead of the inbox.

reject

Failing emails are completely blocked and never delivered.

Start with none to learn who sends email on your behalf without affecting delivery. Move to quarantine once you've reviewed your DMARC reports, then reject for full protection.

Our recommendation

You get a daily summary (XML) showing which servers sent mail using your domain and whether they passed SPF and DKIM. Essential for monitoring.

Our recommendation Always set this. Without it, you're flying blind and won't know if legitimate email is being affected.

You get a DMARC forensic report each time an individual email fails authentication. Useful for debugging specific failures during setup and for investigating attacks.

Our recommendation Set this for debugging. Note that some providers (e.g. Gmail) don't send forensic reports due to privacy policies.

none / quarantine / reject

Same options as the main policy, but only for subdomains (e.g. mail.example.com, news.example.com).

Set this when subdomains need a different policy than the main domain. If you don't set it, subdomains inherit the main domain's policy.

Our recommendation Omit to inherit policy from p= tag unless subdomains send email differently from the main domain.

Apply your full policy to only a portion of failing emails. The remainder is handled one level down. With p=reject the leftover messages are quarantined, and with p=quarantine they're treated as none. For example, p=reject; pct=5 rejects 5%% of failing messages and quarantines the other 95%%.

Our recommendation Omit when at p=none (monitoring). When moving to quarantine or reject, start at 5 and gradually increase.

r - Relaxed (default)

The DKIM signing domain can be a subdomain of the From domain.
e.g. mail.example.com signing for example.com passes.

s - Strict

The DKIM signing domain must exactly match the From domain.
e.g. mail.example.com signing for example.com fails.

Use strict during monitoring (p=none) to see exactly where alignment issues exist without impacting delivery. Switch to relaxed when enforcing if third-party senders need subdomain flexibility.

Our recommendation

r - Relaxed (default)

The Return-Path domain can be a subdomain of the From domain.

s - Strict

The Return-Path domain must exactly match the From domain.

Many email services (e.g. Mailchimp, Zendesk) send from subdomains like bounces.example.com on behalf of example.com. Relaxed accepts this and avoids false failures, while strict would reject it. Only pick strict if every sender uses the exact From domain.

Our recommendation

3600 - Reports requested every hour.

43200 - Reports requested every 12 hours.

86400 - Reports requested once a day (RFC default).

Hourly reports give faster feedback, especially when you're making changes to SPF/DKIM. Once stable, daily is fine. Note: some providers always send daily regardless.

Our recommendation

0 - Report when neither SPF nor DKIM produce an aligned pass (default).

1 - Report whenever any authentication mechanism fails to produce an aligned pass.

d - Report when a DKIM signature fails to validate, regardless of alignment.

s - Report when SPF fails to validate, regardless of alignment.

Combine multiple options with colons, e.g. fo=1:d:s

The default 0 only triggers a report when both SPF and DKIM fail to align, which hides cases where one mechanism is broken. Combining options catches every type of failure separately.

Our recommendation

afrf

Authentication Failure Reporting Format. The only widely supported standard.

This is the only format currently in use. There's no practical reason to change it.

Our recommendation Leave as default. No action needed.