ip4 og ip6 SPF mekanismer sammenligner forbindelsesadressen med en offentliggjort adresse eller CIDR netværk. De er ligetil, når du styrer stabile udgående servere, men en lille præfiksfejl kan give tilladelse til langt mere infrastruktur end beregnet.
Brug den adresse, som modtageren faktisk ser. En servers private grænsefladeadresse, en webstedsadresse og en cloudkontos generelle netværksområde er ikke erstatninger for den udgående SMTP kilde.
Vælg det snævreste begrundede omfang
ip4:192.0.2.70 identificerer én IPv4 adresse, fordi det udeladte præfiks som standard er /32. ip6:2001:db8::70 på samme måde som standard til /128. Et /24 IPv4 præfiks repræsenterer 256 adresser, mens et /64 IPv6 præfiks dækker et enormt adresserum. Netværksstørrelse er ikke en grund til at godkende det; kontrol- og driftsbehov er.
RFC 7208 afsnit 5.6 definerer reglerne for matchning og præfiks. Brug komplette adresser og korrekt CIDR-notation. En forkortet værdi som 192.0.2. er ikke en gyldig erstatning for 192.0.2.0/24 .
Bearbejdet eksempel: grænsetest fanger brede bevillinger
Overvej den syntetiske politik v=spf1 ip4:192.0.2.64/28 ip6:2001:db8:1::/64 -all. IPv4 området løber fra 192.0.2.64 til 192.0.2.79 . En forbindelsesadresse på 192.0.2.70 matcher; 192.0.2.80 ikke og når -all hvis intet andet matcher.
IPv6 -adressen 2001:db8:1::25 matcher /64. Adressen 2001:db8:2::25 gør det ikke. Disse reserverede dokumentationsadresser er til begrundelse om politikken, ikke afsendere.
For et rigtigt foreslået område skal du oprette de samme grænsetest og liste, hvem der kontrollerer hvert inkluderet segment. Hvis den eneste godkendte afsender er én vært, skal du sammenligne tilladelsessættet med en enkeltadressemekanisme, før du godkender det bredere præfiks.
Tjek både netværksfamilier og udgangsstier
En indbygget IPv6 kilde kræver en IPv6 tilladelse. RFC 7208 RFC 7208 §5 kræver separat, at IPv4-tilknyttede IPv6 adresser kontrolleres som IPv4 ; dette gør ikke, at en ip4-række dækker native IPv6 . Et system, der begynder at bruge IPv6 kan pludselig nå politikken, selvom dets IPv4 meddelelser fortsætter med at passere. Få modtagne meddelelsesbeviser eller udgående infrastrukturregistreringer for begge familier, der faktisk er brugt.
Tag også højde for NAT, failover-gateways, regionale relæer og planlagte job. En test fra en enkelt aktiv node kan gå glip af en standby-rute. Løs ikke usikkerhed ved at godkende en hel hostingudbyder. Etabler det understøttede udgangssæt og ejerskab i stedet.
Forstå vedligeholdelsesafvejningen
Under RFC 7208 §4.6.4, ip4 og ip6 bruger ikke de ti DNS-forespørgsels-forårsager-term-budgetter under mekanismeevaluering. Modtageren skal stadig hente SPF rekord, og politikkens størrelse og korrekthed har stadig betydning. En rekord med hundredvis af kopierede intervaller kan ikke automatisk vedligeholdes, blot fordi disse termer ikke tæller med i denne grænse.
Når en udbyder anbefaler en inkludering, vil erstatning af den med et øjebliksbillede af IP-adresser gøre dig ansvarlig for fremtidige ændringer. Registrer, hvordan ændringer vil blive opdaget, hvem der vil godkende dem, og hvordan forældede adresser vil blive fjernet. Forældede tilladelser kan både forstyrre legitim post og bevare adgangen til infrastruktur, du ikke længere bruger.
Udgiv med en tilladelsesdiff
Behold den gamle registrering og forklar de nøjagtige områder, der tilføjes og fjernes. Valider hele den foreslåede SPF post, test kendte afsenderadresser og uautoriserede adresser i nærheden, og bekræft det offentliggjorte TXT svar. Send derefter repræsentative beskeder gennem normale stier og failover-stier.
Hvis en adresse uventet er uden for det godkendte område, skal du undersøge ruten, før du udvider den. En uventet udgang kan afsløre en konfigurationsfejl eller en ikke-godkendt afsender i stedet for en manglende tilladelse.
Den praktiske takeaway
En adressemekanisme er kun eksplicit, når dens ejerskab og grænser er eksplicitte. Brug observeret egress, test range edges og behandl fremtidige adresseændringer som en del af autorisationslivscyklussen.
Registrer beslutningen og dens grænser
For /28-armaturen noteres 192.0.2.63 som udvendig, .64 og .79 som indvendig og .80 som udvendig. SPF præfiksmatching inkluderer alle adresser i blokken, ikke kun det konventionelle værtsadresseundersæt. Hvis kun .70 er berettiget, så sammenlign /32 med /28: sidstnævnte giver 16 adresser, ikke én. Disse er beregnede medlemseksempler, ikke udførte SPF tests.