Fai due diverse domande DNS
Un controllo MX chiede dove deve essere consegnata la posta indirizzata a un dominio. Un controllo DNS inverso chiede quale nome host è associato a un indirizzo IP, seguito dal fatto se quel nome host si risolve nell'indirizzo pertinente. Nessuna delle due domande misura la reputazione del mittente o dimostra l'autenticazione del messaggio. Mantenerli separati previene un errore comune: ispezionare il gateway in entrata di un dominio e presupporre che sia anche il server che invia la posta dell'applicazione.
Questa è una guida interpretativa con un dispositivo DNS deliberatamente fittizio, non un controllore funzionante o un rapporto sul dominio attivo. Non è stata eseguita alcuna ricerca o connessione SMTP . Un controllore implementato avrebbe bisogno di input espliciti, osservazioni registrate, test sui risultati attesi e spiegazioni per risposte incomplete prima che il suo output possa supportare una decisione operativa.
Interpretare il percorso di ricezione tramite MX
Un record di risorse MX contiene un valore di preferenza e un nome host di Exchange. I valori di preferenza più bassi vengono provati prima di quelli più alti; non sono percentuali o una garanzia che un particolare server accetterà un messaggio. RFC 1035 definisce il record e RFC 5321 spiega la selezione della destinazione SMTP . Conserva ogni elemento rilevante Record MX e i risultati della risoluzione degli indirizzi per i suoi obiettivi.
Distinguere un percorso di ricezione utilizzabile da una semplice risposta. Una destinazione MX necessita di record di indirizzi appropriati; un obiettivo presentato come a CNAME non è un sostituto valido secondo le regole di risoluzione della destinazione SMTP . Un indirizzo irraggiungibile, un errore DNS temporaneo o un servizio SMTP non disponibile richiedono una spiegazione diversa da un MX non valido. Non dedurre la disponibilità del trasporto solo dal DNS .
Nessuna risposta MX non significa sempre che un dominio non possa ricevere posta. SMTP può utilizzare un MX implicito secondo le condizioni della RFC 5321 , mentre RFC 7505 definisce un MX null esplicito: preferenza zero con il nome root come exchange. Un MX nullo annuncia l'assenza di servizi di ricezione e non deve coesistere con altri record MX . Mantieni quello stato intenzionale distinto dai dati mancanti e da una configurazione di ricezione interrotta.
Avvia DNS inverso dall'indirizzo di invio effettivo
Identificare l'IP pubblico che si è connesso al destinatario per il messaggio in esame. L'indirizzo del sito Web di un'azienda, l'indirizzo MX in entrata e l'indirizzo del servizio in uscita possono essere diversi. Con una piattaforma in outsourcing, il relativo proprietario del DNS inverso può essere l'operatore del servizio o dello spazio IP piuttosto che l'organizzazione che controlla il dominio Da visibile.
Esamina la risposta PTR per quell'indirizzo e quindi risolvi il suo nome host nella famiglia di indirizzi corrispondente. Per la consegna Gmail personale, Guida al mittente di Google richiede che l'IP pubblico del server di invio abbia DNS inversi e diretti corrispondenti. Si tratta di linee guida pubblicate specifiche del destinatario, non di una garanzia di accettazione da parte di Gmail o di qualsiasi altro provider. Registra l'IP e il nome host controllati in modo che un altro operatore possa riprodurre la relazione.
Un nome host PTR non deve essere interpretato come il dominio Da visibile, a DKIM firmatario o prova che l'organizzazione ha autorizzato il messaggio. Queste identità hanno scopi diversi. SPF valuta l'identità e la fonte della busta specificata, mentre DMARC dipende da identificatori autenticati allineati. Una corrispondenza avanti e indietro riuscita non può sostituire nessuna delle due valutazioni.
Leggi un appuntamento immaginario minimo
Supponiamo che il dominio inventato inbound.example abbia un record MX con preferenza 10 che punta a mx.inbound.example , il cui Un record è 192.0.2.10 . La risposta prevista alla query MX proposta identifica tale scambio; la risposta A prevista fornisce il suo indirizzo di ricezione. Questi nomi e indirizzi di documentazione sono una struttura creata, non un output catturato. La dipendenza illustrata è il routing SMTP in entrata per i destinatari in inbound.example .
Separatamente, supponiamo che un server in uscita inventato utilizzi 192.0.2.25 . La risposta PTR prevista per 25.2.0.192.in -addr.arpa punta a outbound.example e la risposta A prevista per outbound.example include 192.0.2.25 . Ciò illustra una relazione DNS inverso confermata in avanti per quell'indirizzo di invio. Non stabilisce una relazione MX , una reputazione positiva o una consegna di successo.
Un'implementazione dovrebbe anche testare un PTR che punta a un nome host la cui risposta diretta omette l'indirizzo originale, un MX nullo, un caso MX implicito e un errore temporaneo del risolutore. Specificare il risultato desiderato prima di eseguire ciascuna apparecchiatura. Non modificare un PTR o MX reale semplicemente per far apparire verde il display diagnostico.
Preservare gli errori piuttosto che produrre certezze
Memorizza il nome esatto della query, il tipo, il server o il risolutore, il tempo di osservazione, lo stato della risposta e le sezioni pertinenti. Una risposta vuota può accompagnare un alias, un rinvio o una risposta negativa; RFC 2308 spiega le distinzioni che una pedina deve mantenere. Un timeout o SERVFAIL non può essere rietichettato come prova che non esiste alcun record. Le risposte memorizzate nella cache e quelle autorevoli possono differire senza che siano una trascrizione di ciò che ha visto un destinatario precedente.
Riporta i risultati del routing, la coerenza del DNS inverso, l'autenticazione e la reputazione come dimensioni separate. Se un provider rifiuta un messaggio, conserva la sua diagnostica completa, il timestamp e il percorso insieme alle prove DNS . UN lista bloccata risultato, un SPF un errore e una configurazione errata MX richiedono proprietari e rimedi diversi. La conformità DNS può rimuovere un ostacolo mentre reclami, contenuti, account compromessi o policy del destinatario continuano a influenzare la consegna.
Definire il risultato utile e la porta rimanente
Un output affidabile nomina la dipendenza testata, l'osservazione che la supporta e il successivo passaggio di verifica approvato. Per un problema relativo al percorso in entrata, ciò potrebbe significare confermare lo scambio previsto con l'operatore di posta. Per DNS inverso, potrebbe significare chiedere al proprietario dello spazio degli indirizzi di esaminare la discrepanza osservata. Nessuno dei due passaggi autorizza la pubblicazione di modifiche o l'invio automatico di posta di prova.
L'esatto requisito della prova originale rimane aperto: un esempio DNS minimo con la risposta alla query prevista e la dipendenza di posta specifica che supporta. L'attrezzatura immaginaria fornisce un progetto illustrativo, non un risultato di accettazione eseguito. L'assunzione separata richiede anche l'implementazione e il test della funzione promessa. Fino a quando non esisteranno osservazioni effettive e prove di controllo funzionante, conservare l'etichetta guida della pagina e non rappresentarla come un servizio diagnostico.