SPF, DKIM e DMARC sono tre record che si aggiungono al DNS del dominio per dimostrare che un’email partita a nome dell’azienda è autentica. SPF elenca i server autorizzati a inviare, DKIM firma ogni messaggio, DMARC dice ai destinatari cosa fare dei messaggi che non superano i controlli e ti manda i report. Senza questi record le email aziendali finiscono più spesso in spam o vengono rifiutate da Gmail, Yahoo e Outlook.com.
- SPF: un record TXT con l’elenco dei server che possono inviare per il tuo dominio. Uno solo per dominio.
- DKIM: una firma digitale aggiunta a ogni messaggio; la chiave pubblica sta nel DNS.
- DMARC: la regola finale (
p=none,quarantineoreject) e l’indirizzo a cui ricevere i report. Si parte sempre dap=none.
Perché dal 2024-2025 non è più facoltativo
Per anni SPF, DKIM e DMARC sono stati “buone pratiche”. Oggi i tre provider di posta più diffusi li chiedono esplicitamente, e chi non li ha se ne accorge con email in spam o rimbalzate.
| Provider | Per tutti i mittenti | Per chi invia molti messaggi | Cosa succede se manca |
|---|---|---|---|
| Gmail (dal 1° febbraio 2024) | SPF o DKIM, record PTR validi, connessione TLS, tasso di spam sotto lo 0,3% | Oltre 5.000 messaggi al giorno verso Gmail: SPF e DKIM, DMARC, allineamento del dominio “Da:”, disiscrizione con un clic per il marketing | Messaggi in spam o rifiutati (es. errore 5.7.26) |
| Yahoo (da febbraio 2024) | SPF o DKIM, DNS diretto e inverso validi, tasso di spam sotto lo 0,3% | Mittenti massivi: SPF e DKIM, DMARC almeno p=none allineato, disiscrizione con un clic | Filtraggio o rifiuto |
| Outlook.com, Hotmail, Live (dal 5 maggio 2025) | — | Da 5.000 messaggi verso i servizi consumer Microsoft con lo stesso dominio: SPF e DKIM superati, DMARC almeno p=none, allineamento | Errore 550 5.7.515 Access denied, sending domain … does not meet the required authentication level |
Le soglie “alti volumi” fanno pensare che una piccola azienda sia esclusa. In pratica no: il requisito minimo di Gmail e Yahoo vale per tutti, una newsletter o un invio massivo di solleciti può superare le soglie senza che nessuno se ne accorga, e i filtri antispam premiano comunque i domini autenticati. La scelta più semplice è configurare tutti e tre i record una volta per tutte.
SPF: chi può inviare per il tuo dominio
SPF (Sender Policy Framework, RFC 7208) è un record TXT pubblicato nel DNS del dominio. Dice ai server che ricevono la posta: “i messaggi di questo dominio possono partire solo da questi server”. Il controllo riguarda l’indirizzo del mittente “tecnico” (quello della busta, che spesso coincide con quello visibile).
Esempio di record SPF e il limite dei 10 lookup DNS
Un’azienda che usa Microsoft 365 per la posta e un servizio esterno per la newsletter avrà un record simile a questo (i nomi del servizio newsletter sono di esempio):
v=spf1 include:spf.protection.outlook.com include:servizio-newsletter.example -all
include:autorizza i server di un fornitore. Per Google Workspace il valore èinclude:_spf.google.com; per hosting e gestionali va chiesto al fornitore.-allchiede di rifiutare tutto il resto;~allchiede di trattarlo come sospetto. Con DMARC attivo,~allè una scelta prudente nella fase iniziale.- Ogni
include,a,mxe simili costa una o più interrogazioni DNS: la RFC 7208 fissa il limite a 10. Oltre, il risultato è permerror e SPF smette di funzionare per tutti i messaggi.
v=spf1. Se ne trovi due (capita quando si aggiunge un servizio senza guardare cosa c’era prima), la RFC prevede di nuovo permerror: vanno uniti in un unico record.DKIM: la firma dei messaggi
DKIM (DomainKeys Identified Mail, RFC 6376) aggiunge a ogni email una firma crittografica nell’intestazione. Il server che riceve recupera la chiave pubblica dal DNS (in un nome del tipo selettore._domainkey.tuodominio.it) e verifica che il messaggio non sia stato alterato e che sia stato firmato per quel dominio.
A differenza di SPF, la firma DKIM sopravvive agli inoltri: per questo è il controllo più importante per DMARC. In pratica:
- Microsoft 365: DKIM per il dominio personalizzato va attivato dal portale di sicurezza, pubblicando i due record CNAME indicati (
selector1eselector2). - Google Workspace: la chiave si genera dalla Console di amministrazione e si pubblica come record TXT (di solito con selettore
google), poi si avvia l’autenticazione. - Hosting e servizi esterni (newsletter, CRM, e-commerce): ognuno ha la propria procedura per firmare con il tuo dominio. Se un servizio non la prevede, firmerà con il suo dominio e non sarà “allineato”.
Dove il DNS lo consente, conviene usare chiavi a 2048 bit.
DMARC: la regola e i report
DMARC è un record TXT pubblicato su _dmarc.tuodominio.it. Fa due cose: chiede che almeno uno tra SPF e DKIM sia superato e allineato al dominio che il destinatario vede nel campo “Da:”, e indica cosa fare dei messaggi che falliscono. Un primo record tipico:
v=DMARC1; p=none; rua=mailto:dmarc-report@tuodominio.it
Con rua ricevi report giornalieri in XML da Gmail, Yahoo, Microsoft e altri: dicono quali server hanno inviato a nome tuo e se hanno superato i controlli. Sono illeggibili a occhio, ma esistono servizi che li trasformano in grafici. Lo standard è stato aggiornato nel maggio 2026 (RFC 9989, che sostituisce la RFC 7489): i valori none, quarantine e reject restano gli stessi, mentre il vecchio tag pct è sostituito da un tag di test (t=y).
Da p=none a p=quarantine a p=reject: percorso sicuro in 3 tappe
- Osserva (p=none, 2-4 settimane). Nessun effetto sulla consegna. Leggi i report e fai l’elenco di tutti i servizi che inviano a nome del dominio.
- Correggi e stringi (p=quarantine). Quando ogni servizio legittimo supera SPF o DKIM allineato, passa a quarantine: i messaggi falsi finiscono in spam. Tieni d’occhio i report per qualche settimana.
- Chiudi (p=reject). I messaggi che si spacciano per il tuo dominio vengono rifiutati. È la protezione piena contro le email contraffatte con il tuo nome.
Il caso più dimenticato: chi invia a nome del dominio senza che tu lo sappia
Nelle piccole aziende la posta “ufficiale” è quasi sempre configurata bene. I problemi arrivano da tutto il resto, che quando si passa a DMARC restrittivo smette di arrivare:
- Gestionale e fatturazione: preventivi, solleciti, documenti di trasporto inviati dal programma con l’indirizzo dell’azienda.
- Newsletter e CRM: vanno autorizzati in SPF e, soprattutto, configurati per firmare DKIM con il tuo dominio.
- Sito ed e-commerce: moduli di contatto e conferme d’ordine spesso partono dal server del sito. Meglio farli passare da un servizio SMTP autenticato; vedi anche la nostra pagina sul server relay.
- Stampanti multifunzione e scanner con la funzione “scansiona e invia per email”, centralini che inviano i messaggi della segreteria, sistemi di allarme.
- PEC: viaggia sui server del gestore PEC. Se la casella PEC usa un sottodominio del tuo dominio, quei record li gestisce il gestore: non modificarli senza sentirlo.
Come verificare che funzioni
- Manda un’email a un indirizzo Gmail e aprila con “Mostra originale”: Gmail riporta in chiaro SPF, DKIM e DMARC con l’esito PASS o FAIL.
- Leggi le intestazioni in Outlook (Proprietà del messaggio) e cerca la riga
Authentication-Results: ci sono gli stessi tre esiti. - Interroga il DNS da un PC Windows:
nslookup -type=txt tuodominio.itper SPF enslookup -type=txt _dmarc.tuodominio.itper DMARC. - Usa uno strumento gratuito come il Check MX della Google Admin Toolbox, che controlla MX, SPF, DKIM e DMARC del dominio in un colpo solo.
Se i messaggi vengono già rifiutati, il testo dell’errore dice quasi sempre quale controllo è fallito: trovi la spiegazione dei codici nella guida errori di consegna 550, 552 e 554.
Errori comuni: effetto e correzione
| Errore | Effetto | Correzione |
|---|---|---|
| Due record SPF sullo stesso dominio | SPF non valido (permerror) per tutti i messaggi | Unire i valori in un solo record v=spf1 |
Troppi include (oltre 10 interrogazioni DNS) | SPF non valido, anche se “sembra” giusto | Togliere i servizi non più usati; preferire DKIM per i servizi esterni |
| DKIM mai attivato su Microsoft 365 o Google Workspace | Resta solo SPF, che fallisce quando i messaggi vengono inoltrati | Attivare DKIM per il dominio personalizzato |
| Newsletter firmata con il dominio del fornitore | DMARC fallisce per mancanza di allineamento | Configurare il dominio di invio e la firma DKIM nel servizio |
DMARC subito su p=reject | Fatture e notifiche del gestionale rifiutate senza preavviso | Tornare a p=none, leggere i report, ripartire dalle 3 tappe |
Nessun indirizzo rua | Nessun report: non sai chi invia a nome tuo | Aggiungere rua=mailto:… con una casella dedicata |
Domande frequenti
Cosa succede se il mio dominio non ha DMARC?
I grandi provider come Gmail e Outlook.com possono mettere in spam o rifiutare i messaggi, soprattutto se invii molte email. Senza DMARC, inoltre, è più facile per chiunque spacciarsi per il tuo dominio.
Posso mettere subito DMARC su reject?
Meglio di no. Si parte da p=none per leggere i report e scoprire tutti i servizi che inviano a tuo nome, poi si passa a quarantine e solo alla fine a reject.
Ho due record SPF: è un problema?
Sì. Un dominio deve avere un solo record SPF: con due record il controllo restituisce un errore permanente e SPF non vale per nessun messaggio. I valori vanno uniti in un unico record.
Chi deve configurare questi record?
Chi gestisce il DNS del dominio, spesso il provider dell’hosting o il fornitore IT, usando i valori forniti da ogni servizio che invia email per tuo conto.
Basta avere SPF per essere a posto?
No. SPF da solo fallisce quando un messaggio viene inoltrato e non dice ai destinatari cosa fare dei messaggi falsi. Servono anche DKIM, che sopravvive agli inoltri, e DMARC, che collega i due controlli al dominio visibile al destinatario.
Le tue email arrivano davvero?
Controlliamo gratuitamente SPF, DKIM e DMARC del tuo dominio e ti mandiamo il risultato via email, con le correzioni da fare.
Richiedi il controllo del dominioFonti: Google – Linee guida per i mittenti di email · Yahoo Sender Hub – Best practices · Microsoft – Errore NDR 550 5.7.515 in Outlook.com · RFC 7208 (SPF) · RFC 6376 (DKIM) · RFC 9989 (DMARC) · Google Admin Toolbox – Check MX