Autenticazione email: guida a SPF, DKIM e DMARC

L'autenticazione email con SPF, DKIM e DMARC è ormai un'attività essenziale. Se il dominio invia posta aziendale nel 2025 o 2026, questi record contribuiscono al trattamento dei messaggi insieme a molti altri segnali. Per valutare prima l'insieme degli strumenti, leggi email aziendale per piccole imprese.

Molti team pensano che i problemi dipendano solo dai contenuti. A volte è così, ma spesso il dominio è configurato male: un SPF errato, una chiave DKIM mancante o una politica DMARC mai pubblicata. Possono quindi comparire rifiuti in Outlook, limiti di frequenza in Gmail, campagne nello spam di Yahoo e difficoltà con l'inoltro.

La soluzione è semplice in teoria e impegnativa in pratica. SPF indica quali IP possono inviare per il dominio MAIL FROM effettivo. DKIM attesta che il messaggio è stato firmato e che i dati firmati non hanno subito modifiche incompatibili con la canonicalizzazione. DMARC richiede un trattamento quando i controlli falliscono e verifica se il dominio From visibile è allineato con quello autenticato. Una configurazione corretta rafforza la base tecnica, senza garantire consegna o posta in arrivo.

Cosa fanno davvero SPF, DKIM e DMARC

Questi tre livelli fanno parte dei segnali usati dai provider di caselle. SPF controlla il percorso, DKIM la firma e DMARC allineamento e politica. Quando le regole applicabili agli invii in massa lo richiedono, pubblica tutti e tre; per superare DMARC basta che un risultato SPF o DKIM sia positivo e allineato.

Ricorda: DMARC non richiede che SPF e DKIM passino insieme. Uno dei due deve passare ed essere allineato con il dominio From visto dal destinatario.

SPF: chi può inviare posta per il dominio

Il primo livello è SPF, un elenco di autorizzazione. Il server destinatario esamina il dominio MAIL FROM, o dominio envelope, consulta il relativo record TXT SPF e decide se l'IP connesso è autorizzato. È rapido e utile, ma anche fragile: inoltro e catene include troppo lunghe possono farlo fallire.

SPF viene pubblicato nel DNS come TXT. Un esempio è:

v=spf1 include:_spf.google.com include:spf.trekmail.net -all

Questa riga significa:

1. v=spf1 dichiara il tipo di record.
2. include: richiama l'infrastruttura di invio pubblicata da un altro dominio.
3. -all indica che tutto il resto deve fallire.

Molte configurazioni incontrano il limite di 10 ricerche della RFC 7208. Nel conteggio rientrano meccanismi e modificatori che provocano query, oltre alle valutazioni annidate dietro un include. Oltre il limite, il destinatario può restituire PermError: la valutazione SPF non è stata completata correttamente.

Hai annullato un CRM due anni fa, ma ne hai lasciato il include:. La piattaforma marketing ne ha aggiunti altri tre e l'assistenza un altro. Tutto sembrava corretto finché i destinatari non hanno valutato l'intera catena.

SPF può fallire anche dopo l'inoltro. Se un'università inoltra il messaggio a Gmail, Gmail può vedere come fonte il server universitario. Un SPF corretto sul percorso diretto può quindi fallire dopo l'inoltro. SPF da solo non basta.

Se invii tramite TrekMail, la documentazione mostra il valore include richiesto e come integrarlo senza duplicati: Record DNS richiesti.

DKIM: chi ha firmato il messaggio e se è cambiato

Il secondo livello è DKIM. Firma il messaggio con una chiave privata e consente di verificare la firma con una chiave pubblica nel DNS. A differenza di SPF, DKIM può restare valido dopo l'inoltro se la firma sopravvive e i dati firmati rispettano la canonicalizzazione. Modifiche incompatibili al corpo o alle intestazioni firmate causano l'errore.

I record DKIM si trovano sotto un selettore, come selector1._domainkey.example.com o dkim._domainkey.example.com. Il mittente firma con il selettore corrispondente e il destinatario recupera la chiave pubblica dal DNS.

Un tipico valore è:

Host: dkim._domainkey
Type: TXT
Value: v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4G...

Gli errori operativi sono spesso semplici:

1. Le chiavi sono state ruotate, ma il server usa ancora il vecchio selettore.
2. Hai cambiato provider senza pubblicare la nuova chiave pubblica.
3. Il provider DNS ha alterato il lungo valore TXT.
4. Una mailing list ha riscritto il corpo e invalidato la firma.

In una configurazione solida, usa chiavi da 2048 bit come impostazione predefinita quando servizio e DNS sono compatibili, salvo un motivo specifico per una scelta diversa. Esistono ancora sistemi legacy da 1024 bit, ma è preferibile pianificare una sostituzione compatibile nel 2026.

Nei piani TrekMail a pagamento, la posta del dominio viene firmata con la sua chiave DKIM quando è attivo SMTP gestito, secondo la configurazione corrente. Questo può mantenere un percorso DMARC allineato in alcuni inoltri se la firma resta valida. Per analizzare gli errori, consulta Le mie email finiscono nello spam.

DMARC: le regole che orientano i destinatari

Il livello finale è la politica DMARC. Si basa su SPF e DKIM, richiede un trattamento quando l'autenticazione fallisce e controlla l'allineamento tra From visibile e i domini usati da SPF o DKIM. Senza un percorso positivo e allineato, DMARC fallisce.

Pubblica il record in _dmarc.example.com. Inizia con cautela:

v=DMARC1; p=none; rua=mailto:dmarc@example.com

Procedi quando hai prove sufficienti:

v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com

v=DMARC1; p=reject; rua=mailto:dmarc@example.com

p=none non richiede restrizioni DMARC, ma il filtraggio locale continua. p=quarantine richiede di trattare gli errori come sospetti. p=reject ne richiede il rifiuto. Sono politiche richieste, non garanzie di azione o consegna.

L'altra difficoltà è l'allineamento. Esempio:

Visible From: newsletter@yourcompany.com
Return-Path: bounce.vendor.com
DKIM domain: vendor.com

SPF può passare. DKIM può passare. DMARC fallisce comunque, perché nessuno dei due è allineato con yourcompany.com.

È un problema comune con Mailchimp, HubSpot, Zendesk e CRM: il pannello del servizio appare verde, ma il dominio non è allineato nei messaggi reali. Le linee guida attuali di Google per i mittenti di grandi volumi verso account Gmail personali richiedono SPF e DKIM, con almeno uno allineato a From per la posta diretta. Richiedono anche un record DMARC minimo, pur se impostato su p=none: Domande frequenti Google per i mittenti. Verifica sempre la versione e l'applicabilità correnti.

SPF, DKIM o DMARC: quale conta di più?

Ogni protocollo svolge un ruolo distinto e nessuno sostituisce gli altri. Una firma DKIM valida resiste spesso meglio ad alcuni inoltri, SPF resta richiesto da molte regole e DMARC aggiunge politica e allineamento. La configurazione adatta dipende dai percorsi e dai requisiti applicabili.

In configurazioni semplici, i tre meccanismi sono facili da gestire. Con un server e nessun mittente SaaS, SPF e DKIM sono di solito diretti. Con assistenza, newsletter, CRM e inoltro sullo stesso dominio, i report DMARC aiutano a scoprire cosa è davvero allineato.

Perché inoltro e mailing list causano ancora errori insoliti

L'inoltro può rompere SPF perché il server intermedio trasmette il messaggio. DKIM può mantenere un percorso valido, ma fallisce se un intermediario modifica il corpo o un'intestazione firmata in modo incompatibile. Il risultato dipende dal percorso e dalla firma.

Per questo una configurazione perfetta sulla carta può fallire presso destinatari reali. SPF può fallire dopo il cambio di IP, DKIM perché una lista aggiunge un piè di pagina e DMARC perché non resta alcun percorso allineato.

Quando tutti e tre falliscono dopo l'inoltro, ARC consente agli intermediari di registrare la cronologia osservata. Il destinatario può considerarla nella propria decisione, ma ARC non preserva né converte automaticamente un risultato DMARC. Le indicazioni Google trattano in modo specifico l'allineamento DMARC nel traffico indiretto e raccomandano intestazioni ARC. Il mittente di solito non configura ARC: mantieni DKIM valido ed evita catene fragili. Se l'inoltro è centrale, leggi la guida sull'inoltro email.

I controlli nascosti che danneggiano ancora la consegna

Record validi non garantiscono la posta in arrivo. I provider considerano anche DNS inverso, TLS, reclami e disiscrizione. SPF, DKIM e DMARC sono le fondamenta, non l'intero sistema.

1. DNS inverso con risoluzione diretta confermata: l'IP deve avere un PTR e quel nome deve risolvere sullo stesso IP. Google include DNS diretto e inverso validi tra i requisiti applicabili.
2. TLS: i grandi provider si aspettano il trasporto TLS; Google cita la posta senza TLS tra le possibili cause di errori temporanei o permanenti.
3. Reclami spam: le attuali indicazioni Google per il traffico applicabile raccomandano di restare sotto 0.1% e non raggiungere 0.3%.
4. Disiscrizione con un clic: per la posta promozionale soggetta ai requisiti, i provider si aspettano intestazioni conformi a RFC 8058 oltre al collegamento visibile.

Questi segnali contano ancora di più per un dominio nuovo. Una campagna improvvisa e una lista scadente possono danneggiare una reputazione con poca cronologia.

Come configurare SPF, DKIM e DMARC senza danneggiare la produzione

Prima inventaria tutti i mittenti, pubblica record coerenti, verificali con messaggi reali e passa gradualmente dall'osservazione all'applicazione. Saltare l'inventario può interrompere uno strumento SaaS dimenticato.

1. Elenca ogni servizio che usa il dominio: caselle, CRM, assistenza, newsletter, moduli, fatturazione e server.
2. Riunisci i mittenti in un solo SPF. Non pubblicare mai due record TXT SPF.
3. Pubblica DKIM per ogni mittente che richiede il proprio selettore.
4. Pubblica prima DMARC con p=none e analizza più periodi rappresentativi.
5. Correggi l'allineamento di ogni mittente esterno attivando il dominio personalizzato e prova messaggi reali.
6. Passa per gradi a p=quarantine e p=reject dopo aver verificato percorsi comuni e rari, con un piano di ripristino.

Per un dominio TrekMail con invio gestito, i record di base possono avere questo aspetto secondo la configurazione corrente:

MX  @                mail.trekmail.net.            priority 10
TXT @                v=spf1 include:spf.trekmail.net -all
TXT dkim._domainkey  v=DKIM1; k=rsa; p=...unique key from dashboard...
TXT _dmarc           v=DMARC1; p=quarantine; rua=mailto:dmarc@trekmail.net

La documentazione descrive struttura e verifica in Record DNS richiesti e Controllo dello stato DNS. Se sei in una fase precedente, leggi configurare l'email sul mio dominio.

Metodo tradizionale e approccio attuale

Il metodo tradizionale prevedeva una grande suite con prezzo per utente o un server proprio con DNS, TLS, selettori e reputazione da mantenere. Un altro approccio separa caselle e invio e usa una piattaforma che facilita record, validazione e migrazione senza legare tutto al numero di utenti. L'idoneità dipende dall'ambiente.

TrekMail può inserirsi in questo modello. Secondo le condizioni descritte dalla fonte, Nano consente fino a 10 domini, 5 GB condivisi e SMTP proprio. I piani a pagamento partono da $3.50 al mese, includono SMTP gestito e sono offerti senza prezzo per casella secondo le condizioni attuali. A seconda del piano corrente, possono essere disponibili anche domini personalizzati, IMAP, catch-all, inoltro, migrazione IMAP e accesso API nei livelli superiori. I piani a pagamento hanno una prova gratuita di 14 giorni che richiede una carta. Nano è presentato come gratuito e senza carta. Verifica prezzi, funzioni e limiti correnti.

Questo modello può semplificare le operazioni su più domini: un pannello, spazio condiviso, record DNS da copiare e migrazione lato server, secondo il piano. La migrazione IMAP copia i messaggi, non DNS, applicazioni o percorsi. Consulta hosting email multidominio e verifica le cifre attuali in prezzi TrekMail.

Conclusione: SPF, DKIM e DMARC sono oggi una base tecnica

Questi controlli non sono più riservati alle configurazioni avanzate. SPF autorizza l'IP per il dominio envelope, DKIM valida la firma e DMARC collega un percorso autenticato al dominio From pubblicando una politica richiesta.

Se questa settimana puoi svolgere una sola attività, pubblica un SPF unico e valido, un DKIM funzionante e DMARC con p=none. Poi verifica ogni mittente con messaggi reali, analizza report parziali per più periodi, prova percorsi rari e procedi per gradi con un piano di ripristino. In questo modo riduci gli incidenti evitabili senza promettere risultati di consegna.