Record MX indica ai client SMTP dove un dominio riceve la posta. Non autorizzano, da soli, l'invio di un servizio come quel dominio. Una configurazione di ricezione affidabile richiede nomi host di scambio utilizzabili, endpoint SMTP raggiungibili e un piano per guasti temporanei, non semplicemente una ricerca MX verde.
Interpretare correttamente la preferenza
Riferimenti: RFC 5321 §5.1, RFC 2181 §10.3.
Ogni record MX contiene una preferenza numerica e un nome host di scambio. I numeri di preferenza più bassi vengono provati prima dei numeri più alti. Quando non esiste un motivo chiaro per favorire una destinazione con uguale preferenza, RFC 5321 richiede la randomizzazione dell'ordine per distribuire il carico. Il loro ordine in una risposta DNS non è una designazione stabile del server primario. Tutti i percorsi pubblicizzati dovrebbero essere previsti e operativi.
Un nome host di scambio deve avere record A o AAAA utilizzabili e non deve essere un CNAME. Non inserire un valore letterale IP nel campo dello scambio MX . Risolvi ogni scambio separatamente, quindi testa il servizio SMTP pubblicizzato. La sola risposta all'indirizzo non può mostrare se l'endpoint accetta la posta per il dominio del destinatario.
Distinguere MX assente, inutilizzabile e nullo
Riferimenti: RFC 5321 §5.1, RFC 7505 §3.
SMTP ha una regola MX implicita quando una ricerca riuscita non restituisce record MX : tratta il dominio stesso come destinazione e cerca i suoi record di indirizzo. Questa non è un'autorizzazione per ignorare i record MX espliciti non funzionanti e utilizzare invece l'indirizzo del sito Web del dominio. Anche un errore DNS temporaneo è diverso da un'assenza definitiva e normalmente porta ad accodarsi e riprovare.
Un MX nullo è una dichiarazione esplicita che il dominio non accetta posta: un singolo MX con preferenza zero e l'etichetta root come scambio, comunemente visualizzato come 0 .. RFC 7505 dice di non pubblicare altri record MX insieme ad esso. No MX e null MX sono quindi configurazioni diverse.
Lavora attraverso i dispositivi di instradamento
L'apparecchio sintetico A ha example.com. MX 10 mx1.example.com. E example.com. MX 20 mx2.example.com.. Il primo ospite ha A 192.0.2.10; il secondo ha A 192.0.2.20. L'ordine di preferenza previsto è mx1 prima di mx2. Una connessione fallita a mx1 può causare un altro tentativo di consegna consentito; ciò non dimostra che mx2 abbia accettato il messaggio.
La Fixture B rimuove entrambi i record MX ma se ne va example.com. A 192.0.2.30. Secondo la regola implicit-MX, quell'indirizzo diventa la potenziale destinazione SMTP . La Fixture C invece pubblica solo example.com. MX 0 .; l'interpretazione prevista è che il dominio non accetta posta. L'apparecchio D conserva i record MX di A ma rimuove gli indirizzi di entrambi gli scambi. Il risultato atteso sono percorsi espliciti inutilizzabili, non il fallback all'apice Un record.
Riproduci la parte DNS in un laboratorio interrogando MX per ogni dispositivo isolato e A/AAAA per ogni scambio restituito. Registra l'ordine e la classificazione selezionati. Utilizzare un server SMTP controllato per testare i tentativi e l'accettazione, se necessario. Gli indirizzi della documentazione e i risultati descritti sono illustrativi, non misurazioni della produzione.
Verificare il percorso commerciale
Riferimenti: RFC 7208 §5.4, RFC 5321 §4.2.5.
Mantieni il routing in entrata separato da SPF politica. Un SPF mx Il meccanismo può rendere esplicitamente gli indirizzi associati a MX rilevanti per una valutazione SPF , ma la sola pubblicazione MX non crea tale autorizzazione. La modifica dei fornitori in entrata può quindi influire anche su una politica SPF esistente che utilizza mx e merita una recensione a parte.
Durante una migrazione, verifica il provisioning dei destinatari, le risposte SMTP e la sicurezza del trasporto su tutti gli scambi attivi prima di rimuovere il vecchio percorso. Uno scambio di backup può accettare spam o rifiutare destinatari legittimi se configurato diversamente. Registrare chi possiede ciascun endpoint e quali prove chiudono la modifica; non equiparare l'accettazione SMTP al posizionamento della casella di posta o alla lettura del messaggio da parte di un essere umano.
Esecuzione del routing isolato catturato
L'acquisizione cronologica conservata, ispezionata per questa revisione ma non rieseguita, registra che il 7 novembre 2026 alle 20:34:42 UTC un dispositivo di loopback eseguito ha restituito il set MX 10 mx1.example.com. E 20 mx2.example.com. dalla porta 127.0.0.1 42125. Un client Python 3.12.14 che utilizza dnspython 2.9.2 ha ordinato queste preferenze. La mappa endpoint esplicita del laboratorio ha inviato mx1 alla porta 127.0.0.1 45271 e mx2 alla porta 37481; questa mappa delle porte sostituisce l'instradamento pubblico della porta 25 solo all'interno dell'apparecchiatura.
Con entrambi gli ascoltatori in esecuzione, è tornato mx1 220, accettato EHLO con 250, accettato MAIL DA e RCPT TO con 250, inserito DATI con 354 e restituito 250 messaggi sintetici accettati; scartato localmente. Dopo aver chiuso solo l'ascoltatore principale, viene registrata l'esecuzione successiva Errore di connessione rifiutata per mx1 e la stessa sequenza di accettazione per mx2. Non è stata coinvolta alcuna posta esterna, destinatario reale o consegna di cassette postali.
Per riprodurlo, avvia due dispositivi SMTP di loopback, interroga il risponditore MX del laboratorio, mappa i suoi nomi di scambio sugli ascoltatori e invia un messaggio sintetico innocuo con Python smtplib. Ripetere dopo aver chiuso la primaria. Conserva la risposta al bonifico, la mappa degli endpoint, la trascrizione client/server, i timestamp e le versioni dello strumento. L'apparecchiatura catturata utilizza un server SMTP volutamente piccolo e dimostra solo tentativi basati sulle preferenze; non è un test di conformità di una produzione MTA o evidenza di failover della produzione.
Mantenere esplicito l'ambito delle prove
La trascrizione archiviata conferma solo il comportamento del dispositivo di loopback descritto sopra, inclusa la mappatura delle porte personalizzata e l'eliminazione locale. L'acquisizione e il cablaggio della sorgente vengono mantenuti invariati; questa revisione non ha ripetuto il traffico SMTP né dedotto il failover della produzione dal test storico.