Still to forskjellige DNS spørsmål
En MX sjekk spør hvor e-post adressert til et domene skal leveres. En omvendt DNS-sjekk spør hvilket vertsnavn som er knyttet til en IP-adresse, etterfulgt av om det vertsnavnet går tilbake til den relevante adressen. Ingen av spørsmålene måler avsenderens omdømme eller beviser meldingsautentisering. Ved å holde dem adskilt forhindrer du en vanlig feil: å inspisere et domenes inngående gateway og anta at det også er serveren som sender applikasjonsposten.
Dette er en tolkningsguide med en bevisst fiktiv DNS armatur, ikke en fungerende kontrollør eller en live domenerapport. Ingen oppslag eller SMTP tilkobling ble utført. En implementert kontrollør vil trenge eksplisitte input, registrerte observasjoner, tester med forventet resultat og forklaringer på ufullstendige svar før utdataene kan støtte en operasjonell beslutning.
Tolk mottaksruten gjennom MX
En MX -ressurspost inneholder en preferanseverdi og et utvekslingsvertsnavn. Lavere preferanseverdier prøves før høyere; de er ikke prosenter eller en garanti for at en bestemt server vil godta en melding. RFC 1035 definerer posten, og RFC 5321 forklarer SMTP målvalg. Ta vare på alle relevante MX post og adresseoppløsningsresultatene for målene.
Skille en brukbar mottaksrute fra bare et svar. Et MX mål trenger passende adresseoppføringer; et mål presentert som et CNAME er ikke en gyldig erstatning under SMTP -måloppløsningsreglene. En uoppnåelig adresse, midlertidig DNS feil eller utilgjengelig SMTP tjeneste krever en annen forklaring enn en misformet MX . Ikke utlede transporttilgjengelighet fra DNS alene.
Ingen MX svar betyr ikke alltid at et domene ikke kan motta e-post. SMTP kan bruke en implisitt MX under betingelsene i RFC 5321 , mens RFC 7505 definerer en eksplisitt null MX : preferanse null med rotnavnet som utveksling. En null MX kunngjør ingen mottakstjeneste og må ikke eksistere side om side med andre MX poster. Hold den tilsiktede tilstanden forskjellig fra manglende data og fra en ødelagt mottakskonfigurasjon.
Start omvendt DNS fra den faktiske avsenderadressen
Identifiser den offentlige IP-en som koblet til mottakeren for meldingen som undersøkes. Et selskaps nettstedsadresse, inngående MX adresse og utgående tjenesteadresse kan alle variere. Med en outsourcet plattform kan den relevante revers-DNS-eieren være tjeneste- eller IP-space-operatøren i stedet for organisasjonen som kontrollerer det synlige From-domenet.
Inspiser PTR svaret for den adressen og løs deretter vertsnavnet i den tilsvarende adressefamilien. For personlig Gmail levering, Googles avsenderveiledning krever at den offentlige IP-adressen til avsenderserveren har samsvarende omvendt og videresende DNS . Dette er mottakerspesifikk publisert veiledning, ikke en garanti for aksept fra Gmail eller alle andre leverandører. Registrer den sjekkede IP-en og vertsnavnet slik at en annen operatør kan reprodusere forholdet.
Et PTR vertsnavn trenger ikke å tolkes som det synlige From-domenet, en DKIM underskriver eller bevis på at organisasjonen godkjente meldingen. Disse identitetene tjener forskjellige formål. SPF evaluerer dens spesifiserte konvoluttidentitet og kilde, mens DMARC avhenger av justerte autentiserte identifikatorer. En vellykket forover-og-bakover-kamp kan ikke erstatte noen av evalueringene.
Les et minimalt fiktivt innslag
Anta at det oppfunnede domenet inbound.example har en MX post med preferanse 10 som peker på mx.inbound.example , hvis En rekord er 192.0.2.10 . Det forventede svaret på den foreslåtte MX spørringen identifiserer den utvekslingen; det forventede A-svaret oppgir mottaksadressen. Disse dokumentasjonsnavnene og -adressene er en forfattet inventar, ikke innhentet utdata. Avhengigheten som er illustrert er innkommende SMTP ruting for mottakere på inbound.example .
Separat, anta at en oppfunnet utgående server bruker 192.0.2.25 . Det forventede PTR svaret for 25.2.0.192.in -addr.arpa peker på outbound.example , og det forventede A-svaret for outbound.example inkluderer 192.0.2.25 . Dette illustrerer et foroverbekreftet revers-DNS-forhold for den senderadressen. Det etablerer ikke et MX forhold, et positivt rykte eller vellykket levering.
En implementering bør også teste en PTR som peker til et vertsnavn hvis videresendte svar utelater den opprinnelige adressen, en null MX , en implisitt-MX-tilfelle og en midlertidig løserfeil. Spesifiser det tiltenkte resultatet før du kjører hver armatur. Ikke endre en ekte PTR eller MX bare for å få et diagnostisk display til å se grønt ut.
Bevar feil i stedet for produksjonssikkerhet
Lagre det nøyaktige søkenavnet, typen, serveren eller løseren, observasjonstid, responsstatus og relevante seksjoner. Et tomt svar kan følge med et alias, henvisning eller negativt svar; RFC 2308 forklarer distinksjoner som en brikke må beholde. En timeout eller SERVFAIL kan ikke ommerkes som bevis på at det ikke finnes noen post. Bufret og autoritative svar kan variere uten at det er en utskrift av det en tidligere mottaker så.
Rapporter rutingfunn, omvendt DNS-konsistens, autentisering og omdømme som separate dimensjoner. Hvis en leverandør avviser en melding, behold dens fullstendige diagnostikk, tidsstempel og rute sammen med DNS beviset. EN blokkeringsliste resultat, en SPF feil og en MX feilkonfigurasjon krever forskjellige eiere og rettsmidler. DNS konformitet kan fjerne én hindring mens klager, innhold, kompromitterte kontoer eller mottakerpolicy fortsetter å påvirke leveringen.
Definer det nyttige resultatet og den gjenværende porten
En pålitelig utgang navngir avhengigheten som er testet, observasjonen som støtter den og neste godkjente verifiseringstrinn. For et problem med innkommende rute kan det bety å bekrefte den tiltenkte utvekslingen med postoperatøren. Til omvendt DNS, kan det bety å be eieren av adresseområdet om å gjennomgå det observerte misforholdet. Ingen av trinnene autoriserer publisering av endringer eller sending av testpost automatisk.
Det eksakte originale beviskravet forblir åpent: Et minimalt DNS eksempel med forventet spørringssvar og den spesifikke e-postavhengigheten det støtter. Den fiktive armaturen gir et illustrativt design, ikke et utført akseptresultat. Det separate inntaket krever også implementering og testing av den lovede funksjonen. Inntil faktiske observasjoner og bevis for arbeidskontroll foreligger, behold sidens guideetikett og ikke representer den som en diagnostisk tjeneste.