Could someone send email as you, and would it arrive?
Nothing in an email proves who sent it. Four public records decide whether a message forged in your name lands in the inbox; this test reads all four in about a second and gives you the record that closes the gap. It works for any mail provider, in any country.
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.
Eight things read from your DNS, one answer back.
The result is a sentence, the evidence under it and the record that fixes it. There is no score out of a hundred; a number says nothing about what to change.
DMARC
The instruction receiving servers follow for a message that fails: deliver it, move it to spam, or refuse it.
SPF
The servers allowed to send as you, and whether anything outside that list is turned away.
DKIM
Whether your genuine mail carries a signature, so it keeps arriving once a policy starts enforcing.
MX
Whether the domain takes in mail at all. A domain with no MX can still be forged as a sender.
Reports
Whether anyone collects evidence of failures, or a forgery goes through and nobody hears of it.
Subdomains
A policy on the main domain does not always reach mail sent from a subdomain; the result says which.
Partial enforcement
A policy can be limited to a share of messages. When yours is, the result says so.
What to change
The record to add today, and how far it can safely be tightened later.
One TXT record, published at your DNS host.
The record tells every receiving server what to do with a message that fails the checks. You are adding an entry, not editing one, and your own mail carries on as before.
Before you paste it: the reports
The rua= part asks every large mail provider for a daily report, from the day after you publish and without end. Send them to an address you do not read each morning, so they never crowd your working inbox.
Open the DNS settings
Sign in where the domain is managed, usually the registrar or the web host, and find the page named DNS, DNS records or Advanced DNS.
Add a TXT record
Choose to add a new record and set its type to TXT.
Name it _dmarc
Type the name with its leading underscore. If the other records show full names, add your domain after it.
Paste the value
Paste the value from the box above into the Value, Content or Data field.
Leave the TTL, then save
The TTL can stay as it is. The record usually applies within minutes, sometimes within the hour.
Test the domain again
Run the check once more. A forgery now goes to spam instead of the inbox.
A start with no risk at all
Publish the same record with p=none. It changes no delivery and only starts the reports; after a few clean weeks, change that one word to quarantine.
Minutes to add, weeks to finish
The record goes in within minutes. Full enforcement follows once a few weeks of reports are in; nothing technical holds it up.
In order: test the domain, publish the record, read the reports, then tighten to reject once nothing genuine fails.
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.
A fixed domain can quietly come open again.
Records get edited in the middle of unrelated work, and nothing warns you. Your own mail keeps flowing, so the gap shows only when someone else receives a forgery. A re-check takes a second, and we re-check our own domains for the same reason.
A website move
The new host republishes DNS from scratch and the policy is left behind.
A new mail provider
Records are rebuilt for the new service, and the old policy does not always make the list.
A tidy-up
Someone removes entries they did not recognise, and the one that mattered goes with them.
A restored zone file
An older copy of the zone comes back after a fault, from before the record existed.
When we first ran this test on our own fourteen domains, eleven had no policy at all and none was protected. The three of them that send mail were closed within the day.
The customer who pays a forged invoice blames the name on it.
Spoofing turns the trust people place in your address into money for someone else. Small businesses are tried as often as large ones, because domains are tested in bulk and it costs the forger nothing.
The forged invoice
A customer who owes you money gets a message from your address, in your tone, with new bank details. They pay. When it comes to light weeks later, the question they ask is why your business allowed it.
The quiet cost
Domains without a policy are filtered harder by the large providers, so your genuine quotes and invoices are likelier to land in spam. The record that turns forgeries away also tells those providers your domain can be trusted.
Three checks decide whether a message reaches the inbox.
A message that claims your address meets SPF, DKIM and DMARC at the receiving server. This test reads what your domain publishes for each of them and names the one that leaves the door open.
A false return address, and the mail still gets delivered.
Email was designed for a network where every sender was trusted. The sender types the From line, and nothing checks it against the owner of the address.
Spoofing
Someone puts your address in the From line of their own message. No password is needed and nothing of yours is broken into.
Compromise
Someone gets into your real mailbox with a stolen password. A new password fixes that; it does nothing against spoofing.
What decides delivery
Four public records on your domain. Without them each receiving server guesses, and its safest guess is to deliver.
What the record can do
Nobody can be stopped from typing your address. The record has every receiving server refuse the result, or file it as spam.
Four rules the checker keeps.
The test 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 test your domain.
Send any other question in writing; a written answer follows within one business day.
Has our email account been broken into?
Very unlikely. A forger needs neither your password nor your mailbox; they type your address into a message of their own, which is why a new password changes nothing.
Will the record affect our own mail?
Not while the policy is p=none: that setting blocks nothing and only switches reporting on. Quarantine moves failing mail to spam and is safe once your own services pass. The risk comes only from jumping straight to reject without reading the reports.
Can I test someone else’s domain?
Yes. The test reads public DNS, which every mail server can see. People check a supplier’s domain before paying an invoice that arrived by email.
Check another domain.
Test a supplier, a client or a second domain of your own. Each answer comes back in about a second, read from public DNS.