If your own domain has no DMARC record, anyone can send mail that claims to be from you, and receivers get no instruction from you about it. You also get no report when it happens. The fix starts with one TXT record, and the steps are below.
What we found
All shares are of the 892 domains that receive mail. 9 more domains gave a failed lookup, so we left them out rather than count them as "no record".
| Result | Domains | Share |
|---|---|---|
| No DMARC record | 154 | 17.3% |
DMARC at p=none: reports only, no action | 306 | 34.3% |
DMARC at p=quarantine (spam folder) | 189 | 21.2% |
DMARC at p=reject (refuse) | 243 | 27.2% |
| No SPF record | 40 | 4.5% |
| 2 SPF records, which makes SPF fail | 4 | 0.4% |
| No DMARC and no SPF | 32 | 3.6% |
| A DKIM key found on a common selector name | 637 | 71.4% |
With 892 domains, the true share is likely within about 2.5 points of 17.3%. The 95% range is 14.9% to 19.9% (a Wilson interval, a standard way to put error bars on a share).
Add the first two rows and 460 of 892 domains (52%) have no DMARC policy that asks a receiver to stop a fake. The DMARC standard says plainly what p=none means: "the Domain Owner expresses no handling preference for messages that fail DMARC validation" (RFC 9989).
The same table has some good news. 119 of the 154 domains with no DMARC record already have exactly 1 SPF record. For them, the fix is one more TXT record.
Where the domains run their mail
The MX record names the server that takes a domain's mail, so it shows the mail service.
| Mail service (from MX) | Domains | No DMARC |
|---|---|---|
| Microsoft 365 | 369 | 66 (17.9%) |
| Google Workspace | 160 | 25 (15.6%) |
| Mimecast | 91 | 4 (4.4%) |
| Proofpoint | 63 | 7 (11.1%) |
| Other or own server | 209 | 52 (24.9%) |
On Microsoft 365 and Google Workspace, an admin has to add the DMARC record. Microsoft's setup guide says you "need to configure the DMARC TXT records for your custom domains" (Microsoft Learn, Set up DMARC). Domains behind Mimecast missed the record less often in our sample. The Proofpoint group is too small to compare, and we do not know the cause for either.
How it compares with another UK count
The share depends on which list you start from.
| Study | Domains | No DMARC record |
|---|---|---|
| Servnet, FTSE 350, 2026-09-19 | 267 company mail domains | 2.6% |
| This post, all of our sample | 892 company website domains | 17.3% |
The FTSE 350 are the biggest listed UK companies, and most have a security team. Servnet also read each company's mail domain, while we read the domain of its website, which is sometimes a different domain. Our sample has only 68 public companies (6 had no DMARC), which is too few to compare with the FTSE count. Inside our sample, the 288 domains that end in .uk missed DMARC more often (20.8%) than the 604 on .com and other endings (15.6%).
The record that fixes it
A DMARC record is one TXT record at the name _dmarc under your domain. A TXT record is a line of text in your domain's DNS settings. DMARC tells receivers what to do with mail that fails both SPF and DKIM, where the passing check must match the domain in the From line. It also says where to send a daily report.
The standard advises 3 steps: publish p=none "for at least a month", then p=quarantine "for an equally long period of time", and only then p=reject (RFC 9989).
Step 1, today. Add this record at your DNS host. Put your own domain and a mailbox on that domain in place of the example.
Type: TXT
Host: _dmarc
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.co.uk
Nothing changes for your mail yet. Receivers such as Gmail now send a report to that mailbox, most days, as an XML file. It lists every server that sent mail as your domain, and whether each one passed. The files come often, so use a new mailbox for them, not your own inbox. A free DMARC report viewer turns the files into a readable table.
Google recommends that you "always include" the rua address (Google Workspace Admin Help, Set up DMARC). In our sample, 148 domains with a DMARC record had no rua address, so nobody gets those reports.
Step 2, after at least a month. Check that every real sender passes in the reports. That means your mail service, and also the tools people forget: a newsletter tool, an invoicing system, a website contact form. A sender that fails here will have its mail sent to spam after this step. When they all pass, change one word:
v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.co.uk
Fake mail now goes to spam.
Step 3, after another month. If the reports stay clean, move to:
v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.co.uk
Receivers that follow DMARC now refuse fake mail in your name.
Do not add pct=. Many old guides still show it, but RFC 9989 removed the tag because receivers applied it unevenly.
Two checks first. You need exactly one SPF record that names every service that sends for you, because 2 SPF records make SPF fail (RFC 7208). In our sample, 4 domains had 2. The same goes for DMARC: publish one record only, because receivers ignore a domain with 2, and 3 domains in our sample had 2. If you have no SPF record, your mail service's setup page gives the line to add, such as v=spf1 include:_spf.google.com ~all for Google Workspace.
Also turn on DKIM signing in your mail service. DMARC passes on SPF or DKIM, and DKIM survives forwarding where SPF does not. A DKIM key sits at a name called a selector, which each mail service picks.
A domain that sends no mail
83 domains in our sample have no MX record, and 10 of those publish a null MX, a record that says the domain takes no mail. Some of the 83 may still send mail. A domain that sends nothing can still be faked, and only 16 of the 83 had both v=spf1 -all and p=reject.
The UK government's guidance gives the records for a domain that sends no mail (GOV.UK, Protect domains that don't send email). Use these only if no person, website form or tool sends mail from this domain:
TXT @ v=spf1 -all
TXT _dmarc v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s; rua=mailto:dmarc-reports@example.co.uk
MX @ 0 .
The last line is the null MX record (RFC 7505). Some DNS hosts do not accept it; skip that line if yours refuses it. We shortened the GOV.UK block: it also adds fo=1 and an empty DKIM record at *._domainkey.
Why it matters now
Gmail requires SPF or DKIM from every sender. It requires SPF, DKIM and DMARC only from senders of more than 5,000 messages a day to Gmail accounts, which most small firms do not reach (Google, Email sender guidelines). So the reason for a small firm is not the Gmail rule. Without DMARC, a receiver has no instruction from you about a message that only pretends to be from you, and you get no report that it happened.
A DMARC record does not stop a lookalike domain, such as one with a letter changed, and it does not fix a bad sending reputation. It covers exact use of your own domain.
How we measured
- The list. From Wikidata, we took every item marked as a business, company, enterprise, public company or private limited company, with the United Kingdom as its country, an official website, and no end date. We dropped government, university and NHS addresses, social media pages, and any domain shared by 6 or more companies, such as a group's main site. That gave 6,486 unique domains.
- The sample. We drew 1,000 at random with the fixed seed 20261011. Wikidata changes every day, so a later query gives a slightly different list.
- The reads. For each domain we asked Cloudflare's 1.1.1.1 for the MX record, the TXT records at the domain (for SPF), the TXT record at
_dmarc, and 26 DKIM selector names that common mail services use. Google's 8.8.8.8 was asked only when 1.1.1.1 failed. - The rules. A failed or timed-out lookup counts as a failed reading, never as "no record". That put 9 domains aside. 16 more domains no longer exist. Every "no DMARC" answer was asked again through dns.google over HTTPS (a DNS lookup sent over a web connection, to another operator). All 154 came back the same.
- DKIM. A DKIM key counts only when it holds a real key. Some domains answer every selector name with the same record (a wildcard record); we do not count those.
- A cross-check. We ran 10 of the domains, 5 with no DMARC and 5 with one, through the same free check that runs on /mailfix. All 10 agreed.
- The limits. Wikidata lists companies that someone thought worth an entry, so the sample leans to older and better-known firms, and the share for small firms is likely higher. A DKIM miss does not prove there is no key, because a selector can have any name and DNS cannot list them. We did not send any mail.
To check your own domain, open the free check on /mailfix, type your domain, and see in seconds whether SPF, DKIM and DMARC pass. No sign-up, no key. If you would rather have a person write the exact records for your mail setup, that is our Mailfix report: a fixed price shown on the page, delivered within 24 hours of the deposit, and we never ask for your DNS login.
Sources
- Wikidata, read through query.wikidata.org on 2026-10-11: UK companies with an official website. Wikidata data is CC0.
- RFC 9989, DMARC (May 2026): what
p=nonemeans, the none, quarantine and reject rollout, and whypctwas removed. It replaces RFC 7489. - RFC 7208, SPF: one SPF record per domain.
- RFC 7505, Null MX: how a domain says it takes no mail.
- Google, Email sender guidelines and Set up DMARC, read 2026-10-11.
- Microsoft Learn, Set up DMARC, read 2026-10-11.
- GOV.UK, Protect domains that don't send email, read 2026-10-11.
- Servnet, FTSE 350 email security 2026: the other UK count in the comparison table.
- Our own reads: 1,000 domains through 1.1.1.1, 8.8.8.8 and dns.google, 2026-10-11 06:35 to 06:47 UTC.