MX poster fortælle SMTP klienter, hvor et domæne modtager mail. De autoriserer ikke i sig selv en tjeneste til at sende som det pågældende domæne. En pålidelig modtageopsætning kræver brugbare udvekslingsværtsnavne, tilgængelige SMTP slutpunkter og en plan for midlertidig fejl, ikke blot et grønt MX opslag.
Fortolk præferencer korrekt
Referencer: RFC 5321 §5.1, RFC 2181 §10.3.
Hver MX post indeholder en numerisk præference og et Exchange-værtsnavn. Lavere præferencenumre prøves før højere tal. Når der ikke er nogen klar grund til at favorisere en destination med samme præference, kræver RFC 5321 , at deres rækkefølge tilfældiges for at sprede belastningen. Deres rækkefølge i et DNS svar er ikke en stabil primær-server-betegnelse. Alle annoncerede ruter skal være beregnede og operationelle.
Et Exchange-værtsnavn skal have brugbare A- eller AAAA-poster og må ikke være en CNAME. Indsæt ikke en IP-literal i MX udvekslingsfeltet. Løs hver udveksling separat, og test derefter den annoncerede SMTP tjeneste. Et adressesvar kan ikke alene vise, om slutpunktet accepterer mail for modtagerdomænet.
Skeln fraværende, ubrugelig og null MX
Referencer: RFC 5321 §5.1, RFC 7505 §3.
SMTP har en implicit MX-regel, når et vellykket opslag ikke returnerer nogen MX poster: det behandler selve domænet som målet og leder efter dets adresseposter. Dette er ikke tilladelse til at ignorere brudte eksplicitte MX poster og bruge domænets webstedsadresse i stedet. En midlertidig DNS fejl adskiller sig også fra et definitivt fravær og fører normalt til kø og genforsøg.
En null MX er en eksplicit erklæring om, at domænet ikke accepterer mail: en enkelt MX med præference nul og rodetiketten som udveksling, almindeligvis vist som 0 .. RFC 7505 siger ikke at publicere andre MX poster ved siden af den. Ingen MX og null MX er derfor forskellige konfigurationer.
Arbejd gennem routing-armaturer
Syntetisk armatur A har example.com. MX 10 mx1.example.com. og example.com. MX 20 mx2.example.com.. Den første vært har A 192.0.2.10; den anden har A 192.0.2.20. Forventet præferencerækkefølge er mx1 før mx2. En mislykket forbindelse til mx1 kan forårsage endnu et tilladt leveringsforsøg; det beviser ikke, at mx2 accepterede beskeden.
Fixtur B fjerner begge MX poster, men forlader example.com. A 192.0.2.30. Under implicit-MX-reglen bliver denne adresse den potentielle SMTP destination. Fixture C udgiver i stedet kun example.com. MX 0 .; forventede fortolkning er, at domænet ikke accepterer mail. Fixtur D beholder A's MX poster, men fjerner begge centralers adresser. Det forventede resultat er ubrugelige eksplicitte ruter, ikke tilbagefald til spidsen En rekord.
Genskab DNS delen i et laboratorium ved at forespørge MX for hver isoleret armatur og A/AAAA for hver returneret udveksling. Registrer den valgte rækkefølge og klassifikation. Brug en kontrolleret SMTP server til at prøve igen og acceptere, hvis det er nødvendigt. Dokumentationen omhandler og beskrevne resultater er illustrative, ikke produktionsmålinger.
Bekræft forretningsruten
Referencer: RFC 7208 §5.4, RFC 5321 §4.2.5.
Hold indgående routing adskilt fra SPF politik. En SPF mx mekanisme kan eksplicit gøre MX-associerede adresser relevante for en SPF evaluering, men udgivelse af MX alene skaber ikke denne autorisation. Ændring af indgående udbydere kan derfor også påvirke en eksisterende SPF politik, der bruger mx og fortjener en særskilt anmeldelse.
Under en migrering skal du kontrollere modtagerklargøring, SMTP svar og transportsikkerhed på alle aktive udvekslinger, før du fjerner den gamle rute. En backup-udveksling kan acceptere spam eller afvise legitime modtagere, hvis den er konfigureret anderledes. Registrer, hvem der ejer hvert endepunkt, og hvilke beviser der lukker ændringen; sæt ikke lighedstegn mellem SMTP accept og indbakkeplacering eller et menneske, der læser beskeden.
Fanget isoleret rutekørsel
Den bevarede historiske optagelse, inspiceret til denne gennemgang, men ikke genudført, registrerer, at den 7. november 2026 kl. 20:34:42 UTC returnerede en udført loopback-armatur MX sættet 10 mx1.example.com. og 20 mx2.example.com. fra 127.0.0.1 port 42125. En Python 3.12.14 klient, der bruger dnspython 2.9.2, sorterede disse præferencer. Det eksplicitte lab-endepunktskort sendte mx1 til 127.0.0.1 port 45271 og mx2 til port 37481; dette portkort erstatter kun offentlig port-25-ruting inden for armaturet.
Med begge lyttere kørende, vendte mx1 tilbage 220, accepteret EHLO med 250, accepteret MAIL FRA og RCPT TIL med 250, indtastet DATA med 354 og vendte tilbage 250 syntetiske meddelelser accepteret; kasseres lokalt. Efter kun at have lukket den primære lytter, blev den næste kørsel optaget ConnectionRefusedError for mx1 og den samme acceptsekvens ved mx2. Ingen ekstern post, reel modtager eller postkasselevering var involveret.
For at reproducere skal du starte to loopback SMTP armaturer, forespørge lab MX responderen, kortlægge dens udvekslingsnavne til lytterne og sende en harmløs syntetisk besked med Python smtplib. Gentag efter lukning af den primære. Bevar trådsvaret, endepunktskortet, klient/server-transskriptionen, tidsstempler og værktøjsversioner. Det opfangede armatur bruger en bevidst lille SMTP server og demonstrerer kun præferencedrevet genforsøg; det er ikke en overensstemmelsestest af en produktion MTA eller bevis på produktionsfejl.
Hold bevisets omfang eksplicit
Det arkiverede transkript bekræfter kun loopback-fixturens adfærd beskrevet ovenfor, inklusive dens tilpassede portkortlægning og lokale kassering. Kildefangsten og selen bibeholdes uændret; denne anmeldelse gentog ikke SMTP trafik eller udledte produktionsfailover fra den historiske test.