Columbia Games / August 2026
Email is not an MX record: routing, sending and authentication had to be separated
The hosting migration made email the clearest example of why treating 'mail' as one box is dangerous. Incoming addresses, application-generated transactional mail and domain authentication needed separate lifecycles.
Situation
During the server migration, email became a risk area of its own. Moving a website does not mean the domain's mail system has to move with it, yet the two are easy to couple accidentally. In the Columbia Games environment, incoming addresses and aliases, transactional messages sent by applications, and SPF, DKIM and DMARC authentication all had to remain correct at the same time. The same user-visible symptom — a message not arriving — can mean entirely different failures depending on whether the problem is routing, the sending application, DNS or the recipient's spam filtering. If all of those are treated as one mail configuration, troubleshooting quickly becomes random experimentation with MX and TXT records rather than diagnosis.
Approach
I separated the roles first. Incoming routing and aliases became their own service layer and could not depend on whichever web server happened to host WordPress or commerce. Application-generated mail kept a separate sending path with its own configuration and verification. Domain authentication became the third layer: SPF defines which systems may send on behalf of the domain, DKIM signs the actual message, and DMARC defines policy and feedback when the first two do not align. Acceptance testing was therefore not 'I sent myself a Gmail and it arrived'. We verified inbound routing, forwarding, transactional sending and the authentication results in message headers. DNS changes were timed so a web cutover would not unnecessarily drag email along with it, and so a failure could be traced back to the exact layer that needed attention.
Outcome
Email stopped being a service that merely 'worked somehow on the server'. A routing change no longer implied an application change, a WordPress or commerce deployment did not inherently threaten incoming mailboxes, and delivery failures could be investigated specifically at the sending or domain-authentication layer. This separation also simplified later operations: changing a provider or server did not require reinventing the entire mail chain because each component had a defined responsibility and a known way to prove that it worked.