[ Regionala krav ]

Designa en reproducerbar DMARC adoptionsstudie

Frys populationen och klassificeringsreglerna innan du frågar och bevara sedan fel vid sidan av framgångsrika svar.

Av EmailAuth forskningsteam · 2 min läsning

[Nyckelpunkter]

  • Frys populationen och klassificeringsreglerna innan du frågar och bevara sedan fel vid sidan av framgångsrika svar.
  • Frys omfång och behåll obearbetade observationer innan du beräknar ett resultat; en ny fråga kan inte spela upp ett tidigare DNS svar.
På den här sidan

En reproducerbar DMARC adoptionsstudien börjar med en fråga som dess observationer kan besvara. En fråga för en policypost kan fastställa vad en resolver returnerade för det namnet under ett insamlingsfönster. Det kan inte fastställa om varje meddelande som skickas av en organisation passerar autentisering, om mottagare accepterat dessa meddelanden eller om organisationen har upplevt bedrägeri.

Skriv ett protokoll innan du tittar på resultaten

Ange målpopulation, urvalsram och observationsenhet separat. Ett mål kan vara registrerade institutioner i en jurisdiktion; en ram kan vara en officiell lista över webbplatsdomäner; enheten som faktiskt efterfrågas kan vara ett DNS ägarnamn. Det är olika föremål. Verifiera entitet-till-domän-mappningen och ange varför en domän ingår. Frys uteslutningar, försök igen gränser, resolver val och klassificeringsregler före insamling så att en obekväm timeout inte kan försvinna från nämnaren senare.

Bevara observationer innan du tolkar dem

Behåll råsvar, HTTP-status, DNS svarskod, ägarens namn, posttyp, returnerade TTL- och klienttidsstämplar. Lagra skriptrevisionen och en hash av varje sparad fil. Separera transportfel från ett lyckat DNS svar utan begärt svar. Ett DNS namnfel, ett tomt svar och en timeout är inte utbytbara resultat. Förklara vilka statuser klassificeraren kan känna igen och vilka som kräver manuell granskning.

Gör publikationen revisionsbar

Publicera räkningar med nämnare och olösta observationer bredvid dem. En graf utan den efterfrågade populationen, insamlingsdatum och klassificeringsversion kan inte tolkas oberoende. Be en andra analytiker att återskapa offlinesammanfattningen från de frusna svaren innan du ber dem att köra nya nätverksfrågor. Nya frågor testar nuet, inte det förflutna. Bevara båda körningarna och förklara eventuella skillnader istället för att skriva över äldre data.

Tillämpa ett transparent hypotetiskt beslut

Anta att tio deklarerade domäner producerar sex kandidatpolicysträngar, två framgångsrika svar utan begärd data och två timeouts. Behåll alla tio försök till observationer. Rapportera sex kandidatsträngar av tio försök till domäner, med de två tomma svaren och två olösta timeouts separat. Kalla inte detta sex giltiga implementeringar: syntax, policyupptäckt och avsändardomäntäckning kräver fortfarande sina angivna kontroller. En komplett fallberäkning måste identifiera dess olika nämnare. Dessa uppfunna räkningar förklarar endast klassificeringen; ingen insamling verkställdes.

Teknisk avgränsning och publiceringsbeslut

RFC 9989 avsnitt 4.7, 4.10.1 och 5.3 särskilja postsyntax, policyupptäckt och meddelandeutvärdering. En TXT observation från exakt ägare är inte fullständig policyupptäckt. RFC 9990 Avsnitt 3.1 beskriver samlade meddelandebevis, som är separat från en domängenomsökning. RFC 2308 avsnitt 2 särskiljer negativa DNS svar; en klienttimeout är inte ett bevis på frånvaro. Val av studiedesign här är redaktionell metodik, inte statistiska krav som föreskrivs av dessa RFC:er. Denna undervisningsrevision gör inga historiska pilot- eller nationell adoptionsfynd; alla senare empiriska resultat behöver sin egen tillgängliga, hashbundna data och oberoende metodgranskning.

[ Takeaway ]

Frys omfång och behåll obearbetade observationer innan du beräknar ett resultat; en ny fråga kan inte spela upp ett tidigare DNS svar.

[Efter roll]

Vad detta betyder för dig

Välj din roll för praktiska nästa steg.

IT / Mail Admin

Gör varje resultat spårbart

En annan analytiker borde hitta det exakta svaret bakom varje räkning.

Nästa steg

  1. Behåll råsvar och hash.
  2. Spela om offline innan du samlar in ytterligare en ögonblicksbild.
  3. Spela in inställningarna för samlarrevision och timeout.

CISO / SecOps

Separera bevis från försäkran

DNS publicering är en begränsad säkerhetsobservation.

Nästa steg

  1. Avvisa påståenden om bedrägeri eller meddelandeefterlevnad.
  2. Kräv en oberoende granskning av omfattningen.
  3. Kräv spårbara källor för följdanspråk.

Grundare / Icke-teknisk

Frys forskningsfrågan

En marknadsrubrik måste matcha den faktiska observationsenheten.

Nästa steg

  1. Godkänn befolkningsuppgiften innan hämtning.
  2. Avslöja genomförbarhetsundersökningar och senare ändringar separat.
  3. Behåll studieprotokollet med det publicerade resultatet.

[ Vanliga frågor ]

Vanliga frågor

Måste jag definiera provet innan jag frågar?

Ja. Spela in urval och uteslutningsregler först; avslöja eventuella genomförbarhetsundersökningar eller senare ändringar separat.

Är en offentlig webbplatsdomän en verifierad sändningsdomän?

Nej. Det är den valda observationsenheten tills separata avsändare-bobevis fastställer mer.

Ska fel finnas kvar i datasetet?

Ja. Behåll varje försökt observation och särskilj olösta resultat från negativa DNS svar.

Kan en annan analytiker återskapa gårdagens DNS ?

De kan spela om de sparade svaren. En ny fråga kan skilja sig eftersom DNS och cacheminne ändras.

Beräknar det hypotetiska exemplet nationell adoption?

Nej. Uppfunna räkningar förklarar nämnare och klassificeringsbeslut; de är inte observationer.

Varför behålla det råa TXT svaret?

En sammanfattning kan dölja flera poster, ovanlig formatering eller ett klassificeringsfel som en granskare behöver inspektera.

Bevisar p=reject att e-post avvisas?

Nej. Det är en efterfrågad policy; mottagarens beslut och meddelandebevis är separata.

Vad måste ses över innan publicering?

Populationshärkomst, tidsstämplar, felhantering, klassificeringslogik och den exakta omfattningen av varje påstådda resultat.

[ Källor ]

Källor

  1. RFC 9989

    Avsnitt §4.4 · §4.7 · §4.10.1 · §5.3.5 · §5.4

  2. RFC 9990

    Avsnitt §3.1 · §7

  3. RFC 2308

    Avsnitt §2 Negativa svar · §5 Cacha negativa svar

[ Ordlista ]

Ordlista

Provtagningsram
Den deklarerade listan från vilken observationer väljs; det är inte nödvändigtvis målpopulationen.
Exakt ägarobservation
Ett svar på det angivna DNS namnet och -typen, utan att sluta sig till en bredare avsändare.
Okänd observation
Ett försök till mätning som inte gav tillräckliga tolkbara bevis.
Observationsfönster
Den registrerade UTC-starten och slutet av insamlingsoperationen.

Företagets härkomst

Varför toppfinansiella institutioner och regeringar avvecklat sina instrumentpaneler för e-postsäkerhet.

Traditionella plattformar för e-postautentisering säljer dig en instrumentpanel och ber dina ingenjörer att göra jobbet. I miljöer med hög insats innebär manuell övervakning försenad tillämpning, konfigurationsdrift och oövervakade skuggdomäner.

EmailAuth är den agentiska e-postplattformen. Våra agenter verkställer p=reject, håll avsändare från tredje part i linje och flytta dina domäner till fulla RFC 9989 överensstämmelse, den nya DMARC standarden, med auditerbarhet för människor i slingan.

regeringar Stora företag Tier-1 finansiella institutioner

SaaS · Dedikerad hyresavtal · Air-gapped on-prem · BYOK-kryptering

Kunskapsbas