[ SPF ]

SPF og IPv6 : Opdag afsendere, der savnes af en IPv4-kun-gennemgang

Revider begge adressefamilier, så IPv6 levering ikke afslører huller skjult af vellykkede IPv4 tests.

Af EmailAuth -forskningsteamet

[Nøglepunkter]

  • Bevis, hvilken adressefamilie den modtagende forbindelse brugte.
  • En ip6-term uden præfiks dækker én adresse, ikke en hel allokering.
  • Tjek understøttet udbyderomfang i stedet for at kopiere forbigående observationer.
På denne side

En ansøgning kan bestå SPF på et leveringsforsøg og mislykkes på et andet, når dets post går gennem forskellige adressefamilier. Hvis en beholdning kun viser IPv4 udgang, kan en IPv6 -rute være legitim, men uautoriseret af den faktisk evaluerede politik. Diagnosticer tilslutningsadressen, før du udvider posten.

Målet er præcis dækning: godkend de IPv6 kilder, din organisation eller udbyder faktisk bruger, mens du bevarer eksisterende IPv4 adfærd og holder ikke-relaterede adresser uden for politikken.

Find de rigtige IPv6 afsendelsesstier

Indsaml repræsentative betroede modtagerresultater og udgående MTA logs. Optag den tilsluttede IP, kuvertdomæne, HELO værtsnavn, afsendertjeneste og tidsstempel. Gruppér observationer efter både domæneidentitet og adressefamilie. En webservers AAAA rekord er ikke bevis for, at den samme adresse sender mail, og en indgående MX destination er ikke automatisk en udgående kilde.

Inkluder reserverelæer og regionale ruter. En enkelt vellykket besked kan ikke vise, at hver rute er dækket. Spørg infrastrukturejere, om IPv6 er aktiveret på primære servere, failover-systemer og hostede leveringsstier, og sammenlign derefter disse svar med observerede forbindelser.

Brug de rigtige mekanismer

SPF har distinkt ip4 og ip6 mekanismer under RFC 7208 §5.6. ip4 autoriserer IPv4 -adresser; den dækker ikke automatisk IPv6 ækvivalenter. An ip6 mekanisme uden præfikslængde identificerer én adresse svarende til /128. Bredere præfikser autoriserer det matchende netværk, så brug kun det område, der er begrundet i dit faktiske afsendelsesdesign.

De a og mx mekanismer kan involvere adressefamiliespecifikke opslag: IPv6 evaluering bruger AAAA-adresser, hvor det er relevant. Det gør dem ikke til en erstatning for inventar. En fremtidig AAAA-ændring kan ændre de værter, som disse mekanismer tillader. Udbyder inkluderer kan dække begge familier, men inspicer den understøttede politik i stedet for at antage, at alle inkluderer gør.

RFC 7208 §5 adresserer også IPv4-kortlagt IPv6 håndtering af evaluatorer. Når et værktøj repræsenterer en IPv4 forbindelse i kortlagt form, skal du ikke reagere ved at tilføje vilkårlige IPv6 intervaller uden at kontrollere evaluatorens håndtering og den underliggende forbindelse.

Test en tilføjelse med snævert omfang

Syntetisk politik: v=spf1 ip4:192.0.2.10 ip6:2001:db8:1234::10 -all. Begge adresser er reserveret til dokumentation. En kontrolleret evaluator bør returnere bestået for en af ​​de anførte kilder ved hjælp af det evaluerede domæne og mislykkes for umatchede kilder, forudsat at ingen DNS eller syntaksfejl griber ind.

IPv6 -udtrykket ovenfor godkender én adresse. Udskifter den med ip6:2001:db8:1234::/48 udvider sættet væsentligt. Vælg ikke et bredt præfiks, blot fordi det ligner en allokering vist i et infrastrukturdashboard. Fastlæg, hvilken del af allokeringen der bruges og kontrolleres til udgående post.

Iscenesætter produktionsændringen

Bekræft de foreslåede adresser med tjenesteejeren og den nuværende udbydervejledning. Bevar den tidligere politik, indhent den relevante godkendelse og valider den komplette post før offentliggørelse. Under RFC 7208 §4.6.4, eksplicitte IP-mekanismer bruger ikke selv SPF 's DNS-opslagsperiodebudget, men resten af ​​posten skal stadig evalueres.

Test en IPv4 rute, en IPv6 rute og en uovertruffen kilde under din kontrol. Ved rigtige modtagere skal du beholde den faktiske tilslutnings-IP og evaluerede identitet, så en test, der stille brugte IPv4 ikke rapporteres som en IPv6 succes. Tag højde for cachelagrede DNS -svar, når du sammenligner observationer umiddelbart efter ændringen.

Overhold grænsen

Tilføj SPF gennemgang til IPv6 udrulning og netværks-omnummereringsprocedurer. Hvor adresser roterer, eller en udbyder administrerer en stor pulje, skal du foretrække dens understøttede godkendelseskonfiguration frem for at kopiere forbigående observationer til en permanent tilladelsesliste. En prøve-IP viser, at en kilde blev brugt; det definerer ikke nødvendigvis udbyderens fulde autoriserede rækkevidde.

Luk gennemgangen med dokumentation for, at begge familier arbejder for de tilsigtede identiteter, og at de valgte intervaller er berettigede. IPv6 dækning bør være en lagerforbedring, ikke en undskyldning for at autorisere et helt netværk uden ejerskab.

Optag den næste beslutning

I den syntetiske politik er IPv6 -adressen 2001:db8:1234::10 dækket som /128, mens 2001:db8:1234::11 ikke er det. Skift til /48 ville også dække sidstnævnte og mange flere adresser. Registrer hvilket omfang tjenesteejeren faktisk godkender og den rigtige modtagerobserverede familie; vellykket IPv4 mail er ikke bevis for IPv6 dækning. Der blev ikke udført nogen live-test.

[ Takeaway ]

Bevis, hvilken adressefamilie den modtagende forbindelse brugte. En ip6-term uden præfiks dækker én adresse, ikke en hel allokering. Tjek understøttet udbyderomfang i stedet for at kopiere forbigående observationer.

[Efter rolle]

Hvad betyder det for dig

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

IT / Mail Admin

Bevis adressefamilien.

En bestået besked er ikke en IPv6 test, medmindre forbindelsen brugte IPv6 .

Næste trin

  1. Optag kildeadresser ved modtageren.
  2. Sammenlign snævre og brede præfikskonsekvenser.

CISO / SecOps

Undgå bred netværksautorisation.

Et tildelt præfiks er ikke automatisk en passende afsendelsesgrænse.

Næste trin

  1. Kræv begrundelse for præfiks-omfang.
  2. Gennemgå dynamisk og delt infrastruktur separat.

Grundlægger / Ikke-teknisk

Knyt autentificering til infrastrukturændringer.

IPv6 aktivering kan ændre mailadfærd, selv når selve applikationen er uændret.

Næste trin

  1. Kræv mailtests under netværksudrulning.
  2. Tildel ejerskab til adresseændringer.

[ Ofte stillede spørgsmål ]

Ofte stillede spørgsmål

Godkender ip4 IPv6 -trafik?

Nej. Brug passende IPv6 autorisation, såsom en berettiget ip6-mekanisme eller en understøttet udbyderpolitik.

RFC 7208 §5 RFC 7208 §5.6

Hvad er standard ip6-præfikset?

Uden et eksplicit præfiks matcher ip6 én IPv6 adresse, svarende til /128.

RFC 7208 §5.6

Kan jeg godkende hele mit tildelte præfiks?

Kun hvis hele rækkevidden er berettiget til afsendelse. Et bredt præfiks udvider autorisation til hver matchende adresse.

RFC 7208 §5.6

Fungerer a og mx med IPv6 ?

Deres adresseopslag kan bruge AAAA-data til IPv6 evaluering. Gennemgå de faktiske DNS data og afsendelsesdesign.

RFC 7208 §5.3 RFC 7208 §5.4

Identificerer et websteds AAAA-registrering min mailkilde?

Ikke nødvendigvis. Webhosting, indgående mail og udgående SMTP kan bruge forskellig infrastruktur.

Hvordan beviser jeg en test brugt IPv6 ?

Undersøg den faktiske tilslutningsadresse i betroede modtagere eller SMTP logfiler. Udled det ikke fra en vellykket levering.

Skal jeg kopiere hver observeret udbyder-IP til SPF ?

Nej. Observationer kan være ufuldstændige eller midlertidige. Følg udbyderens understøttede konfigurations- og vedligeholdelsesmodel.

Hvornår skal IPv6 SPF gennemgås igen?

Gennemgå efter netværksændringer, relæmigreringer, udbyderændringer og enhver nyligt observeret IPv6 senderute.

[ Kilder ]

Kilder

  1. RFC 7208

    Afsnit §2.4 · §4.1 · §4.6.4 · §5 · §5.3 · §5.4 · §5.6

[ Ordliste ]

Ordliste

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

RFC 7208 §2.4

SPF ip6
Et eksplicit IPv6 -netværksmatch; udeladt præfikslængde betyder /128.

RFC 7208 §5.6

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