I 7 record DNS che ogni mittente email self-hosted deve avere

L'email è atipica: un setup mittente completo prevede sette record DNS distinti, suddivisi tra tre o quattro tipologie. Ne ometta uno e i messaggi continueranno a fluire, ma i mailbox provider La declasseranno silenziosamente nella cartella spam. Pubblichi tutti e sette e supererà la soglia "tutto quello che chiede Google" descritta in /guide/email-deliverability.

L'ordine conta: SPF e DKIM devono atterrare prima che il DMARC inizi a far rispettare l'allineamento, altrimenti la posta legittima finisce in quarantena. La regola universale tra i vendor è anche "aspetti che il DNS si propaghi" — lasci passare almeno 30 minuti tra la pubblicazione di un record e la richiesta al mailbox provider di rifare il check.

I record MX (RFC 1035 §3.3.9) dicono al mondo dove consegnare la posta in entrata per il Suo dominio. Anche se il Suo dominio mittente è "solo outbound" (non legge le risposte su di esso), un record MX è comunque richiesto — molti mailbox provider declassano la reputazione dei domini senza MX, sulla teoria che i mittenti legittimi accettano risposte. Basta un singolo record che punta a un qualsiasi mail server raggiungibile, anche se quel server consegna soltanto a una mailbox postmaster.

SPF (RFC 7208) è un singolo record TXT che elenca quali IP sono autorizzati a inviare per il dominio. La regola rigida: il totale dei lookup DNS ricorsivi deve restare sotto 10 (RFC 7208 §4.6.4). Ogni include: ne consuma uno; gli include annidati contano cumulativamente. I meccanismi ip4: / ip6: costano zero lookup, quindi collassi i vecchi include in range IP espliciti se il conteggio cresce.

Termini con -all (hard-fail) una volta verificato che tutte le sorgenti di invio legittime sono coperte. Se non è ancora sicuro, parta con ~all (soft-fail) e stringa a -all dopo due settimane di report DMARC puliti.

DKIM (RFC 6376) pubblica la metà pubblica di una keypair di firma come record TXT su {selector}._domainkey.{domain}. Il "selector" è un identificatore a Sua scelta — vendor-specifico o arbitrario. Per SES, AWS Le fornisce tre CNAME che si risolvono in record TXT gestiti da AWS (così AWS può ruotare le chiavi senza che Lei tocchi il DNS):

Per Postal o Postfix+OpenDKIM self-hosted, genera la keypair localmente, configura l'MTA per firmare e pubblica la metà pubblica come TXT:

Qualunque sia il path, verifichi con dig TXT {selector}._domainkey.{domain} prima di dichiarare DKIM completato.

DMARC (RFC 7489) sta su _dmarc.{domain}. Saltare la rampa p=none è l'errore più frequente — saltare dritti a p=reject su un dominio i cui flussi di posta non sono ancora compresi a fondo farà silenziosamente bouncing posta legittima (forwarder, mailing list, mittenti su CRM di terze parti).

Legga i report XML aggregati giornalieri che arrivano nella Sua mailbox rua tra uno stage e l'altro. Strumenti come il DMARC analyzer di Postmark o Parsedmarc self-hosted li visualizzano; l'XML nudo è denso ma leggibile.

Di default, le URL di open-pixel e click-tracking di AcelleMail partono dal dominio primario della Sua installazione. I mailbox provider preferiscono vedere root domain coerenti tra il From, i click sui link e l'URL di disiscrizione — tutto sullo stesso dominio registrato. Dal punto di vista del branding, anche i link che puntano a tracker.suaazienda.com trasmettono più fiducia di link che puntano a links.acellemail.com.

Una volta che il CNAME si risolve, AcelleMail riscrive tutte le URL di click-tracking nei messaggi in uscita per usarlo. Il dominio del link di disiscrizione segue la stessa regola (e lo stesso CNAME).

MTA-STS (RFC 8461) dice agli altri mittenti "richiedere sempre TLS quando consegnano al mio MX". Senza, un attaccante sul percorso può degradare un handshake TLS-capable a cleartext. Con MTA-STS, il server mittente si rifiuta di consegnare se non può stabilire TLS. L'implementazione è un record TXT che punta a un file di policy ospitato:

Faccia girare la policy in mode: testing per la prima settimana, poi passi a mode: enforce. Molti bulk sender saltano MTA-STS — deployarlo è un segnale di fiducia gratuito.

BIMI (Brand Indicators for Message Identification) è il più giovane dei sette e l'unico non ancora un RFC finalizzato, ma è supportato in produzione da Gmail, Yahoo, Apple Mail, Fastmail e altri client. Il patto: pubblichi un record TXT che punta a un logo SVG e (opzionalmente) a un Verified Mark Certificate (VMC), e i client supportati mostreranno il logo accanto ai Suoi messaggi nella lista inbox.

Precondizioni: una policy DMARC almeno a p=quarantine (BIMI non è onorato sotto p=none), e l'SVG deve essere SVG Tiny Portable / Secure (SVG-PS). L'accettazione varia: Gmail richiede un VMC a pagamento ($1.500/anno via DigiCert / Entrust) per la visualizzazione completa nella lista inbox; Yahoo e Apple accettano BIMI senza VMC. Aumenti di open rate del 5-20% sono comunemente riportati nei case study pubblicati.

Dopo la pubblicazione, si invii un messaggio di test e controlli gli header. Gmail web: apra il messaggio, clicchi il menu tre puntini, "Mostra originale". Cerchi:

Tre verdetti pass sono la soglia. Qualsiasi cosa meno — fail, softfail, neutral — significa che un record è sbagliato, o il DNS non si è ancora propagato, o il body della posta viene modificato in transito (raro). Faccia il cross-check con la spec canonica Authentication-Results header (RFC 8601) se un verdetto è ambiguo.