DMARC record syntax explained: every tag, what it does, and what to set it to

Most DMARC guides explain what DMARC does. Far fewer explain the record itself - the actual line of text you publish in DNS, tag by tag. That gap matters, because a DMARC record is small, unforgiving, and easy to get subtly wrong. A misplaced value can leave you in monitoring mode for years, or send your forensic reports to nobody.

This post is a reference. It covers every tag defined in RFC 7489, what each one does, what to set it to, and the mistakes we see most often. If you want the concepts first, read What is DMARC? A plain-English guide before this one.

Where the record lives

A DMARC record is a TXT record published at a specific hostname: _dmarc.yourdomain.co.uk. Not at the root of the domain, and not anywhere else. The value is a single string made up of tags separated by semicolons.

A complete example looks like this:

v=DMARC1; p=quarantine; rua=mailto:[email protected]; ruf=mailto:[email protected]; sp=quarantine; adkim=s; aspf=s; pct=100; fo=1; ri=86400

Only two tags are mandatory: v and p. Everything else is optional and falls back to a default if you leave it out. The rest of this post works through each tag in turn.

v - version

This must always be the first tag, and its only valid value is DMARC1. If it is missing, misspelled, or not first, the entire record is ignored. Receivers will treat the domain as having no DMARC policy at all.

Set it to: v=DMARC1. There is no other option.

p - policy

This is the instruction to receiving mail servers about what to do with email that fails DMARC checks. It has three possible values:

• p=none - take no action. The mail is delivered as normal and you simply receive reports. This is monitoring mode.
• p=quarantine - treat failing mail as suspicious, usually delivering it to the spam or junk folder.
• p=reject - refuse failing mail outright. It is never delivered.

The important thing to understand is that p=none provides no protection. It tells the world your domain can be spoofed and nothing will happen. We cover this in detail in Why DMARC p=none is not protecting you. The goal is to reach p=reject safely, which we describe in Getting to DMARC p=reject: the safe route to enforcement.

Set it to: none while you assess your legitimate senders, then quarantine, then reject once your reports are clean.

sp - subdomain policy

This sets a separate policy for subdomains of your domain. If you do not include it, subdomains inherit the policy in the p tag.

This tag matters more than people expect. If your main domain is at p=reject but you omit sp, every subdomain also defaults to reject - which is usually what you want. But if you set sp=none while testing, you leave every subdomain open to spoofing, including ones you forgot you had.

Set it to: match your main policy in most cases. Only relax it deliberately and temporarily while onboarding a known subdomain sender.

rua - aggregate report address

This is where aggregate (RUA) reports are sent. These are the daily XML summaries that tell you who is sending email as your domain and whether it passed authentication. Without this tag, you get no visibility at all, which defeats the purpose of deploying DMARC.

The value is one or more mailto: addresses, comma-separated. To understand what these reports contain, see What does a DMARC report actually show?

Set it to: an address that is monitored and parsed. Raw XML is hard to read by hand, which is why most organisations send reports to a processing service rather than a person.

Cross-domain reporting and the external check

If your rua address is on a different domain to the one publishing the record, the receiving domain must publish an authorisation record confirming it agrees to receive your reports. This is a common reason reports silently stop arriving. Same-domain addresses do not need this.

ruf - forensic report address

This sets where forensic (RUF) reports go. These are individual copies, or partial copies, of messages that failed DMARC. In theory they are useful for investigating specific incidents.

In practice, very few receivers send RUF reports at all, largely because of privacy concerns - a forensic report can contain personal data from a real email. Do not rely on them. If you do publish the tag, treat the destination mailbox as sensitive.

Set it to: usually leave it out. If you include it, point it at a controlled, access-restricted mailbox.

pct - percentage

This applies your policy to a percentage of failing mail, from 1 to 100. So pct=25 at p=quarantine means a quarter of failing mail is quarantined and the rest is delivered normally.

It was designed as a phased rollout tool, letting you apply enforcement to a small slice first. In modern practice it is used less than it once was, because aggregate reports already let you assess impact before you change the policy. If you use it, remember to return it to 100 - a policy stuck at a low percentage is barely enforcing at all.

Set it to: 100, or omit it (100 is the default).

adkim - DKIM alignment

This controls how strictly the DKIM signing domain must match your From address. There are two values:

• adkim=r - relaxed. The organisational domain must match, so a signature from mail.example.co.uk aligns with example.co.uk. This is the default.
• adkim=s - strict. The signing domain must match exactly.

Set it to: relaxed for most organisations. Strict is only worth it if you control every signing domain precisely and want the tightest possible posture.

aspf - SPF alignment

This is the SPF equivalent of adkim, with the same r and s values and the same meaning. Relaxed allows subdomain alignment with the organisational domain; strict requires an exact match.

Set it to: relaxed unless you have a specific reason to tighten it.

fo - failure reporting options

This controls when forensic reports are generated. It only has an effect if you have also set ruf. The values are:

• fo=0 - report only if both SPF and DKIM fail. This is the default.
• fo=1 - report if either SPF or DKIM fails. The most useful option.
• fo=d - report on any DKIM failure.
• fo=s - report on any SPF failure.

Set it to: 1 if you are using forensic reports at all. Otherwise it is irrelevant.

ri - reporting interval

This requests how often, in seconds, you would like aggregate reports. The default is 86400, which is 24 hours. In practice almost all receivers send daily reports regardless of what you ask for, so this tag rarely changes anything.

Set it to: 86400, or omit it.

Common mistakes

The same handful of errors account for most broken DMARC records:

• Two DMARC records on one domain. If _dmarc returns more than one TXT record starting with v=DMARC1, the policy is ambiguous and receivers ignore all of them. Only one is permitted.
• Stuck at p=none. Publishing a record and never moving past monitoring is the most common failure of all. It looks like progress but offers no protection.
• A forgotten sp tag. Leaving subdomains exposed while the main domain is locked down, or vice versa.
• Unmonitored rua addresses. Reports arriving as raw XML in a mailbox nobody reads. The data is there but nobody acts on it.
• Missing external authorisation. Cross-domain report addresses that were never authorised by the receiving domain, so reports silently never arrive.
• Syntax errors. A missing semicolon, a space in the wrong place, or v not appearing first. The record fails as a whole.

A sensible starting record

For an organisation beginning its rollout, this is a reasonable first record:

v=DMARC1; p=none; rua=mailto:[email protected]; sp=none; fo=1

This puts you in monitoring mode, sends aggregate reports somewhere you can analyse them, and keeps subdomains in monitoring too while you build a full picture. Once the reports show your legitimate senders are aligned, you tighten p and sp to quarantine and then reject. The NCSC's email security guidance describes the same staged approach.

The DMARC record is one line of text, but every tag in it changes what receivers do with mail claiming to be from you. Understanding each one is the difference between a record that protects your domain and a record that simply describes how it can be abused. Get the syntax right, get to enforcement, and keep reading the reports.