Does your domain tell mail servers to refuse a forgery?
DMARC, SPF, DKIM and MX together decide what happens to a message forged in your name. The checker reads all four from public DNS, answers in one line and gives you the record to publish. There is nothing to sign up for, and it never asks for access to your mailbox or your domain.
Checking
Reading your domain
Your result
The record is on this page. Publishing it is yours to do, or ours.
Copy the record shown above and follow the numbered steps further down. Most domains take one sitting at the DNS host.
Go to the stepsWe publish SPF, DKIM and DMARC for the domain and verify each one once it is live. Report reading, the later move to reject and support after that are separate work.
Ask us in writingYou receive the scope and the price in writing before any record is touched.
Four records, and the one that decides.
Three of the records describe your mail. DMARC is the one that tells a receiving server what to do when a message fails the other three.
MX
The servers that take mail for the domain. A domain that takes no mail is still easy to forge.
SPF
Your list of allowed senders and its last word: ~all marks strangers and lets them through, -all turns them away.
DKIM
The signature on your outgoing mail. The checker tries the selector names mail providers use most.
DMARC
The instruction itself: deliver the forgery, move it to spam, or refuse it at the door.
Where reports go
Whether evidence is being gathered at all, and the mailbox it goes to.
Alignment
Whether the From address a reader sees has to match the signed domain, or a lookalike slips past.
Subdomains
Whether the policy also covers mail from names such as billing.yourbusiness.example.
What to change first
Which entry to publish now, and how far to tighten once two weeks of reports are in.
Publish the record, then let the reports guide the rest.
The first setting changes no delivery. It starts the reports that name every server sending as you, and those reports tell you when it is safe to tighten.
Before you paste it: the reports
rua= asks each large provider for a daily report, starting about a day after you publish. Send it to a mailbox nobody reads first thing in the day; the volume is what pushes most people to switch DMARC off. The section below explains the flood.
Open the DNS menu
Sign in where the domain is managed and look for DNS, DNS records, Advanced DNS or Name servers.
Add a TXT record
Choose Add record and set the type to TXT.
Name it _dmarc
Type _dmarc in the Name or Host box. If the records already there show full names such as mail.yourbusiness.example, type _dmarc.yourbusiness.example; this step is the one most often got wrong.
Paste the value
Put the value from the box above into the field called Value, Content or Data.
Leave the TTL alone
It makes no difference to this record; keep what the host suggests.
Save
It usually applies within minutes, occasionally within the hour.
Check again
Run the domain here once more. DMARC should now read published.
If the check found no SPF
Read the MX line
The server name in your result is whoever runs your mail.
Find their include
Their help pages give the exact include: line for SPF, the same for every customer.
List the other senders
Accounting or invoicing software, a booking system, the website form, a CRM, the newsletter tool: each one publishes its own include.
Join them, ending ~all
One record, for example v=spf1 include:mail.example include:invoices.example ~all.
Publish at @
A TXT record with the Name blank or @, never at _dmarc. One SPF record per domain: edit the existing one, never add a second.
Ten lookups at most
Every include: costs one DNS lookup. Past ten, receivers may stop reading the record, and your own mail can begin to fail. The checker counts them for you.
~all before -all
End with ~all until a few weeks of reports have been read. -all refuses anything not listed, so a service you missed would stop arriving without a word.
If the check found no DKIM
Open the provider admin
In your mail provider’s settings, find the section called DKIM, email authentication or domain authentication; the mailbox itself has no such switch.
Switch it on
The provider generates the key and gives you a record, usually starting v=DKIM1;.
Publish it exactly
Copy the name, something._domainkey, character for character.
Repeat for each sender
Your invoicing tool needs its own key, and so does the newsletter. The checker guesses common selector names, so the provider admin has the final word.
About two weeks later
Check the domain again
DMARC should show as published, and SPF should match what you meant to publish.
Read the reports
They name every server sending as you, the forgotten ones included.
Move to reject
When nothing genuine fails, change p=quarantine to p=reject. A forgery is then refused, not filed as spam.
Only then, -all
Change SPF’s ~all to -all after that, never before.
Read, publish, read the reports, tighten: in that order, nothing of yours stops arriving.
Rather not edit DNS yourself? We publish SPF, DKIM and DMARC for the domain and verify them, with the scope and the price in writing first. Ask us in writing.
Then the reports start arriving, every day.
Every large provider answers the rua= request with a daily report of zipped XML written for machines. That flood is the evidence: it lists your invoicing tool, your booking system, a tool a former colleague set up, and anyone forging you. Until it is read, moving past p=none is a guess.
Filter them to a folder
Point rua= at an address such as dmarc@yourbusiness.example and file it unread. Nothing crowds your inbox and the evidence waits.
Remove rua=
The reports stop, and so does any way of knowing when it is safe to tighten. We advise against it.
Have someone read them
The only route that ends with the domain protected. Ask us in writing if you would rather not do it yourself.
Re-read every month
Protection can vanish during a website move or a provider change, with no warning. The check takes a second.
When we first checked our own fourteen domains, eleven had no DMARC record at all and two stopped at p=none. The three that send mail were fixed that day.
A forgery in your name is usually an invoice.
Without these records, a message typed with your address lands in the inbox looking exactly like one of yours.
What happens
A customer with an unpaid bill gets a message from your address naming a different bank account. Nothing about it looks wrong, so they pay, and when it unravels they hold your business to account.
The cost you do not see
Domains with no policy are filtered harder. Real invoices, quotes and replies sit in spam, and nobody writes to say their mail went missing. Publishing it improves the delivery of your own mail as well as blocking a forger.
A note on your domain telling the post what to do.
DMARC is a short public note on your domain, read by every mail server that receives a message claiming to be from you and cannot verify it. Most businesses have never published one, and many that did stopped at p=none.
p=none
Deliver it and send me a report. A sensible first week; on its own it protects nothing.
p=quarantine
Put it in the spam folder.
p=reject
Refuse it outright.
Reading a record
v=DMARC1 names the record, p= is the policy, rua= is where reports go and fo=1 asks for detail on each failure. Check yours with dig _dmarc.yourbusiness.example TXT.
Four rules the checker keeps.
The checker only looks. Every change is one you make, at your own DNS host, when it suits you.
Always: public DNS, and nothing else
Every answer comes from records any mail server can look up. Nothing is sent to the domain and nothing about it is kept.
Always: the record as published, and a command to check it
Each line shows the raw text we read, with a dig command that returns the same answer on your own machine.
Never: your mailbox, your password or your DNS login
The check needs a domain name and nothing more. No test message is sent to or from the domain.
Never: a strict SPF record we cannot verify
Senders we cannot see from outside would be refused by it. When a record cannot be read, the result says unread, never missing.
Before you check your domain.
Send any other question in writing; a written answer follows within one business day.
Will this change anything about our email?
No. It looks only at public DNS, the same records every receiving server consults. No message goes out and no record is edited, whichever provider runs your mail.
What if we have no DMARC record?
That is the most common result: nothing is enforced, and a forgery from your address is delivered as normal. The fix is one TXT record, and its first setting, p=none, leaves delivery untouched, so it can go in today.
Why will you not give us a strict SPF record?
Looking in from outside, some of the services that send for you are invisible to us. Leave a billing tool or a form notifier off a strict record and its mail stops arriving, with no bounce to warn you. SPF gets tightened once the reports have shown what sends as you.
Check another domain.
Run a supplier’s domain before paying an emailed invoice, or a second domain of your own. The answer is back in about a second.