Stil to forskellige DNS spørgsmål
Et MX tjek spørger, hvor mail adresseret til et domæne skal leveres. Et omvendt DNS-tjek spørger, hvilket værtsnavn der er knyttet til en IP-adresse, efterfulgt af om dette værtsnavn går tilbage til den relevante adresse. Ingen af spørgsmålene måler afsenderens omdømme eller beviser meddelelsesgodkendelse. Ved at holde dem adskilt forhindrer du en almindelig fejl: at inspicere et domænes indgående gateway og antage, at det også er serveren, der sender dets applikationsmail.
Dette er en fortolkningsvejledning med et bevidst fiktivt DNS armatur, ikke en fungerende checker eller en live domænerapport. Ingen opslag eller SMTP forbindelse blev udført. En implementeret checker ville have brug for eksplicitte input, registrerede observationer, tests med forventet resultat og forklaringer på ufuldstændige svar, før dens output kunne understøtte en operationel beslutning.
Fortolk modtagerruten gennem MX
En MX ressourcepost indeholder en præferenceværdi og et udvekslingsværtsnavn. Lavere præferenceværdier prøves før højere; de er ikke procenter eller en garanti for, at en bestemt server vil acceptere en besked. RFC 1035 definerer posten, og RFC 5321 forklarer SMTP målvalg. Bevar alle relevante MX record og adresseopløsningsresultaterne for dets mål.
Skeln en brugbar modtagerute fra et simpelt svar. Et MX mål har brug for passende adresseposter; et mål præsenteret som et CNAME er ikke en gyldig erstatning under SMTP -målopløsningsreglerne. En uopnåelig adresse, midlertidig DNS fejl eller utilgængelig SMTP tjeneste kræver en anden forklaring end en forkert udformet MX . Udled ikke transport tilgængelighed fra DNS alene.
Intet MX svar betyder ikke altid, at et domæne ikke kan modtage mail. SMTP kan bruge en implicit MX under betingelserne i RFC 5321 , hvorimod RFC 7505 definerer en eksplicit null MX : præference nul med rodnavnet som udveksling. En null MX annoncerer ingen modtagende service og må ikke eksistere side om side med andre MX poster. Hold den tilsigtede tilstand adskilt fra manglende data og en ødelagt modtagekonfiguration.
Start omvendt DNS fra den faktiske afsenderadresse
Identificer den offentlige IP, der er forbundet til modtageren for den meddelelse, der undersøges. En virksomheds webstedsadresse, indgående MX adresse og udgående tjenesteadresse kan alle være forskellige. Med en outsourcet platform kan den relevante reverse-DNS-ejer være tjeneste- eller IP-space-operatøren snarere end den organisation, der kontrollerer det synlige From-domæne.
Undersøg PTR svaret for den adresse, og find derefter dets værtsnavn i den tilsvarende adressefamilie. Til personlig Gmail levering, Googles afsendervejledning kræver, at den afsendende servers offentlige IP har matchende omvendt og fremadrettet DNS . Det er modtagerspecifik offentliggjort vejledning, ikke en garanti for accept fra Gmail eller enhver anden udbyder. Registrer den kontrollerede IP og værtsnavn, så en anden operatør kan gengive forholdet.
Et PTR værtsnavn skal ikke fortolkes som det synlige From-domæne, en DKIM underskriver eller bevis på, at organisationen har godkendt meddelelsen. Disse identiteter tjener forskellige formål. SPF evaluerer dens specificerede kuvertidentitet og kilde, mens DMARC afhænger af justerede autentificerede identifikatorer. En vellykket frem-og-tilbage-kamp kan ikke erstatte nogen af evalueringerne.
Læs et minimalt fiktivt inventar
Antag, at det opfundne domæne inbound.example har en MX record med præference 10, der peger på mx.inbound.example , hvis En rekord er 192.0.2.10 . Det forventede svar på den foreslåede MX forespørgsel identificerer denne udveksling; det forventede A-svar angiver modtageradressen. Disse dokumentationsnavne og -adresser er en forfattet fixtur, ikke indfanget output. Den illustrerede afhængighed er indgående SMTP routing for modtagere på inbound.example .
Antag separat, at en opfundet udgående server bruger 192.0.2.25 . Det forventede PTR svar for 25.2.0.192.in -addr.arpa peger på outbound.example , og det forventede A-svar for outbound.example inkluderer 192.0.2.25 . Dette illustrerer et fremadbekræftet omvendt DNS-forhold for den afsenderadresse. Det etablerer ikke et MX forhold, et positivt omdømme eller vellykket levering.
En implementering bør også teste en PTR der peger på et værtsnavn, hvis videregående svar udelader den oprindelige adresse, en null MX , en implicit-MX-case og en midlertidig resolverfejl. Angiv det tilsigtede resultat, før du kører hvert armatur. Ændr ikke en rigtig PTR eller MX blot for at få et diagnostisk display til at se grønt ud.
Bevar fejl frem for fremstillingssikkerhed
Gem det nøjagtige forespørgselsnavn, type, server eller resolver, observationstid, svarstatus og relevante sektioner. Et tomt svar kan ledsage et alias, henvisning eller negativt svar; RFC 2308 forklarer distinktioner, som en brik skal beholde. En timeout eller SERVFAIL kan ikke ommærkes som bevis på, at der ikke findes nogen registrering. Cachelagrede og autoritative svar kan være forskellige uden enten at være en udskrift af, hvad en tidligere modtager så.
Rapportér routingfund, omvendt DNS-konsistens, autentificering og omdømme som separate dimensioner. Hvis en udbyder afviser en meddelelse, skal du beholde dens komplette diagnostik, tidsstempel og rute sammen med DNS beviset. EN blokeringsliste resultat, en SPF fejl og en MX fejlkonfiguration kræver forskellige ejere og løsninger. DNS konformitet kan fjerne én hindring, mens klager, indhold, kompromitterede konti eller modtagerpolitik fortsat påvirker leveringen.
Definer det nyttige resultat og den resterende gate
Et pålideligt output navngiver den testede afhængighed, den observation, der understøtter den, og det næste godkendte verifikationstrin. For et problem med indgående ruter kan det betyde, at du bekræfter den påtænkte udveksling med postoperatøren. For omvendt DNS, kan det betyde, at man beder adresseområdets ejer om at gennemgå den observerede uoverensstemmelse. Ingen af trinene autoriserer udgivelse af ændringer eller automatisk afsendelse af testmail.
Det nøjagtige krav om originalbevis forbliver åbent: Et minimalt DNS eksempel med forventet forespørgselssvar og den specifikke mailafhængighed, det understøtter. Det fiktive armatur leverer et illustrativt design, ikke et udført acceptresultat. Det separate indtag kræver også implementering og test af den lovede funktion. Indtil der findes faktiske observationer og beviser fra arbejdskontrol, skal du beholde sidens guideetikette og ikke repræsentere den som en diagnostisk tjeneste.