Home › Guide

Configurare SPF, DKIM e DMARC: record, errori comuni e verifiche

Pubblicato il 2026-11-03 ／ Aggiornato il 2026-11-03 ／ A cura di Yuki Nakazawa

Una configurazione di SPF, DKIM e DMARC non è più facoltativa se invia email dal proprio dominio. Proceda in questo ordine: pubblichi un unico record SPF, attivi la firma DKIM con una chiave a 2048 bit, poi pubblichi un record DMARC che parta da p=none con i report attivati. Già che c'è, si assicuri che l'indirizzo IP da cui parte la sua posta abbia un DNS inverso (PTR) corrispondente.

Questa guida vale sia che invii da un hosting condiviso, dal suo VPS, da Google Workspace, da Microsoft 365 o da un servizio di email marketing. Fornisce record da adattare, gli errori che più spesso compromettono l'autenticazione e il modo per verificare che tutto funzioni a partire dall'intestazione di un messaggio reale.

Le informazioni riportate sono state verificate sulle RFC e sulle pagine ufficiali di Google, Yahoo e Microsoft aggiornate a novembre 2026. I requisiti dei provider di posta cambiano, quindi consideri le loro pagine come riferimento definitivo.

Cosa dimostrano SPF, DKIM e DMARC e in quale ordine configurarli

SPF (Sender Policy Framework) permette a un dominio di elencare nel DNS i server autorizzati a inviare la sua posta. Il server ricevente esamina il mittente della busta (l'indirizzo SMTP MAIL FROM, che poi compare come Return-Path), recupera il record SPF di quel dominio e controlla se l'indirizzo IP che si connette è nell'elenco. Da solo, SPF non dice nulla sull'indirizzo From visto dal lettore.

DKIM (DomainKeys Identified Mail) aggiunge una firma crittografica a ogni messaggio. Il sistema di invio firma con una chiave privata e i server riceventi verificano la firma con una chiave pubblica pubblicata nel DNS. Una firma valida dimostra che il dominio firmatario (il valore d=) si è assunto la responsabilità del messaggio e che le intestazioni firmate e il corpo non sono stati alterati lungo il percorso.

DMARC (Domain-based Message Authentication, Reporting and Conformance) collega i due al dominio From visibile. Un messaggio supera DMARC solo quando SPF o DKIM viene superato e il dominio autenticato è allineato con il dominio From. Il record DMARC indica inoltre ai server riceventi cosa fare con i messaggi che non superano il controllo (niente, quarantena o rifiuto) e dove inviare i report aggregati, grazie ai quali si scoprono le fonti di invio dimenticate.

Ordine di configurazione

1. Elenchi tutti i sistemi che inviano posta a nome del suo dominio: il suo server, Google Workspace o Microsoft 365, servizi di newsletter e di email transazionali, moduli web, strumenti di fatturazione e di help desk.
2. Pubblichi un unico record SPF che li comprenda tutti.
3. Attivi DKIM su ciascun sistema di invio e ne pubblichi la chiave pubblica.
4. Pubblichi DMARC con p=none e un indirizzo rua per i report. Google suggerisce di attendere 48 ore dopo la configurazione di SPF e DKIM prima di aggiungere DMARC.
5. Legga i report, corregga le fonti che non superano il controllo, poi passi a p=quarantine e infine a p=reject.

Configurazione di SPF: un solo record, dieci lookup

SPF è un record TXT sul dominio stesso. Ecco un dominio che invia dal proprio server tramite IPv4 e IPv6 e usa anche Google Workspace:

example.com.  3600  IN  TXT  "v=spf1 ip4:203.0.113.10 ip6:2001:db8::10 include:_spf.google.com ~all"

Nella maggior parte dei pannelli DNS si lascia vuoto il campo host (o si inserisce @), si sceglie TXT e si incolla il valore a partire da v=spf1. Elementi comuni:

Errori frequenti con SPF

• Un solo record SPF per nome. RFC 7208 vieta più record SPF per lo stesso dominio; i server riceventi restituiscono permerror e SPF fallisce per tutto. Quando aggiunge un servizio, modifichi il record esistente aggiungendo il suo include: invece di creare un secondo record v=spf1.
• Il limite di 10 lookup. I meccanismi include, a, mx, ptr ed exists e il modificatore redirect generano ciascuno ricerche DNS, e il totale sull'intera valutazione, comprese le ricerche all'interno degli include annidati, non deve superare 10. Superarlo produce permerror. ip4:, ip6: e all non costano nulla. RFC 7208 indica inoltre che i server riceventi dovrebbero fermarsi dopo due ricerche senza risposta, quindi rimuova gli include dei servizi che non usa più.
• ~all oppure -all. -all significa che le fonti non elencate non sono autorizzate (fail); ~all significa che probabilmente non sono autorizzate (softfail). Google consiglia ~all per i domini Workspace; Microsoft consiglia -all per i domini Microsoft 365 che usano anche DKIM e DMARC. Se non è ancora sicuro di aver individuato tutti i mittenti, parta da ~all e lasci l'applicazione delle regole a DMARC.
• I sottodomini hanno bisogno di un proprio record. Il record SPF su example.com non copre news.example.com. Collocare un servizio di invio massivo su un sottodominio dedicato gli assegna anche un budget separato di 10 lookup e tiene la sua reputazione distinta da quella della posta del personale.
• Errori di sintassi. Microsoft elenca i più comuni: include= al posto di include:, uno spazio dopo i due punti e un punto finale dopo il dominio incluso.

Per i domini che non inviano mai posta, pubblichi v=spf1 -all in modo che sia più difficile falsificarli.

Configurazione di DKIM: chiavi a 2048 bit e selettori

DKIM ha due parti: il sistema di invio firma con una chiave privata e il DNS pubblica la chiave pubblica corrispondente. Con Google Workspace, Microsoft 365, la maggior parte dei pannelli di controllo dell'hosting e dei servizi email, si genera la chiave nella console di amministrazione e si copia il valore DNS mostrato.

Lunghezza della chiave e selettori

Usi una chiave RSA a 2048 bit. RFC 8301 fissa a 1024 bit il minimo e indica che chi firma dovrebbe usare almeno 2048 bit; vieta inoltre rsa-sha1. Le indicazioni di Google coincidono: scelga 2048 bit se il suo provider DNS li supporta e ripieghi su 1024 solo in caso contrario.

Il selettore è un'etichetta che identifica quale chiave ha firmato un messaggio, così un dominio può avere più chiavi contemporaneamente, una per servizio di invio o una per periodo di rotazione. La chiave pubblica si trova in selector._domainkey.yourdomain. Google Workspace usa google come selettore predefinito. Microsoft 365 usa due record CNAME, selector1._domainkey e selector2._domainkey, che puntano a chiavi ospitate da Microsoft; prenda le destinazioni esatte dal portale Defender o da Get-DkimSigningConfig, perché il formato varia in base al tenant.

Pubblicare una chiave pubblica lunga

Una chiave pubblica a 2048 bit supera i 255 caratteri consentiti in una singola character-string DNS, quindi nel file di zona viene scritta come più stringhe tra virgolette in un unico record TXT:

selector1._domainkey.example.com.  3600  IN  TXT  ( "v=DKIM1; k=rsa; "
    "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA(first part of your key)"
    "(rest of your key)IDAQAB" )

Sostituisca le parti tra parentesi con la sua chiave effettiva. I server riceventi uniscono le stringhe senza spazi, quindi può dividerla in qualsiasi punto all'interno della chiave. Molti pannelli di controllo dividono automaticamente i valori lunghi: incolli prima il valore intero e lo divida personalmente solo se il pannello lo rifiuta. Si assicuri che nella copia non vada perso nulla; un p= vuoto significa che la chiave è stata revocata.

Sul suo VPS con Postfix o un MTA simile, un milter di firma come OpenDKIM può creare la coppia di chiavi, ad esempio opendkim-genkey -b 2048 -s selector1 -d example.com. Pubblichi il contenuto del file della chiave pubblica generato come mostrato sopra.

Verifichi che i messaggi siano davvero firmati

Apra un messaggio che ha inviato e cerchi un'intestazione DKIM-Signature:. Il tag d= dovrebbe essere il suo dominio e s= il selettore pubblicato. Molti servizi email firmano per impostazione predefinita con il proprio dominio; questo supera DKIM ma non è allineato con il suo dominio From, quindi non aiuta DMARC. Attivi l'autenticazione del dominio personalizzato del servizio, in modo che d= diventi il suo dominio.

Configurazione di DMARC: partire da p=none, poi applicare

DMARC è un record TXT su _dmarc sotto il suo dominio. Parta in modalità di monitoraggio, che chiede ai server riceventi di non cambiare il modo in cui trattano la sua posta, e richieda i report aggregati:

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

I report aggregati sono riepiloghi leggibili da una macchina che indicano quali indirizzi IP hanno inviato posta a nome del suo dominio e se il controllo è stato superato; Google suggerisce una casella o un gruppo dedicato per riceverli. Quando i report mostrano che ogni fonte legittima supera il controllo con allineamento, renda più rigida la policy modificando lo stesso record invece di aggiungerne un secondo:

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com"

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com"

L'allineamento, in parole semplici

Per superare DMARC, almeno uno tra SPF e DKIM deve essere superato per un dominio che corrisponde al dominio From. In modalità relaxed devono coincidere i domini organizzativi, quindi una firma DKIM con d=example.com è allineata con la posta da alerts@news.example.com. La modalità strict richiede una corrispondenza esatta. I servizi email usano spesso il proprio dominio nel Return-Path, quindi SPF non sarà allineato anche quando viene superato; un DKIM allineato è il modo pratico per far superare DMARC a quei messaggi.

Se desidera una policy diversa per i sottodomini, aggiunga sp=. Ad esempio, p=reject; sp=quarantine rifiuta la posta non conforme del dominio principale e mette solo in quarantena quella non conforme dei sottodomini.

Una nota sullo standard aggiornato

A maggio 2026 DMARC è stato ripubblicato come RFC 9989, che rende obsoleta RFC 7489. I record esistenti continuano a funzionare e iniziano ancora con v=DMARC1. Il nuovo standard elimina il tag pct, raramente applicato con precisione se non con i valori 0 o 100, e aggiunge tag come t=y (modalità di test) e np (policy per i sottodomini inesistenti). Alcune pagine di assistenza dei provider mostrano ancora pct, quindi il modo meno ambiguo per introdurre l'applicazione delle regole è passare gradualmente attraverso i valori di p=.

DNS inverso (PTR) per l'IP di invio

Il DNS inverso associa un indirizzo IP a un nome host. Google richiede a tutti i mittenti verso account Gmail personali un record PTR il cui nome host si risolva nello stesso IP di invio, e Yahoo richiede un DNS diretto e inverso valido per gli IP di invio e consiglia un record PTR significativo e non generico.

203.0.113.10       PTR  mail.example.com.
mail.example.com.  A    203.0.113.10

Il record PTR non si trova nella zona del suo dominio. Lo gestisce chi possiede l'indirizzo IP, quindi su un VPS lo si imposta nel pannello di controllo del provider (spesso chiamato reverse DNS o rDNS), poi si crea un record A corrispondente (AAAA per IPv6) nel proprio DNS. Se invia tramite IPv6, anche l'indirizzo IPv6 richiede lo stesso trattamento. Con Google Workspace, Microsoft 365, i servizi email e la maggior parte degli hosting condivisi, è il provider a gestire per lei gli IP di invio e il relativo DNS inverso.

Come verificare la configurazione

Leggere Authentication-Results

Invii un messaggio di prova a una casella esterna e visualizzi le intestazioni complete. In Gmail, apra il messaggio e scelga Mostra originale. La guida di Google su DKIM precisa che conviene inviare a un altro utente e non a se stessi. Cerchi un'intestazione come questa:

Authentication-Results: mx.example.net;
       dkim=pass header.i=@example.com header.s=selector1;
       spf=pass smtp.mailfrom=example.com;
       dmarc=pass header.from=example.com

Il formato esatto varia in base al server ricevente. Ciò che conta è spf=pass, dkim=pass e dmarc=pass, con il suo dominio in header.i o header.d e in header.from. Se SPF viene superato per il dominio di un servizio ma DKIM mostra un altro dominio, DMARC fallirà: corregga prima l'allineamento DKIM.

Interrogare direttamente il DNS

dig +short TXT example.com
dig +short TXT selector1._domainkey.example.com
dig +short TXT _dmarc.example.com
dig +short -x 203.0.113.10

Su Windows, nslookup -type=TXT _dmarc.example.com svolge la stessa funzione. Le modifiche DNS possono richiedere tempo per propagarsi; Google indica che SPF e DKIM possono richiedere ciascuno fino a 48 ore per iniziare a funzionare. Anche strumenti online gratuiti possono analizzare i suoi record e contare i lookup SPF.

Se l'autenticazione viene superata ma la posta torna ancora indietro o finisce nello spam, verifichi se l'IP o il dominio di invio è inserito in una DNSBL con il nostro controllo delle blacklist e consulti email non recapitate a causa di una blacklist per i passi successivi.

Requisiti per i mittenti di Gmail, Yahoo e Outlook.com

I grandi provider di posta ora impongono l'autenticazione. A novembre 2026, le loro pagine ufficiali indicano quanto segue.

• Gmail (in vigore dal 1 febbraio 2024): chiunque invii ad account Gmail personali ha bisogno di SPF o DKIM, di un DNS diretto e inverso corrispondenti, di una connessione TLS e di un tasso di spam inferiore allo 0,3% in Postmaster Tools. Chi invia più di 5.000 messaggi al giorno ha bisogno anche di SPF e DKIM insieme, di un record DMARC (p=none è accettabile), di un dominio From allineato con SPF o DKIM e dell'annullamento dell'iscrizione con un clic per la posta di marketing. Le chiavi DKIM devono essere di almeno 1024 bit, con 2048 consigliati.
• Yahoo (applicazione da febbraio 2024): tutti i mittenti hanno bisogno di SPF o DKIM, di un DNS diretto e inverso valido e di un tasso di spam inferiore allo 0,3%. I mittenti di grandi volumi hanno bisogno di SPF e DKIM insieme, di una policy DMARC almeno p=none che venga superata, dell'allineamento del From (relaxed va bene), di un annullamento dell'iscrizione con un clic funzionante e di un DNS diretto e inverso valido per gli IP di invio.
• Outlook.com (il servizio consumer dietro outlook.com, hotmail.com e live.com): i domini che inviano più di 5.000 email al giorno devono superare SPF e DKIM e pubblicare un DMARC almeno p=none, allineato con SPF o DKIM. Microsoft ha dichiarato che dal 5 maggio 2025 i messaggi non conformi sarebbero stati rifiutati con l'errore 550; 5.7.515.

Legga il testo completo nelle linee guida di Google per i mittenti email, nelle best practice di Yahoo per i mittenti e nell'annuncio di Microsoft per Outlook.com. Anche se invia molti meno messaggi, configurare subito tutti e tre fa sì che un'eventuale soglia più bassa in futuro non la colga impreparato. Per la risoluzione dei problemi specifici di Gmail, veda Gmail non recapita le sue email.

Errori comuni

• Un secondo record SPF. Aggiungere un nuovo record v=spf1 per ogni servizio invalida SPF per l'intero dominio. Unisca tutto in un unico record.
• Troppi include. I vecchi servizi lasciati in SPF consumano il budget di 10 lookup. Rimuova ciò che non usa più e sposti la posta massiva su un sottodominio.
• Chiave pubblicata, firma non attivata. In Google Workspace occorre comunque fare clic su Avvia autenticazione dopo che il record DNS è attivo; altre piattaforme hanno un'opzione simile.
• Il servizio firma con il proprio dominio. SPF e DKIM vengono entrambi superati, DMARC fallisce. Attivi la firma con dominio personalizzato.
• Passare subito a p=reject. Un modulo web o un sistema di fatturazione dimenticato smette di recapitare da un giorno all'altro. Parta da p=none e legga i report.
• Danni da copia e incolla. Virgolette in più all'interno del valore, una chiave troncata o un nome host che diventa _dmarc.example.com.example.com perché il pannello aggiunge automaticamente il dominio. Un rapido dig li individua tutti.

Domande frequenti

Pagine ufficiali consultate

Le informazioni di questo articolo sono state verificate sulle pagine ufficiali indicate di seguito al momento della pubblicazione. Le policy e il funzionamento possono cambiare senza preavviso: prima di fare affidamento su un'informazione importante, consulti le pagine ufficiali.

• RFC 7208: Sender Policy Framework (SPF)
• RFC 6376: DomainKeys Identified Mail (DKIM) Signatures
• RFC 8301: Cryptographic Algorithm and Key Usage Update to DKIM
• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC)
• RFC 9989: DMARC (obsoletes RFC 7489)
• Google: Email sender guidelines
• Google Workspace: Set up SPF
• Google Workspace: Set up DKIM
• Google Workspace: Set up DMARC
• Yahoo Sender Hub: Sender Best Practices
• Microsoft Community Hub: Outlook's New Requirements for High-Volume Senders
• Microsoft Learn: Set up SPF for your Microsoft 365 domain
• Microsoft Learn: How to use DKIM for email in your custom domain

Guide correlate

Tutte le guide →