A DMARC record is a single line of text you add to your domain’s public directory (DNS) that tells email providers how to handle messages that fail verification. Each part of the record controls a different setting — here’s a complete guide to what every piece does and when to use it.
What a Complete Record Looks Like
Here’s a DMARC record that uses every available setting:
v=DMARC1; p=quarantine; sp=none; rua=mailto:dmarc@example.com; ruf=mailto:forensic@example.com; adkim=r; aspf=r; pct=100; fo=1; ri=86400; rf=afrf
This record is added to your domain’s settings (DNS) as a TXT record at this specific location:
Don’t worry — most records only need 3–4 of these settings. The rest have sensible defaults. Let’s go through each one.
Required Settings
Every DMARC record must include these two settings:
v=DMARC1 — Version
This tells email providers “this is a DMARC record.” It must be the very first thing in the record — if it’s not, the whole record is ignored.
DMARC1 (there’s only one version)p= — Policy (what to do with fakes)
This is your instruction to email providers: “When someone sends a fake email pretending to be me, here’s what I want you to do with it.”
none |
Deliver it normally — just send me reports so I can see what’s happening. Start here. |
quarantine |
Send it to the spam/junk folder — it’s suspicious. |
reject |
Block it entirely — don’t deliver it at all. Maximum protection. |
See DMARC Policies Explained for a detailed guide on when to use each one.
Reporting Settings
These settings control the reports you receive about who’s sending email as your domain:
rua= — Where to Send Summary Reports
The email address where you want to receive daily summary reports. These reports show you who has been sending email using your domain and whether they passed or failed — like a daily security log.
rua=mailto:dmarc@example.com
You can send to multiple addresses: rua=mailto:a@example.com,mailto:b@example.com
Sending to a different domain? That domain needs to publish a special DNS record to authorise it.
ruf= — Where to Send Detailed Failure Reports
The email address for detailed reports about individual emails that failed. These give more information about specific failures.
rua) are much more useful.
ri= — How Often to Send Reports
How frequently you’d like to receive summary reports, measured in seconds. Note: this is a request, not a guarantee — most providers send daily regardless.
86400 |
Every 24 hours (the default — and what most providers actually do) |
43200 |
Every 12 hours |
3600 |
Every hour (most providers won’t actually do this) |
fo= — When to Send Failure Reports
Controls when the detailed failure reports (from ruf) are generated. Only matters if you’ve set a ruf address.
0 |
Only when both SPF and DKIM fail (default) |
1 |
When either SPF or DKIM fails (recommended if you use this feature — gives you more detail) |
d |
Only when the digital seal (DKIM) fails |
s |
Only when the authorised sender list (SPF) fails |
rf= — Report Format
The format for detailed failure reports. The only option is afrf (Authentication Failure Reporting Format). You can safely leave this out — it makes no practical difference.
Matching (Alignment) Settings
These control how strictly the verified domains need to match the visible “From” address. See DMARC Alignment Explained for the full story.
adkim= — How Strictly DKIM Must Match
Controls whether the digital seal’s (DKIM) signing domain needs to exactly match the “From” address, or just share the same main domain.
r |
Relaxed (default) — The main domain just needs to match. mail.example.com counts as a match for example.com. |
s |
Strict — Must be an exact match. mail.example.com does NOT match example.com. |
💡 Stick with relaxed unless you have a specific reason for strict. Most third-party services sign with a subdomain.
aspf= — How Strictly SPF Must Match
Controls whether the return address (checked by SPF) needs to exactly match the “From” address, or just share the same main domain.
r |
Relaxed (default) — The main domain just needs to match. |
s |
Strict — Must be an exact match. |
Policy Settings
sp= — Subdomain Policy
A separate policy for your subdomains (like mail.example.com or marketing.example.com). If you don’t set this, subdomains automatically use the same policy as your main domain.
none |
Monitor subdomains only (even if the main domain is set to reject) |
quarantine |
Send subdomain failures to spam |
reject |
Block subdomain failures entirely |
💡 Common approach: p=reject; sp=reject — protects both your main domain and all subdomains from impersonation.
pct= — Percentage to Apply the Policy To
What percentage of failing emails your policy actually applies to. The rest are treated as if the policy were p=none (delivered normally). This is your “volume knob” for gradually rolling out protection.
Range: 1–100 (default: 100 — applies to all failing emails)
💡 Use this for safe rollouts: start with pct=10 (only 10% of fakes get quarantined/rejected), then increase to 25, 50, 100 over a few weeks. If something goes wrong, only a small portion of email is affected.
Common Record Examples
🔰 Just starting out (monitoring only)
v=DMARC1; p=none; rua=mailto:dmarc@example.com
The minimum you need. Starts collecting reports so you can see who’s sending as your domain.
⚡ Rolling out protection gradually
v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.com
Sends 25% of failing emails to spam. Watch the reports and increase when you’re confident.
🔒 Fully protected
v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@example.com; adkim=s; aspf=s
Blocks all fakes, protects subdomains too, and uses strict matching for maximum security.
🏢 Larger organisation (full reporting + strict matching)
v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@example.com; ruf=mailto:forensic@example.com; fo=1; adkim=s; aspf=s; ri=43200
Everything turned on: full blocking, subdomain protection, strict matching, detailed failure reports, and twice-daily summary reports.
Build your record
Use our generator to create a DMARC record with all the right settings for your needs.