How it came up
I met the business owner at a local networking event. He runs a regional franchise in a service-heavy industry: professional website, Google Workspace for email, and by every visible measure a business that is set up correctly.
A few days later, during a routine email exchange following up on the meeting, I noticed something in my inbox. His messages were arriving with a warning flag: the message had not passed authentication checks. Most recipients would never see that flag. Their mail server would simply deliver the email to spam - or silently drop it - without explanation. He had no idea it was happening.
The authentication gap on his domain
The problem was straightforward to diagnose. Every email he sent was leaving his domain unsigned and unverified — nothing was confirming to receiving mail servers that the message actually came from him. To spam filters, his outbound email was indistinguishable from someone impersonating his domain. The filter's job is to err on the side of caution. It was doing exactly that.
The cause was three authentication records — called SPF, DKIM, and DMARC — that have to be added to your domain separately from your email platform. His had either never been configured or had been left incomplete.
He was on the right platform. Google Workspace is a sound choice for a business his size. The issue was not the platform itself — it was a setup step that happens in a different system entirely, and requires knowing what to add.
This is common. Signing up for Google Workspace does not automatically take care of these records. Most business owners who set up Google Workspace without help skip this step because nothing breaks visibly when they do. Their email still sends. It just lands in spam more often than they know.
"His email still sent. It just landed in spam more often than he knew."
The same gap, across most of the network
Out of curiosity, I checked the DNS records for a handful of other franchise locations in the same network - different operators, different markets, same parent brand.
The same configuration gap appeared across most of them. The authentication records were missing, incomplete, or had never been configured at all.
This was not a coincidence.
The franchise model means new operators follow a standard setup process when they launch. Whatever documentation or setup guidance the franchisor provided, it did not include configuring email authentication on the franchisee's domain. Every operator who followed that standard process inherited the same gap. The problem was not isolated to one location: it was baked into how the franchise launched new operators.
Where the default came from
Tracing it one level further: most franchise locations in the network share the same hosting provider. When I checked the hosting provider's own domain, the same authentication gaps were present there as well.
This is the root of the chain.
The hosting provider's standard account setup - the default configuration that ships when a new customer launches a website - does not include email authentication records. Customers who use that provider and do not know to configure these records themselves end up with the same gap. The franchisor built their new operator setup process on top of that default. Every franchisee who followed the process inherited it.
One provider's default configuration, propagated through a franchise model, quietly put an entire network's outbound email in the spam folder. 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 it took to resolve it
For any single operator in this network, the fix is the same: add the three authentication records to the domain. It is a one-time change — it does not require switching email platforms, changing hosting providers, or modifying anything about the day-to-day experience of sending and receiving email. Once in place, the records work continuously in the background with no ongoing maintenance.
For the business owner I met, the fix would have been a configuration-only engagement. He was already on the right platform. The work would have been entirely in the domain settings: correcting the existing SPF record, enabling DKIM through Google Workspace, and publishing a DMARC policy.
Why this keeps happening
This case is not unusual. The specific details vary - sometimes it is a franchise network, sometimes a web developer who followed a tutorial that predates modern authentication standards, sometimes a business that migrated email platforms and left the old records behind. But the pattern is consistent: the small business owner did not cause the problem. They inherited it from a default configuration, a vendor setup process, or a platform that did not handle this step automatically.
The consequence looks like a communication problem from the outside. Proposals go unanswered. Follow-ups seem to disappear. Clients say they never received something the owner is certain they sent. The real cause - an unauthenticated domain that mail servers are treating with suspicion - is invisible until someone looks for it.
Most small business owners have no reason to look. It requires knowing what SPF, DKIM, and DMARC are, knowing where to check them, and knowing what a correct configuration looks like. That is not a reasonable expectation for someone running a franchise operation, a professional services firm, or a local service business. It is reasonable to expect that their email infrastructure is working. In many cases, it is not.