[ SPF ]

Onderzoek een plotselinge daling van SPF naleving

Scheid echte authenticatiefouten van veranderend verkeer, afstemming en rapportagedekking voordat u reageert op een dalend SPF percentage.

Door het EmailAuth -onderzoeksteam · 3 minuten lezen

[ Kernpunten ]

  • Definieer teller, noemer, verslaggeverset en tijdvenster.
  • Scheid wijzigingen in de verkeersmix van legitieme authenticatiefouten.
  • Valideer representatieve transacties voordat u voor een reparatie kiest.
Op deze pagina

Een vallen SPF nalevingspercentage is een signaal om te onderzoeken, geen DNS diagnose. Het nummer kan een ruwe SPF pas vertegenwoordigen, een uitgelijnde SPF -pas, een leverancierspecifieke classificatie of alleen de berichten die zichtbaar zijn voor bepaalde rapporterende ontvangers. Reconstrueer eerst de teller, de noemer en het tijdvenster. Anders kan een succesvolle infrastructuurwijziging worden verward met een aanval of een rapportageartefact.

Definieer de meting

Noteer de precieze statistiek: bijvoorbeeld: “berichten met uitgelijnde SPF passeren gedeeld door alle berichten in deze ontvangen rapporten tijdens dit UTC-interval.” Registreer de opgenomen verslaggevers, het volume, de ontbrekende perioden en eventuele ontdubbelingsregels. Houd onbewerkte SPF resultaten apart van DMARC uitlijning. SPF kan slagen voor een domein dat geen verband houdt met het auteursdomein, dus een aantal geslaagden en een op één lijn gebrachte aantal slagen beantwoorden verschillende vragen. RFC 9989 §3.2.4, RFC 9989 §4.4.

Vergelijk zowel absolute aantallen als tarieven. Illustratief voorbeeld: gisteren hadden 9.900 van de 10.000 waargenomen berichten SPF afgestemd. Tegenwoordig passeren dezelfde 9.900 legitieme berichten, maar verschijnen er nog eens 10.000 ongeautoriseerde berichten. Neem aan dat de oorspronkelijke 100 niet-uitgelijnde waarnemingen ook blijven bestaan, wat vandaag 20.000 waarnemingen oplevert. Het percentage daalt van 99% (9.900/10.000) naar 49,5% (9.900/20.000) zonder een nieuwe storing in de bekende legitieme stroom. Dit zijn synthetische rekenkundige invoergegevens, geen rapportagemetingen. Dat blijft een veiligheidsrelevante verandering, maar het toevoegen van deze bronnen aan SPF zou de verkeerde reactie zijn.

Partitioneer vóór het bewerken

Verdeel de wijziging op bron-IP, envelopdomein, Van domein, provider of applicatie, ontvangerreporter, adresfamilie en onbewerkt resultaat. Vind het vroegst gewijzigde segment en vergelijk dit met DNS wijzigingen, nieuwe campagnes, routeringswijzigingen, failover-gebeurtenissen en servicemigraties. Gerapporteerde bronadressen alleen vormen geen bedrijfseigendom.

Classificeer fail, softfail , neutraal, geen, temperror En permerror afzonderlijk. Het resultaatonderscheid is van belang: een DNS storing heeft niet dezelfde corrigerende actie als een nieuw ongeautoriseerd adres of een verkeerd ingedeeld record. Leg voor een foutpad het exacte beleid en de geneste afhankelijkheden vast; SPF evaluatielimieten zijn niet eenvoudigweg een telling van zichtbare tekenreeksen. RFC 7208 §4.6.4, RFC 7208 §8.

Bevestig met transactiebewijs

Neem een ​​representatief foutbericht van elke getroffen legitieme stream. Verkrijg SMTP logboeken of het ontvangen origineel met authenticatieresultaten van een vertrouwde grens. Controleer het verbindende IP-adres en het werkelijke MAIL VAN identiteit, en reproduceer vervolgens de beleidsevaluatie met gedateerd DNS bewijs. Een dashboardlabel moet naar deze observaties verwijzen in plaats van ze te vervangen. RFC 8601 §1.2, RFC 8601 §7.1.

Als het onbewerkte slagingspercentage stabiel is maar de uitlijning afneemt, zoek dan naar een nieuw envelopdomein. Als er slechts één ontvangerspopulatie verandert, vergelijk dan de doorstuur- en verbindingspaden. Als het legitieme volume afneemt terwijl het onbekende volume groeit, onderzoek dan de onbekende bronnen zonder deze te autoriseren. Waar de berichtgevingsdekking verandert, annoteer de reeksen in plaats van vergelijkbaarheid uit te vinden.

Herstel de beoogde staat

Kies een oplossing die overeenkomt met de oorzaak: corrigeer een beleidsfout, repareer DNS service, herstel een ondersteunde envelopconfiguratie of stop een onbedoelde route. Bewaar een opgeslagen eerdere status, verantwoordelijke eigenaar en expliciete terugdraaivoorwaarde. Test de getroffen stromen opnieuw en bekijk het volgende vergelijkbare rapportagevenster. Sluit het incident af met zowel het technische resultaat als de meetdefinitie, inclusief onopgeloste rapportagelacunes.

Leg het besluit schriftelijk vast

Gebruik een vergelijkingswerkblad met interval, reporterpopulatie, totale observaties, afgestemde SPF-telling, bekend legitiem volume, onbekend volume en aantekeningen over ontbrekende gegevens. Als de onbewerkte SPF doorgaat terwijl de uitgelijnde SPF daalt, vergelijk dan de daadwerkelijke envelopdomeinen voordat u de adresrechten bewerkt. Een nieuwe reporter of gewijzigde deduplicatieregel kan ervoor zorgen dat twee tarieven niet vergelijkbaar zijn. Dit zijn beoordelingscriteria, geen bewijs van een echte storing of aanval.

[ Afhaalmaaltijden ]

Definieer teller, noemer, verslaggeverset en tijdvenster. Scheid wijzigingen in de verkeersmix van legitieme authenticatiefouten. Valideer representatieve transacties voordat u voor een reparatie kiest.

[ Per rol ]

Wat dit voor jou betekent

Kies jouw rol voor praktische vervolgstappen.

IT/Mailbeheerder

Definieer teller en noemer expliciet.

Houd een kort incidentwerkblad bij met metrische definities, gesegmenteerde tellingen, configuratiewijzigingen en representatief transactiebewijs. Bewerk SPF niet uitsluitend om de kleur van een dashboard te verbeteren.

Volgende stappen

  1. Definieer teller en noemer expliciet.
  2. Segmenteer mislukkingen op identiteit en route.
  3. Bevestig een representatieve transactie voordat u deze bewerkt.

CISO / SecOps

Scheid het volume van de aanvaller van legitieme fouten.

Onderscheid het volume van de aanvaller van ontbrekende autorisatie voor een legitieme afzender. Vereist broneigendom voordat er tijdens een incident een nieuwe machtiging wordt toegevoegd.

Volgende stappen

  1. Scheid het volume van de aanvaller van legitieme fouten.
  2. Vereist broneigendom vóór nieuwe toestemming.
  3. Documenteer onzekerheid in de rapportagedekking.

Oprichter / Niet-technisch

Vraag welke legitieme workflows er zijn veranderd.

Vraag of legitieme zakelijke berichten daadwerkelijk de authenticatie hebben verloren, of de verkeersmix is ​​veranderd en welke impact op de klant bekend is. Een percentage zonder noemer kan herstelwerkzaamheden verkeerd sturen.

Volgende stappen

  1. Vraag welke legitieme workflows er zijn veranderd.
  2. Bekijk absolute volumes naast percentages.
  3. Geef prioriteit aan geverifieerde klantimpact.

[ Veelgestelde vragen ]

Veelgestelde vragen

Bewijst een lager percentage dat SPF kapot is?

Nee. Verkeersmix, verslaggeversdekking, uitlijning of de meetdefinitie zijn mogelijk veranderd.

Wat moet ik eerst inspecteren?

De exacte teller, noemer, tijdvenster, reporterset en absolute berichten telt.

Kan ruwe SPF stijgen terwijl de naleving afneemt?

Ja, als meer passerende berichten een envelopdomein gebruiken dat niet op één lijn ligt, of als het dashboard een andere nalevingsdefinitie toepast.

RFC 9989 §4.4 RFC 9989 §4.4.2

Moeten onbekende bron-IP's worden toegevoegd?

Pas nadat hun eigendom en legitieme verzendbehoefte zijn geverifieerd. Ongeautoriseerd verkeer kan de reden zijn dat het tarief daalde.

Hoe moet er worden omgegaan met tijdelijke fouten?

Onderzoek DNS beschikbaarheid en evaluatietiming afzonderlijk van expliciete fouten. Bewaar tijdstempels en gelijktijdig bewijsmateriaal.

RFC 7208 §2.6.6

Kunnen geaggregeerde waarnemingen elke afzender identificeren?

Het zijn nuttige bewijzen, maar geen volledige inventaris. De dekking en rapportagebeschikbaarheid variëren, dus stem deze af op de applicatie- en SMTP -records.

Waarom IPv4 en IPv6 vergelijken?

Een gewijzigde adresfamilie kan een beleidslacune aan het licht brengen, zelfs als het applicatie- en envelopdomein ongewijzigd blijven.

RFC 7208 §5.6

Wanneer kan ik het incident afsluiten?

Wanneer de beoogde legitieme paden worden geverifieerd, wordt de metriek correct geïnterpreteerd en krijgen de resterende gegevenslacunes of risico's een eigenaar.

[ Bronnen ]

Bronnen

  1. RFC 7208

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

  2. RFC 9989

    Secties §3.2.4 · §4.4 · §4.4.2

  3. RFC 8601

    Secties §1.2 · §7.1

[ Glossarium ]

Glossarium

SPF
Autorisatie-evaluatie voor een verbindend IP-adres en de relevante SMTP identiteit.

RFC 7208 §2.4

DMARC uitlijning
De vereiste relatie tussen een geverifieerde identificatie en het auteurdomein.

RFC 9989 §4.4

Nalevingspercentage
Een meetlabel waarvan de teller, noemer, bronpopulatie en interval moeten worden gedefinieerd voordat waarden worden vergeleken.

Herkomst onderneming

Waarom top financiële instellingen en overheden hebben hun e-mailbeveiligingsdashboards stopgezet.

Traditionele platforms voor e-mailauthenticatie verkopen u een dashboard en vragen uw technici om het werk te doen. In omgevingen waar veel op het spel staat, betekent handmatig toezicht vertraagde handhaving, configuratieafwijking en niet-gecontroleerde schaduwdomeinen.

EmailAuth is het agentische e-mailherkomstplatform. Onze agenten handhaven p=reject, houd externe afzenders op één lijn en verplaats uw domeinen naar vol RFC 9989 compliance, de nieuwe DMARC standaard, met 'human-in-the-loop'-auditeerbaarheid.

Regeringen Grote ondernemingen Tier-1 financiële instellingen

SaaS · Toegewijde huur · Air-gapped on-premise · BYOK-encryptie

Kennisbank