DMARC – the instruction you give to everyone who receives your mail
DMARC tells recipients what to do when mail in your name fails authentication, and reports back daily. Here is the record, the path from p=none to p=reject, and every DMARC finding.
SPF and DKIM measure. Neither of them decides anything. A message can fail both checks and still land in the inbox, because nothing in either standard says what a recipient should do about it. DMARC is the missing instruction: it ties the two checks to the address the recipient actually reads, states what should happen when the result is bad, and asks for a report.
The reports are the part people underestimate. Once a day, every large mail provider sends you a summary of everything that claimed to be your domain – how much passed, how much failed, and from which servers. It is the only view you will ever get of what is being sent in your name, including the sending path in your own company that nobody documented.
What the record looks like
DMARC lives in a single TXT record under the name _dmarc on your domain.
_dmarc.example.com. TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; sp=quarantine; adkim=r; aspf=r"| Part | What it means |
|---|---|
v=DMARC1 | Marks the record as DMARC. It must come first. |
p=quarantine | The policy: what recipients should do with mail that fails. none, quarantine or reject. |
rua=mailto:… | Where the daily aggregate reports go. Without it you are blind. |
sp=quarantine | The policy for subdomains. Left out, the value of p applies to them too. |
adkim=r, aspf=r | Relaxed alignment: a subdomain counts as the same organisation. This is the default and normally what you want. |
Alignment is the idea that makes DMARC work. It is not enough that SPF or DKIM passed somewhere – the domain they passed for has to match the domain in the From line the recipient sees. That is exactly the gap a forger uses: their own domain passes SPF perfectly while your name sits in the From line. DMARC closes it.
A message passes DMARC when either SPF passes and aligns, or DKIM passes and aligns. One of the two is enough, which is why forwarded mail still survives if DKIM is signing.
The path from monitoring to protection
DMARC is meant to be walked in three steps. Skipping them is how legitimate mail disappears.
| Step | Record | What happens | How long |
|---|---|---|---|
| 1. Watch | p=none with rua | Nothing is filtered. Reports start arriving. | Two to six weeks |
| 2. Filter | p=quarantine | Failing mail goes to the spam folder. | Four weeks or more |
| 3. Reject | p=reject | Failing mail is refused at the door. | The finishing state |
In step 1 you read the reports and look for one thing: which senders are yours. Almost every company finds one or two it had forgotten – an old invoicing tool, a monitoring system, a form on a microsite. Each of those gets authenticated, or moved to a subdomain, before you go further.
The raw reports are XML in a zip file and are painful to read by hand. Any DMARC report service will turn them into a table for you; several are free at the volume a small company produces. Alternatively, send rua to a mailbox you check monthly and open one file when something looks odd.
As a first step, p=none is exactly right. As a permanent state it is a record that reports forgeries and permits them. Many domains have stood there for years because nobody read the reports – and a domain in monitoring mode offers a forger the same opportunity as a domain with no DMARC at all.
How to set it up
DMARC is one TXT record. It is published where your DNS lives, regardless of who hosts the mailboxes.
| Provider | Where to add the record |
|---|---|
| GoDaddy | My Products, DNS, Add New Record, type TXT |
| Namecheap | Domain List, Manage, Advanced DNS, Add New Record |
| Bluehost | Domains, DNS, TXT section |
| Rackspace | Cloud Office control panel, Domains, DNS |
| Fasthosts / 123-reg | Control panel, Domain, Manage DNS |
| Cloudflare | DNS, Records, Add record, type TXT |
| Microsoft 365 | No DMARC setting of its own – publish the record at your DNS host |
| Google Workspace | The same; the admin console only links to the instructions |
Step by step at GoDaddy
- Sign in, open My Products, then DNS next to the domain.
- Add New Record, type TXT.
- Name:
_dmarc– not the whole domain, and no trailing dot. - Value:
v=DMARC1; p=none; rua=mailto:dmarc@example.com, with your own address. - Save. Leave the TTL at one hour.
- Run this check again after an hour, and set a reminder for four weeks from now to read the reports.
The findings in detail
No DMARC record
There is no TXT record at _dmarc on your domain.
This is the largest of the three gaps. SPF and DKIM may be perfect, but without DMARC no recipient is told what to do when they fail, and nobody reports anything back to you. Forgeries in your name pass without consequence, and you never learn that they happened.
What to do: publish a record with p=none and a reporting address today. That changes nothing about your delivery – it only starts the reports. Read them for a few weeks, authenticate every sending path they reveal, then move to quarantine and later reject.
Multiple DMARC records
More than one TXT record at _dmarc begins with v=DMARC1.
As with SPF, only one is allowed, and two mean the domain is treated as having none at all. Both records are ignored, both policies stop applying, and the reports stop arriving. Usually it happens when a second record is added instead of the first being edited.
What to do: decide which record is current, delete the others, and check afterwards that exactly one remains. Some DNS panels hide duplicates behind a scroll bar.
DMARC without a valid policy
The p field is missing, or it holds a value that is not none, quarantine or reject.
Without a valid policy the record does not apply. The most common cause is a typo – p=reject;;, p = none, or a word from another standard. The record looks present and complete in the panel, and it does nothing.
What to do: set p to one of the three permitted values and check the whole record for stray spaces and semicolons. v=DMARC1 has to be the first field.
DMARC monitoring only (p=none)
Your policy is p=none.
Forgeries are reported, and then delivered. As the first step of a rollout that is correct and deliberate. As a permanent state it is protection that never arrives: anybody can send mail in your name, recipients are explicitly told to accept it, and the only difference from having no DMARC at all is that you could have read about it in the reports.
What to do: read the last four weeks of reports. If everything failing is recognisably not yours, move to p=quarantine. Wait another month, then p=reject. If you have never looked at a report, that is the step that comes first – not the tightening.
DMARC applies only partly
Your record contains pct with a value below 100.
The pct field tells recipients to apply the policy to only a share of failing messages. It was designed for a careful rollout: start at 10 per cent, watch, increase. Left at a low number it becomes an odd half-measure, where the same forgery is rejected for one recipient and delivered to the next.
What to do: if you are in a rollout, keep raising the value until you reach 100, then remove the field – no pct means 100. If nobody remembers setting it, remove it now.
DMARC without a reporting address
The record has no rua field.
Without it you receive no aggregate reports, and the reports are the main benefit of DMARC. You see neither the forgeries nor your own sending paths that are still failing. Worse, you cannot tighten the policy safely, because you have no way of knowing what a stricter setting would block.
What to do: add rua=mailto:dmarc@example.com with an address you actually read. A shared mailbox is fine. If you want the reports as tables rather than XML, point rua at a DMARC report service instead.
Subdomains exempted (sp=none)
Your record contains sp=none.
The main domain is protected and its subdomains are not. Forgers move to where the door is open, and invoice.your-domain.com is a pattern recipients see every week. Subdomains you have never created are covered by this too: DMARC applies to names that do not exist.
What to do: remove sp entirely so that p applies to subdomains as well. Only keep a separate sp if a subdomain genuinely needs a milder policy during a rollout – and then set it to quarantine, not none.
Reporting address not authorised
Your rua address is on a different domain, and that domain has not authorised it.
A domain cannot simply nominate a stranger to receive its reports, otherwise DMARC would be a way to flood other people's mailboxes. The receiving domain has to agree, by publishing a small record of its own. Without it, the sending providers discard the reports – your record looks correct and nothing ever arrives.
What to do: have the report recipient publish <your-domain>._report._dmarc.<report-domain> with the value v=DMARC1;. Report services do this automatically when you add a domain; if you send reports to a colleague's own domain, they have to add it by hand.
DMARC inherited from the parent domain
The name you checked has no _dmarc record of its own, so the parent domain's policy applies to it.
This is valid, and usually intentional. DMARC was built this way precisely so a subdomain cannot become a soft spot by being forgotten. The finding is a note, not a fault.
What to do: nothing, in most cases. A separate record is only worth it when the subdomain has its own sending paths – for example a newsletter tool on news.example.com – and you want its reports separated from the rest.
Frequently asked questions
Will p=reject make my mail disappear?
Only mail that fails both SPF and DKIM alignment, which after a proper rollout means mail that is not yours. The danger is the forgotten sending path, and that is exactly what the reports from the p=none phase are for. Do not skip that phase.
What happens to mailing lists and forwarded mail?
Forwarding usually breaks SPF, because the forwarding server is not on your list. DKIM survives it as long as the message is not modified. That is the practical reason to run both: one of the two carries the message through.
Do I need a DMARC record on domains that never send mail?
Yes, and there the answer is simple: p=reject with a strict SPF record. A parked domain with no policy is a convenient sender for someone else. The inbox page explains the rest of that setup.
How long until the reports arrive?
The first ones usually appear within 24 to 48 hours, from the large providers first. Volume depends on how much mail your domain sends and how much someone else sends in its name.
The Mail Check measures exactly what this page describes – on your own domain, in one to three seconds, without signing up.
Check a domain now →