[ SPF ]

SPF omdirigering: uddelegere politik og forstå, hvordan den adskiller sig fra include

Centraliser SPF -politikken uden ved et uheld at deaktivere delegationen eller ændre dens betydning.

Af EmailAuth -forskningsteamet · 4 min læst

[Nøglepunkter]

  • Omdirigering kører kun under dens reservebetingelser og er deaktiveret af alle.
  • Evalueringsdomænet ændres, mens IP- og afsenderinput forbliver.
  • Revider hver ydre post såvel som det delte mål.
På denne side

SPF omdirigerer delegerer den resterende godkendelsesbeslutning til en anden politik. Den er designet til situationer, hvor flere domæner skal dele centralt administrerede autorisation og politik, ofte inden for én administrativ organisation.

Det er ikke et alias for include og er ikke en backup trods -all . Det er vigtigt at forstå, hvornår omdirigering kører, før registreringer konsolideres. RFC 7208 afsnit 6.1 definerer sin adfærd.

Etabler delegationsbetingelsen

Når ingen mekanisme matcher, ingen tidligere fejl har afsluttet evalueringen, og omdirigering er til stede, evaluerer SPF omdirigeringsmålet. Den forbindende IP og afsender forbliver den samme, mens domænet under evaluering bliver målet. Den resulterende evaluering leverer resultatet, med manglende SPF ved målet bliver permerror snarere end ingen.

Hvis der er nogen mekanisme til stede i den ydre post, ignoreres omdirigering. Placeringen af ​​omdirigering før alle redder den ikke. Skriv omdirigering til sidst for klarhedens skyld, men husk, at det er en modifikator snarere end en venstre-til-højre-matchningsmekanisme.

En lokal mekanisme kan gå forud for delegering. For eksempel kan en eksplicit ip4-tilladelse matche, før den delte politik konsulteres. Beslut om sådanne undtagelser er tilsigtede; ellers er en angiveligt central politik måske ikke hele autorisationshistorien.

Bearbejdet eksempel: to domæner, en administreret politik

Under forudsætning af gyldig syntaks, er en valgt SPF rekord navn og vellykket DNS hentning, i denne syntetiske opstilling, publicerer east.example.com og west.example.com hver v=spf1 redirect=policy.example.com. Det delte mål offentliggøres v=spf1 ip4:192.0.2.30 -all.

For 192.0.2.30 uddelegerer hver ydre politik, målet ip4 matcher, og resultatet er bestået. For 192.0.2.31 når målet -all , og det delegerede resultat er mislykket. Hvis målet TXT post forsvinder, giver evalueringer, der kræver omdirigering, permerror .

Skift nu østpolitikken til v=spf1 ip4:198.51.100.8 redirect=policy.example.com. Den ekstra adresse sendes lokalt, selvom det delte mål ikke godkender det. En central politisk revision skal derfor læse alle delegerende poster i stedet for kun at gennemgå målet.

Sammenlign det samme mål under inkludere

Hvis den ydre politik i stedet indeholder v=spf1 include:policy.example.com ~all, matcher et børnepas med inkluderet. Et barnfejl giver ikke det endelige resultat; behandlingen genoptages, og det ~all producerer softfail .

Omdirigering bærer målpolitikkens resultat, når det påberåbes. Inkluder spørger, om målet passerer og derefter fortsætter under den ydre politik, når det ikke gør det. Vælg den konstruktion, der matcher ejerskabsmodellen i stedet for at oversætte mellem dem mekanisk.

Revision kontekstfølsomme regler

Omdirigering ændrer det aktuelle evalueringsdomæne, mens afsenderinput bibeholdes. Makroer og domæne-relative mekanismer kan derfor afhænge af, hvilket domæne eller afsenderværdi de bruger. En politik, der fungerer for ét domæne, er ikke automatisk sikker for et andet.

For en tredjeparts sendetjeneste skal du bruge den integrationsmekanisme, som dens nuværende dokumentation understøtter. RFC 7208 advarer om, at omdirigerer på tværs af administrative grænser muligvis ikke opfører sig pålideligt, især når målpolitikken afhænger af lokale dele. Udskift ikke en dokumenteret inkluderet med omdirigering blot for at forkorte den synlige post.

Udfør den delte politik sikkert

Inventar alle afhængige domæner og lokale undtagelser. Tildel én ansvarlig ejer til det delte mål. Før du ændrer det, skal du teste en tilladt og en ikke-tilladt afsender for hver særskilt politikkontekst, inklusive IPv6 hvor det bruges. Behold de originale delegerende og delte optegnelser sammen.

Under RFC 7208 §4.1 og RFC 7208 §4.6.4, omdirigere og nåede indlejrede termer bruger SPF DNS termsbudgettet. Registrer loops og afhængighedsvækst gennem evaluering i stedet for at stole på den korte længde af hver lokal post. Efter en ændring, inspicer autoritative og rekursive svar og testrepræsentant modtaget mail.

Den praktiske takeaway

Omdirigering er nyttig centralisering, når du virkelig ønsker delt politik. Hold alt ude af delegeringsregistret, kontroller lokale undtagelser og test afsenderkonteksten, der overlever delegeringen.

Hold beslutningen reproducerbar

For east.example.com passerer den lokale 198.51.100.8 undtagelse uden at kalde det delte mål; et udfald med fælles mål behøver derfor ikke at påvirke den nøjagtige vej. En anden kilde, der kræver omdirigering, kan støde på målfejlen. Registrer den ydre post, afsenderinput, nået mål og forventet resultat sammen, før centralisering godkendes. Der blev ikke udført nogen delt politikændring eller udfaldstest.

[ Takeaway ]

Omdirigering kører kun under dens reservebetingelser og er deaktiveret af alle. Evalueringsdomænet ændres, mens IP- og afsenderinput forbliver. Revider hver ydre post såvel som det delte mål.

[Efter rolle]

Hvad betyder det for dig

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

IT / Mail Admin

Test både delegering og undtagelser.

Det delte mål er ikke den komplette politik, hvis lokale mekanismer kan matche først.

Næste trin

  1. Undersøg hver ydre post.
  2. Test makroer og afsenderkontekst.
  3. Bekræft sagen om manglende mål.

CISO / SecOps

Styr central autorisation.

Centralisering forenkler administrationen, men koncentrerer virkningen af ​​fejl og kompromiser.

Næste trin

  1. Begræns ændringsadgang på passende måde.
  2. Gennemgå lokale undtagelser.
  3. Bevar en koordineret tilbagerulning.

Grundlægger / Ikke-teknisk

Kend den delte ændringsradius.

En enkelt central redigering kan påvirke flere indtægtskritiske domæner.

Næste trin

  1. Lagerafhængige tjenester.
  2. Tildel en policeejer.
  3. Kræv repræsentative test før udrulning.

[ Ofte stillede spørgsmål ]

Ofte stillede spørgsmål

Hvornår evalueres omdirigering?

Efter ingen mekanisme matcher og ingen tidligere fejl afslutter evalueringen, forudsat at der ikke er alle mekanismer i posten.

RFC 7208 §6.1

Virker omdirigering trods -all ?

Nej. Enhver mekanisme medfører, at omdirigering ignoreres.

RFC 7208 §6.1

Ændrer omdirigering den oprindelige afsender?

Nej. IP- og afsenderargumenterne forbliver; det aktuelle evalueringsdomæne ændres til omdirigeringsmålet.

RFC 7208 §6.1

Hvad sker der, hvis målet ikke har nogen SPF ?

Den delegerede evaluering returnerer permerror snarere end ingen.

RFC 7208 §6.1

Hvordan er inkludere anderledes?

Inkluder kampe på et børnepas og ellers kan fortsætte. Omdirigering bruger det delegerede resultat, når det kører.

RFC 7208 §5.2 RFC 7208 §6.1

Kan et domæne beholde en lokal undtagelse?

Ja. En foregående matchningsmekanisme kan vende tilbage før omdirigering. Revision undtagelser, så centrale politikkrav forbliver nøjagtige.

RFC 7208 §4.6.2 RFC 7208 §6.1

Kan jeg omdirigere til et hvilket som helst udbyders SPF domæne?

Brug den udbyder-understøttede konfiguration. Tværadministrative omdirigeringer kan have kontekstfølsom adfærd og kan ikke udskiftes med include.

RFC 7208 §6.1

Undgår en kort omdirigeringspost opslagsgrænser?

Nej. Omdirigering og nåede rekursive afhængigheder tæller med i SPF -evalueringsgrænserne.

RFC 7208 §4.1 RFC 7208 §4.6.4

[ Kilder ]

Kilder

  1. RFC 7208

    Afsnit §2.4 · §4.1 · §4.6.2 · §4.6.4 · §5.2 · §6.1 · §7

[ Ordliste ]

Ordliste

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

RFC 7208 §2.4

SPF inkluderer
En rekursiv aflevering gør, at inkluderet matcher; dens qualifier bestemmer så det ydre resultat, mens fejl følger den specificerede mapping.

RFC 7208 §5.2

SPF omdirigering
Fallback-evaluering med målet som aktuelt domæne og uændrede IP/sender input; enhver alle mekanisme deaktiverer omdirigering.

RFC 7208 §6.1

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