Come impostare SPF, DKIM e DMARC in Cloudflare

Se stai cercando di imparare come configurare SPF, DKIM e DMARC in Cloudflare, inizia con un fatto semplice: Cloudflare memorizza i record DNS, ma il tuo fornitore di posta fornisce i valori. Sembra poco. Non è poco.

Cloudflare è il luogo in cui risiedono i record, e ciò significa che modificherai le voci TXT o CNAME nel suo pannello DNS. La stringa di inclusione SPF effettiva, il selettore DKIM, la chiave pubblica e la politica DMARC provengono dal servizio che invia la tua posta, sia esso Google Workspace, Microsoft 365, SendGrid, Mailgun o un'altra piattaforma. Senza quei valori, stai indovinando.

1. Conferma cosa può e non può fare Cloudflare per l'autenticazione email

Cloudflare non inventa valori SPF, DKIM o DMARC. Li pubblica solo. Se il tuo fornitore dice di aggiungere un record TXT per SPF, Cloudflare può ospitarlo. Se il fornitore ti fornisce un selettore DKIM e un obiettivo CNAME, Cloudflare può ospitare anche quello. Ma non può decidere quali server possono inviare posta per te.

Questo è importante perché le persone spesso aprono Cloudflare per prime e cercano un pulsante magico. Non ce n'è. Hai bisogno del contenuto esatto del record dal tuo mittente prima di toccare il DNS, altrimenti rischi di pubblicare un record che supera un controllo del pannello e fallisce in una casella di posta reale.

2. Raccogli i valori DNS dalla tua piattaforma di invio email

Prima di modificare qualsiasi cosa, raccogli tre cose dalla documentazione del fornitore. Prima di tutto, raccogli i meccanismi di inclusione SPF e gli indirizzi IP che il servizio desidera nel tuo record SPF. In secondo luogo, raccogli i nomi dei selettori DKIM e i dati della chiave pubblica, o gli obiettivi CNAME se il fornitore utilizza DKIM basato su CNAME. Infine, raccogli la stringa della politica DMARC, inclusa la politica con cui intendi iniziare e eventuali tag di reporting.

Annota i valori in un unico posto. Usa i nomi esatti dei selettori. Se il tuo fornitore ti dà due selettori, non rinominarli perché sembrano disordinati. Se la documentazione dice che il record dovrebbe essere `_spf.example.net`, mantienilo così. Piccole imprecisioni di formattazione causano lunghe ore pomeridiane.

C'è un'abitudine utile qui: cattura il nome del mittente, il nome host, il tipo di record e la stringa di destinazione in una tabella prima di accedere a Cloudflare. Questo rende la fase di modifica più veloce e previene anche l'errore comune di incollare il valore corretto nel campo nome sbagliato.

3. Aggiungi un record SPF nel DNS di Cloudflare

In Cloudflare, apri DNS e crea o modifica il record TXT alla radice del dominio se il tuo fornitore invia posta dal dominio nudo. Alcuni servizi utilizzano invece un sottodominio, come `mail.example.com`, quindi utilizza il nome host specificato dal tuo fornitore, non quello che assumi. Un nome host. Un record.

Un record SPF dovrebbe di solito esistere solo una volta per un hostname. Questo è il punto che le persone trascurano. Se hai già un record SPF TXT, non crearne un secondo accanto ad esso. Unisci i mittenti autorizzati in un'unica stringa in modo che il server ricevente veda una sola politica, non due risposte in competizione.

Un valore SPF tipico include meccanismi come `include:` o `ip4:`. Se il tuo servizio aggiunge un secondo mittente in seguito, aggiorna il record esistente invece di aggiungerne un altro. Un record SPF duplicato può causare un permerror, il che significa che i sistemi riceventi potrebbero trattare il controllo come fallito anche se le singole parti sembrano corrette.

Usa il nome del record fornito dal tuo provider. Per il dominio principale, Cloudflare mostra spesso `@` come campo nome. Per un sottodominio, inserisci esattamente quell'etichetta. Non aggiungere virgolette attorno al valore a meno che il tuo provider non ti dica esplicitamente di farlo. Cloudflare memorizza il testo come contenuto DNS semplice.

4. Pubblica record DKIM TXT o CNAME in Cloudflare

DKIM è dove il selettore conta. Il fornitore può darti un record TXT come `selector1._domainkey` con una lunga chiave pubblica, oppure può darti un record CNAME che punta a un altro hostname. Cloudflare supporta entrambi, ma il tipo deve corrispondere a quanto dice il fornitore. Un valore TXT in un campo CNAME non ti aiuterà.

Molti servizi utilizzano due selettori. È normale. Google Workspace spesso utilizza due chiavi durante la rotazione, e altri fornitori fanno qualcosa di simile in modo che una chiave possa essere sostituita senza interrompere la consegna. Se il mittente ti dà `s1` e `s2`, pubblica entrambi i record. Se un secondo mittente utilizza una famiglia di selettori diversa, tieni quei record separati. I nomi possono sembrare ripetitivi; i record non sono ridondanti.

Inserisci l'hostname DKIM esattamente come fornito. Se il fornitore ti dice di creare `selector1._domainkey.example.com`, usa quell'etichetta completa in Cloudflare. Se il fornitore fornisce un obiettivo CNAME, incolla la destinazione esattamente come scritto. Cloudflare non ha bisogno di una traduzione. Ha bisogno di precisione.

Per i team che seguono l'impostazione DKIM SPF DMARC per transazionali, la stessa regola si applica anche quando il volume di email è ridotto: il selettore nel DNS deve corrispondere al selettore nell'intestazione del messaggio. Se differiscono, DKIM fallisce. Niente drammi, solo fallimento.

5. Crea un record DMARC in _dmarc

DMARC appartiene a `_dmarc.tuodominio.com`. In Cloudflare, crea un record TXT con quel nome esatto. Il valore inizia con `v=DMARC1`, poi aggiunge la tua politica e i tag opzionali. Una politica di partenza comune è `p=none`, perché ti consente di raccogliere report prima di bloccare qualsiasi cosa. Questo è il punto di partenza meno aggressivo.

Se la tua organizzazione è pronta a ricevere report, aggiungi il tag `rua` con l'indirizzo di reporting aggregato e, se necessario, il tag `ruf` per i report forensi. Usa un indirizzo che qualcuno monitora effettivamente. Una casella di posta morta non è una strategia. È una trappola.

Una regola pratica aiuta qui: inizia con una politica DMARC che corrisponde alla tua attuale tolleranza per i falsi positivi, poi stringila più tardi dopo aver verificato che i mittenti legittimi siano allineati. Se ti muovi troppo velocemente, puoi bloccare fatture, avvisi o reset delle password. Questo viene notato immediatamente.

Cloudflare memorizzerà il record DMARC TXT come qualsiasi altra voce di testo, ma i dettagli contano. Il nome del record deve essere `_dmarc`, non `dmarc`, non `_dmarc1`, e non il dominio radice. La stringa della politica deve seguire la sintassi che il tuo fornitore si aspetta. Se la tua piattaforma di posta suggerisce tag come `sp`, `adkim` o `aspf`, aggiungili solo quando comprendi l'effetto.

6. Controlla le impostazioni DNS specifiche di Cloudflare che possono bloccare la convalida

Cloudflare ha un'impostazione che causa più confusione di quanto dovrebbe: il proxying. I record di autenticazione email non dovrebbero essere proxyati. SPF, DKIM e DMARC vivono nel DNS, non dietro la nuvola arancione. Se proxyi accidentalmente un hostname relativo alla posta, stai mescolando le regole del traffico web con i record DNS email.

I nomi dei record sono un altro comune punto di errore. Un selettore DKIM che dovrebbe essere `selector1._domainkey` può essere inserito come `selector1._domainkey.` con un punto di troppo, o come `selector1 domainkey` con uno spazio copiato da una pagina del fornitore. Cloudflare accetta molti ingressi DNS, ma i sistemi di ricezione sono meno indulgenti dell'interfaccia.

I record più vecchi possono anche interferire. Se un vecchio record SPF TXT rimane accanto a quello nuovo, o se un CNAME DKIM obsoleto punta ancora a un servizio ritirato, la convalida può fallire in modi che sembrano casuali. Rimuovi l'entry morta solo dopo aver confermato che non è più necessaria. Questo mantiene il mittente attivo intatto.

Se stai anche lavorando alla configurazione dell'autenticazione email per le email transazionali, questo è il momento di controllare ogni host di invio elencato dal fornitore. Un sottodominio dimenticato può far passare un messaggio di supporto mentre un messaggio di ricevuta fallisce, e quel comportamento diviso è difficile da individuare fino a quando un cliente non si lamenta.

7. Verifica la propagazione e l'autenticazione della posta dal DNS gestito da Cloudflare

Dopo aver salvato i record, attendi la propagazione DNS. Il tempo esatto dipende dal tuo TTL e dalla cache del risolutore davanti a te, quindi non assumere che il record sia visibile ovunque nel momento in cui Cloudflare dice che è stato salvato. Controlla esternamente con uno strumento di ricerca DNS e conferma che ogni nome di record restituisca il valore atteso.

Poi invia un vero messaggio di test dal servizio che utilizza i record. Non testare da una casella di posta casuale che bypassa il tuo normale flusso di posta. Apri le intestazioni del messaggio nella casella di posta ricevente e cerca SPF pass, DKIM pass e DMARC alignment pass. Il messaggio può comunque finire nello spam per altri motivi, ma il risultato dell'autenticazione dovrebbe dirti se il lato DNS è corretto.

Un controllo rapido è sufficiente per il primo passaggio, ma un secondo controllo da una casella di posta diversa ti dà un segnale migliore. Un test su Gmail e un test su Microsoft 365 possono comportarsi in modo diverso se un risolutore vede brevemente il vecchio record mentre un altro vede il nuovo. Non è raro. Succede.

Se la deliverability fa parte dello stesso progetto, abbina questo lavoro alle migliori pratiche per la deliverability delle email. L'autenticazione non è tutta la storia, ma è la parte che consente ai destinatari di decidere se il tuo dominio sta parlando per conto suo.

8. Aggiorna i record quando il tuo fornitore di posta cambia

Le configurazioni della posta cambiano. Un fornitore ruota le chiavi DKIM, viene aggiunta una piattaforma di marketing o un servizio di transazione viene spostato dopo una migrazione. Quando ciò accade, aggiorna i record DNS in Cloudflare prima di cambiare il traffico, non dopo. Quell'ordine ti salva da un giorno di firme rotte.

La rotazione DKIM è di solito il cambiamento più pulito. Il fornitore ti dà un nuovo selettore e una chiave, tu lo pubblichi in Cloudflare e aspetti che il nuovo selettore venga convalidato prima di ritirare il vecchio. Tieni entrambi attivi durante la transizione se il fornitore lo supporta. Due selettori sono più facili di un'interruzione.

Le modifiche SPF sono un po' più delicate perché il record deve rimanere sotto i limiti di dimensione TXT DNS e di ricerca stabiliti dallo standard SPF. Se un nuovo mittente si unisce al gruppo, aggiungi il suo meccanismo di inclusione al record SPF esistente invece di impilare un altro record accanto ad esso. Se sei vicino al limite di ricerca, riduci le inclusioni non necessarie dove possibile e conferma le attuali indicazioni del fornitore.

Per i team che inviano tramite più servizi, la manutenzione diventa più semplice se una persona possiede l'elenco dei mittenti autorizzati. Questo elenco dovrebbe nominare il servizio, il nome host, il selettore DKIM e la data dell'ultima modifica. Una semplice tabella mantiene le modifiche di Cloudflare coerenti, e la coerenza è più importante dell'ingegnosità.

Se la gestione dei rimbalzi e le modifiche ai mittenti fanno parte dello stesso progetto della casella di posta, la stessa disciplina aiuta con le migliori pratiche per la gestione dei rimbalzi email. Una migrazione del fornitore può cambiare sia l'autenticazione che il comportamento degli errori nello stesso giorno, e nessuna delle due parti dovrebbe essere lasciata al caso.

Cloudflare rende la parte di pubblicazione semplice, ma i record richiedono comunque disciplina. Un mittente. Un record SPF. Ogni selettore DKIM al posto giusto. Un record DMARC a `_dmarc`. Se mantieni dritti questi quattro punti, il resto è per lo più pazienza, qualche controllo dell'intestazione e la volontà di aggiornare il DNS prima che arrivi il prossimo cambiamento della piattaforma.