De SPF a- og mx-mekanismer autoriserer adresser opdaget via DNS . De kan reducere manuel adressevedligeholdelse, men de kobler også udgående tilladelse til registreringer, der vedligeholdes for andre job. En hjemmesidemigrering eller ændring af indgående e-mail kan derfor ændre SPF uden at nogen redigerer SPF rekord sig selv.
Det rigtige spørgsmål er ikke, om disse mekanismer er gyldige. Det er, om DNS afhængigheden udtrykker din tilsigtede afsendelsespolitik.
Hvad en faktisk vurderer
a-mekanismen løser det valgte målnavn til adresser, der passer til SMTP -forbindelsesfamilien. Den bruger A til en IPv4 forbindelse og AAAA til native IPv6 ; IPv4-kortlagt IPv6 behandles som IPv4 under RFC 7208 §5. På trods af navnet er a ikke begrænset til IPv4 . Hvis et mål udelades, bruges det aktuelle SPF -evalueringsdomæne.
Med a:mail.example.com, kan en matchende adresse passere under standard +-kvalifikationen. Med bar a på example.com bliver adresserne på example.com relevante. Hvis dette navn peger på en webstedsvært eller CDN, så spørg, hvorfor disse adresser skal have tilladelse til at sende post for den evaluerede identitet. Semantikken optræder i RFC 7208 afsnit 5.3.
Hvad mx faktisk vurderer
Mx-mekanismen henter MX værter for dets måldomæne og derefter deres adresser. Den sammenligner den forbindende IP med de løste adresser. MX poster beskriver normalt indgående routing, men indgående servere er ikke nødvendigvis de samme systemer, som sender udgående mail.
SPF mx bruger ikke SMTP 's implicitte-MX fallback. Hvis målet ikke har nogen MX post, må SPF ikke behandle sine A- eller AAAA-poster som reserve MX værter. Den skelnen er eksplicit i RFC 7208 afsnit 5.4.
Bearbejdet eksempel: to afhængigheder, forskellige tilladelser
Forudsat en gyldig enkelt SPF politik, vellykkede DNS svar, standardværtspræfikser og ingen tidligere evalueringsfejl, er denne syntetiske politik v=spf1 a:out.example.com mx:example.com -all. Antag, at out.example.com løses til A 192.0.2.40 . MX for example.com er inbound.example.com , hvis En rekord er 198.51.100.12 .
En forbindelse fra 192.0.2.40 matcher en. En forbindelse fra 198.51.100.12 savner a, så matcher mx. En forbindelse fra 203.0.113.18 savner begge og når fejl. Hvis den indgående MX vært ændres, kan den anden tilladelse ændres, selvom SPF TXT post forbliver identisk.
For en IPv6 -forbindelse skal du undersøge de relevante AAAA-svar i stedet for at genbruge IPv4 sporingen. Hvis et mål er fraværende eller ikke returnerer nogen relevant adresse, skal du skelne mellem den manglende match-tilstand fra en DNS fejl; en timeout er ikke et bevis på, at den påtænkte vært er uautoriseret.
Gennemgå opslagsarbejde og sekundære grænser
Begge mekanismer bidrager til grænsen på ti DNS-forespørgsler-forårsager-termer, når de evalueres. MX udvidelse har også yderligere adresseforespørgselsgrænser defineret i RFC 7208 §4.6.4. En politik kan svigte disse grænser, selv når en overfladisk optælling af vilkår på øverste niveau ser acceptabel ud.
Indfang MX svarsættet og efterfølgende adresseopslag i testbeviset. Behandl ikke ti som en garanti for, at hver post med ti synlige ord er sikker. Rekursive afhængigheder, ekspansion og ugyldige opslag har brug for deres egen vurdering.
Beslut dig for, om du vil beholde afhængigheden
Behold en eller mx, når domæneejeren med vilje ønsker, at den DNS record skal styre afsendelsestilladelsen, og de operationelle teams forstår koblingen. Overvej eksplicitte ip4/ip6-mekanismer til stabil dedikeret egress, eller en udbyder-understøttet inkluderer, når udbyderen vedligeholder den udgående infrastruktur.
Før du fjerner en afhængighed, skal du identificere, hvilke legitime adresser der i øjeblikket matcher den. En tilsyneladende unødvendig mx kan være den eneste autorisation for et sjældent brugt relæ. Byg erstatningen, sammenlign tilladelsessættene og bekræft repræsentative meddelelser, før du sletter det gamle udtryk.
Den praktiske takeaway
En a- eller mx-mekanisme gør en anden DNS ændring til en SPF tilladelsesændring. Gør dette forhold tilsigtet, synligt for de relevante ejere og omfattet af tests.
Registrer beslutningen og dens grænser
Behold en afhængighedsrække for out.example.com og en anden for hver MX vært: DNS ejer, adressefamilie, observeret svar og legitim tjeneste, der bruger den. En indgående udbydermigrering bør udløse gennemgang af MX rækken, selvom TXT er uændret. Prøveresultaterne er analytiske; reelle beviser skal omfatte svartidsstempler og terminalfejl samt matches.