Il tag fo chiede al ricevitore quali condizioni di errore dovrebbero generare report. Non modifica le regole di autenticazione né obbliga il destinatario a inviare report. Comprendere questa distinzione evita un errore comune: leggere un rapporto richiesto da fo=1 come prova che il messaggio non è riuscito DMARC complessivamente.
RFC 9989 sezione 4.7 definisce quattro valori: 0, 1, d e s. Il valore predefinito è 0. Il tag viene ignorato quando ruf è assente e i destinatari possono scegliere se onorare le opzioni richieste. Esaminare la privacy e la preparazione alla gestione dei report prima di ampliare una richiesta.
Comprendere 0 e 1 in termini di allineamento
Con fo=0, la condizione di segnalazione di errore DMARC richiesta è che tutti i meccanismi di autenticazione sottostanti non riescano a produrre un passaggio allineato. Con fo=1, la condizione è che qualsiasi meccanismo sottostante non riesca a produrre un passaggio allineato. La differenza riguarda l'attivatore della segnalazione, non una nuova definizione di successo DMARC .
Un messaggio può passare DMARC attraverso allineato DKIM Mentre SPF fallisce o non è allineato. Tale condizione può soddisfare una richiesta di reporting fo=1 anche se il messaggio supera DMARC . Chiamare tale rapporto un risultato DMARC contraddittorio confonde l'opzione di reporting con il risultato della valutazione.
Distinguere le opzioni specifiche del meccanismo
Il valore d richiede un DKIM rapporto di fallimento quando una firma non supera la valutazione, indipendentemente da allineamento. Il valore s richiede un rapporto di errore SPF quando la valutazione SPF fallisce, anche indipendentemente dall'allineamento. Si tratta di richieste di report specifiche del meccanismo, non di sinonimi delle condizioni di passaggio allineato di 0 e 1.
Ad esempio, un'identità SPF superata ma non allineata non diventa un errore di valutazione SPF solo perché non è allineata. Può avere importanza per la condizione di passaggio allineato fo=1 senza soddisfare s su tale base. RFC 9991 sezione 3 discute la relazione tra DMARC e segnalazioni di guasti specifici del meccanismo; la generazione effettiva rimane dipendente dal sostegno e dalla politica del destinatario.
Utilizza deliberatamente combinazioni valide
Quando si richiede più di un'opzione, separare i valori con i due punti, ad esempio fo=0:d. I valori 0 e 1 si escludono a vicenda. Non pubblicare fo=0:1 come un modo per richiedere tutto. Mantenere coerenti la versione esistente, la policy e le destinazioni di reporting durante la revisione di una proposta di modifica del record.
Frammento illustrativo: ruf=mailto:diagnostics@example.com; fo=1. Mostra una destinazione e un trigger richiesti, non un completamento Registro DMARC o una destinazione autorizzata per la tua organizzazione. Non incollare indirizzi di esempio nella produzione. Confermare le modalità di ricezione supportate e autorizzazione esterna ai sensi RFC 9991 sezione 5 ove applicabile.
Analizza due casi
Il caso sintetico A ha allineato il passaggio DKIM e il fallimento SPF . DMARC passa attraverso DKIM ; il trigger fo=1 può essere soddisfatto, mentre la condizione di tutti i meccanismi fo=0's non lo è. L'opzione s descrive una condizione di segnalazione di errore SPF in questo caso, soggetta al comportamento del ricevitore.
Il caso sintetico B ha il passaggio DKIM sotto un dominio non correlato e il passaggio SPF sotto un dominio non correlato. Nessuno dei due meccanismi fornisce un passaggio allineato, quindi DMARC fallisce e la condizione fo=0 viene soddisfatta. Né la condizione di fallimento della valutazione d né la condizione di fallimento della valutazione derivano semplicemente da questi passaggi non allineati. Questi esempi spiegano le condizioni del protocollo, non i rapporti osservati da un fornitore reale.
Verificare la richiesta senza promettere l'output
Esaminare il record pubblicato, la proprietà della destinazione, l'autorizzazione e segnalare i controlli sulla privacy del consumatore. Utilizzare un test controllato con un ricevitore cooperante, se disponibile, quindi registrare esattamente ciò che ha generato. Un rapporto di assenza non dimostra che il tag non è valido o che il test è stato superato.
Mantenere separate le decisioni di reporting aggregato e di applicazione delle norme. La modifica di fo non modifica p, né stabilisce una nuova autorizzazione SPF né ripara a Firma DKIM. Il suo scopo è richiedere un diverso insieme di report diagnostici potenzialmente sensibili.
Leggi un esempio di guasto del meccanismo
Il caso sintetico C ha una firma DKIM non riuscita e un passaggio SPF allineato. DMARC passa attraverso SPF . La condizione fo=1 può essere soddisfatta perché DKIM non ha fornito alcun passaggio allineato e d descrive la condizione di segnalazione della firma non riuscita. La condizione fo=0 non è soddisfatta perché SPF ha fornito un passaggio allineato; s non segue da un passaggio SPF . Una richiesta come fo=1:d esprime le due condizioni rilevanti, ma non obbliga il destinatario a generare nessuno dei due report. Sceglilo solo se lo scopo diagnostico e i controlli di gestione dei report giustificano una richiesta più ampia.
Tieni un registro compatto delle indagini
Utilizza questo foglio di lavoro suggerito per il percorso in esame. Si tratta di un aiuto alla pianificazione, non della prova di un test eseguito.
- Necessità: la domanda diagnostica e il trigger più ristretto che la affronta.
- Registra: i valori ruf e fo correnti, assicurando che 0 e 1 non siano combinati.
- Destinazione: proprietà, autorizzazione esterna ove necessaria, decisioni di accesso e conservazione.
- Osservazione: supporto del destinatario e segnalazioni effettive ricevute; il silenzio è inconcludente.