You've set up your DMARC record, reports are coming in, but you don't know why p=none doesn't stop any email or why with p=reject your site's contact form suddenly stops sending email. The problem is almost always in the value of a single tag, not the whole record. This is a short reference for each tag: the allowed value, the real effect, and the combination you can move to without breaking email.
A DMARC record is a TXT record on _dmarc.example.com and starts with v=DMARC1. The order of tags doesn't matter, but v must be first. If you're checking with dig:
dig +short TXT _dmarc.example.com
"v=DMARC1; p=none; rua=mailto:dmarc@example.com; fo=1"If the output is empty, the record doesn't exist or was registered under the wrong name. A common mistake is registering it on example.com instead of _dmarc.example.com, which no tool will see.
The p tag: the policy that's actually enforced
It has three allowed values: none, quarantine, reject. This tag determines what the receiver does with an email where both SPF and DKIM have failed. none means just report and do nothing; quarantine means send it to spam; reject means don't deliver it at all.
A point that's rarely mentioned: DMARC only enforces the policy when both mechanisms fail. If SPF passes, even with DKIM failing, the message goes through. So p=reject isn't as dangerous as it's made out to be, provided SPF is correct.
The practical migration order: stay on p=none for two to four weeks, read the reports, solidify the authorized sources in SPF and DKIM, then p=quarantine and finally p=reject. If you want to know why emails go to spam, the complete guide to fixing spam issues opens up exactly this chain.
The rua and ruf tags: where reports go
rua is the aggregate report address (daily XML) and ruf is the forensic report (samples of failed messages). Both start with mailto: and are separated by commas. A practical limitation: many large receivers, including Gmail, don't send ruf reports. If you rely only on ruf, your inbox stays empty and you think the record isn't working.
Don't underestimate the volume of rua reports. For a domain with a few thousand emails a day, the daily XML file reaches several megabytes, and if you put the address on a personal inbox, the mailbox quota fills up within days. Email quota management explains what happens when the mailbox fills up and how to prevent it. The right way is a dedicated mailbox or a DMARC analytics service.
This is where they go wrong
They put the rua address on the same domain that DMARC is configured for, without making sure that mailbox exists. The result: reports are silently discarded, and no error is ever seen. The sign is that you wait weeks for a report and it never arrives, while the record is perfectly valid.
The pct, fo, and rf tags
pct is the percentage of messages the policy is applied to; the allowed value is 0 to 100. The default is 100. If you set pct=25, only a quarter of failed emails are treated according to the policy. This tag was made for gradual migration, but in practice it causes more confusion than security. My recommendation: don't use pct, and instead go directly from p=none to p=reject.
fo determines under what conditions a forensic report is sent: 0 (both fail), 1 (either fails), d (DKIM fails), s (SPF fails). The value 1 gives the most reports and is useful for troubleshooting. rf is the report format, and today only afrf is meaningful; setting it is optional.
The adkim and aspf tags: strict mode
Both take the value r (relaxed, the default) or s (strict). adkim is for DKIM and aspf is for SPF. The difference is in domain alignment: in relaxed mode, subdomains are also accepted; in strict mode, only the exact domain.
| Tag | Allowed value | Default | Practical effect |
|---|---|---|---|
v | DMARC1 | Required | Record version; must be first |
p | none / quarantine / reject | — | Policy for the main domain |
sp | Same values as p | Equal to p | Separate policy for subdomains |
rua | List of mailto: | — | Daily aggregate report |
ruf | List of mailto: | — | Forensic report; limited support |
pct | 0–100 | 100 | Percentage of policy enforcement |
adkim | r / s | r | DKIM alignment |
aspf | r / s | r | SPF alignment |
fo | 0 / 1 / d / s | 0 | Condition for sending forensic reports |
Choose strict mode only when you have full control over all sending sources. If you use a transactional email service that sends from a subdomain, aspf=s will reject your emails for no reason. The transactional email guide explains why sending from shared hosting is problematic and what the right alternative is.
The sp tag and subdomain management
If you don't set sp, the value of p is also applied to subdomains. This default is a disaster in many organizations: a subdomain that never sends email suddenly faces p=reject, and if anyone sends from it, it's silently rejected.
You have two options. Either set sp=quarantine so subdomains are treated more leniently, or set a separate record with p=reject for unused subdomains. The second way is safer and prevents spoofing from forgotten subdomains.
The combination that's safe to start with
If you want to set the record today and not regret it tomorrow, register this line on _dmarc.example.com:
v=DMARC1; p=none; rua=mailto:dmarc@example.com; fo=1; adkim=r; aspf=rRead the reports for two weeks. Any source that appears as fail in the reports must either be added to SPF or get DKIM properly. Then change p to quarantine and finally reject. The whole path usually takes a month, and if you rush, the site's contact form or the password reset email is the first casualty.
One note about tools: before any change, check the MX and SPF records with the MX record lookup to make sure sending is happening from the right place. If you're on shared hosting and don't have full control over records, Linux hosting with full DNS access is what makes this path simple. More technical documentation is also available in the ServerNet knowledge base.
If after p=reject you notice that some internal emails are being rejected, check SPF first, not DMARC. In ninety-nine out of a hundred cases, that's where the problem is.
Frequently asked questions
What's the difference between p and sp in a DMARC record?
p determines the policy for the main domain and sp determines the policy for subdomains. If you don't set sp, the value of p is automatically applied to subdomains too, which in many cases is unwanted.
Does pct=50 halve security?
Yes, that's exactly what it does. With pct=50, only half of failed emails are treated according to the policy and the rest go through. It was made for gradual migration, but in practice it isn't recommended; it's better to go directly from none to reject.
Why aren't rua reports arriving?
Three common reasons: the mailbox address doesn't exist, the record was registered under the wrong name, or the receiver doesn't send aggregate reports. First confirm the record exists with dig +short TXT _dmarc.example.com, then confirm the destination mailbox exists.
Does DMARC replace SPF and DKIM?
No. DMARC rides on top of SPF and DKIM and does nothing without them. If SPF isn't set up correctly, p=reject will only reject your own legitimate emails too.