Vad är SPF-mekanismen ptr — och varför finns den fortfarande i 950,631 poster? (2026)

Q: Vad ska jag använda i stället för ptr?

ip4:/ip6:-block för servrar du kontrollerar, eller din leverantörs dokumenterade include:. Båda är deterministiska, snabba och pålitliga — allt ptr inte är.

Q: Räknas ptr mot SPF:s gräns på 10 uppslagningar?

Ja — varje ptr kostar minst en av de tio DNS-uppslagningar en mottagare utför innan den ger upp med ett PermError. På poster som redan är staplade med include:-mekanismer kan den döda mekanismen vara den som knuffar dig över gränsen.

Publicerad 2026-07-03

Siffror per 2026-06-29 · metodik v7. Samlad folkräkning över 261 miljoner betygsatta domäner. Alla siffror är aggregerade — aldrig ett enskilt företags post. Se hur vi betygsätter.

ptr är en SPF-mekanism som auktoriserar avsändare via omvänd DNS-uppslagning — och själva SPF-standarden har sagt “använd den inte” sedan 2014. 12 år senare publicerar 950,631 domäner den fortfarande. Det är ungefär 1 av 146 av de 139 miljoner SPF-poster på internet som bär en mekanism som specifikationen fasade ut innan en del av dessa domäner ens registrerades.

Vad ptr var tänkt att göra

ptr säger: “acceptera post från vilken server som helst vars omvända DNS pekar tillbaka till min domän.” Det låter elegant — inga IP-listor att underhålla. I praktiken kräver det att mottagaren gör en omvänd uppslagning på den anslutande IP-adressen och sedan framåtbekräftar varje värdnamn som kommer tillbaka. RFC 7208 (§5.5) fasade ut den med tydliga ord: mekanismen är “långsam, är inte lika pålitlig som andra mekanismer vid DNS-fel och ställer stora resurskrav på .arpa-namnservrarna” — och instruerar att den “SHOULD NOT be used” (bör inte användas).

Varför den fortfarande är en fälla 2026

Tre skäl till att en mekanism som fasades ut för 12 år sedan fortfarande spelar roll:

Den förbrukar din uppslagningsbudget. Varje ptr räknas mot SPF:s hårda tak på 10 DNS-uppslagningar per kontroll — gränsen som, när den väl överskrids, ogiltigförklarar hela posten med ett PermError. En mekanism som inte gör något pålitligt kostar ändå den budget som dina riktiga include:-mekanismer behöver.
Den fallerar oförutsägbart. Omvänd DNS är det minst underhållna hörnet av de flesta nätverk. När ptr-uppslagningen får timeout eller framåtbekräftelsen misslyckas förlorar din legitima post det SPF-godkännande den räknade med.
Vissa mottagare hoppar över den helt. Eftersom standarden fasar ut den ignorerar en del implementationer helt enkelt ptr — så avsändarna den var tänkt att auktorisera var aldrig skyddade från första början.

Varifrån den kommer

Nästan ingen väljer ptr idag. Den anländer genom arv: en installationsguide skriven 2009, en mall kopierad från en gammal serverkonfiguration, en “fungerande” post som migrerats intakt genom tre hostingbyten. Det är mönstret vår folkräkning ser över varje utfasad-men-närvarande mekanism: gamla råd dör inte, de kopieras och klistras in. Domänerna som bär ptr är inte slarviga — de följer instruktioner som pensionerades för 12 år sedan.

Så här åtgärdar du det — gratis, fem minuter

Hitta din SPF-post (dig TXT yourdomain.com eller kontrollera gratis).
Om den innehåller ptr, ta reda på vilka servrar som förlitade sig på den.
Ersätt ptr med den exakta formen: ett ip4:/ip6:-block för servrar du kontrollerar, eller den include: som din leverantör dokumenterar.
Passa på att bekräfta att posten slutar med en riktig kvalificerare — se ~all mot -all.

Vanliga frågor

Vad betyder ptr i en SPF-post? Den auktoriserar vilken server som helst vars omvända DNS pekar in i din domän. RFC 7208 §5.5 fasade ut den 2014 som långsam och opålitlig och säger att den SHOULD NOT (bör inte) användas — ändå publicerar 950,631 domäner den fortfarande per 2026-06-29.

Är SPF-mekanismen ptr någonsin giltig? Den tolkas fortfarande, och vissa mottagare utvärderar den fortfarande — men standarden avråder från den i samtliga fall, en del mottagare ignorerar den, och den förbrukar en av dina tio DNS-uppslagningar. Det finns ingen modern konfiguration där ptr är rätt svar.

Vad ska jag använda i stället för ptr? ip4:/ip6:-block för servrar du kontrollerar, eller din leverantörs dokumenterade include:. Båda är deterministiska, snabba och pålitliga — allt ptr inte är.

Räknas ptr mot SPF:s gräns på 10 uppslagningar? Ja — varje ptr kostar minst en av de tio DNS-uppslagningar en mottagare utför innan den ger upp med ett PermError. På poster som redan är staplade med include:-mekanismer kan den döda mekanismen vara den som knuffar dig över gränsen.

Kontrollera din post efter spöken

En mekanism som fasades ut för 12 år sedan, som fortfarande sitter kvar i din DNS, är precis den sortens sak som ingen letar efter. Att titta tar en halv minut.

Kontrollera din domän → · Åtgärda SPF → · Två SPF-poster = ingen → · SPF-mognadsmodellen → · Endast aggregerade data. Data lagras och behandlas inom EU.