Domain email and Workspace

The job

A carrier sending rate confirmations and driver paperwork from a personal Gmail address has a credibility problem and a continuity problem. The credibility problem is obvious the moment a broker looks at the sender. The continuity problem is worse and shows up later: when mail lives in a personal account, the company does not own its own correspondence.

The job was to move everything onto the company domain, make sure it landed in inboxes, and set it up so that adding or removing a person takes two minutes instead of a phone call to whoever knows the password.

What I found

A domain with no mail records to speak of. That is the normal state of a domain that was registered to point at a website, and it is fine right up until something tries to send mail as that domain.

The website’s driver application form was already sending notifications through a third-party handler. Nothing in the DNS said that handler was allowed to send as the domain, so receiving servers had no way to tell it apart from someone spoofing the address. Gmail’s answer to that question is the spam folder, and it was giving that answer consistently.

What broke

The interesting failure was not the setup. It was what happened after.

SPF has a hard limit of ten DNS lookups. Go past it and the record does not degrade politely, it fails: the result is permerror, and a receiving server is entitled to treat that as no SPF at all. Every service you authorize to send mail on your behalf adds lookups, and services that use include: chains add several each without telling you.

Between Workspace, the form handler, and one more sender, the record went over the limit. Everything appeared configured. The DNS was valid. Mail was authenticated right up until it silently was not, and the only visible symptom was that some recipients got mail and others did not, which is the least debuggable symptom there is.

The other thing I got wrong was moving too fast on DMARC. Publishing an enforcing policy before you know every legitimate sender means you are the one blocking your own mail. I published p=none first, read the aggregate reports for a few weeks, and found a sender I had forgotten about entirely. Had I gone straight to p=reject, that mail would have vanished with no bounce and no notification to anyone.

The fix

Count the lookups. The SPF record is now flattened where it needs to be and audited whenever a sender is added. Anything that wants to send as this domain gets added deliberately, not because a setup wizard suggested it.

Stage DMARC. Start at p=none with aggregate reports going somewhere a person will actually read them. Watch for a few weeks. Confirm every legitimate sender is aligned. Then tighten. The reports are the whole point; publishing a policy without reading them is a guess with consequences.

Structure the account, not just the mailboxes. Role addresses for dispatch and recruiting rather than personal ones, so a role can change hands without a forwarding rule. Groups instead of distribution lists maintained by hand. Two-factor enforced across the domain. Drive organized so the paperwork automation has a stable place to file into, since an automation that writes into a folder structure someone reorganizes by hand is an automation with a countdown on it.

I still run this. Adding a driver, rotating an address, checking why a specific message bounced. Administration is not a project you finish, it is a thing you keep doing, and most of the value shows up in the weeks nobody notices anything.

What I’d do differently

I would have set up the DMARC report mailbox on day one, before touching anything else. I configured senders first and turned on reporting afterward, which meant my first few weeks of evidence about who was sending mail as this domain simply do not exist. That data would have made the whole migration faster, and I had to wait to collect it again.

I would also write down the sender inventory somewhere other than my own memory. There is now a document. There should have been one from the start.