SPF-grensen på 10 DNS-oppslag

En SPF-post kan være kort og likevel overskride grensen på ti DNS-baserte mekanismer. Årsaken er at hver include kan starte en ny evaluering med egne include, a, mx og andre oppslag. Når en mulig evalueringsvei passerer grensen, skal SPF gi permerror.

Dette er ikke bare en penhetsfeil i et testverktøy. Mottakeren får ikke en gyldig SPF-autorisasjon for den aktuelle meldingen. Hvis meldingen var avhengig av alignet SPF for å bestå DMARC, kan også DMARC feile.

Løsningen er å kartlegge evalueringsveiene og rydde i avsenderarkitekturen. Å dele verdien i flere SPF-poster gjør problemet verre, og blind «flattening» kan gjøre en dynamisk leverandøravtale om til en skjør liste med IP-adresser.

Den presise regelen

RFC 7208 krever at en SPF-evaluator begrenser det samlede antallet DNS-utløsende termer til ti under én evaluering. Overskrides grensen, er resultatet permerror.

Det innledende TXT-oppslaget for å hente SPF-posten er ikke en ekstra mekanisme i denne ti-grensen. Regelen gjelder termene som utløser DNS-arbeid under evalueringen.

En egen grense for tomme svar

Et oppslag som gir NXDOMAIN, eller et vellykket DNS-svar uten relevante data, kalles ofte et void lookup. RFC 7208 anbefaler at implementasjoner begrenser slike resultatløse oppslag til to. Går evalueringen over denne grensen, gir det permerror.

Det betyr at en post kan ligge under ti-grensen og fortsatt feile fordi flere refererte navn er slettet, feilstavet eller tomme. Gamle include-mål er derfor ikke bare unødvendige; de kan være direkte skadelige.

Du må telle en evalueringsvei, ikke bare ord

Anta at hovedposten er:

v=spf1 include:_spf.post.example include:_spf.crm.example a:relay.dittfirma.no -all

Det er fristende å telle tre oppslag. Men den første leverandøren kan publisere:

v=spf1 include:_spf.pool-a.example include:_spf.pool-b.example -all

CRM-leverandøren kan igjen bruke a og en ny include. Hovedpostens to include er bare inngangene til et tre.

Et forenklet verstefall kan se slik ut:

SPF går fra venstre mot høyre og stopper når en mekanisme matcher. Den faktiske veien avhenger derfor av avsender-IP-en. En tidlig match kan bruke få oppslag, mens en annen legitim eller ukjent IP går gjennom hele kjeden. En robust analyse må kontrollere de dyreste mulige veiene, ikke bare en test som tilfeldigvis traff første leverandør.

Slik analyserer dere posten

1. Finn riktig SPF-identitet

Ikke start med å analysere rotdomenet bare fordi det er bedriftens domene. Se i en virkelig melding hvilket domene mottakeren vurderte for SPF. Det er normalt domenet i SMTP-returadressen, ofte synlig som Return-Path etter levering.

Guiden til SPF-postens syntaks og meldingskontroll forklarer forskjellen mellom returdomene og synlig Fra-domene.

2. Hent den autoritative verdien

Finn aktive navnetjenere og spør en av dem direkte:

dig dittfirma.no NS +short
dig @ns1.dnsleverandor.example dittfirma.no TXT +short

Bytt ut navnene med faktiske verdier. Kontroller at nøyaktig én TXT-verdi på det vurderte navnet starter med v=spf1. To valgte SPF-poster gir permerror før oppslagsgrensen i det hele tatt er hovedproblemet.

3. Tegn hele include- og redirect-treet

For hver include henter dere den refererte SPF-posten og fortsetter rekursivt. Følg også redirect=. Registrer:

• DNS-navnet
• hele SPF-verdien
• hvilke termer som utløser oppslag
• hvilke leverandører og interne tjenester de representerer
• tomme eller feile svar
• hvor i kjeden samme navn brukes flere ganger

Et rekursivt analyseverktøy sparer tid, men rapporten bør kunne forklares. Hvis verktøyet bare viser et rødt tall uten treet bak, er det vanskelig å vite hva som trygt kan fjernes.

4. Test ulike avsender-IP-er

Kjør ikke bare en syntakstest. En SPF-evaluator bør testes med representative IP-adresser fra hver reelle avsenderstrøm og minst én ikke-autorisert adresse. Da ser dere både tidlige treff og veien helt frem til all.

Leverandørkjeder kan endres uten at hovedposten deres gjør det. Lagre derfor dato, resultat, leverandør og analyseverktøy slik at en senere forskjell kan undersøkes.

Tiltak i riktig rekkefølge

Fjern tjenester som faktisk er avviklet

Dette er vanligvis det sikreste og mest verdifulle tiltaket. Bekreft med systemeier, leveringslogger og avtaleinformasjon at tjenesten ikke lenger sender. Fjern den deretter og test resten.

Ikke anta at en gammel e-postleverandør sluttet å sende da MX ble byttet. MX gjelder mottak. Skrivere, fakturasystemer eller nettskjema kan fortsatt bruke den gamle utgående infrastrukturen.

Fjern mekanismer som ikke representerer en avsender

a og mx blir ofte lagt inn «for sikkerhets skyld». De skal bare være der dersom serverne bak navnene faktisk leverer utgående e-post med den aktuelle SPF-identiteten. En webserver trenger ikke SPF-autorisasjon bare fordi den har en A-post, og mottaksserverne i MX er ikke automatisk utgående avsendere.

Be leverandøren om et dedikert returdomene

Mange avsendertjenester støtter et egendefinert bounce- eller returdomene, for eksempel bounce.marked.dittfirma.no. Da kan leverandørens SPF-policy ligge på dette underdomenet i stedet for å gjøre hoveddomenets policy stadig større.

Ved avslappet DMARC-alignment kan et korrekt konfigurert underdomene være alignet med det synlige organisasjonsdomenet. Kontroller likevel den faktiske meldingen; leverandøren må bruke domenet i SMTP-returadressen, ikke bare be dere opprette en ubrukt TXT-post.

Streng SPF-alignment krever identiske domener og må vurderes separat. Alignet DKIM bør uansett aktiveres som en robust DMARC-vei.

Fordel ulike strømmer på meningsfulle underdomener

Personpost, transaksjonspost og markedsføring har ulik eier, risiko og livssyklus. Separate returdomener kan gi:

• kortere SPF-policy per strøm
• tydeligere ansvar
• enklere rapporttolkning
• mindre konsekvens når én leverandør byttes
• mer presis tilbakeføring

Dette er arkitektur, ikke en rask DNS-reparasjon. Oppsettet må støttes av sendetjenesten og testes for SPF, DKIM og DMARC.

Bruk direkte IP-mekanismer bare når dere styrer adressene

ip4 og ip6 bruker ikke av ti-grensen. De er gode når bedriften kontrollerer stabile utgående serveradresser og har en prosess for endringer.

Ikke erstatt en leverandørs dokumenterte include med IP-adresser dere fant i ett DNS-oppslag. Leverandøren kan bytte eller utvide infrastrukturen, og meldinger kan begynne å feile uten at avtalen eller SPF-posten ser endret ut.

Konsolider policy under samme administrative kontroll

Hvis flere domener i samme organisasjon skal bruke identisk avsenderpolicy, kan redirect= være relevant. Det flytter både autorisasjon og avsluttende policy til en felles SPF-post. Dette bør designes og testes samlet; en redirect til en ekstern leverandør er ikke en generell erstatning for include.

Hvorfor blind flattening er risikabelt

SPF-flattening betyr vanligvis å løse opp leverandørens kjede og erstatte dynamiske navn med dagens ip4- og ip6-verdier. Det kan redusere oppslag, men overfører vedlikeholdsansvaret til dere.

Før flattening vurderes, må dere kunne svare på:

• Hvor ofte kontrolleres leverandørens kildepolicy?
• Hvordan oppdages nye og fjernede IP-områder?
• Oppdateres DNS atomisk før leverandørendringen tas i bruk?
• Finnes varsling, eier og test ved feil?
• Hvordan unngås stadig bredere, foreldede IP-områder?
• Passer den flatede posten fortsatt innen DNS-størrelsesgrenser?

Manuell flattening uten overvåking er en forsinket leveringsfeil. Den kan virke på endringsdagen og svikte når leverandøren flytter trafikk senere. Rydding og separate returdomener er ofte bedre førstevalg.

Endre uten å stoppe legitim e-post

Bruk én kontrollert endring om gangen:

1. Lagre nåværende SPF-verdi og rekursivt tre.
2. Knytt mekanismen som skal endres til en bekreftet systemeier.
3. Beskriv forventet reduksjon i dyreste evalueringsvei.
4. Definer tilbakeføring før publisering.
5. Publiser den nye, samlede SPF-posten.
6. Kontroller den hos autoritativ DNS.
7. Test hver legitim avsenderstrøm eksternt.
8. Kontroller spf=pass, vurdert domene og DMARC-alignment i meldingshodet.
9. Følg returmeldinger og DMARC-rapporter gjennom relevante utsendingssykluser.

Ikke publiser en ekstra SPF-post som midlertidig sikkerhetsnett. To poster er ikke fallback; de gjør resultatet permanent feil.

Når DKIM hjelper – og når det ikke er en unnskyldning

En melding kan bestå DMARC gjennom alignet DKIM selv om SPF ikke er den alignede veien. Det er nyttig ved videresending og ved tjenester med eget returdomene.

Men DKIM gjør ikke en ugyldig SPF-post ufarlig. SPF kan fortsatt brukes av mottakere, være nødvendig for andre meldingsstrømmer og gi et dårligere autentiseringsbilde når det ender i permerror. Målet er gyldig SPF og gyldig, alignet DKIM der leverandøren støtter det.

Driftskontroll etter opprydding

SPF er en avhengighet til leverandørenes DNS og endrer seg over tid. Gjenta analysen:

• etter ny avsendertjeneste
• før og etter e-postmigrering
• når en leverandør avvikles
• ved permerror i meldingshode eller DMARC-data
• periodisk for kritiske domener

Dokumenter maksimumsveien med margin under ti, ikke bare et øyeblikksresultat på nøyaktig ti. En leverandør kan legge til et nytt internt ledd uten å varsle hver kunde.

Trenger dere å rydde et eksisterende oppsett, send domenenavnet, den offentlige SPF-verdien og et anonymisert autentiseringsresultat via kundeservice . Del aldri passord, private DKIM-nøkler eller innhold fra kundemeldinger.