Anyone Can Send Email As Your Business. Here's How Many Local Companies Have Nothing Stopping Them.

I checked the public mail settings on 1,525 local business domains. This is what I found, how I checked, and everything that could be wrong with it.

Three quarters of the local businesses I checked have nothing in place to stop someone sending email that appears to come from them.

Not a few. Not the ones with bad websites. 939 out of 1,235 — including most of the ones with good websites, professional offices, and full-time staff.

I want to explain what that actually means before I show you any more numbers, because when I started this I didn't understand it either. I've spent fifteen years connecting business systems together and I still had to sit down and learn this properly. If you find it confusing, that isn't you.

Part one: what this is, in plain terms

Email has a hole in it

When you post a letter, you write the return address yourself. Nobody checks it. You could write anyone's address there and the post office would still deliver the letter.

Email works the same way. The "From" line is typed by whoever sends the message. Nothing about the system requires it to be true.

So a stranger can send an email that says it's from you. Not a lookalike address, not yourcompany-billing@gmail.com — your actual domain. Your customer sees your business name and no reason to doubt it.

This isn't a flaw someone recently discovered. Email was designed in the 1980s among people who trusted each other, and the trust part was never fixed. Instead, three add-ons were built on top.

The three add-ons

SPF is a guest list. You publish a list of which mail servers are allowed to send email for your business. When a message arrives claiming to be from you, the receiving server checks whether it came from a server on your list.

DKIM is a wax seal. Your mail server adds an invisible signature to every message you send. The receiving server checks the signature against a key you've published. If it matches, the message really came from you and nobody altered it in transit.

DMARC is the instruction that ties them together, and it does two things nothing else does.

First, it tells receiving servers what to do when a message fails those checks. There are three possible answers:

• p=none — do nothing. Deliver it anyway.
• p=quarantine — put it in the spam folder.
• p=reject — refuse it entirely.

Second, it asks receiving servers to send you reports on who is sending mail using your name.

Here's the part that took me longest to understand. SPF and DKIM without DMARC are a guest list nobody enforces. The checks run. The results go nowhere. A message can fail every test and still land in your customer's inbox, because nobody ever told the receiving server what failure should mean.

And p=none is not protection. It's a note saying "I'd like to hear about it, but let them in." That distinction is the single most important thing in this post.

Who is supposed to set this up

This is the question I most wanted answered, and the answer explains everything else.

These three things are DNS records — small public text entries attached to your domain name. DNS is the internet's address book. It's what turns yourbusiness.com into an actual location.

Whoever controls your DNS controls these records. That's usually where you bought your domain — GoDaddy, Namecheap, Squarespace, Network Solutions — or wherever your domain's settings were pointed after that.

Now consider who that isn't:

• It usually isn't your web designer. They build and host the site. The domain settings are often somewhere else entirely, controlled by someone else.
• It isn't Microsoft or Google. They run your mailboxes. They publish instructions telling you to add these records. They cannot add them for you, because they don't control your domain.
• It might be your IT person, if you have one. Most small businesses don't.

So the job sits in a gap. The website company thinks it's an email thing. The email provider thinks it's a domain thing. The domain registrar just sells you the name. Nobody owns it, so nobody does it.

That is why the number is 76% and not 6%.

Part two: what I found

I checked the public mail settings on 1,525 local business domains across St. Charles County, the surrounding rural counties, and a set of local business-to-business companies. Full method further down, including everything I couldn't check.

There are two separate problems here, and almost everything written about this blurs them together. They're worth keeping apart because one is about other people harming you and the other is about you harming yourself.

Problem one: anyone can send mail as you

Of the 1,235 domains set up to receive mail:

Strip out 24 national chains that appeared in the listings — Home Depot, Lowe's, State Farm and the like, whose settings belong to a corporation in another state — and the local-only figure rises to 77.2%. Those chains were among the best-configured domains in the set. Removing them makes the local picture slightly worse, which is why I'm reporting it that way round.

What this looks like in practice. Your customer gets an email that appears to come from your company. It references a real job, because that information isn't secret. It attaches a revised invoice with different bank details. They pay it. You find out weeks later when your actual invoice goes unpaid.

This is one of the most common forms of business fraud there is, and it's especially effective against trades and contractors, where invoices arrive by email between people who've never met in person. The 939 businesses above have no technical barrier to it whatsoever.

Problem two: your own mail is failing

This is the smaller problem and the more immediate one.

94 domains have mail authentication that is actively broken. Not missing — broken. Their mail is failing checks right now:

• 53 publish a guest list that doesn't include the mail service they actually use. They send from Microsoft 365; the list authorizes something else entirely. Every message fails.
• 29 have a guest list that references so many other lists that it exceeds a hard technical limit of ten. Past ten, the whole record is discarded as invalid. It looks fine to a human reading it. It doesn't work.
• 16 have two guest lists instead of one. This is invalid by design — when a receiving server finds two, it uses neither. This usually happens the same way: you sign up for a mailing tool or a scheduling system, it tells you to add a record, and you add it alongside the existing one instead of merging the two. Now both are dead.

A further 176 domains publish no guest list at all. That's a weaker position rather than an outright failure — their mail isn't rejected, it's just unvouched-for and more likely to be filtered.

I'm keeping those two groups separate on purpose. 94 businesses have mail that is failing. Another 176 have mail that is unprotected. Adding them together and calling all 270 "broken" would overstate it, and you'll see that number reported both ways elsewhere.

What's actually working

The most interesting finding is the contrast.

85.6% of these domains publish a guest list. That's 1,057 of 1,235, and it barely varies by segment — 84.4% residential trades, 84.3% rural, 86.8% business-to-business.

Why so high? Because Microsoft and Google add it automatically when you set up email. Nobody decided to do it. It came in the box.

Compare that to enforcement, which requires a person to sit down, understand the problem, inventory every system that sends mail on their behalf, and deliberately turn something on. 24%.

That's the whole story in one line: the things your provider does for you are done. The one thing that requires a decision isn't.

Bigger businesses are barely better

I expected the business-to-business companies — the ones with offices, staff, and someone whose job includes IT — to be dramatically better. They're not.

A ten-point gap where I'd have guessed thirty. Having an office and a real IT budget moves this a little. It doesn't fix it.

I've given each figure as a range because 127 businesses appeared in more than one of my source lists and had to be assigned to one segment. The two ends of each range are the two defensible ways of assigning them. The gap holds at roughly eleven points either way, so it isn't an artifact of how I sorted them.

Part three: there is no benchmark for businesses like these

I wanted to tell you how St. Charles County compares to everywhere else. I can't, and the reason is worth more than the comparison would have been.

The nearest reference is Valimail's 2026 State of DMARC Report, the most-cited dataset in this field. It reports about 42% of tracked domains reaching enforcement by the end of 2025, up from 35% at the start of the year.

I originally intended to put my numbers beside theirs. Then I read their methodology, and three things make the comparison invalid.

They're measuring different companies. Valimail's methodology note says their domain list was compiled by ranking companies on web traffic, annual revenue, market capitalization and customer count. The examples they name include IGN, Blizzard, Michaels and the Washington Ballet. That's a list of large, well-known organizations. Mine is a list of roofers, machine shops and local B2B firms. Any gap between the two would tell you about company size, not about this county.

They count differently. Valimail sorts domains into four groups, not three — at enforcement, DMARC with reporting but not enforcement, DMARC set to none with no reporting, and invalid or missing. My scan didn't split that middle ground. So their "not at enforcement" figure covers only part of what mine does, and putting the two percentages side by side would be comparing different measurements that happen to be expressed in the same unit.

They apply a test I didn't. Valimail only counts a domain as protected if it's at quarantine or reject and doesn't have a weaker policy set for its subdomains. I never checked subdomain policies. Their bar is higher than mine, which means my enforcement number is, if anything, slightly generous.

So I'm not giving you a comparison. Nobody has published these numbers for local small businesses in any county, which is the actual reason I ran the scan.

What does survive is their explanation, and it's the most useful thing in their report. Valimail states directly that many organizations adopted a p=none policy in response to sender requirements from Microsoft, Yahoo and Google — Yahoo and Google announcing in 2023, Microsoft in 2025 — without realizing that it satisfies the requirement while doing nothing to protect the domain against misuse.

That's the mechanism behind my 317. Those businesses aren't negligent. Most of them were told to add a DMARC record, added one, and reasonably assumed they were done.

One caveat on the source, in fairness: Valimail sells DMARC monitoring and enforcement services and is owned by DigiCert. Their report is the standard reference and their methodology is published, which is how I was able to work out that I shouldn't compare against it. But they're not a disinterested party. Neither am I.

Part four: how I checked

I looked up public records. That's all.

Every one of these settings is published in DNS, openly, by design — receiving mail servers have to be able to read them. Checking them is like looking up a phone number.

For each domain I looked up four things: which servers handle its mail, its guest list (SPF), its enforcement policy (DMARC), and whether a signature key (DKIM) exists at any of nine common locations. I used public resolvers, retried once on failure, and verified the results against a third independent resolver.

I sent no email to anyone. I never contacted a mail server. I ran no address testing of any kind. These are real businesses that didn't ask to be examined, and the traffic I generated is indistinguishable from ordinary internet lookups.

No business is named here and none ever will be. In a county this size, publishing a neighbor's security gap is unrecoverable. These are aggregate numbers and that's all they'll ever be.

Of the 1,525 domains I attempted: 60 don't exist at all (stale directory listings), 10 failed to answer even after a retry, and 220 exist but aren't set up to receive mail. That leaves 1,235, which is the denominator for every percentage above. I chose it because a guest list on a domain that receives no mail is meaningless.

Part five: where this could be wrong

If you only read one section, make it this one. Every number above has a limit and I'd rather state them than have you find them.

I couldn't check alignment on a third of the domains. To know whether a guest list authorizes the right service, I have to know what service the business actually uses. For 381 of 1,057 domains, the mail is routed through a filtering service — Proofpoint, Mimecast, Barracuda and similar — which hides what's behind it. Those are marked unknown, not broken. The 94 broken-sending figure is a floor. The true number is higher, not lower.

My "wrong guest list" test can produce false positives. I compare the guest list against the service that receives their mail, assuming a business sends from where it receives. That's true in the common case but not always. A company that receives on Microsoft 365 but deliberately sends everything through its website host would be flagged incorrectly. I hand-verified ten of these and all ten were genuine, but treat the 53 as very likely misconfigured rather than certainly.

I never checked whether the DMARC records are valid. I checked whether one exists. A record with a syntax error is treated by receiving servers as no record at all. If some of my 613 are malformed, then adoption is lower than I've reported and the 76% is understated. This is the biggest hole in my data and I'm flagging it rather than quietly leaving it out.

My signature check is a floor, not a count. DKIM keys can be published anywhere the sender chooses. I checked nine common locations. A business not found at any of them may still have DKIM somewhere else. I'm reporting the number I found (612) and deliberately not reporting the inverse as though it meant anything.

There's a failure mode I didn't test for. The SPF standard sets a second limit alongside the ten-lookup cap: no more than two "void" lookups, meaning references that point at something which no longer exists. Exceed that and the record fails exactly the same way, even while comfortably under ten. I didn't check it. So some domains I've counted as fine are probably failing for a reason my scan never looked for — another way the broken-sending number is a floor.

My sample skews toward established businesses. These lists came from public trade directories, which over-represent businesses old enough to be listed and miss newer operations running on Facebook alone. Older, established businesses probably have better settings than average, which means the real local picture is likely worse than what I've reported.

This is one day's snapshot. DNS changes. A business could fix this tomorrow, or break it.

One group is too small to generalize from. 37 domains in my set have no working website at all. Twenty of them still have mail configured — paying for a domain, mailboxes wired up, nothing on the web. It's a striking finding and it comes from one rural sample, so I'm giving you the count and not a percentage.

Part six: what to do about it

Please read this warning before you do anything.

Do not turn on enforcement today. If you set p=reject without first knowing every system that sends mail using your name — your invoicing software, your scheduling tool, your CRM, your newsletter, the form on your website — those messages will start disappearing. Silently. No bounce, no warning, no clue where they went.

I could have written a scarier post that told 939 businesses to go turn this on. That post would break people's mail.

The correct order is:

1. Find out where you stand. Several free checkers will read your public records back to you — MXToolbox, EasyDMARC and Valimail all run one, and all three are linked at the end. Type in your domain, no account needed. Costs nothing, takes a minute. Each of those companies sells something in this space, so expect the results to be framed urgently; the underlying records they show you are simply facts.

I also built a free check of my own — the same lookups I ran across all 1,525 domains, pointed at one. It reports what your records say in plain language, tells you which of the two problems above you have, and doesn't ask for an email address. I'd rather you used whichever of these you trust; they're all reading the same public DNS.

2. If you have nothing, start with p=none and reporting turned on. This is the one place p=none is the right answer — it changes nothing about how your mail flows, but it starts collecting reports on who's sending as you. That's the inventory step, and you can't skip it.

3. Read those reports for a few weeks. You will find senders you forgot about. Everyone does. This is the whole point.

4. Once every legitimate sender is accounted for, tighten to quarantine, then reject.

5. Find out who controls your DNS before you need to. This is worth doing regardless. If you don't know who can change your domain settings, you have a bigger problem than email — it's how your website, your mail and your business name all get pointed somewhere else.

Steps one and two are genuinely a short afternoon's work for someone comfortable in a DNS panel. Step three is where it stalls for most people, because reading those reports means understanding what's in them.

What I'm not going to tell you

I'm not going to tell you this is costing you money. I don't know that. I attached no dollar figures to any finding on purpose, because I can't see what any of it costs a specific business. Neither can anyone who tells you otherwise.

I'm not going to tell you your business has been targeted. I checked configuration. I have no visibility into whether anyone has ever spoofed your domain — that's exactly what the reporting step exists to answer, and neither of us knows the answer until it's turned on.

I'm not going to pretend this is urgent for everyone. A one-person operation that invoices three customers a year by hand has a smaller problem than a contractor emailing fifty invoices a month. The risk scales with how much of your business moves through email.

And I'm not going to claim I'm an expert in email security. I'm not. I spent fifteen years connecting business systems that had to talk to each other reliably, which is why this kind of gap between two vendors is familiar territory — but I learned the specifics of this properly while doing this research. I've shown my method and my limitations so you can judge the work rather than my credentials.

Sources

Everything I've cited, with its origin and date. All links verified August 13, 2026.

The benchmark I decided not to use

Valimail — "The State of DMARC in 2026: DMARC Growth and Industry Adoption" by Al Iverson, Industry Research and Community Engagement Lead (published February 12, 2026; DMARC data queried January 2026, describing end-of-2025 state) https://www.valimail.com/dmarc-report-2026/ Source of: roughly 42% of tracked domains at enforcement by the end of 2025, up from about 35% at the start of the year; the four-category breakdown (at enforcement / reporting but not enforcement / policy of none with no reporting / invalid or missing); the explanation of p=none adoption as a response to Microsoft, Yahoo and Google sender requirements; and the methodology notes on domain selection, top-level querying, and the subdomain-policy test — which are what told me not to compare my numbers against theirs. Requires a form to access the full document. Valimail sells DMARC monitoring and enforcement services and is owned by DigiCert.

The technical standards

RFC 7208 — Sender Policy Framework (SPF), Version 1 https://datatracker.ietf.org/doc/html/rfc7208 The specification itself. Source of: the ten-lookup limit (§4.6.4), which states that implementations must limit DNS-querying terms to ten per evaluation and must return a permanent error beyond that; the requirement that a domain publish only one SPF record (§4.5), with multiple records causing the same permanent error; and the two-void-lookup limit I did not test for.

RFC 6376 — DomainKeys Identified Mail (DKIM) Signatures https://datatracker.ietf.org/doc/html/rfc6376

RFC 7489 — Domain-based Message Authentication, Reporting, and Conformance (DMARC) https://datatracker.ietf.org/doc/html/rfc7489 Source of the three policy values — none, quarantine, reject — and the aggregate reporting mechanism.

The free checkers mentioned above

• My own email deliverability check — https://dotgridos.com/tools/email-deliverability-check (the same lookups used in this study, run against a single domain. I built it and I sell website services, so treat it the way you'd treat the others — as a tool that reads public records, run by someone with an interest in what you conclude.)
• Valimail Domain Checker — https://www.valimail.com/domain-checker/
• Valimail SPF Record Validator — https://www.valimail.com/spf-validator/
• EasyDMARC SPF lookup — https://easydmarc.com/tools/spf-lookup
• MXToolbox — https://mxtoolbox.com/

My own data

The scan described in Part four was run by me on August 13, 2026 using public DNS lookups only. The aggregate figures, the full method, and the complete list of limitations are what you've just read. No business is named. If you want to check a specific number against a specific domain, the records are public — look them up yourself with any of the tools above.

Want to know where your business stands? Run the free check yourself, or send me your domain and I'll send you what your records currently say, in plain language, with no jargon and nothing to buy. If it's useful, I'll keep watching them for ninety days and tell you if anything changes — I run that monitoring already and adding one more domain costs me nothing.

No call, no pitch. Just what's there.