SPF, DKIM e DMARC: perché gli indicatori verdi non bastano

Autenticazione email: perché configurare SPF, DKIM e DMARC non basta

Avete fatto tutto il necessario. Avete trascorso ore nel DNS copiando stringhe incomprensibili dai vostri fornitori di invio. Avete eseguito i controlli e ottenuto indicatori verdi ovunque. Allora perché i tassi di apertura stanno crollando? Perché i messaggi transazionali, come reimpostazioni della password, fatture e avvisi, finiscono nello spam o scompaiono del tutto?

Ecco la dura verità sull'autenticazione email con SPF, DKIM e DMARC: una configurazione valida non equivale a una buona reputazione. Un documento valido non basta a far superare il buttafuori a una persona ubriaca. Da febbraio 2024, fornitori come Google, Yahoo e Microsoft applicano requisiti tecnici più rigorosi, oltre a valutare se un messaggio sembra spam. Se la dashboard mostra indicatori verdi ma i ricavi lanciano segnali d'allarme, probabilmente state incontrando uno dei controlli nascosti che vengono dopo gli acronimi fondamentali.

La trappola del mittente massivo: la soglia è più bassa del previsto

Il malinteso più pericoloso è questo: «Invio meno di 5,000 email al giorno, quindi le regole per i mittenti massivi non mi riguardano».

Non è così per due motivi, e configurare correttamente SPF, DKIM e DMARC non vi protegge da questa trappola. Primo, Google conta il volume a livello del dominio principale. Se inviate 2,000 messaggi di marketing da news.example.com, 2,000 messaggi transazionali da app.example.com e 1,500 avvisi interni da corp.example.com, siete un mittente massivo. Il volume dei sottodomini viene sommato a quello del dominio radice.

Il secondo motivo è il massimo storico. Se superate anche una sola volta la soglia di 5,000 messaggi, magari con una campagna per il Black Friday o un aggiornamento una tantum del database, Google può classificare il dominio in modo permanente come mittente massivo in base alle regole vigenti. La classificazione resta anche se il volume scende a 50 email al giorno, e il dominio continua a essere soggetto ai requisiti di conformità più severi.

Microsoft applica criteri diversi. I vostri record SPF, DKIM e DMARC possono essere impeccabili, ma conta anche l'anzianità dell'IP. Se avviate un dominio e un IP nuovi e inviate subito 2,000 messaggi, Microsoft può limitare il traffico con errori 4xx anche se SPF è corretto. Il provider non conosce ancora il vostro traffico, e ciò può bastare per attivare la limitazione.

Errori di SPF, DKIM e DMARC: il triangolo di ferro

Molti amministratori configurano SPF, DKIM e DMARC, verificano la sintassi e considerano concluso il lavoro. Una sintassi corretta, però, non garantisce il funzionamento. Ecco dove il meccanismo si inceppa.

SPF: il buco nero dell'inoltro

SPF funziona come un elenco di IP autorizzati: afferma che «l'IP 1.2.3.4 può inviare per example.com». Tutto procede bene finché qualcuno non attiva l'inoltro automatico.

Inviate una fattura a client@smallbiz.com. Il cliente inoltra tutta la posta a client@gmail.com. Gmail vede la connessione provenire dall'IP di smallbiz.com, non dal vostro. Consulta il record SPF, non trova smallbiz.com e la verifica fallisce. Se fate affidamento solo su SPF, il messaggio inoltrato può finire nello spam o essere rifiutato. DKIM è indispensabile perché l'autenticazione sopravviva a questo passaggio. Per la configurazione completa, consultate la nostra guida ai record SPF.

DKIM: il problema dell'allineamento

DMARC verifica due aspetti: se SPF o DKIM, secondo RFC 6376, ha superato il controllo e se i domini sono allineati. L'allineamento richiede che il dominio dell'intestazione From corrisponda ai domini delle intestazioni tecniche, cioè Return-Path per SPF e d= per DKIM.

Ecco l'incubo di ogni servizio di assistenza. Usate un CRM come Zendesk o HubSpot per inviare come support@yourcompany.com. Il CRM gestisce i messaggi respinti, quindi Return-Path è bounces.zendesk.com e l'allineamento SPF fallisce. Non avete configurato un CNAME personalizzato, perciò DKIM firma con d=zendesk.com e fallisce anche l'allineamento DKIM. Il messaggio è tecnicamente autenticato, dato che proviene da Zendesk ed è firmato da Zendesk, ma DMARC non vede alcun protocollo allineato con il vostro dominio. Se la policy è p=reject, il messaggio viene rifiutato.

Il limite di 10 interrogazioni

SPF, come definito in RFC 7208, impone un limite rigido di 10 interrogazioni DNS per record. Se lavorate in un'agenzia con clienti che usano molti strumenti SaaS, probabilmente avete già incontrato il problema. Da solo, Google Workspace può consumare 4 interrogazioni. Aggiungete Mailchimp, HubSpot, un sistema di ticket e uno strumento per le risorse umane:

Ogni include: richiede un'interrogazione DNS, e le inclusioni possono contenerne altre annidate. Superate le 10 interrogazioni complessive e il server destinatario restituisce PermError, che viene trattato come se non esistesse un record SPF. Nel tentativo di essere scrupolosi, finite quindi per rimuovere l'autenticazione dai vostri stessi messaggi.

Controlli nascosti oltre SPF, DKIM e DMARC

Oltre ai tre protocolli principali, esistono requisiti tecnici privi di nomi accattivanti che possono bloccare la posta con la stessa rapidità.

FCrDNS (DNS inverso confermato dalla risoluzione diretta)

Ogni IP di invio deve avere un record PTR, cioè un DNS inverso, che si risolva in un nome host. Tale nome deve a sua volta avere un record A che punti all'IP originale. Questa verifica circolare aiuta a dimostrare il controllo dell'infrastruttura. Se avviate una macchina virtuale nel cloud, installate Postfix e inviate messaggi senza record PTR, Gmail può considerare il server parte di una botnet e restituire immediatamente 550 5.7.1.

RFC 8058: annullamento dell'iscrizione con un clic

Da giugno 2024, per i messaggi di marketing soggetti agli attuali requisiti dei grandi provider non basta un collegamento nel piè di pagina. Occorre includere due intestazioni specifiche:

L'endpoint HTTPS deve accettare una richiesta POST, non GET. I bot antispam analizzano i messaggi «facendo clic» sui collegamenti. Se l'annullamento dell'iscrizione usa GET, i bot possono cancellare per errore utenti reali. Inoltre, quando una persona non trova un'uscita semplice, tende a scegliere «Segnala come spam», spingendo il mittente verso la soglia di reclami dello 0.3%.

La soglia dello 0.3%: l'economia della reputazione

Un'autenticazione SPF, DKIM e DMARC perfetta, un FCrDNS impeccabile e intestazioni corrette non servono a nulla se i destinatari detestano i contenuti.

La metrica che domina tutte le altre è il tasso di segnalazioni spam. Secondo le politiche descritte alla data di pubblicazione, la soglia critica è dello 0.3%, cioè 3 reclami ogni 1,000 messaggi. Se la superate, Google può arrivare a bloccare completamente il dominio.

La trappola del denominatore della posta in arrivo di Yahoo

Yahoo può calcolare il tasso di spam sui messaggi che raggiungono la posta in arrivo, anziché sul totale inviato. Inviate 1,000 email. La reputazione del dominio è già fragile, quindi 900 finiscono nello spam e 100 nella posta in arrivo. Una persona presenta un reclamo. Il calcolo è 1/100 = 1.0%, un tasso 3x superiore al limite applicato. Un solo reclamo può innescare una spirale dalla quale è estremamente difficile uscire.

Il problema del vicino rumoroso

Anche con SPF, DKIM e DMARC configurati correttamente, su un normale hosting condiviso o una piattaforma email «illimitata» a basso costo i vostri messaggi partono dallo stesso IP usato da migliaia di altri clienti. Se uno di loro invia una truffa legata alle criptovalute, Spamhaus può inserire l'IP in una lista di blocco. La vostra posta viene fermata anche se non avete fatto nulla di male. Condividete il palazzo con il problema e le conseguenze colpiscono tutti.

La lista del venerdì per correggere SPF, DKIM e DMARC

1. Controllate le intestazioni: Inviate un messaggio a un account Gmail personale. Apritelo, fate clic sui tre punti e scegliete «Mostra originale». Cercate Authentication-Results. SPF è valido? DKIM è valido? Il dominio di dkim= corrisponde al dominio di header.from? In caso contrario, avete un problema di allineamento.

2. Verificate FCrDNS: Eseguite dig -x <your-sending-ip>. Restituisce un nome host? Eseguite dig <that-hostname>. Restituisce l'IP? Se il ciclo non si chiude, interrompete gli invii e correggete il DNS.

3. Separate il traffico: Non inviate mai marketing dal dominio aziendale principale. Usate team@company.com per i messaggi tra persone e newsletter@marketing.company.com per le campagne. Se il marketing raggiunge la soglia dello 0.3%, la direzione potrà comunque scrivere agli investitori dal dominio principale.

4. Approfondite: Per conoscere il processo di recupero, consultate la nostra guida alla reputazione del mittente e l'analisi dettagliata della reputazione del dominio email.

Piani TrekMail

In base alle condizioni attuali, tutti i piani a pagamento includono una prova di 14 giorni (carta richiesta). Free non richiede una carta.

Conclusione

L'autenticazione email con SPF, DKIM e DMARC non è un'attività da configurare e dimenticare. È un requisito operativo continuo. Superare le verifiche è soltanto il prezzo d'ingresso. Per restare davvero nella posta in arrivo servono un allineamento rigoroso, un'igiene di rete impeccabile, compresi FCrDNS e le intestazioni di annullamento con un clic, e una strategia di reputazione che vi protegga dagli altri mittenti. Non accontentatevi delle impostazioni predefinite. Mantenete il controllo dell'infrastruttura.

Ottenere indicatori verdi per SPF, DKIM e DMARC è il prezzo d'ingresso, non il traguardo. Provate TrekMail gratuitamente e assumete davvero il controllo dell'autenticazione email.