In short
A DMARC record is one TXT record at _dmarc.yourdomain that starts v=DMARC1 and sets a policy (p), report addresses (rua and ruf) and optional tags such as sp, np, adkim, aspf, fo and t. RFC 9989 made pct historic in May 2026, and the NCSC says every domain, parked ones included, should have a DMARC record.
Want help with DMARC record review?
We can plan it with you or do it for you. Tell us where you are up to.
Where the DMARC record lives: the _dmarc host name
A DMARC record is a DNS TXT record published at the name you get by putting _dmarc in front of your domain. RFC 9989 section 4.5 (opens in a new tab) gives the example: the owner of example.com publishes at "_dmarc.example.com", and a receiver checking mail from example.com "would issue a TXT query to the DNS for the name _dmarc.example.com".
The leading underscore marks _dmarc as a special-purpose name rather than a real host, so it cannot clash with a website or mail server. _dmarc is registered for TXT records in IANA's "Underscored and Globally Scoped DNS Node Names" registry (RFC 9989 section 9.5 (opens in a new tab)).
In most DNS panels you enter just _dmarc as the host name, because the panel adds your domain for you; if yours wants the full name, enter _dmarc.example.co.uk. The record type is TXT, unless a platform's managed set-up asks for a CNAME. The field-by-field steps, with guides for 123 Reg and one.com, are in how to set up DMARC.
For a subdomain such as news.example.co.uk the name is _dmarc.news.example.co.uk. Long values can be split into several quoted strings; RFC 9989 says receivers "MUST concatenate these strings" and read them as one. Our DMARC checker reads the record exactly as a receiver does.
DMARC tags: the full reference
DMARC records use tag=value pairs separated by semicolons, the same syntax as DKIM (opens in a new tab) keys. This table follows the tag list in RFC 9989 section 4.7 (opens in a new tab). Only v is required, and v must come first.
| Tag | What it does | Values | Default if left out |
|---|---|---|---|
| v | Identifies the record as DMARC. Must be the first tag | DMARC1 (case sensitive) | Required: without it the whole record is ignored |
| p | Policy for mail using this domain that fails DMARC | none, quarantine, reject | Treated as none |
| sp | Policy for existing subdomains of the organisational domain | none, quarantine, reject | Inherits p |
| np | Policy for subdomains that do not exist in DNS (new in RFC 9989) | none, quarantine, reject | Inherits sp, or p if there is no sp |
| rua | Where to send aggregate reports: a comma-separated list of URIs | mailto:address (receivers must support mailto) | No aggregate reports are sent |
| ruf | Where to send failure reports about individual messages | mailto:address | No failure reports are sent |
| adkim | DKIM alignment mode | r (relaxed) or s (strict) | r |
| aspf | SPF alignment mode | r (relaxed) or s (strict) | r |
| fo | When failure reports should be generated. Ignored unless ruf is present | 0, 1, d, s (colon-separated, e.g. fo=0:d) | 0 |
| t | Test mode: apply one policy level below the one stated (new in RFC 9989) | y or n | n |
| psd | Public suffix domain flag, for registries and similar operators | y, n, u | u |
| pct | Historic. Applied the policy to a percentage of mail (RFC 7489) | 0 to 100 | No longer processed |
| rf, ri | Historic. Failure report format and aggregate report interval | Not applicable | No longer processed |
The fo tag in detail
The DMARC fo tag only matters if you publish a ruf address. fo=0 asks for a failure report when every mechanism fails to produce an aligned pass; fo=1 asks for one when any mechanism fails; d asks for a report on any failed DKIM signature and s on any SPF failure, whatever the alignment. RFC 9989 (opens in a new tab) adds that report generators "may choose to adhere to the requested options", and RFC 9991 (opens in a new tab) warns that failure reports can contain message headers or content, including personal data. Some large providers send none: Microsoft, for example, says (opens in a new tab) Outlook.com sends aggregate reports but has no plans to send RUF.
Not sure which option applies to you? Ask us
Tell us about your organisation and we will point you to the right option.
DMARC alignment: strict vs relaxed
Alignment is what makes DMARC more than SPF or DKIM alone. A message passes DMARC only if the domain that passed SPF, or the domain that signed with DKIM, aligns with the domain in the From address. RFC 9989 section 4.4 (opens in a new tab) defines two modes:
- Relaxed (r, the default): the two domains share the same organisational domain, so mail.example.co.uk aligns with example.co.uk
- Strict (s): the two domains must be identical, so only example.co.uk aligns with example.co.uk
| From address domain | SPF (Mail From) or DKIM (d=) domain | Relaxed (adkim=r, aspf=r) | Strict (adkim=s, aspf=s) |
|---|---|---|---|
| example.co.uk | example.co.uk | Aligned | Aligned |
| example.co.uk | mail.example.co.uk | Aligned | Not aligned |
| news.example.co.uk | example.co.uk | Aligned | Not aligned |
| example.co.uk | sendingservice.example.net | Not aligned | Not aligned |
The last row is the common real-world failure: a marketing or CRM platform sends with its own bounce domain and its own DKIM signature, so both checks pass for the platform but neither aligns with you. The fix is a custom bounce domain or DKIM signing with your own domain, set up in the platform. RFC 9989 notes that "nearly all Domain Owners have found relaxed alignment sufficient", so strict mode is worth using only where you control every sender on that domain.
DMARC for subdomains and parked domains
A record at your organisational domain also covers its subdomains, unless a subdomain publishes its own record. Three tags decide what applies:
| Mail claims to come from | Policy applied |
|---|---|
| example.co.uk itself | p |
| An existing subdomain, e.g. invoices.example.co.uk, with no record of its own | sp if present, otherwise p |
| A subdomain that does not exist in DNS, e.g. random123.example.co.uk | np if present, otherwise sp, otherwise p |
| A subdomain that publishes its own _dmarc record | That record's p (sp in a subdomain's record is ignored) |
Subdomains do not need their own record, but giving a busy sending subdomain one lets you move it to enforcement on its own timetable. gov.uk's set-up guidance (opens in a new tab) suggests "using a separate subdomain for third party email services to simplify SPF and DKIM implementation".
Parked and non-sending domains need records too. The NCSC (opens in a new tab) says "all of your domains, including parked domains, should have DMARC records in place, regardless of whether the domain is used for email or not". A domain that sends no mail can usually go straight to a strict record such as v=DMARC1; p=reject; sp=reject; np=reject, with a rua address if you want to see spoofing attempts.
Prefer a hand with this?
We can help you plan it and set it up, alongside your own team.
DMARC record examples you can copy
These example DMARC TXT records use RFC 9989 syntax. Replace example.co.uk and the addresses with your own, and publish each at _dmarc on the domain shown. The first is the basic DMARC record from RFC 9989 appendix B.2.1 (opens in a new tab).
| Purpose | Example DMARC record |
|---|---|
| Basic monitoring record (start here) | v=DMARC1; p=none; rua=mailto:dmarc-feedback@example.co.uk |
| Monitoring plus failure reports | v=DMARC1; p=none; rua=mailto:dmarc-feedback@example.co.uk; ruf=mailto:auth-reports@example.co.uk; fo=1 |
| Reports to two places (your mailbox and a platform) | v=DMARC1; p=none; rua=mailto:dmarc@example.co.uk,mailto:reports@platform.example.net |
| Testing quarantine (receivers following RFC 9989 treat it as none while t=y) | v=DMARC1; p=quarantine; t=y; rua=mailto:dmarc@example.co.uk |
| Quarantine | v=DMARC1; p=quarantine; rua=mailto:dmarc@example.co.uk |
| Reject, with a softer policy for subdomains | v=DMARC1; p=reject; sp=quarantine; rua=mailto:dmarc@example.co.uk |
| Parked or non-sending domain | v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:dmarc@example.co.uk |
| Strict alignment on a dedicated sending subdomain | v=DMARC1; p=reject; adkim=s; aspf=s; rua=mailto:dmarc@example.co.uk |
A note on t=y and pct. Receivers that have not yet adopted RFC 9989 ignore t and apply your stated policy in full, so only publish quarantine or reject once the reports show your senders passing. If your record has pct below 100, removing it applies the full policy everywhere, so step p down a level first rather than just deleting pct.
Sending reports to another domain. If rua points outside your own organisational domain, for example to a monitoring platform, RFC 9990 section 4 (opens in a new tab) requires receivers to check that the destination agrees to take them: for reports about example.co.uk sent to reports.example.net, they look for a TXT record starting v=DMARC1 at example.co.uk._report._dmarc.reports.example.net. DMARC platforms publish this for their customers' domains.
Our DMARC record generator builds a valid record from your choices, and the DMARC policy guide explains when to move from one example to the next.
Common DMARC record mistakes
Most broken DMARC records fail in one of a handful of ways. RFC 9989 is strict about several of them, so a small typo can mean receivers ignore the record completely.
| Mistake | What happens | Fix |
|---|---|---|
| Two DMARC records on the same name | Receivers discard both: "If multiple DMARC Policy Records are returned for a single target, they are all discarded" (RFC 9989 4.10.1 (opens in a new tab)) | Merge them into one record |
| v=DMARC1 not first, misspelt or missing | The whole record is ignored | Start the record with v=DMARC1; |
| rua=dmarc@example.co.uk without mailto: | The value is not a valid reporting URI, so you may get no reports | Write rua=mailto:dmarc@example.co.uk |
| pct still in the record | Receivers following RFC 9989 no longer act on it | Remove pct once your senders pass at the current p; if pct was below 100, lower p a step first |
| fo set without a ruf address | fo is ignored | Add ruf or remove fo |
| Record published at the domain itself, not at _dmarc | Receivers do not find it | Move it to the _dmarc host name |
| Report mailbox filtered as spam or full | Reports are lost | Use a dedicated address or a monitoring platform |
| p=reject before every sender is aligned | Legitimate mail from unaligned services can be refused | Read DMARC reports at p=none first |
Run any domain through the DMARC checker to catch these, and see how to set up DMARC for the full process.
How we help with your DMARC record
A correct record is quick to publish; knowing which policy each domain can safely carry needs the reports behind it. We can help:
- Review your records: we check the DMARC, SPF and DKIM records on every domain you own, including parked and subdomain records
- Set up reporting: we can add a monitoring platform's rua address so reports are collected and readable
- Choose and supply the platform: we supply EasyDMARC, Valimail and the Check Point Email Security DMARC Management add-on, some of which can host the record and change the policy for you
- Plan your route to enforcement: we help you plan each change to p, sp and np at a pace that suits you
Contact us for free advice or a quote.
Frequently asked questions
What DNS record type is DMARC?
DMARC is a TXT record. It is published at the host name _dmarc, so for example.co.uk the full name is _dmarc.example.co.uk. Some DMARC platforms, such as EasyDMARC's Managed DMARC or Valimail's delegated set-up, ask you to point _dmarc at them with a CNAME or NS record instead, so they can change the policy for you.
What is the fo tag in a DMARC record?
fo sets when failure (ruf) reports should be generated: 0 when all mechanisms fail to give an aligned pass (the default), 1 when any mechanism fails, d for any DKIM signature failure and s for any SPF failure. It is ignored unless the record also has a ruf address, and some large receivers, Outlook.com among them, send no failure reports at all.
Do subdomains need their own DMARC record?
No. Your organisational domain's record covers its subdomains, using sp for existing subdomains and np for non-existent ones, falling back to p. A subdomain can publish its own _dmarc record when you want a different policy for it, such as reject on a dedicated sending subdomain while the main domain is still at quarantine.
Is pct still valid in a DMARC record?
No longer. RFC 9989, published in May 2026, lists pct as historic, along with rf and ri, because pct was rarely applied accurately except at 0 or 100. Older guidance, including some NCSC and gov.uk pages, still shows pct. Use t=y, the new test mode, to ask receivers to apply one level below your stated policy while you test. Receivers that have not yet adopted RFC 9989 ignore t and apply your stated policy in full, so only publish quarantine or reject once the reports show your senders passing. If your record has pct below 100, removing it applies the full policy everywhere, so step p down a level first rather than just deleting pct.
What does a basic DMARC record look like?
The simplest useful DMARC record is v=DMARC1; p=none; rua=mailto:dmarc@example.co.uk, published as a TXT record at _dmarc.example.co.uk. It changes nothing about how your mail is delivered, but asks mailbox providers to send you aggregate reports so you can see every service sending as your domain.
Can a DMARC record have more than one rua address?
Yes. List them in the rua tag separated by commas, each starting mailto:. RFC 9989 says a report should be sent to each listed address. Addresses outside your own domain need an authorisation record published by the receiving domain, which DMARC platforms set up for you.
Still have a question about DMARC record review?
Ask us and a member of our team will get back to you.