Basta un record SPF da solo?

No. SPF verifica solo il mittente tecnico (Return-Path) e spesso fallisce con gli inoltri. Solo DMARC protegge l'indirizzo mittente visibile, e i grandi provider di posta richiedono SPF, DKIM e DMARC ai mittenti di grandi volumi.

Che cosa succede con più di 10 lookup DNS nel record SPF?

Il destinatario interrompe la verifica con il risultato permerror. SPF risulta quindi non superato, il che può peggiorare la recapitabilità e il risultato DMARC.

Devo usare -all o ~all?

Non appena tutti i mittenti legittimi sono inclusi nel record, -all è la scelta più chiara. ~all è adatto alla fase di transizione; la vera protezione contro lo spoofing la offre DMARC con quarantine o reject.

Quanto velocemente posso passare a p=reject?

Preveda diverse settimane. Resti su p=none finché i report non mostrano che tutti i Suoi servizi di invio superano SPF o DKIM e sono allineati, poi renda la policy più restrittiva in modo graduale.

Configurare SPF, DKIM e DMARC: guida con esempi

Perché oggi l’autenticazione e-mail è indispensabile

Il protocollo e-mail SMTP permette in linea di principio a chiunque di inserire un indirizzo mittente qualsiasi. SPF, DKIM e DMARC danno ai server destinatari la possibilità di verificare se un messaggio proviene davvero dal Suo dominio. Le ragioni concrete sono tre:

Recapitabilità: le e-mail non autenticate vengono classificate più spesso come spam o rifiutate.
Requisiti dei grandi provider: da febbraio 2024 Gmail e Yahoo richiedono a tutti i mittenti almeno SPF o DKIM. Chi invia grandi volumi (per Google: più di 5000 messaggi al giorno verso indirizzi Gmail) necessita di SPF, DKIM e di un record DMARC, almeno con p=none, oltre a un’autenticazione allineata all’indirizzo mittente. Da maggio 2025 anche Microsoft richiede SPF, DKIM e DMARC per Outlook.com, Hotmail.com e Live.com ai mittenti con più di 5000 messaggi al giorno.
Protezione dallo spoofing: solo con una policy DMARC quarantine o reject i destinatari possono scartare in modo affidabile le e-mail falsificate con il Suo dominio.

Come interagiscono i tre metodi

SPF elenca i server autorizzati a inviare per il Suo dominio. Viene verificato il dominio del mittente tecnico (Return-Path).
DKIM firma crittograficamente ogni messaggio. La chiave pubblica viene pubblicata nel DNS.
DMARC collega entrambi all’indirizzo mittente visibile (From). Un messaggio supera DMARC se SPF o DKIM hanno esito positivo e il dominio verificato corrisponde al dominio From (alignment). DMARC stabilisce inoltre che cosa succede ai messaggi non superati e fornisce report.

Tutti e tre sono record TXT. Le basi sui tipi di record si trovano nella guida Record DNS spiegati.

Configurare SPF

Struttura di un record SPF

Il record SPF è un record TXT sul dominio stesso:

example.ch.  3600  IN  TXT  "v=spf1 mx include:_spf.google.com ip4:192.0.2.25 -all"

I meccanismi vengono valutati da sinistra a destra, conta la prima corrispondenza:

ip4: / ip6: autorizzano singoli indirizzi o reti
a e mx autorizzano gli indirizzi dei record A o MX del dominio
include: riprende il record SPF di un provider
all alla fine vale per tutti gli altri server

I qualificatori davanti ad «all»

Qualificatore	Risultato	Utilizzo
`-all`	fail	Consigliato non appena tutti i mittenti sono inclusi
`~all`	softfail	Fase di transizione durante l’introduzione
`?all`	neutral	Praticamente inefficace
`+all`	pass	Consente l’invio a qualsiasi server del mondo: non usarlo mai

Il limite di 10 lookup DNS

Durante la valutazione un record SPF può generare al massimo 10 query DNS. Vengono conteggiati include, a, mx, ptr, exists e redirect, compresi gli include annidati all’interno dei record dei provider. ip4, ip6 e all non contano. Se il limite viene superato, la verifica termina con permerror e SPF risulta non superato.

Così resta sotto il limite:

Rimuova gli include dei servizi che non utilizza più.
Sostituisca a e mx con ip4/ip6, se gli indirizzi sono stabili.
Faccia inviare gli strumenti per newsletter o CRM tramite un sottodominio dedicato (ad es. news.example.ch) con un SPF separato.
Rinunci a ptr, che è obsoleto.

Un solo record SPF per dominio

Se esistono due record TXT che iniziano con v=spf1, anche in questo caso il risultato è permerror. Succede spesso quando si configura un nuovo servizio e se ne inserisce il modello in aggiunta. Inserisca invece l’include del nuovo servizio nel record esistente.

Configurare DKIM

Capire i selettori

Ogni messaggio firmato contiene nell’intestazione il dominio (d=example.ch) e un selettore (s=google). Il destinatario interroga poi la chiave sotto selettore._domainkey.example.ch. Possono esistere più selettori in parallelo, di solito uno per servizio di invio. Questo consente anche di cambiare chiave senza interruzioni. Utilizzi chiavi a 2048 bit.

google._domainkey.example.ch.  3600  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqh…"

Come pubblicano DKIM i provider più diffusi

Google Workspace: nella Console di amministrazione, in Gmail alla voce «Autentica email», generi una chiave. Il selettore standard si chiama google. Pubblichi il record TXT indicato e poi avvii l’autenticazione nella console.
Microsoft 365: qui si impostano due record CNAME, selector1._domainkey e selector2._domainkey, che puntano a destinazioni nel Suo tenant Microsoft. I valori esatti sono indicati nel portale Microsoft Defender, dove poi attiva DKIM. Il cambio delle chiavi è gestito da Microsoft.
Hostpoint: se dominio e DNS sono presso Hostpoint, attivi DKIM per il mail hosting nel Control Panel e il record viene inserito nella zona. Se gestisce il DNS esternamente, riporti manualmente selettore e chiave presso il provider DNS.
Infomaniak: DKIM si attiva nel Manager, nel servizio di posta. Se il DNS non è presso Infomaniak, inserisca personalmente il record TXT indicato.

Il nome del selettore non può essere elencato dall’esterno. Verifichi quindi nella documentazione di ogni servizio quale selettore utilizza.

Configurare DMARC

Il record DMARC si trova sempre sotto _dmarc:

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

I tag più importanti:

p: policy per il dominio: none (solo osservare), quarantine (cartella spam) o reject (rifiutare)
rua: indirizzo per i report aggregati giornalieri. Se si trova su un dominio esterno, quest’ultimo deve confermarne la ricezione tramite DNS.
sp: policy per i sottodomini, altrimenti vale p
pct: percentuale dei messaggi a cui viene applicata la policy (standard 100)
adkim / aspf: alignment per DKIM o SPF, r (relaxed, i sottodomini sono considerati corrispondenti, standard) o s (strict, corrispondenza esatta)

Il percorso sicuro verso p=reject

Osservare: inizi con p=none e rua e analizzi i report per due-quattro settimane. Mostrano tutte le fonti che inviano con il Suo dominio: CRM, newsletter, contabilità, moduli di contatto.
Correggere: per ogni fonte legittima configuri SPF e DKIM correttamente e in modo allineato al dominio From.
Quarantena: passi a p=quarantine, se necessario dapprima con pct=25, aumentando poi gradualmente.
Rifiutare: se i report restano puliti, passi a p=reject.

_dmarc.example.ch.  3600  IN  TXT  "v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@example.ch"

I domini che non inviano mai e-mail si proteggono con v=spf1 -all, una policy DMARC p=reject e, facoltativamente, un null MX (0 .).

MTA-STS e TLS-RPT

Mentre SPF, DKIM e DMARC proteggono le e-mail in uscita, MTA-STS protegge la ricezione: i server mittenti devono stabilire con i Suoi server MX una connessione cifrata con certificato valido. Servono un record TXT e un file di policy all’indirizzo https://mta-sts.example.ch/.well-known/mta-sts.txt.

_mta-sts.example.ch.  3600  IN  TXT  "v=STSv1; id=20261002"

version: STSv1
mode: testing
mx: mx1.example.com
max_age: 604800

TLS-RPT fornisce report sulle connessioni TLS non riuscite. Avvii MTA-STS con mode: testing, analizzi i report e passi poi a enforce.

_smtp._tls.example.ch.  3600  IN  TXT  "v=TLSRPTv1; rua=mailto:tls-reports@example.ch"

Checklist

Censiti tutti i servizi che inviano e-mail con il Suo dominio
Esattamente un record SPF, al massimo 10 lookup, chiusura con -all o ~all
DKIM attivo per ogni servizio di invio, chiavi a 2048 bit
DMARC pubblicato con rua, partenza con p=none
Report analizzati, poi quarantine e reject
Domini che non inviano e-mail protetti con -all e p=reject
Facoltativo: MTA-STS e TLS-RPT configurati

La verifica e-mail di NetScanner controlla MX, SPF con il numero di lookup, DMARC, i selettori DKIM più diffusi nonché MTA-STS, TLS-RPT e BIMI. I singoli record TXT li controlla con la ricerca DNS. Se una modifica non è ancora visibile, aiuta la guida sulla propagazione DNS; in caso di cambio di provider, la checklist per la migrazione del dominio.

Configurare correttamente SPF, DKIM e DMARC