Un plausibile DMARC string può fallire perché è stata pubblicata con il nome sbagliato, divisa in record separati o alterata da un editor. Può anche contenere un valore di policy non valido che presenta un fallback specifico anziché l'errore generico previsto da un operatore.
Esaminare l'esatto valore restituito in più fasi. Preservare innanzitutto la rappresentazione DNS e i limiti dei record, quindi ispezionare l'identificazione, la grammatica e la semantica delle policy. Questo approccio rende la correzione rivedibile ed evita cambiamenti politici non necessari.
Confermare il proprietario e registrare i confini
Interrogare il nome _dmarc applicabile per il dominio Da effettivo. Salva il pieno registrazione TXT set, autorità, ora e TTL. Un valore nella radice del dominio non soddisfa il nome di pubblicazione previsto.
Un record di risorse TXT può contenere diverse stringhe di caratteri. DMARC unisce le stringhe all'interno di quel record in ordine prima di analizzarle RFC 9989 §4.5. Non unisce record di risorse separati in un'unica policy.
Ad esempio, questo è un record in stile zona sintetica:
_dmarc.example.com. 300 IN TXT "v=DMARC1; " "p=none"Le virgolette delimitano la rappresentazione del file di zona. Esaminare ciò che il provider DNS effettivamente memorizza e restituisce prima di decidere che le virgolette siano un contenuto letterale del record.
Identificare prima la versione
Sotto RFC 9989 §4.7 e quello ereditato RFC 6376 §3.2 sintassi, utilizzare i nomi dei tag in minuscolo registrati e il valore esatto della versione DMARC1 . Il tag v deve apparire per primo. Una versione mancante, un valore diverso o una versione che appare solo dopo un altro tag fanno sì che il record venga ignorato RFC 9989.
Non fare affidamento sulla modifica delle maiuscole e minuscole dei nomi dei tag per produrre un tag riconosciuto equivalente. I valori hanno anche requisiti specifici dei tag; il valore della versione fa esplicitamente distinzione tra maiuscole e minuscole.
Questo è diverso dal comportamento dei maiuscole e minuscole dei nomi DNS . Evitare di estendere una regola generale del nome DNS al testo all'interno di una policy DMARC .
Ispeziona con precisione i separatori e gli spazi bianchi
Le coppie tag-valore utilizzano il punto e virgola come separatori. Le virgole hanno un ruolo diverso all'interno di un elenco di destinazione del reporting e non possono sostituire ogni punto e virgola nel record.
Gli spazi bianchi non sono universalmente vietati. L'ereditato RFC 6376 §3.2 la grammatica del valore del tag consente gli spazi bianchi attorno alla sintassi del tag, ma ciò non autorizza gli spazi all'interno di un token la cui grammatica del valore li vieta.
Un'operazione di copia e incolla può introdurre virgolette tipografiche, punteggiatura non standard o interruzioni di riga involontarie. Confronta gli esatti caratteri memorizzati con la grammatica invece di riparare il valore a vista. Conservare sia la forma originale che quella corretta proposta.
Utilizzare dispositivi che denominano la fase di elaborazione
I seguenti incontri sintetici illustrano problemi e decisioni distinti. Non sono risultati di test in tempo reale o una promessa di etichette diagnostiche identiche per ogni implementazione.
- Dispositivo con un nome proprietario: v=DMARC1; p=none; rua=mailto:reports@example.com; Risultato della revisione: nessuna policy e richiesta di reporting esplicite
- Apparecchio con un nome proprietario: p=none; v=DMARC1; Risultati della revisione: la versione non è la prima; ignorare questo record
- Dispositivo con un nome proprietario: v=DMARC2; p=none; Risultati della revisione: non la versione attualmente definita; ignorare questo record
- Dispositivo con un nome proprietario: v=DMARC1; p=invalid; rua=mailto:reports@example.com; Risultato della revisione: applicare l'attuale fallback delle norme condizionali
- Dispositivo con un nome proprietario: v=DMARC1; p=invalid; Risultati della revisione: nessun URI rua qualificante per quel fallback
- Dispositivo con un nome proprietario: v=DMARC1; p=none; p=reject; Risultato della revisione: nome tag duplicato; riparare l'elenco di tag non valido anziché selezionare un valore
- Dispositivo con un nome proprietario: due record separati ciascuno che inizia con v=DMARC1; Risultati dell’analisi: molteplici candidati politici; ispezionare il filtraggio e il rilevamento dei set di record
- Dispositivo con un nome proprietario: v=DMARC1; p=none; xnote=example; Risultati della revisione: il tag sconosciuto viene ignorato in base alle regole attuali
Un tag sconosciuto personalizzato non dovrebbe diventare parte del contratto di politica operativa semplicemente perché un parser lo ignora. Utilizza campi documentati e conserva le note amministrative nel record delle modifiche.
Distinguere i nomi duplicati da più record
Un tag duplicato è un nome ripetuto all'interno di un elenco di tag. L'ereditato RFC 6376 §3.2 DKIM la sintassi tag-value vieta i nomi duplicati e considera l'elenco come non valido. Non dare per scontato che l'ultimo valore p sovrascriva il primo o combinare due tag rua senza una correzione pianificata.
Più record di policy costituiscono un livello diverso. Sotto RFC 9989 §4.10, l'attuale elaborazione del percorso ad albero DNS elimina più record di policy DMARC su una destinazione. Discovery potrebbe quindi trovare un'altra politica applicabile. Un incontro che verifica solo il nome non ha stabilito il risultato completo del ricevitore.
Mantieni questi risultati separati in una segnalazione di bug: conteggio esatto dei record, valore del record singolo concatenato, nomi duplicati e successivo rilevamento.
Applicare la politica di riserva attuale senza generalizzarla eccessivamente
Sotto RFC 9989 §4.10.1, una p mancante o non valida, o sp o np non validi, provoca la continuazione dell'elaborazione come p=none solo se rua contiene almeno un URI di reporting sintatticamente valido. In caso contrario, al messaggio non verrà applicata alcuna elaborazione DMARC in base a tali regole.
Questa condizione non convalida ogni tag-list arbitrariamente interrotto. Un record ignorato all'identificazione della versione non diventa utilizzabile solo perché contiene un indirizzo successivo. Applicare le regole nella fase a cui appartengono.
Sotto RFC 9990 §4, un URI di segnalazione sintatticamente valido non dimostra inoltre l'autorizzazione alla destinazione esterna, la raggiungibilità o l'effettiva raccolta. La guida alle no-report copre quelle dipendenze separate.
Verificare la correzione approvata
Crea un set di record coerente con il nome esatto del proprietario. Esamina le regole dei tag definite in RFC 9989 §4.7, il riferimento al registro in RFC 9989 §9.3 e il completo cambiamento semantico. Non aggiungere un altro record di policy come sostituzione.
Salvare la differenza di configurazione e il vecchio valore per indagini e ripristino. Controlla le risposte autorevoli dopo la modifica, confronta le visualizzazioni ricorsive pertinenti e tieni conto dei dati precedenti memorizzati nella cache. Il flusso di lavoro della registrazione unisce tali controlli al test rappresentativo della posta.
Infine, invia un messaggio controllato attraverso il percorso effettivo dell'applicazione. Una politica sintatticamente valida non lo dimostra SPF oppure DKIM si allinea con Da. Conserva insieme la correzione DNS e la prova di autenticazione del mittente, con risultati separati ove necessario.
Il risultato utile è una spiegazione precisa del difetto, della sua fase di lavorazione, del valore corretto e dell'esito della posta verificata. Ciò è più duraturo che dichiarare un errore permanente ogni stringa dall'aspetto non corretto.
Mantenere la decisione e le prove separate
Per v=DMARC1; p=invalid con un URI rua valido, applica il fallback condizionale indicato solo dopo che il record raggiunge la fase pertinente. Non applicare la regola di riparazione a un elenco di versioni rifiutate o di tag duplicati. Mantenere l'intento della policy e il test effettivo del messaggio come prova di approvazione separata. RFC 8767 §4 consente risposte obsolete qualificanti dopo la scadenza del TTL; la modifica della sintassi non sostituisce immediatamente ogni cache. Non è stato eseguito alcun test del parser, DNS o della posta.