I Scanned 300 Small Business Domains. 243 Had Broken Mail Records.

I ran a mail-record scanner over 300 small business domains, the kind of local shops that send invoices, quotes, and appointment reminders out of their own domain.

243 of them, 81 percent, had at least one defect.

Not a judgment call. A measured defect: no SPF record, an SPF ending in ~all, a DMARC record that enforces nothing, or a DKIM key that has been revoked. The breakdown: 120 domains with no DMARC record at all, 112 with SPF ending in ~all, 73 running DMARC at p=none, 66 with no SPF record at all, and 48 with a DMARC record that collects no reports.

Eighty-one percent. That is not a rounding error. That is the default state of small business email.

THE ONE RECORD NOBODY PUBLISHES

Here is the one I see most and the one almost nobody understands.

A restaurant domain had this in DNS:

v=SPF1 include:spf.easywp.com ~all

and this at _dmarc:

v=DMARC1; p=none;

The SPF is fine. The DKIM is fine. But the DMARC policy says p=none, which tells every receiver on earth: if mail claiming to be from this domain fails both checks, do nothing. Deliver it anyway.

p=none is not enforcement. It is a shrug written in DNS.

The owner thinks they have DMARC because the record exists. They have the appearance of DMARC. Any spammer with a cheap mail server can send "invoices" from their domain, and every receiver will wave it through, because the record they published literally instructs receivers to accept the failure.

Worse: this particular record had no rua tag, so even the reporting, the only reason p=none exists as a testing stage, was switched off. The domain was reporting nothing to nobody.

THE RECORD THAT DOES THE OPPOSITE OF WHAT YOU THINK

Second most common: SPF ending in ~all.

v=spf1 include:secureserver.net ~all

~all is soft fail. It tells receivers: mail from an IP not on this list is suspicious, but you should probably accept it anyway. That is a suggestion. Receivers treat a soft fail as a yellow light and wave most of it through while flagging you for suspicious behavior.

The fix is -all. Hard fail. Any mail from an unauthorized IP is refused.

So why does ~all exist everywhere? Because owners are afraid of locking themselves out. Legitimate fear, wrong remedy. You do not flip to -all on day one. You publish DMARC with a rua reporting address first, at p=none, and let the reports tell you every service actually sending as your domain. You will find one or two you forgot about. Then you authorize them, and then you flip.

The staging is the fix. Nobody does the staging, so everybody sits at ~all forever.

THE DOMAIN WITH NOTHING

And then there is the domain with no SPF and no DMARC at all.

Empty. Both records. No MX record either, so the domain receives no mail and sends with no authentication whatsoever.

Anyone on earth can send mail as this domain. Your bank, your customers, your own employees, and nobody receiving it has any instruction on what is real. That is not a deliverability problem. That is an open door.

This was not a rare find. 66 of the 300 domains had no SPF. 120 had no DMARC. If you are one of them, the question is not whether someone is spoofing you yet. The question is what stops them when they start.

WHY MAIL-TESTER SAYS 10 AND GMAIL SAYS SPAM

The classic trap. You run mail-tester, it says 10/10, and your invoices still land in junk.

Mail-tester grades the message. Gmail grades the domain. A perfect score on a single test message tells you nothing about your domain reputation, and it says nothing about whether your DKIM selector is actually the one your provider signs with.

Half the "10/10 and still spamming" questions I see are a provider mismatch. The domain carries DKIM records for a platform the owner stopped using two years ago, and there are no records for the platform they actually send from today. The stale sender sits in SPF, burning trust. Nobody notices because nothing enforces alignment. A p=none DMARC hides it by design.

You cannot diagnose that from a message grader. You diagnose it from the records.

WHAT TO DO TODAY

Three checks, ten minutes, no tools you have to pay for.

One. Look up your domain's TXT record. If SPF does not exist or ends in ~all or +all, that is your problem. +all is worse than missing: it authorizes the entire internet.

Two. Look up _dmarc.yourdomain.com. If the record does not exist, publish one at p=none with a rua pointing at a mailbox you actually check. That is behavior-identical to what you have now; it cannot break sending, and it starts the reporting engine.

Three. Once a few weeks of reports show every legitimate sender aligning, tighten. ~all to -all. Then p=none to p=quarantine. Then, after another clean window, p=reject. Each stage is its own decision.

Never jump straight to p=reject. That is how a fix becomes an outage, and it is the reason most owners freeze at p=none and call it done.

THE UNCOMFORTABLE QUESTION

I fixed my own domain the same way: staged DMARC, watched the aggregate reports from Google land in my inbox for a day, confirmed every message passing dkim and spf with zero failure reasons, then tightened to -all and p=reject. The Google report confirmed the fix end-to-end. That is the standard, and it is not a high bar.

So: is your domain one of the 243 or one of the 57?

You do not know until you look. Go look.

If you would rather hand the DNS surgery to someone who does it every day, I fix these records the same day, flat $500, and verify the result with real delivered mail: PhantomByte Email Deliverability Rescue Service