Configurazione delle registrazioni DNS per l'autenticazione e-mail: Spf, Dkim e Dmarc Spiegati

Perché Email Authentication Matters

Ogni giorno, miliardi di email attraversano internet, e una parte significativa di loro sono fraudolenti. E-mail spesse, attacchi di phishing e tentativi di impersonazione costano miliardi di imprese all'anno. I protocolli di autenticazione di posta elettronica - SPF, DKIM e DMARC - sono la base di un ecosistema di posta elettronica sicuro. Senza di loro, il tuo dominio è vulnerabile ad essere falsificato, i tuoi messaggi legittimi rischiano di essere contrassegnati come spam, e la reputazione del tuo marchio può soffrire può danneggiare.

La configurazione di questi record DNS non è solo un compito IT; è una funzione di business critica. Questa guida fornisce una guida completa e pronta alla produzione di SPF, DKIM e DMARC, che copre ciò che ciascuno fa, come impostarli, errori comuni da evitare e come monitorarli per la sicurezza in corso.

Cos'è SPF?

Sender Policy Framework (SP&F) è un metodo di autenticazione e-mail che specifica quali server di posta sono autorizzati a inviare e-mail per conto del tuo dominio. Funziona pubblicando un elenco di indirizzi IP approvati o hostname in un record DNS TXT. Quando un server di posta ricevente riceve un messaggio che richiede di essere dal tuo dominio, controlla il record SPF per vedere se l'invio server’s IP è stato rifiutato come ricevitore di posta elettronica non è incluso.

SPF aiuta a prevenire lo spoofing e-mail, ma ha limitazioni. Controlla solo il dominio del mittente (l'indirizzo [), non l'intestazione visibile []. Ciò significa che un martello potrebbe spoof il nome del display durante l'utilizzo di un dominio di busta diverso, bypassando SPF. Ecco perché SPF è tipicamente combinato con DKIM e DMARC.

Come SPF funziona sotto il cappuccio

Quando viene trasmessa una e-mail tramite SMTP, il server di invio annuncia il mittente di busta (di solito il Return-Path). Il server ricevente esegue un controllo DNS per il record SPF di quel dominio. Il record è un record TXT che inizia con seguito da meccanismi e modificatori.

[][]] e [][]] – specificare gli indirizzi IP esatti o i range CIDR consentiti per inviare.
[][]] – importa la politica SPF di un altro dominio (comunemente utilizzata per servizi di posta elettronica di terze parti come SendGrid o Mailgun).
[][]] e [][][]]] – autorizzare il dominio’s A o MX record come mittenti.
[][[]] – controlla se esiste un dominio particolare (raramente usato).
[][]] – qualificante che definisce l'azione predefinita per i mittenti non abbinati.

I qualifiers possono essere (pass), (softfail), [ (fallimento), o (neutral). La configurazione più sicura termina con per rifiutare tutti i mittenti non autorizzati.

Configurazione SPF passo-passo

Identificare tutte le fonti e-mail legittime[] per il tuo dominio: il tuo server di posta IP, il tuo provider di servizi e-mail (ad esempio, Google Workspace, Microsoft 365, Zoho), e qualsiasi servizio di terze parti che invia e-mail (transactional, marketing, ecc.).
Aggiungete il vostro provider DNS[[] (ad esempio, Cloudflare, AWS Route 53, GoDaddy, Namecheap).
Aggiungi un nuovo record TXT[] per il tuo dominio (spesso il ] record per il dominio root).
Creft the value[[]. Esempio per un dominio che utilizza Google Workspace e un servizio di terze parti:

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

Il meccanismo tira nelle politiche SPF di Google e Mailgun.
Usa durante il test iniziale, quindi passare a [] dopo aver verificato che non si bloccano i mittenti legittimi.

Salvare e propagare[]. I cambiamenti DNS possono richiedere fino a 48 ore, ma spesso propagarsi in pochi minuti.
Validate[]] con strumenti online come MXToolbox o Kitterman’s SPF validatore.

Pitfalls SPF comuni

Troppi lookup DNS[[] – La specifica SPF limita il numero totale di lookup DNS (compreso include, a, mx, ecc.) a 10. Escludendo questo causa il controllo SPF di restituire un errore permanente, spesso trattato come un risultato neutro.
Utilizzando []] – Un qualificatore neutrale non applica l'autenticazione; usare [ o ]] per fornire una politica significativa.
Per aggiornare[] quando si modificano i provider di posta elettronica o si aggiungono nuovi servizi.
Includendo troppi terzi include[] senza verificare che siano necessari.

Cos'è il DKIM?

DomainKeys Identified Mail (DKIM) fornisce un modo crittografico per verificare che un'email non sia stata manomessa in transito e che sia venuta dal dominio rivendicato. DKIM utilizza un paio di chiavi: una chiave privata tenuta segreta dal server di posta invio e una chiave pubblica pubblicata in un registro DNS TXT. Quando viene inviata una e-mail, il server firma il messaggio (o specifiche headers) con le chiavi private.

DKIM è più robusto di SPF perché sopravvive all'inoltro di posta elettronica. SPF può rompersi quando un messaggio viene inoltrato perché il mittente di busta può cambiare. DKIM, tuttavia, firma le intestazioni e il corpo originali, così la firma rimane valida anche dopo l'inoltro.

Come vengono create le firme DKIM

Quando viene firmata una e-mail, il server di invio aggiunge un [] intestazione contenente parametri come il selettore (che chiave pubblica da usare), il dominio, l'algoritmo di firma (solitamente []), e i campi firmati. Il corpo del messaggio viene distrutto e incluso nella firma. Il server ricevente estrae il selettore dall'intestazione, costruisce il nome chiave DNS (ad esempio record.

Configurazione DKIM: una guida pratica

Abilita la firma DKIM nella tua piattaforma di posta elettronica[[. La maggior parte dei provider ha una pagina delle impostazioni per generare chiavi.
]Nota il selettore[[]]. Molte piattaforme utilizzano [ (per Google Workspace) o []. I provider come Microsoft 365 possono usare o .
Copia la chiave pubblica[[]. Sarà una lunga stringa base64.
Aggiungi un record TXT[[] al tuo DNS con il nome host [] e il valore fornito dal tuo provider di posta elettronica, che in genere assomiglia a:

v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC...[truncated]

] il tag indica la versione è il tipo chiave (default). è il dato chiave pubblico.

]Aspetta per la propagazione[[[]] e poi prova inviando una email e esaminando le intestazioni per una firma DKIM valida. Strumenti come ] o Google’s Strumenti Postmaster possono verificare.

DKIM Rotazione chiave e sicurezza

La migliore pratica è quella di ruotare periodicamente i tasti DKIM (ad esempio, ogni 6 mesi). Molti provider di posta elettronica gestiscono automaticamente la rotazione delle chiavi. Se gestisci il tuo server di posta, genera una nuova coppia di chiavi regolarmente e aggiorna il record DNS.

Inoltre, considerare l'utilizzo ]Author Domain Signing Practices (ADSP)] per indicare che tutte le e-mail del tuo dominio dovrebbero essere firmate DKIM. Tuttavia, ADSP è in gran parte obsoleto; DMARC ora copre quel caso di utilizzo.

Cos'è DMARC?

L'autenticazione dei messaggi basata sul dominio, Reporting & Conformance (DMARC) unifica SPF e DKIM in un unico quadro politico. DMARC dice ai server di posta che cosa fare con i messaggi che non riescono a controllare sia SPF che DKIM. Inoltre fornisce un meccanismo di report che fornisce ai proprietari di dominio visibilità in errori di autenticazione e-mail, aiutandoli a rilevare abusi e a regolare le loro configurazioni.

La politica DMARC è impostata in un record DNS TXT sotto []. Il record specifica una politica per come trattare la posta non autenticata: [ (solo il motore), (marca come spam), o (consegna blocco).

Come DMARC allinea SPF e DKIM

DMARC introduce il concetto di allineamento identificativo. Per SPF passare DMARC, il dominio nella busta da (o Return-Path) deve allineare con il dominio nel visibile [ intestazione. Per DKIM, il dominio di firma (il parametro nell'intestazione DKIM-Signature) deve allineare.

Un controllo DMARC riesce se almeno uno dei passaggi SPF o DKIM [ e[]]] si allinea con il dominio utilizzato nell'intestazione .

Configurazione di DMARC: dal monitoraggio all'esecuzione

Inizia con una politica [][[]]. Questo consente di raccogliere report senza influenzare la consegna.
Aggiungi un indirizzo email di report[[]] usando il tag (relazioni aggregate) e facoltativamente [ (relazioni forensiche). Esempio:

v=DMARC1; p=none; rua=mailto:[email protected]

Analizzare i report[[] per almeno due settimane. Utilizzare strumenti come Postmark’s DMARC Dashboard, DMARCian, o Dmarcian. Cercare qualsiasi servizio legittimo che non sia l'autenticazione e li fissi (aggiornamento SPF, aggiungere DKIM firma).
Movi a [][]] una volta che siete sicuri che nessuna email legittima non sta fallendo.
Infine, imposta [ dopo un mese o due di una gestione della quarantena di successo. Questo significa che i ricevitori bloccano tutte le email non autenticate, fornendo la protezione più forte contro lo spoofing.

DMARC Tags e opzioni

][]] – versione (obbligatorio).
][] – politica per il dominio organizzativo (none, quarantena, rigetto).
[][]] – politica per i sottodomini (se non impostati, i sottodomini ereditano ).
[][]] o [][][] – DKIM modalità di allineamento (stritto o rilassato).
[][]] o [][][]] – modalità di allineamento SPF.
[] – indirizzo(es) e-mail per un feedback aggregato (solitamente un mailto: URI).
[][]] – email per i rapporti forensi (utilizzato per i dettagli di guasto individuali).
[][]] – opzioni di segnalazione dei guasti (ad esempio ] per generare report se un controllo non riesce).
[][]] – percentuale dei messaggi per applicare la politica (utilizzare 100 per l'applicazione completa).

DMARC Reporting e monitoraggio

I report aggregati (rua) sono file XML inviati quotidianamente da ricevitori partecipanti (come Google, Yahoo, Microsoft). Essi contengono conteggi di messaggi per fonte IP, risultati di autenticazione e disposizione.

Per un approccio pratico, è possibile impostare un servizio di analisi report come dmarcian]] o utilizzare soluzioni open source come parsedmarc].

Mettere tutto insieme: una strategia di autenticazione coesa

SPF, DKIM e DMARC lavorano in sinergia. SPF impedisce agli IP non autorizzati di inviare la posta tramite il proprio dominio. DKIM garantisce l'integrità del messaggio e la provenienza. DMARC allinea questi due e fornisce uno strato di applicazione delle policy più visibilità.

Ecco una lista di controllo per una configurazione di livello di produzione:

SPF:[]] Pubblica un record che include tutte le fonti di invio legittime, rispetta il limite di 10 lookup, e termina con (dopo il test).
DKIM:[]] Firma tutte le email in uscita con almeno un selettore. Ruota regolarmente i tasti.
DMARC:[]] Inizia con , analizza i rapporti, poi progredisci e infine . Impostare l'allineamento a rilassamento a meno che non si abbiano requisiti rigorosi.
Monitor continuamente:[] Controlla regolarmente i rapporti DMARC, soprattutto dopo l'aggiunta di nuovi servizi di posta elettronica.

Real-World Esempio: Configurazione per Directus

Se si ospita un'istanza Directus e invia e-mail (ad esempio, reimpostazioni password, notifiche), è necessario autenticare tali messaggi. Assumere la tua app Directus utilizza un servizio SMTP come SendGrid o Mailgun.

Ottenere gli IP di invio o includere il dominio dal provider SMTP (ad esempio, per SendGrid).
Se si invia anche da un altro sistema (ad esempio, un server di posta PHP), includere anche i suoi IP.
Generare chiavi DKIM nel tuo provider SMTP’s dashboard e pubblicare la chiave pubblica.
Impostare un record DMARC con ] indicando un indirizzo e-mail monitorato.
Prova inviando una e-mail di prova da Directus a una casella di posta come Gmail e ispeziona le intestazioni di autenticazione.

Risoluzione dei problemi Problemi comuni

SPF PermError: Troppi lookup

Se il record SPF include più dichiarazioni , è possibile superare 10 lookup DNS. Per correggere, o rimuovere inutili include, combinarle utilizzando intervalli IP, o creare un sottodominio con un record SPF più lento.

DKIM Segnatura Mancante o ingannevole

Per i provider di posta elettronica condivisi, assicuratevi che la firma DKIM sia abilitata nel pannello di controllo. Verificate che il selettore del record DNS TXT corrisponda al selettore nell'intestazione e-mail.

DMARC Reports Mostra guasti per email legittima

Cause comuni: email inoltrata (SPF non riesce perché il inoltratore cambia la busta), servizi di terze parti non DKIM-signing, o allineamento errore. Per email inoltrata, considerare l'utilizzo ARC (Authenticated Received Chain) se supportato, o istruire i destinatari alla whitelist. Per i servizi di terze parti, aggiungere la firma DKIM e garantire SPF include i loro server.

Risorse e Riferimenti esterni

Per immersioni più profonde, fare riferimento a queste fonti autorevoli:

Pensieri finali

Configurare SPF, DKIM e DMARC non è un compito di sola volta ma un processo continuo. I paesaggi di autenticazione e-mail si evolvono e così fanno minacce. Con l'impostazione di questi record correttamente e il monitoraggio in continuazione, si protegge il dominio, migliora la consegna e costruire la fiducia con i destinatari. Inizia con un'attenta verifica della tua infrastruttura di invio e-mail, implementare i record uno per uno, e non saltare mai la fase di reportistica.