Defaults.Exposed › Åtgärder › Guides

"SPF-post hittades inte" — men du har en? De 5 verkliga orsakerna (2026)

Publicerad 2026-07-08

Siffror från 2026-06-29 · metodik v7. Aggregerade censusdata över 261 miljoner graderade domäner. Se hur vi graderar.

Om ett verktyg säger “SPF-post hittades inte” men du är säker på att du publicerade en, är posten vanligtvis osynlig snarare än saknad: 1,013,416 domäner — ungefär en av 138 av dem som försöker med SPF — publicerar två eller fler SPF-poster, ett PermError (RFC 7208 §3.2) som många verktyg rapporterar som hittades-inte, enligt Defaults.Exposed censusdata för 261 miljoner domäner.

Det finns fem verkliga orsaker, alla åtgärdbara på ett par timmar: fel host, dubbelpost, fel DNS-typ eller korrupt citatformat, inkonsekventa namnservrar, eller en längd/CNAME-kollision. Nedan: 60-sekunderstestet för var och en, i den ordning du ska kontrollera dem, sedan åtgärdsstegen.

Är du säker på att posten faktiskt finns?

Börja med den obekväma möjligheten, för det är den vanligaste: av de 261,086,232 domäner som graderats i Defaults.Exposed-censuset har 121,145,609 — 46.4% — ingen SPF-post alls. Många “men jag lade till det” -fall visar sig vara en post som lades till i en stagingzon eller hos en gammal DNS-leverantör som inte längre är auktoritativ. Kontrollera DNS-leverantören som dina namnservrar faktiskt pekar på (ofta inte din registrar) för en TXT-post som börjar med v=spf1. Om den faktiskt inte finns där, hoppa över felsökningen och gå direkt till åtgärda din SPF-post.

Hur kontrollerar du en SPF-post på rätt sätt?

Webbverktyg frågar DNS via sina egna cachande resolvrar. För att se sanningen, fråga din domäns auktoritativa namnserver direkt:

# hitta de auktoritativa namnservrarna
dig NS yourdomain.com +short

# fråga en av dem direkt efter TXT-poster
dig TXT yourdomain.com @ns1.yourdnshost.com +short

På Windows: nslookup -type=TXT yourdomain.com ns1.yourdnshost.com.

Två tolkningsregler. Först, räkna raderna som börjar med v=spf1 — antalet är lika viktigt som innehållet. Andra, kontrollera att du frågade rätt namn: mottagare utvärderar SPF mot domänen i Return-Path (RFC5321.MailFrom, “envelope from”) — inte From-adressen som mottagarna ser. Om ditt nyhetsbrevverktyg studsar e-post via bounce.yourdomain.com, är en perfekt post på toppdomänen inte den post som mottagare slår upp.

Vad är de fem verkliga orsakerna?

Data från 2026-06-29.

1. Är posten på fel host?

Det klassiska: SPF lagt till på mail.yourdomain.com när e-post påstår sig komma från yourdomain.com, eller vice versa. SPF ärver inte nedåt — en post på toppdomänen säger ingenting om underdomäner, och vice versa. Publicera på exakt det namn som finns i din Return-Path. En leverantör som skickar från sin egen studsunderdomän behöver en post på den underdomänen — vanligtvis en CNAME eller TXT som leverantören tillhandahåller (guiden GoDaddy SPF-konfiguration visar var dessa fält finns).

2. Har du två SPF-poster?

Huvudorsaken, och det mest vilseledande felmeddelandet inom e-postautentisering. RFC 7208 §3.2 är tydlig: en domän måste ha exakt en SPF-post. Två eller fler är ett PermError — mottagare behandlar din SPF som ogiltig. Vissa verktyg rapporterar detta tillstånd korrekt (“flera poster hittades”); andra rapporterar nettoeffekten: ingen giltig SPF-post hittades. Du ser en post i din panel och drar slutsatsen att verktyget är trasigt. Det är det inte — du har en post för många.

Censuset hittade 1,013,416 domäner med två eller fler SPF-poster — ungefär en av 138 av de domäner som försöker med SPF — var och en med SPF effektivt avstängt. Det händer vanligtvis vid ett leverantörsbyte: den nya leverantörens guide lägger till en ny post istället för att redigera den gamla. Lösningen är en sammanslagning, aldrig en andra post: kombinera allt till en enda v=spf1 … ~all-rad och ta bort resten. Vår datarticle två SPF-poster är lika med ingen bryter ned hur en miljon domäner hamnade här; om det startade efter en migration, se SPF slutade fungera efter byte av leverantör. Undvik att blint sammanfoga varje include: vid sammanslagning — varje kostar DNS-uppslag mot SPF:s hårda gräns på 10, och byter ut hittades-inte mot ett PermError: för många DNS-uppslag.

3. Publicerade du fel posttyp — eller förstörde gränssnittet den?

Tidigt SPF hade sin egen DNS-posttyp (typ 99, bokstavligen namngiven “SPF”). Den är föråldrad: RFC 7208 kräver TXT, och mottagare frågar inte efter typ 99. Vissa DNS-paneler erbjuder fortfarande “SPF” i rullgardinsmenyn för posttyp; välj det och din post är verklig, välformaterad och osynlig. Kontrollera typkolumnen och återpublicera som TXT.

Den subtilare varianten är citatformat. Att klistra in ett värde omgivet av citationstecken i ett fält som lägger till egna citationstecken ger ""v=spf1 …"" — vilket inte längre börjar med v=spf1, och för en verifierare existerar det inte. Din dig-utdata visar sanningen; DNS-panelen döljer det ofta kosmetiskt.

4. Håller det verkligen på att “spridas”?

“Ge det 24–48 timmar att spridas” är det mest överprescriberade rådet inom DNS. Spridning är bara att cacher förfaller: när postens TTL har gått ut (vanligtvis 1 timme, sällan mer än 24), kan varje resolver se det nya svaret. Fortfarande inte funnet efter 24 timmar? Spridning är inte orsaken.

De två verkliga bovarna: negativ cachelagring — en resolver som slog upp dig innan du lade till posten cachelagrar svaret “ingen sådan post” tills den negativa TTL:n löper ut — och inkonsekventa namnservrar efter en migration, där domänen fortfarande listar den gamla leverantörens namnservrar bredvid de nya och halva världen läser en zon som du inte längre redigerar. Fråga varje listad namnserver direkt; om svaren skiljer sig, har du hittat det. Åtgärda registrarens NS-delegering så att bara den leverantör du faktiskt redigerar är auktoritativ.

5. Är posten för lång, eller blockerad av en CNAME?

En enskild sträng i en TXT-post har maximalt 255 tecken. Längre SPF-poster är tillåtna men måste delas upp i flera citerade strängar inom en post — och DNS-leverantörsgränssnitt hanterar regelbundet uppdelningen fel, avkortar värdet eller bryter det mitt i en mekanism så att det inte längre tolkas. Om din post är lång, kontrollera dig-utdata för ett värde som slutar abrupt.

Separat förbjuder DNS en TXT-post på ett namn som redan har en CNAME. Om mail.yourdomain.com är en CNAME till din leverantör kan du inte heller lägga SPF där — vissa paneler accepterar det och servar sedan bara CNAME:n. Lägg posten där CNAME:n pekar (om du kontrollerar det), eller strukturera om så att avsändarnamnet inte är CNAME-pekat. Leverantörer med ren TXT-hantering gör båda enklare — se Cloudflare SPF-konfiguration.

Hur åtgärdar du det, steg för steg?

1. Kör den kostnadsfria sökningen på defaults.exposed — den läser din aktiva DNS och talar om vilket av de fem tillstånden du befinner dig i, innan du rör något.
2. Bekräfta vilka namnservrar som är auktoritativa (dig NS) och att de alla är överens.
3. Fråga TXT på den auktoritativa namnservern för den exakta Return-Path-domänen.
4. Räkna v=spf1-raderna: noll → publicera en; två eller fler → slå ihop till en.
5. Verifiera att typen är TXT, att värdet börjar exakt med v=spf1 och att inga felaktiga citationstecken eller avkortningar har smugit sig in.
6. Vänta ut en TTL, scanna sedan igen för att bekräfta att det löser sig korrekt överallt.

Vanliga frågor

Varför säger verktyget “hittades inte” när jag kan se posten i min DNS-panel? Vanligtvis orsak 2 eller 4: en andra v=spf1-post gör båda ogiltiga — ett PermError som vissa verktyg rapporterar som hittades-inte, det tillstånd 1,013,416 domäner befinner sig i per 2026-06-29 — eller din panel är inte den DNS som faktiskt är auktoritativ.

Hur lång tid tar det innan verktyg ser min lösning? En TTL — vanligtvis en timme, maximalt 24. Utöver det är “spridning” inte förklaringen; kontrollera de fem orsakerna igen, börja med namnserverskonsistens.

Ska jag använda posttypen “SPF” som min DNS-panel erbjuder? Nej. Typ 99 är föråldrad; RFC 7208 kräver enbart TXT. En typ 99-post är osynlig för moderna mottagare.

Posten hittades nu — varför misslyckas min e-post fortfarande med SPF? Eftersom SPF kontrolleras mot Return-Path-domänen, inte From-rubriken, och posten måste faktiskt lista de servrar som skickar för dig. Hittad är steg ett; guiden åtgärda din SPF-post täcker hur du klarar testet.

Är det att inte ha någon SPF-post verkligen så vanligt? Ja — 121,145,609 domäner, 46.4% av de 261,086,232 som graderats i Defaults.Exposed-censuset (per 2026-06-29), publicerar ingen SPF alls. Hittades-inte är internets standardtillstånd.

Skicka ägaren rapporten

När posten löser sig korrekt, kör sökningen igen och vidarebefordra den graderade rapporten till ägaren eller kunden vars domän det gäller. Den visar, på klarspråk, vad som var trasigt, vad du åtgärdade och var domänen nu står — exakt det bevis de kommer att bli ombedda att visa vid förnyelse av cyberförsäkring och leverantörers säkerhetsenkäter. Rapporten är kvittot för arbetet.

Kontrollera din SPF-post kostnadsfritt

Se vilket av de fem hittades-inte-tillstånden din domän befinner sig i — privat och enbart för ägaren.

Kontrollera din domän → · Åtgärda SPF → · SPF slutade fungera efter byte av leverantör → · Hur vi graderar → · Enbart aggregerade data. Data lagras och behandlas inom EU.