Come configurare SPF, DKIM, DMAR

Come configurare SPF, DKIM, DMAR

La posta consegnata bene non dipende solo dal contenuto. Dipende anche da come i provider leggono il tuo dominio. SPF, DKIM e DMARC servono a questo: ridurre spoofing, migliorare la reputazione e aumentare la deliverability.

Se gestisci un sito, un e-commerce o un dominio aziendale, questi tre record non sono opzionali. Un errore piccolo nel DNS può finire in spam, o peggio, bloccare mail legittime come fatture, reset password e notifiche transazionali.

Nota importante: il titolo parla di DMAR, ma il record corretto è DMARC. Qui trattiamo la configurazione completa e pratica di SPF, DKIM e DMARC.

Warning: configurare i record senza inventario dei servizi di invio è il modo più rapido per rompere la posta in uscita. Prima mappa tutto ciò che invia email per tuo conto.

Prerequisiti

Prima di toccare il DNS, prepara questi elementi.

• Accesso al pannello DNS del dominio.
• Elenco dei servizi che inviano email: server web, CRM, ticketing, newsletter, helpdesk, ERP, SMTP esterno.
• Indirizzo del dominio principale e dei sottodomini coinvolti.
• Una mailbox esterna per test, meglio Gmail, Outlook e un indirizzo su dominio diverso.
• Se possibile, accesso ai log SMTP o al pannello del provider email.

Note: se usi più piattaforme di invio, non improvvisare un record SPF lungo e unico. SPF ha limiti precisi e va progettato con criterio.

Per orientarti, ecco un inventario minimo che conviene compilare prima:

Dominio: esempio.it
Invio transazionale: smtp.examplemail.com
Newsletter: mailer.sendgrid.net
CRM: salesforce.com
Helpdesk: zendesk.com
Server applicativo: 203.0.113.10

# Output: elenco completo delle sorgenti email, pronto per tradurre in SPF, DKIM e DMARC.

Step 1: mappa tutte le sorgenti di invio e scegli il dominio giusto

Spf, DKIM e DMARC funzionano solo se sai chi invia davvero. Il punto non è “mettere i record”. Il punto è evitare che un servizio legittimo fallisca l’autenticazione.

Controlla tre casi distinti. Primo: email inviate dal tuo server web, come WordPress o Magento. Secondo: email inviate da un provider terzo, come SendGrid, Mailgun o Amazon SES. Terzo: email inviate da utenti o reparti diversi con alias e sottodomini.

Esempio reale: un e-commerce usa noreply@shop.example.it per ordini, newsletter@example.it per campagne e supporto@example.it per ticket. Ognuno può avere esigenze diverse. Conviene separare i flussi con sottodomini dedicati.

Dominio principale: example.it
Transazionale: mail.example.it
Newsletter: news.example.it
Supporto: support.example.it

# Output: struttura dei domini e sottodomini definita, con responsabilità di invio separate.

Separare i flussi aiuta anche la reputazione. Se una campagna va male, non rovina subito la posta transazionale. Questo è un vantaggio concreto per deliverability e manutenzione.

Step 2: configura SPF con un solo record corretto

SPF dice quali server possono inviare mail per il dominio. Il destinatario verifica se l’IP o il servizio che ha spedito è autorizzato. Se il controllo fallisce, la mail perde credibilità.

La regola più importante è semplice: un solo record SPF per dominio. Se ne pubblichi due, molti provider lo considerano un errore.

Un record SPF tipico parte così:

v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.10 -all

# Output: record SPF valido con Google Workspace, SendGrid e un IP dedicato autorizzati.

Vediamo la logica. include: autorizza un provider terzo. ip4: autorizza un IP preciso. -all dice che tutto il resto va rifiutato. È la scelta più rigorosa, ma va usata solo quando sei sicuro di aver censito tutti i mittenti.

Se sei in fase di migrazione, puoi usare temporaneamente ~all, cioè softfail. È meno severo. Ti lascia osservare i risultati senza bloccare subito tutto.

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

# Output: SPF in modalità transitoria, utile durante il rollout.

Warning: non concatenare troppi include. SPF ha un limite di lookup DNS. Superarlo produce errori come PermError e peggiora la deliverability.

Se usi Microsoft 365, il record cambia. Un esempio frequente è questo:

v=spf1 include:spf.protection.outlook.com -all

# Output: autorizzazione SPF per Microsoft 365.

Per un server dedicato, puoi anche autorizzare un IP statico:

v=spf1 ip4:198.51.100.25 -all

# Output: solo l’IP 198.51.100.25 può inviare per il dominio.

Se il provider DNS supporta una sola riga, non spezzare il valore in più record. Il TXT deve contenere il testo completo. Molti errori nascono da copia e incolla incompleti.

Step 3: genera e pubblica DKIM per firmare i messaggi

DKIM aggiunge una firma crittografica al messaggio. Il destinatario controlla la firma con una chiave pubblica pubblicata nel DNS. Se il contenuto non è stato alterato, la firma passa.

Qui la differenza rispetto a SPF è importante. SPF valida il server che invia. DKIM valida l’integrità del messaggio e il dominio firmatario. In pratica, DKIM è più robusto quando i messaggi passano da più sistemi.

Molti provider generano la coppia di chiavi per te. Il flusso classico è: generi una chiave privata nel pannello del servizio, pubblichi la chiave pubblica in un record TXT, poi abiliti la firma.

Un record DKIM reale assomiglia a questo:

selector1._domainkey.example.it TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."

# Output: record DKIM pubblicato nel DNS per il selettore selector1.

Il selector è il nome della chiave. Ti permette di ruotare i certificati senza cambiare il dominio. È utile per manutenzione e sicurezza.

Se gestisci DKIM su un tuo MTA, puoi usare OpenDKIM. Un esempio di configurazione minima su sistema Linux è questo:

opendkim-genkey -b 2048 -d example.it -s selector1
chown opendkim:opendkim selector1.private
chmod 600 selector1.private

# Output: coppia di chiavi DKIM generata, con chiave privata protetta.

La chiave pubblica va nel DNS. La chiave privata resta solo sul server che firma. Non copiarla mai su macchine inutili. È una chiave sensibile quanto una password amministrativa.

Note: usa chiavi RSA da 2048 bit se il provider e il DNS lo supportano. Le chiavi da 1024 bit sono sempre più deboli e spesso sconsigliate.

Un esempio di configurazione OpenDKIM può essere questo:

Domain                  example.it
Selector                selector1
KeyFile                 /etc/opendkim/keys/example.it/selector1.private
Socket                  inet:8891@localhost
Canonicalization        relaxed/simple

# Output: configurazione DKIM pronta per firmare i messaggi in uscita.

Se usi un provider come Google Workspace, Microsoft 365 o Mailgun, la procedura è più semplice. Generi il record dal pannello e lo copi nel DNS. La logica però resta identica.

Step 4: imposta DMARC per decidere cosa fare con le mail fallite

DMARC collega SPF e DKIM a una politica. Dice ai destinatari cosa fare se l’autenticazione fallisce e chiede report sul traffico del dominio.

Il record DMARC vive su _dmarc.example.it. Un esempio prudente, buono per l’avvio, è questo:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.it; adkim=s; aspf=s; pct=100

# Output: DMARC in monitoraggio, con invio report aggregati all’indirizzo indicato.

Qui i parametri contano molto. p=none monitora senza bloccare. p=quarantine manda in spam i messaggi sospetti. p=reject rifiuta quelli non allineati. L’allineamento è il punto chiave di DMARC.

Per un dominio appena configurato, parti con p=none. Leggi i report per qualche giorno. Poi passa a quarantine. Solo dopo valuta reject.

Un record più maturo può essere questo:

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.it; ruf=mailto:dmarc-forensics@example.it; fo=1; adkim=s; aspf=s; pct=25

# Output: DMARC con quarantena parziale, report aggregati e forensi attivati.

Warning: non impostare subito p=reject se hai sistemi eterogenei. Un alias, un CRM o una piattaforma di newsletter non allineata può rompere mail legittime.

Se il tuo provider supporta gli indirizzi dedicati ai report, usa una mailbox separata. I report DMARC possono essere numerosi e rumorosi. Non mischiarli con la posta operativa.

Step 5: pubblica i record DNS con attenzione ai dettagli

Il DNS è il punto in cui molti progetti si inceppano. Il contenuto è corretto, ma il record è pubblicato male. Bastano virgolette sbagliate, nome host errato o TTL troppo aggressivo.

Per SPF e DKIM usa record TXT. Per DMARC usa anch’esso TXT. Nel pannello DNS, il nome host può essere richiesto in forma relativa o assoluta. Dipende dal provider.

Esempio di pubblicazione ordinata:

@                TXT   "v=spf1 include:_spf.google.com include:sendgrid.net -all"
selector1._domainkey  TXT   "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."
_dmarc           TXT   "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.it"

# Output: tre record DNS pubblicati per SPF, DKIM e DMARC.

Se il provider spezza automaticamente i TXT lunghi, va bene. Se invece ti chiede più stringhe, controlla che il valore finale resti identico. Alcuni pannelli aggiungono spazi o apici superflui.

Note: il TTL iniziale può stare su 300 secondi durante i test. Dopo la stabilizzazione, puoi alzarlo se vuoi meno churn operativo.

Step 6: verifica con strumenti reali e messaggi di test

La verifica non si fa a occhio. Va fatta con test DNS e con una mail effettivamente inviata a provider diversi.

Per controllare i record puoi usare dig:

dig TXT example.it +short
dig TXT selector1._domainkey.example.it +short
dig TXT _dmarc.example.it +short

# Output: tre risposte TXT contenenti SPF, DKIM e DMARC.

Se vuoi un controllo più immediato, puoi usare anche nslookup:

nslookup -type=TXT example.it
nslookup -type=TXT _dmarc.example.it

# Output: record TXT risolti correttamente dal DNS pubblico.

Poi invia una mail di test. Controlla le intestazioni ricevute. Cerca le righe Authentication-Results, SPF, DKIM e DMARC. Un esempio di risultato sano può essere questo:

spf=pass
 dkim=pass
 dmarc=pass

# Output: autenticazione positiva sui tre livelli.

Per una verifica più pratica, manda una mail a Gmail e apri i dettagli del messaggio. Cerca frasi come “mailed-by” e “signed-by”. Se coincidono con il tuo dominio, sei sulla strada giusta.

Un altro test utile è il comando swaks, ottimo in ambienti tecnici:

swaks --to test@gmail.com --from noreply@example.it --server smtp.example.it --auth LOGIN --auth-user noreply@example.it --auth-password '********'

# Output: invio SMTP di test con autenticazione e tracciabilità del percorso.

Verifica finale

La verifica finale deve rispondere a tre domande. SPF autorizza davvero tutti i mittenti legittimi? DKIM firma ogni flusso rilevante? DMARC riceve report e applica la policy prevista?

Usa questa checklist operativa:

• Solo un record SPF per dominio.
• Nessun servizio legittimo escluso.
• DKIM attivo su tutti i mailer importanti.
• DMARC con indirizzo rua valido.
• Allineamento coerente tra From, SPF e DKIM.
• Report letti e interpretati per almeno alcuni cicli di invio.

Se tutto è corretto, puoi alzare gradualmente la severità di DMARC. Un percorso sensato è: none per osservare, quarantine per contenere, reject per proteggere.

Un esempio di configurazione finale, per un dominio ormai stabile, può essere questo:

v=spf1 include:_spf.google.com include:sendgrid.net -all
v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.it; adkim=s; aspf=s; pct=100

# Output: politica finale rigida, con SPF chiuso e DMARC in reject.

Una volta stabilizzato tutto, documenta i record nel tuo runbook. Ti farà risparmiare ore quando dovrai cambiare provider o fare un audit di sicurezza.

Troubleshooting

1) Errore SPF: “PermError: SPF record too many DNS lookups”

Causa: hai concatenato troppi include o dipendenze annidate. SPF ha un tetto di lookup e lo superi facilmente con più servizi.

Fix con comando: riduci gli include ridondanti e verifica la catena di risoluzione.

dig TXT example.it +short
# poi rimuovi include inutili dal record SPF nel pannello DNS

# Output: record SPF più corto e sotto il limite di lookup.

2) Errore DKIM: “dkim=fail (bad signature)”

Causa: il messaggio è stato modificato dopo la firma, oppure il selettore punta a una chiave sbagliata.

Fix con comando: rigenera la chiave, ripubblica il record e riavvia il servizio di firma.

opendkim-genkey -b 2048 -d example.it -s selector2
systemctl restart opendkim
systemctl restart postfix

# Output: nuova chiave DKIM attiva e servizio riavviato.

3) Errore DMARC: “dmarc=fail (p=reject) header.from does not align”

Causa: il dominio nel campo From non coincide con il dominio che passa SPF o firma DKIM.

Fix con comando: allinea il dominio del mittente o usa un sottodominio dedicato all’invio.

# Esempio operativo
From: noreply@mail.example.it
Return-Path: bounce@mail.example.it

# Output: allineamento più semplice tra mittente visibile e dominio autenticato.

Se il problema resta, controlla i report DMARC aggregati. Spesso mostrano subito quale piattaforma sta inviando mail fuori schema. È il modo più veloce per isolare il colpevole.

Conclusione

SPF, DKIM e DMARC non sono tre caselle da spuntare. Sono un sistema unico per difendere il dominio e migliorare la consegna delle email. Se li imposti bene, riduci spoofing e aumenti fiducia.

Il prossimo passo concreto è semplice: fai l’inventario dei mittenti, pubblica SPF e DKIM, poi passa DMARC da none a quarantine dopo i primi report. Se vuoi fare le cose bene, crea anche un monitoraggio periodico dei report DMARC e dei log SMTP.