Case Study Email Authentication

One spam folder problem. Three layers of cause.

A small business owner's outbound email was going to spam without his knowing it. When I traced it, most of his franchise network had the same misconfiguration, and it went back to a hosting provider's default account setup.

Industry: Service franchise Platform: Google Workspace Status: Diagnosed and reported
Email Authentication Case Study

How it came up

I met the owner at a local networking event. He runs a regional franchise in a service industry, with a professional website and Google Workspace for email. From the outside, everything looked set up correctly.

A few days later we were emailing to follow up on the meeting, and his messages showed up in my inbox with a warning: they had failed authentication checks. Most of the people he emails would never see that warning. Their mail server would just put the message in spam, or drop it, and say nothing. He had no idea.

1 Layer 1 of 3

The authentication gap on his domain

It didn't take long to find. Nothing on his domain was telling receiving mail servers that his messages really came from him, so to a spam filter, his email looked the same as someone pretending to be him. Spam filters are built to be cautious, and this one was.

The fix involves three authentication records, called SPF, DKIM, and DMARC, that get added to your domain separately from your email platform. His were either missing or incomplete.

He was on the right platform. Google Workspace is a sound choice for a business his size. The missing step happens in a different system, and you have to know what to add.

This is common. Signing up for Google Workspace doesn't add these records for you, and most owners who set it up on their own skip the step because nothing visibly breaks. Their email still sends. It just goes to spam more often than they know.

"His email still sent. It just went to spam more often than he knew."
2 Layer 2 of 3

The same gap, across most of the network

I was curious, so I checked the DNS records for a handful of other locations in the same franchise network. They had different operators in different markets, all under the same parent brand.

Most of them had the same gap. Their authentication records were missing or incomplete.

New franchise operators follow a standard setup process when they launch. Whatever setup guidance the franchisor gave them, it didn't cover email authentication on the operator's domain, so everyone who followed it ended up with the same gap. The problem came from how the franchise set up new locations.

3 Layer 3 of 3

Where the default came from

I went one step further. Most locations in the network use the same hosting provider, and when I checked that provider's own domain, it had the same gaps.

The provider's default setup for a new customer's website doesn't include email authentication records. Customers who don't know to add them end up with the gap, and the franchisor built its setup process for new operators on top of that default.

So one provider's default, copied through a franchise's launch process, sent email from most of the network to spam. None of the operators had done anything wrong. They had followed the setup process exactly as designed.

"None of the operators had done anything wrong. They had followed the setup process exactly as designed."

What the fix is, and whose it is to make

For any single operator in this network, the fix is the same: add the three authentication records to the domain. It's a one-time change, and nobody has to switch email platforms or hosting providers or change how they send email day to day. Once the records are in place, they work in the background with no upkeep.

For the owner I met, the fix is in the domain settings only, because he's already on the right platform: correct the existing SPF record, turn on DKIM in Google Workspace, and publish a DMARC policy.

I didn't make that change. I told him what I'd found, what was causing it, and what the fix was. His domain is his to change, and the fix is his to make or hand to someone. As far as I know, it hasn't been made yet.

Estimated time to fix Under two hours
Status Diagnosed and reported to the owner

Why this keeps happening

Cases like this are common. Sometimes it's a franchise network. Sometimes it's a web developer who followed a tutorial written before these records were standard, or a business that switched email platforms and left the old records behind. Usually the owner didn't cause the problem; they inherited it from whoever set things up.

From the outside it looks like a communication problem. Proposals go unanswered. Follow-ups seem to disappear. Clients say they never got something the owner is sure they sent. The real cause, a domain that mail servers don't trust, stays invisible until someone looks for it.

Most small business owners have no reason to look, and checking means knowing what SPF, DKIM, and DMARC are and what a correct setup looks like. Nobody running a plumbing company or an accounting office should have to know that. They should be able to assume their email works, and a lot of the time it doesn't.

Not sure if your domain is configured correctly?

With the email fix, I check your authentication records and fix anything missing or wrong. It's $200 to set up the Google Workspace, Microsoft 365, or Fastmail account you already have, or $350 to move you to one of them and set it up. If it isn't fixed and working when I'm done, you don't pay.

See the email fix Book a free 20-minute chat

The chat is free. I'll check what you have and tell you whether anything needs fixing before any work starts.

Get practical notes on small business operations in your inbox.

Every so often I send a short note about something I fixed for a small business, or a tool worth knowing about.