Come può un team di prodotto implementare DMARC in Cloudflare in modo sicuro?

Separa il DNS di Cloudflare dalla configurazione dei mittenti

Cloudflare può gestire il DNS autoritativo mentre un altro provider invia e firma le email dell'applicazione. Definisci questi confini prima di modificare qualsiasi cosa. La zona pubblica la policy TXT DMARC; ogni provider email controlla il proprio return path, il dominio e il selettore di firma DKIM, la verifica e talvolta il reporting; l'applicazione controlla tenant, classe del messaggio, destinatario, template, indirizzo From visibile e percorso del provider. Un record DNS valido non può correggere un mittente non autorizzato, una firma DKIM mancante, un return path non allineato o un valore From di un altro tenant. Censisci per dominio From visibile i sistemi di produzione, staging, supporto, fatturazione, identità, monitoraggio, CRM, marketing e posta personale. Assegna a ciascuno un responsabile e un contatto per il rollback, e classifica le sorgenti sconosciute nei report prima di aumentare l'enforcement.

Interroga il nome della policy valutato dai destinatari

Per la posta inviata da alerts@notify.example.test, parti dal record TXT su _dmarc.notify.example.test. Non pubblicare per errore la policy sull'host del sito web, sul mail exchanger, sul selettore DKIM o sul nome del return-path. L'attuale meccanismo di individuazione DMARC può selezionare una policy applicabile del dominio organizzativo o del suffisso pubblico quando il dominio dell'autore non ha un record valido, quindi registra sia il nome interrogato sia il dominio della policy selezionato. Interroga le risposte autoritative e ricorsive esistenti prima di aprire Cloudflare. Più record di policy sullo stesso nome, una sintassi dei tag non valida o un CNAME in conflitto possono rendere il risultato inutilizzabile. Registra il contenuto precedente, il TTL, l'output dei resolver, il responsabile e il valore atteso dopo la modifica, così il rollback è esatto invece di essere ricostruito durante un incidente.

Crea un solo record TXT, già revisionato, in Cloudflare

Apri l'account e la zona Cloudflare corretti, vai in DNS Records, scegli Add record e seleziona TXT. Usa _dmarc come nome relativo per una policy sul dominio apex, oppure l'etichetta _dmarc esatta per il sottodominio previsto. Inserisci un unico valore revisionato senza virgolette incoerenti: Cloudflare documenta che racchiude automaticamente tra virgolette i nuovi contenuti TXT salvati senza virgolette. Scegli un TTL coerente con il rollout e il ripristino, aggiungi un riferimento alla modifica che non esponga dati sensibili se opportuno, e salva solo dopo aver controllato zona, nome, valore precedente e nuovo valore. Le policy TXT sono dati DNS, non route web in proxy. Se la zona è gestita da un partner di hosting o da un altro provider autoritativo, esegui la modifica lì invece di presumere che la dashboard di Cloudflare sia autoritativa.

Costruisci il valore DMARC a partire da decisioni esplicite

Un record in fase di osservazione può iniziare con v=DMARC1; p=none e un URI approvato per i report aggregati, ma si tratta di un esempio e non di un valore universale. Metti la versione per prima, rendi intenzionale la policy richiesta e autorizza ogni destinazione dei report. Rivedi la policy dei sottodomini, la modalità di allineamento, la percentuale e i tag di reporting solo in presenza di un requisito documentato e di un'interpretazione aggiornata degli standard. Non copiare un esempio di un vendor che contiene la casella rua di qualcun altro e non passare a p=reject solo perché la sintassi è valida. Un record valido esprime la gestione richiesta ai destinatari; non dimostra che SPF o DKIM autentichino, che uno degli identificatori autenticati sia allineato con il dominio From, che tutti i percorsi di invio legittimi siano stati censiti né che un messaggio sia arrivato in inbox.

Verifica l'allineamento SPF e DKIM su messaggi reali

Invia esempi controllati da ogni percorso dell'applicazione a destinatari di cui puoi esaminare le intestazioni grezze. Registra From visibile, SMTP MAIL FROM, IP di invio, dominio DKIM d= e selettore, Authentication-Results, identificatore del provider, classe del messaggio, ambiente e orario. DMARC può essere superato tramite un SPF autenticato e allineato o tramite una firma DKIM verificata e allineata. SPF valuta un'identità SMTP e può cambiare in caso di inoltro; DKIM verifica una firma su una selezione di contenuti. Nessuno dei due sostituisce l'autorizzazione a livello di applicazione. Testa in modo deliberato l'allineamento relaxed o strict, inclusi sottodomini e percorsi di failover. L'accettazione da parte dell'API del provider, l'accettazione da parte del server di destinazione, il superamento di DMARC, la cartella di arrivo e l'engagement sono osservazioni diverse. Tieni separati questi stati, così una chiamata API riuscita o un indicatore di policy verde non vengono mai scambiati per una prova di consegna più forte.

Convalida DNS e report al di fuori della dashboard

Dopo il salvataggio, interroga i name server autoritativi di Cloudflare e più resolver ricorsivi indipendenti per il record TXT sul nome _dmarc esatto. Conserva le risposte grezze, il dominio della policy selezionato, il TTL, il resolver, il timestamp e il risultato del parser. Conferma che esista esattamente un record utilizzabile, con v=DMARC1 per primo, valori obbligatori validi e URI di reporting approvati. Ripeti il controllo dopo la finestra di cache prevista. Invia di nuovo messaggi controllati ed esamina le intestazioni lato destinatario. Cloudflare documenta DMARC Management come uno strumento per visualizzare le sorgenti di invio e i risultati aggregati di SPF, DKIM e DMARC, ma i report sono osservazioni fornite dai destinatari con ritardo, non un censimento completo in tempo reale. Mettili in relazione con le prove del provider. Fermati in caso di disaccordo tra resolver, traffico a bassa frequenza mancante, sorgenti legittime sconosciute, messaggi controllati non allineati o variazioni inattese del volume dei report.

Tratta Cloudflare DMARC Management come una modifica DNS

Secondo Cloudflare, l'attivazione di DMARC Management può proporre la creazione di un record quando non ne esiste uno, oppure aggiungere un indirizzo di Cloudflare per i report aggregati a un tag rua esistente. Rivedi questa modifica proposta come faresti con l'infrastruttura di produzione: esporta il valore precedente, conferma che le destinazioni esistenti restino intenzionali, verifica l'ambito del dominio e mantieni la possibilità di rollback. La documentazione di attivazione descrive anche l'attuale limitazione ai domini apex e un'avvertenza sui record SPF esterni. Non dedurre che la funzionalità possa riscrivere in sicurezza un percorso SPF ospitato altrove. Una sorgente o un IP presenti nell'elenco non dimostrano quale applicazione, tenant o persona li abbia autorizzati, e l'assenza di una riga non dimostra che non ci sia traffico. Usa la vista per raccogliere prove, conservando al contempo le prove provenienti da DNS autoritativo, messaggi grezzi, log del provider e audit dell'applicazione.

Aumenta l'enforcement per fasi, sulla base delle prove

Osserva abbastanza a lungo da coprire ogni mittente legittimo, classe di messaggio, andamento settimanale, job batch, percorso di failover e flusso a bassa frequenza. Classifica le sorgenti come proprie, vendor approvato, inoltrate, sconosciute o abusive. Correggi l'allineamento del traffico legittimo prima di richiedere un trattamento più severo. Un gate go/no-go dovrebbe includere DNS valido, messaggi controllati che superano i controlli, una copertura allineata accettabile, nessuna sorgente legittima sconosciuta, responsabili degli incidenti definiti, supporto pronto e un rollback testato. Aumenta la policy solo con una modifica circoscritta e approvata, e monitora sia l'autenticazione sia gli errori di business. Esegui il rollback o fermati in caso di rifiuto di messaggi legittimi, perdita di report, sorgenti inattese, incoerenze tra resolver, migrazione del provider o sorprese nell'ereditarietà dei sottodomini. Quando possibile, modifica SPF, DKIM e DMARC separatamente, così resta chiaro a cosa attribuire eventuali regressioni.

Evita gli errori più comuni con DMARC in Cloudflare

Tra gli errori frequenti: modificare la zona sbagliata, pubblicare sul nome _dmarc sbagliato, lasciare due record di policy, aggiungere virgolette non valide, sostituire un elenco rua approvato, presumere che la policy dell'apex e quella del sottodominio siano identiche e usare p=reject prima che i mittenti poco frequenti compaiano. Un altro errore è considerare lo stato salvato o rilevato nella dashboard come una prova a livello di messaggio. Usa diff esatti, destinatari controllati, query indipendenti, intestazioni grezze e log degli incidenti limitati ai destinatari coinvolti. Tieni fuori da ticket e analytics indirizzi dei clienti, corpi dei messaggi, chiavi API e dati dei report non filtrati. Se le risposte autoritative e quelle in cache restano incoerenti oltre quanto previsto, se manca un mittente atteso o se un messaggio reale non supera l'allineamento, fermati e diagnostica separatamente delega, cache, sintassi del record, inventario dei mittenti, SPF e DKIM.

Come si inserisce SendHQ

Il confine sicuro è indipendente dal provider: l'applicazione autorizza un messaggio, il provider di invio lo autentica, Cloudflare pubblica o analizza lo stato DNS e i server riceventi valutano il messaggio. Affidati alla documentazione ufficiale corrente di Cloudflare, allo standard DMARC corrente, alle risposte DNS osservate e alle evidenze di messaggi ricevuti controllati.

Domande frequenti

Fonti

• Gestire i record DNS — Cloudflare
• Tipi di record DNS di Cloudflare — Cloudflare
• Panoramica di Cloudflare DMARC Management — Cloudflare
• Attivare Cloudflare DMARC Management — Cloudflare
• Consultare le statistiche di Cloudflare DMARC — Cloudflare
• RFC 9989: DMARC — RFC Editor
• RFC 7208: SPF — RFC Editor
• RFC 6376: DKIM — RFC Editor