[ SPF ]

Flere SPF poster: flet tilladelser uden at beholde forældede afsendere

Erstat konkurrerende SPF poster med én gennemgået politik, bevar legitime afsendere, mens du fjerner forældede eller overordnede tilladelser.

Af EmailAuth -forskningsteamet

[Nøglepunkter]

  • Flere udvalgte poster slås ikke sammen af ​​modtagere.
  • Bevar kun begrundede tilladelser og forsætlig bestilling.
  • Bekræft DNS og repræsentative stier uden at opfinde resultater.
På denne side

To SPF politikker med samme DNS navn kombineres ikke til en større liste over autoriserede afsendere. Når SPF rekord valg returnerer mere end én relevant post, evalueringen slutter med permerror under RFC 7208 §4.5. Reparationen er én sammenhængende politik, ikke en tredje TXT indgang.

Den svære del er at beslutte, hvilke tilladelser der stadig hører til. Kopiering af hver mekanisme til en enkelt linje kan fjerne syntaksfejlen, samtidig med at forældede leverandører, overdreven netværk og et problem med opslagsgrænser bevares.

Bekræft, hvad der faktisk er duplikeret

Forespørgsel TXT registreringer på det nøjagtige domæne, der bruges til SPF tjekket. Andre TXT poster, såsom domænebekræftelsestokens, er ikke automatisk SPF poster og bør ikke slettes som en del af denne reparation. Skelne flere ressourceposter fra flere citerede tegnstrenge inden for en TXT post. Under RFC 7208 §3.3, strenge inde i én post er sammenkædet; separate SPF poster er det ikke.

Gem det fulde DNS svar, TTL og autoritative serveroplysninger. Bekræft den relevante zone og ejernavn, før du ændrer noget. En udbyder kan automatisk tilføje zonenavnet til et værtsfelt, så en tilsyneladende korrekt editor-indtastning lander på det forkerte navn.

Rekonstruer det tilsigtede sendersæt

Opret én række pr. mekanisme med fire felter: virksomhedstjenesten, ansvarlig ejer, understøttende udbyderkonfiguration og bevis for aktuel afsendelse. For eksplicitte IP-intervaller skal du identificere, hvem der driver adresserne, og hvorfor det område er nødvendigt. For inkluderer, inspicer leverandørens aktuelle instruktioner og rekursive politikafhængigheder. Behandl en ukendt mekanisme som et spørgsmål, der skal løses, ikke en tilladelse til at beholde for evigt.

Adskil afsendere, der bruger dette kuvertdomæne, fra tjenester, der bruger deres eget kuvertdomæne. En leverandørs synlige fra-adresse er ikke nok til at bevise, at dens trafik skal have en SPF inkluderet her. Ligeledes betyder fravær fra en kort observationsperiode ikke pensionering: Fakturaer eller sæsonbestemte kampagner kan køre sjældent.

Byg en ordnet politik

Bevar de valgte autorisationer og en bevidst endelig politik. Lad være med at sammenkæde hele optegnelser og efterlade et sekund v=spf1 token eller en alle mekanisme i midten. Under RFC 7208 §5.1, en tidlig alle matcher alle resterende kilder, så senere mekanismer er uopnåelige.

Illustrativ starttilstand: én post er v=spf1 ip4:192.0.2.10 -all; en anden er v=spf1 ip4:198.51.100.20 ~all. Hvis begge adresser kun til dokumentation repræsenterer bekræftede, nuværende afsendere, er en mulig fusioneret politik v=spf1 ip4:192.0.2.10 ip4:198.51.100.20 ~all. Valg af den endelige kvalifikation kræver sin egen routinggennemgang. Hvis den anden afsender blev pensioneret, ville en sammenlægning af den bevare unødvendig autoritet.

Evaluer den fulde politik, inklusive indlejrede inkluderer og omdirigeringer. Under RFC 7208 §4.6.4, RFC 7208 pålægger en grænse på ti opslagsfremkaldende termer under evaluering; tæller kun synlige inkludere-udsagn er utilstrækkeligt. Eksplicit ip4 og ip6 mekanismer bruger ikke selv det termbudget, men at erstatte administrerede inkluderer med kopierede IP-lister skaber en vedligeholdelsesforpligtelse.

Implementer uden en langvarig tvetydig tilstand

Foretrækker en atomic DNS record-set-opdatering, når udbyderen understøtter det: Erstat de konkurrerende politikker med den godkendte enkelt record i én ændring. Hvis grænsefladen kræver separate redigeringer, planlæg sekvensen og anerkend den forbigående risiko for manglende eller duplikering af politik. Opret ikke en "midlertidig" ekstra SPF record og lad den blive udbredt.

Bekræft autoritative svar og derefter relevante rekursive svar. Cachelagrede gamle svar bevarer deres tidligere friskhedsintervaller; RFC 8767 §4 tillader også kvalificerende brug af uaktuelle svar efter udløb. TTL er ikke en garanteret global tilbagekaldelsesfrist. Send repræsentative beskeder fra hver bibeholdt tjeneste og bekræft den evaluerede identitet og resultatet hos en betroet modtager. Test også en uovertruffen kilde under din kontrol, så et utilsigtet universalpas ikke forveksles med succes.

Behold oprydningsbeviset

Ændringsposten skal forklare hver bevaret og fjernet mekanisme, opslagsevalueringen, før-og-efter DNS tilstanden og testresultaterne. En duplikat-record-advarsel lukkes kun, når der er én valgt SPF post, og politikken udtrykker det gennemgåede afsendersæt. Dette forvandler en engangs- DNS reparation til en godkendelsesbeholdning, der kan vedligeholdes.

Registrer beslutningen og dens grænser

For eksemplet med to adresser skal et arbejdsark med tilladelser beholde hver ejerbeslutning og forventet match adskilt fra den endelige kvalifikation. Det flettede ~all -eksempel returnerer stadig softfail for en uovertruffen adresse; det er ikke en anbefaling at svække en -all politik. Ændring af denne kvalifikation kræver en eksplicit beslutning. Der er ikke udført nogen DNS opdatering eller leveringstest for denne illustration.

[ Takeaway ]

Flere udvalgte poster slås ikke sammen af ​​modtagere. Bevar kun begrundede tilladelser og forsætlig bestilling. Bekræft DNS og repræsentative stier uden at opfinde resultater.

[Efter rolle]

Hvad betyder det for dig

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

IT / Mail Admin

Flet semantik, ikke strenge.

Rekordrækkefølge, kvalifikationer og rekursive afhængigheder skal overleve konsolideringen korrekt.

Næste trin

  1. Gem det originale rekordsæt.
  2. Test alle bevarede tjenester og en uovertruffen kilde.

CISO / SecOps

Gennemgå den bevarede tillid.

Hvert bevaret inkluderer eller netværk er en godkendelsesbeslutning.

Næste trin

  1. Kræv ejerskab for hver mekanisme.
  2. Registrer, hvorfor fjernede afsendere ikke længere har brug for adgang.

Grundlægger / Ikke-teknisk

Brug hændelsen til at rense ejerskabet.

Reparationen skal identificere, hvilke virksomhedstjenester der stadig har tilladelse, ikke blot dæmpe en checker.

Næste trin

  1. Godkend servicepensioneringer med ejere.
  2. Inkluder sjældne afsendelsesjob i valideringen.

[ Ofte stillede spørgsmål ]

Ofte stillede spørgsmål

Kan jeg udgive en separat SPF -record for hver leverandør?

Ikke på samme ejernavn. Flere udvalgte SPF poster producerer permerror snarere end flettede tilladelser.

RFC 7208 §4.5

Skal jeg slette hver anden TXT post?

Nej. Ikke-relaterede verifikationsposter kan forblive. Identificer SPF poster ved hjælp af protokollens udvælgelsesregler.

RFC 7208 §4.5

Er to citerede strenge to SPF poster?

Ikke når de er tegnstrenge i én TXT ressourcepost. Deres indhold er sammenkædet uden indsatte mellemrum.

RFC 7208 §3.3

Kan jeg indsætte begge komplette politikker sammen?

Nej. Behold én versionsmarkør, gennemgå mekanismens rækkefølge og vælg én effektiv endelig politik.

RFC 7208 §4.6 RFC 7208 §5.1

Hvorfor ikke beholde alle gamle inkludere?

Det bevarer leverandørautorisation og bruger evalueringsressourcer, selv når tjenesten ikke længere er nødvendig.

Inkluderer ti synlige garantioverholdelse?

Nej. Indlejret evaluering og andre udtryk, der forårsager opslag, tæller også med i grænsen.

RFC 7208 §4.6.4

Hvornår er reparationen verificeret?

Efter at DNS har serveret én gældende politik, og repræsentative beskeder fra tilbageholdte afsendere evalueres som forventet.

Hvad hvis DNS editoren ikke kan opdatere atomisk?

Planlæg og dokumenter den forbigående tilstand, minimer intervallet mellem redigeringer og bekræft det resulterende rekordsæt med det samme.

[ Kilder ]

Kilder

  1. RFC 7208

    Afsnit §2.4 · §3.3 · §4.5 · §4.6 · §4.6.4 · §5.1 · §4.1

  2. RFC 8767

    Afsnit §4

[ Ordliste ]

Ordliste

SPF
Evaluering af en forbindende IP i forhold til politikken for den relevante SMTP identitet.

RFC 7208 §2.4

DNS TTL
Almindelig friskhedsinterval, ikke en garanteret global deadline for sletning eller tilbagekaldelse; kvalificerende server-forældet brug kan fortsætte efter udløb.

RFC 8767 §4

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