[ Rapporter og undersøgelser ]

Anmodninger om fo-tag og fejlrapportering

Vælg den tilsigtede fejlrapportudløser, og hold den adskilt fra DMARC -beståelsesresultatet, håndhævelsespolitikken og den samlede rapportering.

Af EmailAuth -forskningsteamet · 3 min læst

[Nøglepunkter]

  • for ændringer af rapporteringsanmodninger, ikke DMARC succes eller håndhævelse.
  • 0 og 1 udelukker hinanden; flere tilladte muligheder bruger kolonseparatorer.
  • Ingen rapport er garanteret, og ruf-destinationer kræver gennemgang af privatliv og godkendelse.
På denne side

Fo-tagget spørger en modtager, hvilke fejltilstande der skal generere rapporter. Det ændrer ikke godkendelsesreglerne eller tvinger en modtager til at sende rapporter. Forståelse af denne sondring undgår en almindelig fejl: læsning af en rapport anmodet af fo=1 som bevis på, at meddelelsen mislykkedes DMARC samlet set.

RFC 9989 afsnit 4.7 definerer fire værdier: 0, 1, d og s. Standarden er 0. Tagget ignoreres, når ruf er fraværende, og modtagere kan vælge, om de vil respektere de anmodede muligheder. Gennemgå privatlivets fred og klarhed til rapporthåndtering, før du udvider en anmodning.

Forstå 0 og 1 med hensyn til justering

Med fo=0, er den anmodede DMARC -fejlrapportbetingelse, at alle underliggende autentificeringsmekanismer ikke kan producere en tilpasset pass. Med fo=1, er betingelsen, at en hvilken som helst underliggende mekanisme ikke formår at producere en tilpasset pas. Forskellen vedrører rapporteringsudløseren, ikke en ny definition af DMARC succes.

En meddelelse kan sende DMARC gennem aligned DKIM mens SPF fejler eller er ujusteret. Denne betingelse kan opfylde en fo=1 rapporteringsanmodning, selvom meddelelsen passerer DMARC . At kalde en sådan rapport for et modstridende DMARC -resultat forveksler rapporteringsmuligheden med evalueringsresultatet.

Skelne mekanisme-specifikke muligheder

d-værdien anmoder om en DKIM fejlrapport når en signatur fejler evaluering, uanset justering. S-værdien anmoder om en SPF fejlrapport, når SPF evaluering mislykkes, også uanset justering. Disse er mekanismespecifikke rapportanmodninger, ikke synonymer for betingelserne for aligned-pass 0 og 1.

For eksempel bliver en bestået, men ikke-tilpasset SPF identitet ikke en SPF evalueringsfejl, udelukkende fordi den er ikke-justeret. Det kan have betydning for fo=1 aligned-pass-tilstanden uden at opfylde s på det grundlag. RFC 9991 afsnit 3 diskuterer forholdet mellem DMARC og mekanismespecifikke fejlrapporter; faktisk produktion forbliver afhængig af modtagersupport og politik.

Brug gyldige kombinationer med vilje

Når du anmoder om mere end én mulighed, skal du adskille værdier med koloner, såsom fo=0:d. Værdierne 0 og 1 udelukker hinanden. Udgiv ikke fo=0:1 som en måde at anmode om alt på. Hold den eksisterende version, politik og rapporteringsdestinationer sammenhængende, når du gennemgår en foreslået registreringsændring.

Illustrativt fragment: ruf=mailto:diagnostics@example.com; fo=1. Den viser en anmodet destination og trigger, ikke en komplet DMARC rekord eller en destination, der er blevet godkendt til din organisation. Indsæt ikke eksempeladresser i produktionen. Bekræft understøttede modtageordninger og ekstern autorisation i henhold til RFC 9991 afsnit 5 hvor det er relevant.

Gå igennem to sager

Syntetisk kasse A har justeret DKIM pass og SPF fail. DMARC passerer gennem DKIM ; fo=1 udløseren kan opfyldes, mens fo=0's betingelse for alle mekanismer ikke er det. Indstillingen s beskriver en SPF -fejlrapporttilstand i dette tilfælde, afhængigt af modtagerens adfærd.

Syntetisk sag B har DKIM -pass under et ikke-relateret domæne og SPF pass under et ikke-relateret domæne. Ingen af ​​mekanismerne leverer et tilpasset gennemløb, så DMARC fejler, og fo=0 -betingelsen er opfyldt. Hverken d- eller s-evalueringsfejl-tilstanden følger blot af disse uafstemte afleveringer. Disse eksempler forklarer protokolbetingelser, ikke rapporter observeret fra en rigtig udbyder.

Bekræft anmodningen uden at love output

Gennemgå den offentliggjorte registrering, destinationsejerskab, autorisation og rapportens forbrugers privatlivskontrol. Brug en kontrolleret test med en samarbejdende modtager, hvis en sådan er tilgængelig, og optag derefter præcis, hvad den genererede. En fraværende rapport beviser ikke, at tagget er ugyldigt, eller at testen er bestået.

Hold den samlede rapportering og håndhævelsesafgørelser adskilt. Ændring af fo ændrer ikke p, etablering af en ny SPF -autorisation eller reparation a DKIM signatur. Dens formål er at anmode om et andet sæt af potentielt følsomme diagnostiske rapporter.

Læs et eksempel på mekanismesvigt

Syntetisk kasse C har en mislykket DKIM -signatur og et tilpasset SPF pas. DMARC passerer gennem SPF . fo=1 betingelsen kan opfyldes, fordi DKIM ikke leverede nogen aligned pass, og d beskriver rapporteringsbetingelsen med mislykket signatur. fo=0 betingelsen er ikke opfyldt, fordi SPF leverede et tilpasset pass; s følger ikke af et SPF pas. En anmodning som fo=1:d udtrykker de to relevante betingelser, men forpligter ikke en modtager til at generere nogen af ​​rapporterne. Vælg det kun, hvis det diagnostiske formål og kontrollerne til rapporthåndtering berettiger den bredere anmodning.

Før en kompakt undersøgelsesjournal

Brug dette foreslåede arbejdsark til ruten under gennemgang. Det er en planlægningshjælp, ikke bevis på en udført test.

  • Behov: det diagnostiske spørgsmål og den snævreste trigger, der adresserer det.
  • Registrering: aktuelle ruf- og fo-værdier, der sikrer, at 0 og 1 ikke kombineres.
  • Destination: ejerskab, ekstern autorisation, hvor det er nødvendigt, adgangs- og opbevaringsbeslutninger.
  • Observation: modtagerstøtte og faktiske rapporter modtaget; tavshed er uendelig.

[ Takeaway ]

for ændringer af rapporteringsanmodninger, ikke DMARC succes eller håndhævelse. 0 og 1 udelukker hinanden; flere tilladte muligheder bruger kolonseparatorer. Ingen rapport er garanteret, og ruf-destinationer kræver gennemgang af privatliv og godkendelse.

[Efter rolle]

Hvad betyder det for dig

Vælg din rolle for praktiske næste trin.

IT / Mail Admin

Læs hver trigger præcist

Opretningsbaserede og mekanismespecifikke forhold er forskellige.

Næste trin

  1. Brug kolon til gyldige kombinationer.
  2. Kombiner aldrig 0 og 1.
  3. Registrer den faktiske modtageradfærd separat.

CISO / SecOps

Lad være med at sidestille rapporter med fejl

En fo=1 rapport kan beskrive mail, der bestod DMARC .

Næste trin

  1. Kræv præcise hændelsesmærker.
  2. Tjek destinationsgodkendelse.
  3. Hold håndhævelse og rapporteringsgodkendelser adskilt.

Grundlægger / Ikke-teknisk

Forstå omfanget af en diagnostisk anmodning

Bredere rapportering kan afsløre flere beskeddetaljer uden at ændre beskyttelsen.

Næste trin

  1. Definer det diagnostiske behov.
  2. Gennemgå indvirkningen på privatlivets fred.
  3. Angiv en gennemgangsdato for bredere anmodninger.

[ Ofte stillede spørgsmål ]

Ofte stillede spørgsmål

Hvad er standard fo-værdien?

Standarden er 0, der anmoder om en DMARC fejlrapport, når alle underliggende mekanismer ikke kan producere en tilpasset gennemgang.

RFC 9989 §4.7

Fungerer du uden ruf?

Nr. RFC 9989 kræver, at fo ignoreres, når ruf er fraværende.

RFC 9989 §4.7

Kan fo=1 rapportere om DMARC-passerende mail?

Ja. Den ene mekanisme kan mangle et tilpasset gennemløb, mens den anden leverer det justerede gennemløb, der er nødvendigt for DMARC .

RFC 9989 §4.7

Kan jeg kombinere 0 og 1?

Nej. De udelukker hinanden; flere tilladte værdier bruger kolonseparatorer.

RFC 9989 §4.7

Betyder d unaligned DKIM ?

Nej. Den anmoder om en DKIM fejlrapport for en signatur, der fejler evaluering, uanset justering.

RFC 9989 §4.7

Udløser s, blot fordi SPF ikke er justeret?

Nej. Dens tilstand er mislykket SPF evaluering, ikke blot en forbigående identitet, der mangler tilpasning.

RFC 9989 §4.7

Vil en modtager respektere enhver ønsket mulighed?

Ikke nødvendigvis. Rapportgenerering og valgmuligheder forbliver underlagt modtagerens implementering og politik.

RFC 9991 §3

Ændrer ændring til håndhævelsen?

Nej. Det ændrer en rapporteringsanmodning, ikke p eller DMARC godkendelsesbeslutningen.

RFC 9989 §4.7

[ Kilder ]

Kilder

  1. RFC 9989 : Domænebaseret meddelelsesgodkendelse, rapportering og overensstemmelse

    Afsnit §4.4 · §4.5 · §4.7

  2. RFC 9991 : DMARC -fejlrapportering

    Afsnit §2 · §3 · §5 · §7

[ Ordliste ]

Ordliste

Identifikatorjustering
Det påkrævede forhold mellem forfatterdomænet og et godkendt SPF eller DKIM domæne for DMARC .

RFC 9989 §4.4

Samlet rapporteringsanmodning (rua)
Et DMARC -tag, der angiver destinationer for samlede godkendelsesrapporter.

RFC 9989 §4.7

Anmodning om fejlrapportering (ruf)
Et DMARC tag, der angiver destinationer for potentielt følsomme beskedspecifikke fejloplysninger.

RFC 9989 §4.7

Fejlrapporteringsmuligheder (fo)
Anmodede fejlrapportforhold, kun overvejet med en ruf-destination; de ændrer ikke DMARC pass-betingelsen.

RFC 9989 §4.7

Virksomhedens herkomst

Hvorfor top finansielle institutioner og regeringer pensionerede deres e-mailsikkerhedsdashboards.

Traditionelle e-mail-godkendelsesplatforme sælger dig et dashboard og beder dine ingeniører om at gøre arbejdet. I miljøer med høj indsats betyder manuel overvågning forsinket håndhævelse, konfigurationsdrift og uovervågede skyggedomæner.

EmailAuth er den agentiske e-mail-herkomstplatform. Vores agenter håndhæver p=reject, hold tredjepartsafsendere på linje og flyt dine domæner til fuld RFC 9989 compliance, den nye DMARC standard, med menneskelig auditabilitet.

regeringer Store virksomheder Tier-1 finansielle institutioner

SaaS · Dedikeret lejemål · Air-gapped on-prem · BYOK-kryptering

Vidensbase