Hvad er SPF ptr-mekanismen — og hvorfor findes den stadig i 950,631 records? (2026)

Q: Hvad skal jeg bruge i stedet for ptr?

ip4:/ip6:-blokke for servere, du kontrollerer, eller din udbyders dokumenterede include:. Begge er deterministiske, hurtige og pålidelige — alt det, ptr ikke er.

Q: Tæller ptr med i SPF's grænse på 10 opslag?

Ja — hvert ptr koster mindst et af de ti DNS-opslag, en modtager udfører, før den giver op med en PermError. På records, der allerede er stablet med include:-mekanismer, kan den døde mekanisme være den, der skubber dig over grænsen.

Udgivet 2026-07-03

Tal pr. 2026-06-29 · metode v7. Samlet folketælling på tværs af 261 millioner graderede domæner. Alle tal er aggregerede — aldrig en enkelt virksomheds record. Se hvordan vi graderer.

ptr er en SPF-mekanisme, der autoriserer afsendere via omvendt DNS-opslag — og SPF-standarden selv har sagt “brug den ikke” siden 2014. 12 år senere udgiver 950,631 domæner den stadig. Det er cirka 1 ud af 146 af de 139 millioner SPF-records på internettet, der bærer en mekanisme, som specifikationen udfasede, før nogle af de domæner overhovedet blev registreret.

Hvad ptr var tænkt at gøre

ptr siger: “accepter mail fra enhver server, hvis omvendte DNS peger tilbage til mit domæne.” Det lyder elegant — ingen IP-lister at vedligeholde. I praksis kræver det, at modtageren foretager et omvendt opslag på den forbindende IP og derefter fremad-bekræfter hvert værtsnavn, der kommer tilbage. RFC 7208 (§5.5) udfasede den med klare ord: mekanismen er “langsom, ikke så pålidelig som andre mekanismer i tilfælde af DNS-fejl, og lægger et stort ressourcekrav på .arpa-navneserverne” — og instruerer, at den “SHOULD NOT be used.”

Hvorfor den stadig er en fælde i 2026

Tre grunde til, at en mekanisme, der blev udfaset for 12 år siden, stadig har betydning:

Den brænder dit opslagsbudget. Hvert ptr tæller med i SPF’s hårde loft på 10 DNS-opslag pr. tjek — grænsen, der, når den først overskrides, ugyldiggør hele recorden med en PermError. En mekanisme, der ikke gør noget pålideligt, koster dig stadig det budget, som dine rigtige include:-mekanismer har brug for.
Den fejler uforudsigeligt. Omvendt DNS er det mindst vedligeholdte hjørne af de fleste netværk. Når ptr-opslaget udløber, eller fremad-bekræftelsen fejler, mister din legitime mail det SPF-pass, den regnede med.
Nogle modtagere springer den helt over. Fordi standarden udfaser den, ignorerer nogle implementeringer simpelthen ptr — så de afsendere, den var ment at autorisere, var aldrig beskyttet i første omgang.

Hvor den kommer fra

Næsten ingen vælger ptr i dag. Den ankommer ved nedarvning: en opsætningsvejledning skrevet i 2009, en skabelon kopieret fra en gammel serverkonfiguration, en “fungerende” record migreret intakt gennem tre hostingskift. Det er det mønster, vores folketælling ser på tværs af enhver udfaset-men-stadig-tilstedeværende mekanisme: gamle råd dør ikke, de bliver copy-pastet. De domæner, der bærer ptr, er ikke skødesløse — de følger instruktioner, der blev pensioneret for 12 år siden.

Sådan retter du det — gratis, fem minutter

Find din SPF-record (dig TXT ditdomæne.com eller tjek gratis).
Hvis den indeholder ptr, så identificér hvilke servere, der var afhængige af den.
Erstat ptr med den præcise form: en ip4:/ip6:-blok for servere, du kontrollerer, eller den include:, som din udbyder dokumenterer.
Mens du er derinde, så bekræft at recorden slutter med en rigtig kvalifikator — se ~all vs -all.

Ofte stillede spørgsmål

Hvad betyder ptr i en SPF-record? Den autoriserer enhver server, hvis omvendte DNS peger ind i dit domæne. RFC 7208 §5.5 udfasede den i 2014 som langsom og upålidelig og siger, at den SHOULD NOT be used — alligevel udgiver 950,631 domæner den stadig pr. 2026-06-29.

Er SPF ptr-mekanismen nogensinde gyldig? Den parses stadig, og nogle modtagere evaluerer den stadig — men standarden fraråder den i alle tilfælde, nogle modtagere ignorerer den, og den bruger et af dine ti DNS-opslag. Der findes ingen moderne konfiguration, hvor ptr er det rigtige svar.

Hvad skal jeg bruge i stedet for ptr? ip4:/ip6:-blokke for servere, du kontrollerer, eller din udbyders dokumenterede include:. Begge er deterministiske, hurtige og pålidelige — alt det, ptr ikke er.

Tæller ptr med i SPF’s grænse på 10 opslag? Ja — hvert ptr koster mindst et af de ti DNS-opslag, en modtager udfører, før den giver op med en PermError. På records, der allerede er stablet med include:-mekanismer, kan den døde mekanisme være den, der skubber dig over grænsen.

Tjek din record for spøgelser

En mekanisme udfaset for 12 år siden, der stadig sidder i din DNS, er præcis den slags, ingen leder efter. At kigge tager et halvt minut.

Tjek dit domæne → · Ret SPF → · To SPF-records = ingen → · SPF-modenhedsmodellen → · Kun aggregerede data. Data lagres og behandles i EU.