Imagine walking into a building where the mail room has three separate forwarding addresses taped to the wall, each written by a different employee, none of them dated. A letter arrives. The clerk picks whichever note is closest. That is roughly what happens when a domain’s DNS records disagree with each other, and it is why so many people conclude that Google Workspace has somehow “decided” their domain is an email provider.
It hasn’t. Google Workspace verifies domains to confirm they are legitimate, and that verification step is about ownership, not classification. There is no hidden category in the system that reclassifies your domain as a mail host. What actually happens is more mundane and, for anyone who works on distributed systems, far more interesting: the domain becomes a contested namespace, and the observed behavior looks like a misidentification when it is really a resolution conflict.
Why This Failure Mode Feels Like Misclassification
I spend most of my time studying how agents build and maintain internal models of the systems they operate in. One pattern shows up constantly, in both software agents and humans debugging infrastructure: when a system produces output that contradicts your mental model, you tend to attribute intent to the system rather than revising your model.
Email is unusually good at triggering this. A domain’s mail behavior is determined by records scattered across several layers, each authoritative for a different question:
- MX records answer “where does mail for this domain go?”
- SPF records answer “which servers are allowed to send as this domain?”
- Verification records answer “does this person actually control this domain?”
None of these records asks or answers “what kind of entity is this domain?” But when they disagree, the resulting behavior is legible as an answer to that question. Mail bounces in odd directions. Messages you sent land in spam. Something upstream appears to have made a judgment about you. It didn’t. It followed three sets of instructions that pointed different ways.
MX Conflicts Are a Consensus Problem
The clearest version of this shows up during migrations. If your domain is currently configured for email through Google Workspace and you add it to another provider, you will be prompted to update MX records to route mail through the new service. That prompt is not a formality. It is the system telling you that two providers cannot both hold authority over the same mail flow.
Setting up Gmail with a custom domain works the same way in reverse: you point your MX records at Google’s mail servers, and mail flow follows. The domain is the address. The MX record is the forwarding instruction. Change the instruction and mail goes elsewhere; leave two instructions in place and you have a split-brain situation with no tiebreaker.
This is a familiar shape from consensus protocols. Two nodes both believe they are the leader. Each behaves correctly given its own view. The failure only becomes visible from outside, in the form of inconsistent results that look arbitrary. DNS has no leader election. You are the leader election.
SPF Is the Record That Punishes Neglect
Deliverability is where this gets expensive. Proper SPF setup and ongoing monitoring matter because SPF is the record that determines whether receiving servers trust mail claiming to come from your domain. The remedy is unglamorous: log into your DNS provider’s management console, look for an existing SPF TXT record starting with v=spf1, and create one if it does not exist, using the value Google Workspace specifies.
Note the word “existing” in that instruction. It carries weight. Domains accumulate SPF entries from marketing tools, ticketing systems, and past providers. Each addition seemed correct at the time. Together they form a policy nobody wrote deliberately.
The Agent Angle
I keep returning to this because it is a preview of a problem that gets worse as automated systems take over more configuration work. An agent managing DNS for a domain faces exactly the situation described above: multiple records, no single source of truth about intent, and a history of changes it did not make. Without a durable record of why each entry exists, the agent can only observe current state and guess. It will make the same attribution error a human makes, and it will make it faster and at greater scale.
The lesson generalizes past email. Any system where configuration is distributed across independent records, mutable by multiple parties, with no provenance tracking, will eventually produce behavior that looks like a decision. Google Workspace still offers professional email services as of 2026, and it still works the way it always has: it reads your records and does what they say.
If the answer surprises you, the records are worth auditing before the platform is worth blaming. Your domain is not misunderstood. It is over-instructed.
đź•’ Published: