Free · instant · no sign-up
If your domain isn't set up correctly, anyone can send an invoice that appears to come from your business — to your own customers. The damage lands on your reputation, and you usually hear about it from the client who already paid. This checks the three records that stop it, and tells you exactly what to publish.
Canopytech Email Spoofing Check · canopytech.ca
Protection score — higher is better
0/100
Your domain publishes the full set: a sending policy, a signature, and an enforcing rule telling receiving servers what to do when mail fails both. Somebody trying to invoice your customers as you will find it lands in spam or nowhere at all.
Protection score — higher is better
0/100
The building blocks are there but the enforcement is not finished, which is the most common state we see. Mail that forges your domain can still reach inboxes. The items below are what closes it, and none of them require changing how you send mail.
Protection score — higher is better
0/100
Something is published, but not enough to stop anyone. As it stands, a convincing invoice or payment-change request sent from your domain to your own customers would most likely be delivered.
Protection score — higher is better
0/100
There is effectively nothing stopping somebody sending email that appears to come from your organization. This is a DNS change rather than a purchase, and the first two records can usually be published the same afternoon.
SPF
Which servers may send as you
DKIM
Whether your mail is signed
DMARC
What to do when mail fails
Ordered by how much each one matters, worst first.
SPF is the list of servers allowed to send email using your domain. Without one, receiving mail servers have no published list to check against, so mail claiming to be from you gets far less scrutiny.
What to do
Publish a TXT record on your domain starting with v=spf1, listing your mail provider and any other services that send on your behalf, ending in -all. Your mail provider publishes the exact include: value to use.
A domain is allowed exactly one SPF record. With two or more, the specification says receiving servers must treat the result as a permanent error, which means your SPF is not just weakened, it stops working altogether. This usually happens when a second provider is added without merging into the existing record.
What to do
Merge every sending service into a single TXT record with one v=spf1 at the start and one all mechanism at the end, then delete the others.
+all tells receiving servers that any server anywhere is permitted to send mail as your domain. That is broader than publishing nothing at all, because it converts a missing answer into an explicit yes.
What to do
Change +all to -all (or ~all while you confirm nothing legitimate is being missed). This is a one-character change with a large effect.
DMARC is what ties SPF and DKIM together and tells receiving servers what to do when a message fails both. Without it, even a correct SPF record mostly just informs a decision nobody is required to act on — and you get no reporting on who is sending as you.
What to do
Publish a TXT record at _dmarc on your domain, starting at v=DMARC1; p=none with a rua= reporting address. Read the reports for a few weeks, then move to quarantine and finally reject.
A domain may publish exactly one DMARC record. When receiving servers find several, the specification tells them to ignore DMARC for that domain entirely, so the policy you think you have is not being applied at all.
What to do
Delete every DMARC TXT record at _dmarc except the one you intend to keep.
p=none is monitor-only. It is the correct place to start, and it gives you reports — but on its own it asks receiving servers to take no action, so mail that forges your domain still arrives in your customers' inboxes exactly as before.
What to do
Use the reports to confirm your legitimate mail passes, then move to p=quarantine, and once that is clean, p=reject. Most domains can complete this in a few weeks.
Without a closing all mechanism, the record says which servers are allowed but never says what to do about everyone else, so the default is neutral — the same outcome as not being listed.
What to do
Append -all to the end of the record (or ~all first, if you want a softer landing while you verify your sending sources).
?all tells receiving servers to treat unlisted senders as neither allowed nor disallowed. It is effectively the same as having no policy, and it will not support an enforcing DMARC policy.
What to do
Change ?all to -all once you are confident every legitimate sending service is listed in the record.
SPF allows a maximum of ten DNS-lookup mechanisms — include, a, mx, ptr, exists and redirect. Go over and the result is a permanent error, which fails SPF for all your mail. Each include can contain further lookups of its own, so the real total is usually higher than it looks.
What to do
Remove services that no longer send for you, and ask your provider whether they offer a flattened or consolidated include. Count nested lookups, not just the ones visible in your record.
A pct= value below 100 tells receiving servers to apply your policy to that share of failing messages and treat the rest more leniently. A p=reject at pct=10 reads as strict but leaves nine failures out of ten unchallenged.
What to do
This is fine as a deliberate staged rollout. Once you are confident, remove the pct= tag (or set it to 100) so the policy applies to everything.
Without a rua= address you get no aggregate reports, which means no visibility into who is sending as your domain, whether your own mail is passing, or whether it is safe to tighten the policy. It is the part of DMARC that tells you what is actually happening.
What to do
Add rua=mailto: with a mailbox you will actually read, or point it at a DMARC reporting service. The reports are XML, so a service is usually worth it.
sp= sets the policy for subdomains. With an enforcing policy on the main domain but sp=none beneath it, an attacker can send from a subdomain you never use and still land in an inbox looking like you.
What to do
Remove the sp= tag so subdomains inherit your main policy, or set it to match.
~all is a reasonable place to sit while you confirm every legitimate sender is listed, and it is enough to support DMARC. It asks receiving servers to accept but mark unlisted mail, rather than reject it.
What to do
Once your DMARC reports show no legitimate mail failing, tighten ~all to -all.
DKIM selectors are chosen by whoever set up your mail, and there is no way to list them from outside — a checker can only try common ones. Not finding a key here does not prove DKIM is missing; it means it is not published under any of the selectors we tried.
What to do
Check with your mail provider which selector they use, then confirm the record exists at that selector under _domainkey on your domain. If DKIM genuinely is not set up, your provider's documentation will have a one-page guide.
That is normal for a parked or web-only domain — but it does not make it safe. A domain that receives no mail can still be used to send it, and unused domains are attractive precisely because nobody is watching them.
What to do
Publish SPF and DMARC anyway. For a domain that should never send mail, v=spf1 -all plus a DMARC record at p=reject is the complete answer and takes minutes.
A sending policy, an enforcing DMARC rule and reporting are all published. This is the configuration that actually stops somebody invoicing your customers from your domain — most domains we check do not have it. Anything listed below this is a refinement or a note, not a problem.
What to do
Keep reading the DMARC reports, and re-check whenever you add a service that sends mail on your behalf — a new marketing platform is the usual way a correct setup quietly breaks.
This one is monitor-only, so it changes nothing about how your mail is delivered — it just starts the reports that tell you who is sending as you. Publish it as a TXT record at the host shown, then read the reports for a few weeks before tightening the policy.
Replace the reporting address with a mailbox you'll actually read. The reports arrive as XML, so most businesses point this at a DMARC reporting service instead.
This reads published DNS at a moment in time; it is not a scan, an audit, or a guarantee. SPF and DMARC results are definitive because those records live at fixed names. DKIM is not — selectors are chosen when your mail is set up and cannot be listed from outside, so "not found" means we did not find one under the common names we tried. None of this protects against lookalike domains, which are a separate problem.
Email was designed without any way to prove who sent a message. These three records are the retrofit. They work as a set — the first two produce evidence, and the third is what makes anyone act on it.
SPF
A published list of the servers allowed to send email using your domain.
Without it: Receiving servers have no list to check a sender against.
DKIM
A cryptographic signature added to each message, proving it wasn't altered in transit.
Without it: A message can be modified after it leaves you and still look legitimate.
DMARC
The instruction that ties the other two together and tells receiving servers what to do when a message fails both.
Without it: SPF and DKIM produce a verdict that nobody is obliged to act on.
Points are awarded for what your domain actually publishes: an SPF record that isn't broken, a strict enough SPF policy, a DKIM signature, a DMARC record, an enforcing DMARC policy, reporting, and a policy that applies to all of your mail rather than a percentage of it.
One deliberate exception: if we can't detect DKIM, those points leave the calculation entirely rather than counting against you. DKIM selectors are chosen when your mail is set up and can't be listed from outside — we try 28 common ones, and plenty of providers use something else. Marking a domain down for that would report a problem that isn't there, which is the flaw in most free checkers.
Well protected
90–100
Partly protected
60–89
Exposed
30–59
Wide open
0–29
A read of the public DNS records that decide whether your domain can be impersonated, with a specific fix for each gap. The same records anyone in the world can look up — including whoever might want to send mail as you. It is genuinely useful on a supplier's domain too, before you accept payment instructions by email.
It is not a scan. Nothing connects to your mail server, no port is probed and no test message is sent. It also cannot see lookalike domains — an attacker registering a name one character from yours and authenticating it perfectly is a different problem, and these records do nothing about it.
It reads three kinds of public DNS record for the domain you enter: SPF (which servers may send as you), DKIM (whether your mail is signed), and DMARC (what receiving servers should do when a message fails the first two). It also checks MX records to see whether the domain receives mail at all. Everything it reads is published DNS that anyone in the world can look up.
Yes, and this tool is different from our other two in that respect, so we would rather be plain about it. A DNS lookup has to happen somewhere. The domain you type is sent to our own server, which performs the lookups and sends the answer back. We do not store it, we do not log it against you, and no lead is created — but it is not a browser-only tool, and we would not want the privacy note on our other tools to imply otherwise. We chose this over doing the lookup from your browser precisely so that your IP address and the domain you are curious about are not handed to a third-party DNS provider.
No. It reads public DNS records and nothing else. It does not connect to your mail server, probe any port, send a test message, or touch anything you own. The same information is available to anybody with a command line, which is rather the point — it is available to whoever might want to impersonate you, too.
DKIM keys are published under a selector chosen when your mail was set up, and there is no way to list a domain's selectors from outside. Any checker can only try common ones, so a miss means "not found under the names we tried", never "not configured". If your provider uses a custom or rotating selector we will not see it. SPF and DMARC have fixed locations, so those results are definitive.
Technically yes, since this only reads public records — checking a supplier's domain before you accept payment instructions by email is a genuinely sensible thing to do. It tells you nothing private about them, only what they have chosen to publish.
SPF, DKIM and DMARC protect your exact domain. They do nothing about lookalike domains — an attacker registering a domain one character different from yours, or your name with a different ending, and sending perfectly authenticated mail from it. That is a separate problem, addressed by monitoring for lookalike registrations and by training people to check the address rather than the display name.
Score your security posture across 16 controls and see what to fix first.
Open itScore an IT provider's proposal against 26 checks and get the questions to ask before you sign.
Open itEstimate what an outage actually costs you, based on your real backup setup.
Open itPublishing SPF and DMARC takes minutes. Getting to an enforcing policy without breaking your own mail takes a few weeks of reading reports — we'll do it with you.
Request a Quote