Controllare un dominio email non significa testare la consegna

Un controllo del dominio email può mostrare i record DNS pubblicati. Non dimostra che un messaggio specifico sia stato autenticato, recapitato o inserito nella posta in arrivo. Leggi ogni risultato come un’osservazione su un determinato dominio in un momento preciso, poi scegli il controllo successivo in base alla tua vera domanda sull’invio.

Prima di una campagna, un founder usa uno strumento di controllo e vede diversi risultati positivi. È facile considerare quella schermata come il via libera per annunciare che l’email è pronta. Ma ricevere posta, pubblicare una policy per i mittenti, firmare un messaggio e raggiungere il destinatario sono compiti diversi.

Il 16 ottobre 2026 abbiamo usato il controllo pubblico dei domini email di FounderOmni per esaminare founderomni.com. Abbiamo lasciato vuoto il selettore DKIM facoltativo. Il risultato offre un esempio utile di come leggere le prove di configurazione senza trasformarle in un’affermazione sull’avvenuto recapito. Non è stata inviata alcuna email e non è stata modificata alcuna impostazione DNS.

Leggi il risultato della richiesta che hai effettivamente fatto

Annota il dominio e i dati inseriti prima di interpretare gli indicatori. Un dominio principale e un sottodominio di invio non devono necessariamente pubblicare gli stessi record. Anche una verifica senza selettore DKIM è diversa da una richiesta relativa al selettore specifico di un provider.

Il nostro risultato indicava un controllo effettuato alle 10:00 del mattino, ora di New York. L’interfaccia spiegava che i controlli possono riutilizzare un risultato degli ultimi cinque minuti. Quell’orario descrive questa osservazione; non promette che tutti i resolver del mondo vedano le stesse informazioni in quell’istante.

I risultati visualizzati erano:

• MX: Found (trovato). La risposta elencava mx1.spacemail.com e mx2.spacemail.com come destinazioni della posta in entrata.
• SPF: Found (trovato). Il testo restituito iniziava con v=spf1 e includeva due riferimenti a provider prima del ~all finale.
• DMARC: Review (da verificare). Il record restituito era v=DMARC1; p=none;.
• DKIM: Not checked (non controllato). La spiegazione era «No selector supplied» (nessun selettore fornito).

Ogni riga risponde a una domanda diversa. «Not checked» segnala un dato mancante in questa esecuzione, non dimostra che il dominio sia privo di una chiave DKIM. «Found» stabilisce che lo strumento ha ottenuto un record corrispondente, non che il mittente e ogni messaggio abbiano superato una valutazione completa del protocollo.

Il diagramma seguente riassume le righe osservate e i loro limiti. È una spiegazione originale di questa esecuzione, non una riproduzione dell’interfaccia. Puoi anche aprire la schermata reale con il dettaglio del risultato.

Distingui anche un errore di ricerca dall’assenza di un record. Se una richiesta non è stata completata, il passo utile successivo è indagare quell’osservazione o riprovare con i normali comandi. Sostituire un risultato non disponibile con «mancante» creerebbe un problema di configurazione non dimostrato.

Distingui un record pubblicato da un messaggio che funziona

I record MX indicano dove deve arrivare la posta in entrata. Non autorizzano il mittente di una campagna in uscita. Usa il risultato per confrontare la configurazione di ricezione con il provider previsto, anziché considerarlo un bollino di autenticazione per tutte le email del tuo brand.

SPF pubblica informazioni di autorizzazione per l’identità di invio pertinente. La specifica SPF descrive controlli che coinvolgono il mittente della busta SMTP e l’indirizzo IP di invio. Trovare il testo è un’osservazione; valutare un mittente reale con i dati corretti è un’altra.

Il nostro strumento pubblico dichiarava esplicitamente di non aver valutato l’IP di invio né eseguito le regole SPF ricorsive. I riferimenti ai provider visualizzati non dimostrano quindi che ogni servizio usato dal team sia autorizzato, che la policy completa sia valida per ogni percorso o che un messaggio specifico superi il controllo. Confronta la configurazione effettiva del provider prima di decidere cosa cambiare.

DKIM richiede un altro elemento di contesto. Il suo meccanismo dei selettori supporta chiavi pubbliche diverse all’interno di un dominio di firma. Conta il selettore realmente utilizzato dal provider. Indovinarne uno e non trovare un record non dimostra che tutti i possibili selettori siano assenti.

In questo esempio abbiamo volutamente omesso il selettore. Il passo successivo è ottenere il valore corretto dal provider di invio o dalle informazioni di firma di un messaggio che hai l’autorizzazione a esaminare. Anche una successiva ricerca riuscita mostrerebbe solo il materiale della chiave pubblicato; non verificherebbe la correttezza della firma di un messaggio specifico. Le chiavi private di firma non vanno inserite in un controllo pubblico.

DMARC collega l’autenticazione al dominio del mittente visibile e alla policy del proprietario del dominio. Tra i valori di policy documentati, none non richiede alcuna azione specifica di recapito. Non chiede di rifiutare i messaggi che non superano i controlli e la sua sola presenza non dimostra un’autenticazione allineata.

Il record restituito non conteneva nemmeno una destinazione rua per i report aggregati. Definire una policy «di monitoraggio» non deve trasformarsi nell’affermazione che il team riceva report: le destinazioni e la raccolta dei report richiedono una verifica separata. In questa esecuzione non abbiamo esaminato servizi privati di reportistica né caselle email.

Non sostituire una policy di monitoraggio con una che impone misure soltanto per eliminare un indicatore di revisione. Esamina i percorsi di invio legittimi e le prove con chi gestisce il dominio. Una modifica alla configurazione deve avere una ragione operativa che vada oltre l’aspetto più ordinato del riepilogo.

Scegli il prossimo controllo in base alla domanda a cui devi rispondere

Parti da una domanda precisa. «La nostra modifica DNS compare in questa ricerca?» si può indagare con il dominio esatto, il nome del record, il valore restituito e l’ora del controllo. «La nostra campagna viene autenticata?» richiede prove sul percorso di invio e sui messaggi effettivi. «Il destinatario l’ha ricevuta?» richiede prove di recapito o dal lato del destinatario.

Per un test autorizzato di un messaggio, conserva insieme mittente, destinatario, provider, orario e risultato di autenticazione pertinente. L’accettazione da parte del provider, la risposta di un server ricevente e il destinatario che vede il messaggio sono osservazioni diverse. Non trasformarne una in tutte e tre e non supporre che l’accettazione dimostri l’arrivo nella posta in entrata.

Se un messaggio non arriva come previsto, conserva i dettagli dell’errore invece di ripetere controlli DNS non pertinenti finché non compare un risultato verde. Esamina l’evento o la risposta effettiva del provider e le prove del destinatario previsto che hai l’autorizzazione a consultare. In questo modo l’indagine avrà un passaggio mancante ben preciso.

Un breve registro per il passaggio di consegne può contenere:

• Domanda: il fatto relativo a configurazione, autenticazione o recapito che devi stabilire.
• Ambito: il dominio esatto, il selettore fornito e, se pertinente, il percorso di invio.
• Osservazione: i record restituiti o le prove del messaggio effettivo, con il relativo orario.
• Incognita: la parte che il controllo scelto non ha valutato.
• Prossima azione: l’impostazione del provider, la ricerca specifica o il risultato di un messaggio autorizzato da esaminare in seguito.

Questo registro aiuta un piccolo team a evitare che una conclusione generica come «l’email funziona» passi tra persone che hanno verificato cose diverse. Mantieni intestazioni private, indirizzi e dati degli account nel consueto flusso di lavoro sicuro; condividi solo le informazioni necessarie all’indagine.

Una volta verificato il percorso di invio, il messaggio stesso deve ancora aiutare chi lo legge. La nostra guida alle email di benvenuto affronta un compito distinto: rendere chiara la prima azione utile. Né un testo chiaro né un record DNS pubblicato sostituiscono le prove sul percorso di un messaggio reale.