Le email finiscono nello spam: SPF, DKIM e DMARC spiegati senza gergo

Dal 1° febbraio 2024 Google chiede a chi manda email verso Gmail di autenticare il dominio da cui spedisce, e da novembre 2025 i messaggi fuori regola possono essere rifiutati, in modo temporaneo o definitivo. Microsoft ha fatto lo stesso per Outlook.com, Hotmail e Live dal 5 maggio 2025. Se un cliente trova il tuo preventivo nello spam, prima di riscrivere l'oggetto guarda il DNS del dominio da cui l'hai mandato.

Noi l'abbiamo fatto con il nostro il 22 ottobre e lo usiamo come esempio dall'inizio alla fine, compreso il record che non va.

Cosa chiedono Gmail e Outlook

A chiunque spedisca verso Gmail, Google chiede SPF oppure DKIM, i record DNS diretto e inverso (PTR) per i server che spediscono, una connessione cifrata e meno dello 0,3% di segnalazioni di spam in Postmaster Tools. Oltre i 5.000 messaggi al giorno servono SPF e DKIM insieme, un record DMARC (basta p=none), il dominio del mittente allineato e, per le newsletter, la disiscrizione con un clic.

Microsoft chiede le stesse cose a chi supera i 5.000 messaggi al giorno. Aveva annunciato che i messaggi fuori regola sarebbero finiti nella posta indesiderata, poi con l'aggiornamento del 29 aprile 2025 ha deciso di rifiutarli, con l'errore 550 5.7.515.

Un'azienda che manda qualche decina di email al giorno sta sotto le soglie, e per Gmail le bastano SPF o DKIM. DMARC le serve comunque, per sapere se qualcun altro spedisce a nome suo.

Da dove partono le nostre email

Da due servizi: la posta di tutti i giorni passa da Google Workspace, mentre le email del sito, cioè le notifiche del modulo contatti, i report degli strumenti gratuiti e le conferme della newsletter, le manda Resend.

Fai la stessa lista per il tuo dominio, e di solito viene più lunga del previsto: la casella, il gestionale che manda le fatture, il sito, la newsletter. Quando le email finiscono nello spam il primo indiziato è un servizio che spedisce a nome tuo senza autenticazione, come il modulo di contatto di un sito WordPress che parte dal server dell'hosting senza firma.

SPF: chi può spedire a nome tuo

SPF (RFC 7208) è l'elenco dei server autorizzati a spedire per il dominio, pubblicato in un record TXT. Il nostro è questo:

v=spf1 include:_spf.google.com ~all

Autorizza Google e nessun altro. Resend non compare perché il controllo SPF guarda l'indirizzo a cui tornano i rimbalzi, e Resend ne usa uno su un sottodominio, send.msworks.it, che ha un SPF suo (v=spf1 include:amazonses.com ~all) e un MX verso feedback-smtp.eu-west-1.amazonses.com. Così i rimbalzi arrivano a Resend, che dietro usa Amazon SES, e l'SPF del dominio principale resta di una riga.

Tenerlo corto serve anche a stare lontani dal limite delle 10 consultazioni DNS: oltre quel numero la verifica fallisce per tutte le email del dominio, non solo per l'ultimo servizio aggiunto. Ci arrivano i domini che in qualche anno hanno accumulato un include per ogni servizio provato e mai tolto. L'altro errore frequente sono due record SPF sullo stesso dominio: anche quello fa fallire il controllo, e vanno uniti in uno.

DKIM: la firma

DKIM (RFC 6376) firma ogni email con una chiave privata. Chi la riceve la verifica con la chiave pubblica che trova nel tuo DNS: se torna, il messaggio viene dal dominio dichiarato e nessuno l'ha modificato. La chiave sta sotto un nome scelto dal servizio, il selettore, e sul nostro dominio ce ne sono due: google._domainkey per Workspace, a 2048 bit, e resend._domainkey per Resend, a 1024. Lo standard chiede almeno 1024 bit e raccomanda 2048, quindi quella di Resend è valida ma sta al minimo. Tutte e due firmano con il dominio msworks.it, quindi anche le email del sito risultano allineate per DMARC.

In Workspace la chiave si genera dalla console di amministrazione, si pubblica nel DNS e poi si attiva con «Avvia autenticazione»; Google avverte che possono servire fino a 48 ore. Il passaggio che si dimentica è l'ultimo, e si resta con un record pubblicato e una firma che non parte.

DMARC: il pezzo che ci manca

DMARC dice ai provider cosa fare con un'email che porta il tuo dominio nel mittente ma non passa i controlli, e a chi mandare i rapporti. Passa se SPF o DKIM passano con un dominio allineato a quello del mittente, e con l'allineamento rilassato, quello predefinito, va bene anche un sottodominio come send.msworks.it. La politica p= può valere none (decide il provider), quarantine (l'email è sospetta e di solito finisce nello spam) o reject (va rifiutata). Il tag rua indica dove mandare i rapporti aggregati: chi ha spedito a nome tuo e con che esito.

Alla domanda sul DMARC il nostro dominio risponde _dmarc.msworks.it canonical name = dmarc.ionos.it, e il record a cui rimanda dice solo v=DMARC1; p=none;. Non l'abbiamo scritto noi: è un alias (CNAME) verso il record predefinito di IONOS, il registrar del dominio, con politica none e nessun rua. Rispetta le regole di Gmail e di Outlook, ma non manda rapporti a nessuno, e se domani qualcuno spedisse email a nome di msworks.it non lo sapremmo. Finché resta l'alias, poi, la politica DMARC del nostro dominio vive in un record che gestisce IONOS: per aggiungere un rua bisogna sostituire il CNAME con un TXT nostro.

Su 1,8 milioni di domini fra i più visitati al mondo, EasyDMARC ha contato che il 52,2% non ha nessun record DMARC e solo il 7,7% ha la politica reject.

Se il tuo record usa ancora il tag pct, toglilo: l'RFC 9989, uscito a maggio 2026 al posto del vecchio RFC 7489, lo ha eliminato.

Da none a reject senza perdere email

Si parte da p=none con un indirizzo rua e si leggono i rapporti per qualche settimana. Quando tutte le email legittime passano, si sale a quarantine e poi a reject, che è il percorso graduale consigliato anche da Microsoft. Il caso tipico di chi salta i rapporti e va subito a reject è il gestionale delle fatture, che le manda con il tuo indirizzo ma dai suoi server, senza firma DKIM, e da quel giorno non arrivano più.

Come leggere il DNS del tuo dominio

Servono una casella Gmail e il comando nslookup, che c'è su Windows, macOS e Linux.

1. 01Manda un'email da ogni servizio a un indirizzo Gmail, aprila e scegli «Mostra originale». In alto trovi SPF, DKIM e DMARC, ognuno con PASS o FAIL; nell'intestazione DKIM-Signature il campo d= è il dominio che firma e s= è il selettore.
2. 02nslookup -type=TXT tuodominio.it per l'SPF: la riga che inizia con v=spf1 deve essere una sola.
3. 03nslookup -type=TXT selettore._domainkey.tuodominio.it per ogni chiave DKIM, con il selettore letto al passo 1.
4. 04nslookup -type=TXT _dmarc.tuodominio.it per DMARC. Se non risponde niente, il record non c'è. Se compare un canonical name, come da noi, lo gestisce qualcun altro.

Se le tue email finiscono nello spam e questi controlli non ti tornano, scrivici. Leggiamo il DNS del dominio e gli originali delle email che mandi, e ti diciamo quale servizio spedisce senza autenticazione e da quale cominciare.