Columbia Games / 2026. augusztus
Az e-mail nem egy MX rekord: külön kellett választani a routingot, a küldést és a hitelesítést
A hostingváltás az e-mailnél mutatta meg igazán, mennyire veszélyes egyetlen 'levelezés' dobozként gondolni a rendszerre. A bejövő címek, az alkalmazásból küldött tranzakciós levelek és a domain hitelesítése külön életciklust kaptak.
A helyzet
A szervermigráció közben az e-mail külön kockázati területté vált. Egy weboldal költözése önmagában nem jelenti azt, hogy a domainhez tartozó levelezésnek is ugyanoda kell költöznie, mégis könnyű véletlenül összekötni a kettőt. A Columbia Games környezetében egyszerre kellett gondolni a bejövő címekre és aliasokra, az alkalmazások által küldött tranzakciós levelekre, valamint arra, hogy a domain SPF, DKIM és DMARC szempontból hiteles maradjon. Ugyanaz a felhasználói tünet — például hogy egy levél nem érkezik meg — teljesen más hibát jelenthet attól függően, hogy a routing, a küldő alkalmazás, a DNS vagy a fogadó fél spamellenőrzése hibázik. Ha ezeket egyetlen mail konfigurációnak tekintjük, a hibakeresésből hamar MX- és TXT-rekordok próbálgatása lesz valódi diagnózis nélkül.
A megoldási út
Először a szerepeket választottam szét. A bejövő levelek routingja és az aliasok önálló szolgáltatási réteget kaptak; ez nem függhetett attól, hogy éppen melyik webszerver szolgálja ki a WordPresst vagy a commerce rendszert. Az alkalmazásokból induló levelek külön küldési útvonalon maradtak, saját konfigurációval és ellenőrzéssel. Harmadik rétegként kezeltem a domain hitelesítését: az SPF azt mondja meg, mely rendszerek küldhetnek a domain nevében, a DKIM a tényleges üzenetet írja alá, a DMARC pedig szabályt és visszajelzési keretet ad arra, mi történjen, ha az előző kettő nem stimmel. A váltásnál nem az volt az acceptance teszt, hogy 'küldtem magamnak egy Gmailt és megjött'. Ellenőrizni kellett a bejövő routingot, a továbbítást, a tranzakciós küldést és a levél fejléceiben a hitelesítési eredményt is. A DNS-változtatásokat úgy kellett időzíteni, hogy egy webes cutover ne rántsa magával szükségtelenül a levelezést, és probléma esetén pontosan tudjuk, melyik réteghez kell visszanyúlni.
Mi lett belőle
A levelezés ezzel levált a 'szerveren valahogy működő' szolgáltatás szerepéről. Egy routingmódosítás többé nem jelentett automatikusan alkalmazásmódosítást, egy WordPress- vagy commerce-deploy nem veszélyeztette szükségszerűen a bejövő postafiókokat, és egy kézbesítési probléma esetén célzottan lehetett vizsgálni a küldést vagy a domain hitelesítését. Ez az elválasztás később az üzemeltetést is egyszerűbbé tette: szolgáltató- vagy szerverváltásnál nem kellett a teljes levelezési láncot újra feltalálni, mert megvolt, hogy melyik komponensnek mi a feladata és hogyan bizonyítjuk a működését.