[ SPF ]

Undersøg et pludseligt fald i SPF overholdelse

Adskil reelle autentificeringsfejl fra ændring af trafik, justering og rapporteringsdækning, før du reagerer på en faldende SPF procent.

Af EmailAuth -forskningsteamet · 3 min læst

[Nøglepunkter]

  • Definer tæller, nævner, reportersæt og tidsvindue.
  • Adskil trafikblandingsændringer fra legitime autentificeringsfejl.
  • Validere repræsentative transaktioner, før du vælger en reparation.
På denne side

Et fald SPF overholdelsesprocent er et signal om at undersøge, ikke en DNS diagnose. Nummeret kan repræsentere rå SPF beståelse, justeret SPF beløb, en leverandørspecifik klassifikation eller kun de meddelelser, der er synlige for visse rapporterende modtagere. Rekonstruer først dens tæller, nævner og tidsvindue. Ellers kan en vellykket infrastrukturændring forveksles med et angreb eller en rapporterende artefakt.

Definer målingen

Skriv den præcise metrik ned: for eksempel "beskeder med tilpasset SPF pas divideret med alle meddelelser i disse modtagne rapporter i løbet af dette UTC-interval." Registrer de inkluderede reportere, mængde, manglende perioder og eventuelle deduplikeringsregler. Hold rå SPF resultater adskilt fra DMARC justering. SPF kan bestå for et domæne, der ikke er relateret til forfatterdomænet, så et antal beståelser og et antal beståelser svarer til forskellige spørgsmål. RFC 9989 §3.2.4, RFC 9989 §4.4.

Sammenlign absolutte tal såvel som satser. Illustrativt eksempel: i går havde 9.900 af 10.000 observerede beskeder justeret SPF . I dag passerer de samme 9.900 legitime beskeder, men 10.000 yderligere uautoriserede beskeder dukker op. Antag, at de oprindelige 100 ikke-justerede observationer også forbliver, hvilket giver 20.000 observationer i dag. Satsen falder fra 99 % (9.900/10.000) til 49,5 % (9.900/20.000) uden en ny fejl i den kendte legitime strøm. Disse er syntetiske aritmetiske input, ikke rapportmålinger. Det er fortsat en sikkerhedsrelevant ændring, men at tilføje disse kilder til SPF ville være det forkerte svar.

Partitioner før redigering

Opdel ændringen efter kilde-IP, kuvertdomæne, Fra domæne, udbyder eller applikation, modtagerrapporter, adressefamilie og råresultat. Find det tidligst ændrede segment og sammenlign det med DNS ændringer, nye kampagner, routingændringer, failover-hændelser og tjenestemigreringer. Indberettede kildeadresser alene fastslår ikke virksomhedsejerskab.

Klassificer fail, softfail , neutral, ingen, temperror og permerror separat. Resultatforskellene betyder noget: Et DNS udfald har ikke den samme korrigerende handling som en nyligt uautoriseret adresse eller en forkert udformet post. For en fejlsti skal du fange den nøjagtige politik og indlejrede afhængigheder; SPF evalueringsgrænser er ikke en simpel optælling af synlige inkluderer strenge. RFC 7208 §4.6.4, RFC 7208 §8.

Bekræft med transaktionsbevis

Tag en repræsentativ fejlmeddelelse fra hver berørt legitim strøm. Få SMTP logfiler eller den modtagne original med godkendelsesresultater fra en betroet grænse. Kontroller den tilsluttede IP og den faktiske MAIL FRA identitet, og reproducer derefter sin politikevaluering med dateret DNS bevis. En dashboard-etiket bør pege på disse observationer i stedet for at erstatte dem. RFC 8601 §1.2, RFC 8601 §7.1.

Hvis den rå beståelsesrate er stabil, men justeringen falder, skal du kigge efter et nyt konvolutdomæne. Hvis kun én modtagerpopulation ændres, skal du sammenligne videresendelses- og forbindelsesstier. Hvis den legitime mængde falder, mens ukendt mængde vokser, skal du undersøge de ukendte kilder uden at godkende dem. Hvis rapporteringsdækningen ændrer sig, anmærk serien i stedet for at opfinde sammenlignelighed.

Gendan den tilsigtede tilstand

Vælg en løsning, der matcher årsagen: ret en politikdefekt, reparer DNS tjenesten, gendan en understøttet konvolutkonfiguration eller stop en utilsigtet rute. Bevar en gemt tidligere tilstand, ansvarlig ejer og eksplicit tilbagerulningstilstand. Gentest de berørte flows, og gennemgå det næste sammenlignelige rapporteringsvindue. Luk hændelsen med både det tekniske resultat og måledefinitionen, herunder uløste rapporteringshuller.

Skriv beslutningen på skrift

Brug et regneark til sammenligning med interval, rapportørpopulation, samlede observationer, aligned-SPF-antal, kendt legitim volumen, ukendt volumen og noter med manglende data. Hvis rå SPF forbliver forbi, mens justeret SPF falder, skal du sammenligne de faktiske konvolutdomæner, før du redigerer adressetilladelser. En ny reporter eller ændret deduplikeringsregel kan gøre to rater ikke-sammenlignelige. Disse er gennemgangskriterier, ikke beviser for et reelt afbrydelse eller angreb.

[ Takeaway ]

Definer tæller, nævner, reportersæt og tidsvindue. Adskil trafikblandingsændringer fra legitime autentificeringsfejl. Validere repræsentative transaktioner, før du vælger en reparation.

[Efter rolle]

Hvad betyder det for dig

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

IT / Mail Admin

Definer tæller og nævner eksplicit.

Hold et kort hændelsesark, der forbinder metriske definitioner, segmenterede tællinger, konfigurationsændringer og repræsentative transaktionsbeviser. Rediger ikke SPF udelukkende for at forbedre en dashboardfarve.

Næste trin

  1. Definer tæller og nævner eksplicit.
  2. Segmenter fejl efter identitet og rute.
  3. Bekræft en repræsentativ transaktion før redigering.

CISO / SecOps

Adskil angribervolumen fra legitime fejl.

Skeln angribervolumen fra manglende godkendelse for en legitim afsender. Kræv kildeejerskab, før en ny tilladelse tilføjes under en hændelse.

Næste trin

  1. Adskil angribervolumen fra legitime fejl.
  2. Kræv kildeejerskab før ny tilladelse.
  3. Dokumentere usikkerhed i rapporteringsdækning.

Grundlægger / Ikke-teknisk

Spørg, hvilke legitime arbejdsgange der er ændret.

Spørg, om legitime virksomhedsbeskeder faktisk mistede godkendelse, om trafikblandingen ændrede sig, og hvilken kundepåvirkning er kendt. En procentdel uden en nævner kan fordreje inddrivelsesarbejdet.

Næste trin

  1. Spørg, hvilke legitime arbejdsgange der er ændret.
  2. Gennemgå absolutte mængder sammen med procenter.
  3. Prioriter verificeret kundepåvirkning.

[ Ofte stillede spørgsmål ]

Ofte stillede spørgsmål

Beviser en lavere procentdel, at SPF gik i stykker?

Nej. Trafikmix, reporterdækning, justering eller måledefinitionen kan have ændret sig.

Hvad skal jeg undersøge først?

Den nøjagtige tæller, nævner, tidsvindue, reportersæt og absolutte besked tæller.

Kan rå SPF -pas stige, mens compliance falder?

Ja, hvis flere forbigående meddelelser bruger et konvolutdomæne, der ikke stemmer overens, eller hvis dashboardet anvender en anden overholdelsesdefinition.

RFC 9989 §4.4 RFC 9989 §4.4.2

Skal ukendte kilde-IP'er tilføjes?

Først efter deres ejerskab og legitime afsendelsesbehov er bekræftet. Uautoriseret trafik kan være årsagen til, at satsen faldt.

Hvordan skal midlertidige fejl håndteres?

Undersøg DNS tilgængelighed og evalueringstidspunkt separat fra eksplicit fejl. Bevar tidsstempler og samtidige beviser.

RFC 7208 §2.6.6

Kan aggregerede observationer identificere hver afsender?

De er nyttige beviser, men ikke en fuldstændig opgørelse. Dækning og tilgængelighed af rapportering varierer, så afstem med applikations- og SMTP registreringer.

Hvorfor sammenligne IPv4 og IPv6 ?

En ændret adressefamilie kan afsløre en politikkløft, selv når applikations- og konvolutdomænet forbliver uændret.

RFC 7208 §5.6

Hvornår kan jeg lukke hændelsen?

Når de tilsigtede legitime stier er verificeret, fortolkes metrikken korrekt, og resterende datahuller eller risici har ejere.

[ Kilder ]

Kilder

  1. RFC 7208

    Afsnit §2.4 · §2.6 · §2.6.6 · §4.6.4 · §5.6 · §8

  2. RFC 9989

    Afsnit §3.2.4 · §4.4 · §4.4.2

  3. RFC 8601

    Afsnit §1.2 · §7.1

[ Ordliste ]

Ordliste

SPF
Godkendelsesevaluering for en forbindende IP og den relevante SMTP identitet.

RFC 7208 §2.4

DMARC justering
Det påkrævede forhold mellem en autentificeret identifikator og forfatterdomænet.

RFC 9989 §4.4

Overholdelsesgrad
En måleetiket, hvis tæller, nævner, kildepopulation og interval skal defineres før sammenligning af værdier.

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