Skip to content

DMARC (Domain-based Message Authentication, Reporting, and Conformance) lets you tell receiving mail servers what to do when messages claiming to be from your domain fail SPF and DKIM checks. It also provides a reporting mechanism so you can monitor authentication results before enforcing a policy.

Start with p=none to collect reports without affecting mail delivery. Only advance to quarantine or reject after confirming all legitimate sending sources pass authentication. Deploying an enforcement policy without monitoring risks blocking legitimate mail from third-party services (marketing platforms, CRMs, ticketing systems).

💡 How policies work
What each policy does:
  • none — No action taken on failing mail. You receive aggregate reports showing who is sending as your domain and whether they pass authentication. Use this to identify all legitimate sending sources before enforcing.
  • quarantine — Mail failing both SPF and DKIM alignment is delivered to the recipient's spam/junk folder. Some receivers apply additional scoring rather than a hard spam classification.
  • reject — Mail failing both SPF and DKIM alignment is refused at the SMTP level. The sending server receives a 5xx bounce. The recipient never sees the message.
Policy only applies to messages that fail both SPF alignment and DKIM alignment. A message passing either one is delivered normally regardless of policy.

RFC 7489 §6.3 recommends deploying in stages: none → quarantine → reject.What each policy does:
  • none — No action taken on failing mail. You receive aggregate reports showing who is sending as your domain and whether they pass authentication. Use this to identify all legitimate sending sources before enforcing.
  • quarantine — Mail failing both SPF and DKIM alignment is delivered to the recipient's spam/junk folder. Some receivers apply additional scoring rather than a hard spam classification.
  • reject — Mail failing both SPF and DKIM alignment is refused at the SMTP level. The sending server receives a 5xx bounce. The recipient never sees the message.
Policy only applies to messages that fail both SPF alignment and DKIM alignment. A message passing either one is delivered normally regardless of policy.

RFC 7489 §6.3 recommends deploying in stages: none → quarantine → reject.
💡 Subdomain policy explained
The subdomain policy applies to mail from subdomains (e.g., mail.example.com, marketing.example.com) when those subdomains do not have their own _dmarc record.

If omitted, subdomains inherit the parent domain's policy.

Common patterns:
  • sp=reject on domains that never send mail from subdomains — prevents subdomain spoofing
  • sp=none when subdomains have independent mail infrastructure that hasn't been aligned yet
  • Omit sp when subdomains should follow the same policy as the parent


If omitted, subdomains inherit the parent domain's policy.

Common patterns:
  • sp=reject on domains that never send mail from subdomains — prevents subdomain spoofing
  • sp=none when subdomains have independent mail infrastructure that hasn't been aligned yet
  • Omit sp when subdomains should follow the same policy as the parent
Percentage of messages to apply policy to. Use <100 during rollout.
💡 How percentage works
pct controls what percentage of messages failing authentication have the policy applied. The remaining messages are treated as if the policy were none (delivered normally, still reported).

Recommended rollout when moving to quarantine or reject:
  1. Set pct=10, monitor reports for 1-2 weeks
  2. Increase to 25%, then 50%, monitoring at each stage
  3. Set pct=100 once you confirm no legitimate mail is affected
⚠️ pct is a temporary rollout mechanism, not a permanent safety net. Leaving pct below 100 permanently means that percentage of spoofed mail always bypasses your policy. Once rollout is complete, set pct=100 or remove the tag entirely (100 is the default).

Note: Receivers are not required to implement pct with mathematical precision (RFC 7489 §6.6.4). Treat it as approximate.pct controls what percentage of messages failing authentication have the policy applied. The remaining messages are treated as if the policy were none (delivered normally, still reported).

Recommended rollout when moving to quarantine or reject:
  1. Set pct=10, monitor reports for 1-2 weeks
  2. Increase to 25%, then 50%, monitoring at each stage
  3. Set pct=100 once you confirm no legitimate mail is affected
⚠️ pct is a temporary rollout mechanism, not a permanent safety net. Leaving pct below 100 permanently means that percentage of spoofed mail always bypasses your policy. Once rollout is complete, set pct=100 or remove the tag entirely (100 is the default).

Note: Receivers are not required to implement pct with mathematical precision (RFC 7489 §6.6.4). Treat it as approximate.
Receives daily XML aggregate reports. Highly recommended.
💡 About aggregate reports
Aggregate reports are XML files sent daily (typically) by receiving mail servers. They contain:
  • Source IP addresses that sent mail claiming your domain
  • Message counts per source
  • SPF and DKIM authentication results per source
  • DMARC alignment and policy-applied disposition
They do not contain message content, subject lines, or recipient addresses.

You can specify multiple recipients: mailto:a@example.com,mailto:b@example.com

Aggregate reports are essential for safe DMARC deployment — they let you identify legitimate senders before enforcing policy.
  • Source IP addresses that sent mail claiming your domain
  • Message counts per source
  • SPF and DKIM authentication results per source
  • DMARC alignment and policy-applied disposition
They do not contain message content, subject lines, or recipient addresses.

You can specify multiple recipients: mailto:a@example.com,mailto:b@example.com

Aggregate reports are essential for safe DMARC deployment — they let you identify legitimate senders before enforcing policy.
Receives per-message failure reports. Optional — may contain PII.
💡 About forensic reports
Forensic reports (also called failure reports) are per-message reports sent when individual messages fail DMARC evaluation. They may contain:
  • Message headers (From, To, Subject, authentication headers)
  • Optionally the full message body
⚠️ Important limitations:
  • Most major providers do not send forensic reports. Gmail, Yahoo, and Microsoft have stopped sending them due to privacy concerns. Do not rely on ruf as your primary feedback mechanism.
  • Reports may contain personally identifiable information (PII) — ensure your receiving address has appropriate access controls.
  • Forensic report generation is controlled by the fo tag.
Use aggregate reports (rua) as your primary monitoring tool. Forensic reports are supplementary and unreliable in practice.
  • Message headers (From, To, Subject, authentication headers)
  • Optionally the full message body
⚠️ Important limitations:
  • Most major providers do not send forensic reports. Gmail, Yahoo, and Microsoft have stopped sending them due to privacy concerns. Do not rely on ruf as your primary feedback mechanism.
  • Reports may contain personally identifiable information (PII) — ensure your receiving address has appropriate access controls.
  • Forensic report generation is controlled by the fo tag.
Use aggregate reports (rua) as your primary monitoring tool. Forensic reports are supplementary and unreliable in practice.
Controls when forensic reports are generated. Only relevant if ruf is configured.
💡 Failure reporting options
fo determines when a forensic report is generated:
  • fo=0 (default): Generate a report only when all underlying authentication mechanisms (SPF and DKIM) fail to produce an aligned pass.
  • fo=1: Generate a report when any mechanism fails to produce an aligned pass. More verbose — useful during initial deployment to catch partial failures.
  • fo=d: Generate a report when DKIM evaluation fails, regardless of alignment result.
  • fo=s: Generate a report when SPF evaluation fails, regardless of alignment result.
The RFC allows combining values with colons (e.g., fo=1:d:s). This generator offers individual values which cover most use cases.

fo is only relevant when ruf is configured. If no forensic report address is set, this tag has no effect.fo determines when a forensic report is generated:
  • fo=0 (default): Generate a report only when all underlying authentication mechanisms (SPF and DKIM) fail to produce an aligned pass.
  • fo=1: Generate a report when any mechanism fails to produce an aligned pass. More verbose — useful during initial deployment to catch partial failures.
  • fo=d: Generate a report when DKIM evaluation fails, regardless of alignment result.
  • fo=s: Generate a report when SPF evaluation fails, regardless of alignment result.
The RFC allows combining values with colons (e.g., fo=1:d:s). This generator offers individual values which cover most use cases.

fo is only relevant when ruf is configured. If no forensic report address is set, this tag has no effect.
💡 Understanding alignment
Alignment determines how strictly the domain in the From header must match the domains authenticated by SPF and DKIM.

Relaxed alignment (default): The organizational domains must match. mail.example.com aligns with example.com because they share the same organizational domain.

Strict alignment: The domains must match exactly. mail.example.com does not align with example.com under strict mode.

When to use strict:
  • When subdomains have independent mail infrastructure and you want to prevent one subdomain from authenticating mail for another
  • When you need to ensure DKIM signatures are domain-specific
When to use relaxed (most deployments):
  • When you use subdomains for sending (marketing.example.com, notifications.example.com) and sign with the parent domain's DKIM key
  • When third-party services send on your behalf using a subdomain


Relaxed alignment (default): The organizational domains must match. mail.example.com aligns with example.com because they share the same organizational domain.

Strict alignment: The domains must match exactly. mail.example.com does not align with example.com under strict mode.

When to use strict:
  • When subdomains have independent mail infrastructure and you want to prevent one subdomain from authenticating mail for another
  • When you need to ensure DKIM signatures are domain-specific
When to use relaxed (most deployments):
  • When you use subdomains for sending (marketing.example.com, notifications.example.com) and sign with the parent domain's DKIM key
  • When third-party services send on your behalf using a subdomain
Recommended DMARC Rollout Strategy
  1. Deploy with p=none and rua configured. Monitor aggregate reports for 2-4 weeks.
  2. Identify all legitimate sending sources in reports. Fix SPF/DKIM alignment for each.
  3. Move to p=quarantine with pct=10. Increase pct gradually (25 → 50 → 100) over 2-4 weeks, monitoring at each stage.
  4. Move to p=reject with pct=10. Increase pct to 100 over 2-4 weeks.

Timeline depends on your mail volume and number of sending sources. High-volume domains with many third-party senders may need longer monitoring periods.

Generated Record

Add this TXT record to your DNS:

Name: _dmarc.example.com

Value:

v=DMARC1; p=none;

What this record does

Deployment Checklist

  1. Copy the generated TXT record above.
  2. Add it to your DNS as a TXT record at _dmarc.{domain}. Set TTL to 3600 (1 hour) or lower during initial testing.
  3. Verify publication by querying DNS: dig TXT _dmarc.{domain}
  4. Wait 24-48 hours for the first aggregate report to arrive at your rua address.
  5. Review reports and confirm all legitimate sending sources pass authentication before advancing policy.