Anyone can send an email that looks like it came from your company

Anyone can send an email that appears to come from your company, unless you have published two small records in your domain settings. Most businesses have not. Across a sample of 73.3 million domains in December 2025, 83.9% had no DMARC record at all. Here is the three-minute check, and what to do about it.

Start with the check, then read the rest

You do not need to understand any of this to find out whether it applies to you. Open MXToolbox, type your domain, and look at two things.

Does an SPF record exist? It starts v=spf1. This is the list of servers allowed to send email using your domain.

Does a DMARC record exist? It starts v=DMARC1. This tells receiving servers what to do when a message fails that check, and it is the only mechanism that reports attempted forgery back to you.

If either is missing, someone can send email that appears to come from your address, and there is nothing on the receiving end to catch it.

Most readers of this article will find one or both missing. That is not a personal failing. It is the industry default.

How common is missing, really

Two studies published within months of each other look like they disagree, and the difference between them is the whole point of this article.

Study	Sample	Domains with any DMARC policy
Red Sift, December 2025	73.3 million domains	14.9%
EasyDMARC, 2026	Top 1.8 million domains by traffic	52.1%

Both are correct. They are measuring different populations.

Look at the largest, most-visited domains on the internet and just over half are covered. Widen the sample to seventy-three million ordinary domains and the figure collapses to under fifteen percent, with 83.9% showing no record at all.

Large companies fixed this years ago. The businesses that did not are the small and medium ones, and those are exactly the businesses whose payment instructions nobody double-checks.

Even among the domains that have adopted it, EasyDMARC found only 2.5% set the strictest policy of p=reject. Publishing a record is not the same as enforcing it, which is a distinction we come back to below.

What the two records actually do

Skip this if you already know. It matters less than the check.

SPF is a public list of the mail servers permitted to send as your domain. Your email provider gives you the line to publish. It ends in either ~all, meaning treat anything else as suspicious, or -all, meaning reject anything else outright.

DMARC is the instruction that decides what happens when a message fails. It has three settings:

• p=none reports failures to you and delivers the message anyway. A monitoring mode, and the correct place to start.
• p=quarantine sends failures to the spam folder.
• p=reject refuses them.

A domain sitting on p=none for two years is being told about forgery and doing nothing about it. That is the state most adopters are in.

Why a web studio is telling you about email

Fair question, and the answer is the uncomfortable part.

SPF and DMARC are DNS records. DNS is the same place your website's address lives. In most small businesses one supplier controls that panel, and that supplier is whoever built or hosts the website.

So the person best placed to notice this is your web provider. In our experience they almost never check, because it is not billable, not visible, and not obviously their job. When we surveyed twelve UK pay monthly website providers in July 2026 for what they publish about handling customer data, three mentioned a Data Processing Agreement anywhere on their public site. Email authentication did not appear at all.

Your website is fine. Your domain is the thing that is exposed, and they are managed from the same screen.

How the fraud actually runs

The mechanism is duller than people expect, which is why it works.

1. Somebody learns you are owed money, or that you owe it. A supplier relationship is not secret: it appears in tenders, on invoices, in email signatures, and in any inbox that has been compromised anywhere along the chain.
2. A message arrives that appears to come from you, or from your supplier, saying bank details have changed.
3. The payment goes to the new account.
4. Everyone finds out at the end of the month.

UK Finance reported that over £1 billion was stolen through fraud in 2024, with authorised push payment fraud accounting for just over £450 million of it. Authorised push payment means the victim made the transfer themselves, believing it was legitimate. No system was breached. Somebody was simply convinced.

That is the category this belongs to. Not hacking, persuasion, and a forged sender address is very persuasive.

When DMARC will not save you

This is the section the vendors selling DMARC tend to leave out, and it is the reason to read the rest of this with a clear head.

In 2026, security firm Ironscales documented a business email compromise campaign that passed SPF, DKIM and DMARC and still redirected an invoice payment. It did not forge the target's domain. It used a different domain, registered weeks earlier, configured properly, with a display name that matched a real person.

Email authentication answers exactly one question: was this message sent by a server allowed to send as this exact domain. It has nothing to say about a domain one character different, correctly configured, being read on a phone that shows only the display name.

So publish the records, because leaving your actual domain forgeable is indefensible when the fix is free. Then accept that the remaining risk is a process problem, not a technical one:

• Verify any change of bank details by phone, on a number you already had, never one from the email.
• Make that a rule that applies to the finance team and the director equally, because the fraud usually impersonates the director.
• Treat urgency in a payment request as a reason for more care rather than less. Urgency is the technique.

What to ask whoever manages your domain

Five questions, in writing, and keep the answers:

1. Do we have an SPF record, and does it end -all or ~all?
2. Do we have a DMARC record, and what is the policy set to?
3. Who receives the DMARC reports, and has anybody read one?
4. Does anything else send email as us, such as an invoicing tool, a booking system or a mailing platform, and is it in the SPF record?
5. If we move to p=reject, what would break?

The fifth is the one that separates a supplier who has done this from one who has not. Moving to enforcement without checking question four is how a business stops receiving its own invoices.

You are entitled to five straight answers. A supplier who cannot answer them has told you something useful for free.

Our own answers

It would be hollow to publish that list without answering it.

Both records are published on our domain. Our DMARC policy is not yet at p=reject, and we are not going to claim otherwise: moving to enforcement before you are certain every legitimate sender is listed is how you silently lose real mail, and saying so is more useful to you than a badge.

We check SPF and DMARC on every site we scan, and we report what we find whether or not the visitor becomes a client. It is one of the few checks in that report that has a number attached to being wrong.

If you want the answer without doing it yourself, run our free X-Ray on your address. It reads your published DNS records, your certificate and your security headers, tells you what it found, and says plainly where a check could not be completed rather than guessing.

---

Figures: DMARC adoption from Red Sift's global study of 73.3 million domains, December 2025, and EasyDMARC's 2026 adoption report covering the top 1.8 million domains. Fraud losses from the UK Finance Annual Fraud Report 2025, covering 2024. Authentication bypass case documented by Ironscales, 2026. This is general information about a technical control, not legal or financial advice.