MX poster berätta för SMTP klienter var en domän tar emot e-post. De godkänner inte själva att en tjänst skickas som den domänen. En pålitlig mottagningsinställning kräver användbara utbytesvärdnamn, nåbara SMTP slutpunkter och en plan för tillfälligt fel, inte bara en grön MX uppslagning.
Tolka preferenser korrekt
Referenser: RFC 5321 §5.1, RFC 2181 §10.3.
Varje MX post innehåller en numerisk inställning och ett utbytesvärdnamn. Lägre preferensnummer prövas före högre nummer. När det inte finns någon tydlig anledning att gynna en destination med samma preferens, kräver RFC 5321 att deras ordning slumpas för att sprida lasten. Deras ordning i ett DNS svar är inte en stabil primärserverbeteckning. Alla annonserade rutter bör vara avsedda och fungerande.
Ett utbytesvärdnamn måste ha användbara A- eller AAAA-poster och får inte vara ett CNAME. Lägg inte en IP-literal i MX utbytesfältet. Lös varje utbyte separat och testa sedan den annonserade SMTP tjänsten. Enbart ett adresssvar kan inte visa om slutpunkten accepterar post för mottagardomänen.
Särskilj frånvarande, oanvändbar och null MX
Referenser: RFC 5321 §5.1, RFC 7505 §3.
SMTP har en implicit MX-regel när en lyckad sökning inte returnerar några MX poster: den behandlar själva domänen som målet och letar efter dess adressposter. Detta är inte tillåtelse att ignorera brutna explicita MX poster och använda domänens webbadress istället. Ett tillfälligt DNS fel skiljer sig också från en definitiv frånvaro och leder normalt till kö och försök igen.
En null MX är ett uttryckligt uttalande att domänen inte accepterar e-post: en enda MX med inställningen noll och rotetiketten som utbyte, vanligen visas som 0 .. RFC 7505 säger att man inte ska publicera andra MX poster bredvid den. Ingen MX och noll MX är därför olika konfigurationer.
Arbeta igenom routing fixturer
Syntetfixtur A har example.com. MX 10 mx1.example.com. och example.com. MX 20 mx2.example.com.. Den första värden har A 192.0.2.10; den andra har A 192.0.2.20. Förväntad preferensordning är mx1 före mx2. En misslyckad anslutning till mx1 kan orsaka ytterligare ett tillåtet leveransförsök; det bevisar inte att mx2 accepterade meddelandet.
Fixtur B tar bort båda MX posterna men lämnar example.com. A 192.0.2.30. Enligt implicit-MX-regeln blir den adressen den potentiella SMTP destinationen. Fixtur C publicerar istället bara example.com. MX 0 .; förväntad tolkning är att domänen inte accepterar någon post. Fixtur D behåller A:s MX poster men tar bort båda börsens adresser. Förväntat resultat är oanvändbara explicita vägar, inte fallback till spetsen Ett rekord.
Reproducera DNS delen i ett labb genom att fråga MX för varje isolerad fixtur och A/AAAA för varje returnerad utbyte. Anteckna den valda ordningen och klassificeringen. Använd en kontrollerad SMTP server för att testa igen och acceptera om det behövs. Dokumentationen tar upp och beskrivna utfall är illustrativa, inte produktionsmått.
Verifiera affärsvägen
Referenser: RFC 7208 §5.4, RFC 5321 §4.2.5.
Håll inkommande routing åtskild från SPF politik. En SPF mx mekanism kan uttryckligen göra MX-associerade adresser relevanta för en SPF utvärdering, men endast publicering MX skapar inte den auktoriseringen. Att byta inkommande leverantör kan därför också påverka en befintlig SPF policy som använder mx och förtjänar en separat recension.
Under en migrering, verifiera mottagarprovisionering, SMTP svar och transportsäkerhet på alla aktiva utbyten innan du tar bort den gamla rutten. En säkerhetskopiering kan acceptera skräppost eller avvisa legitima mottagare om den är konfigurerad på annat sätt. Registrera vem som äger varje endpoint och vilka bevis som stänger förändringen; likställ inte SMTP acceptans med placering i inkorgen eller en människa som läser meddelandet.
Fångad isolerad routingkörning
Den bibehållna historiska insamlingen, inspekterad för denna granskning men inte omkörd, registrerar att den 7 november 2026 kl. 20:34:42 UTC returnerade en utförd loopback-fixtur MX setet 10 mx1.example.com. och 20 mx2.example.com. från 127.0.0.1 port 42125. En Python 3.12.14-klient som använder dnspython 2.9.2 sorterade dessa inställningar. Den explicita labbändpunktskartan skickade mx1 till 127.0.0.1 port 45271 och mx2 till port 37481; denna portkarta ersätter offentlig port-25 routing endast inom fixturen.
Med båda lyssnarna igång kom mx1 tillbaka 220, accepterat EHLO med 250, accepterat MAIL FRÅN och RCPT TO med 250, angav DATA med 354 och återvände 250 syntetiskt meddelande accepterat; kasseras lokalt. Efter att endast den primära lyssnaren stängts, spelades nästa körning in ConnectionRefusedError för mx1 och samma acceptanssekvens vid mx2. Ingen extern post, riktig mottagare eller postlådeleverans var inblandad.
För att reproducera, starta två loopback SMTP fixturer, fråga lab- MX -svararen, mappa dess utbytesnamn till lyssnarna och skicka ett ofarligt syntetiskt meddelande med Python smtplib. Upprepa efter att ha stängt den primära. Behåll trådsvaret, ändpunktskartan, klient/server-transkript, tidsstämplar och verktygsversioner. Den fångade fixturen använder en avsiktligt liten SMTP server och visar endast preferensdrivna försök; det är inte ett överensstämmelsetest av en produktion MTA eller bevis på produktionsfel.
Håll bevisens omfattning tydlig
Det arkiverade transkriptet bekräftar endast loopback-fixturens beteende som beskrivs ovan, inklusive dess anpassade portmappning och lokala kassering. Källfångsten och selen bibehålls oförändrade; den här granskningen upprepade inte SMTP trafik eller slutade inte till produktionsfel från det historiska testet.