Defaults.Exposed › Åtgärder › Guides

SPF PermError: Hur du åtgärdar "för många DNS-uppslag" utan att bryta din e-post (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.

Minst 797,263 domäner bryter SPF:s gräns på 10 DNS-uppslag, enligt Defaults.Exposed censusdata för 261,086,232 domäner — av 139 miljoner SPF-publicerare. Över tio uppslag avbryter mottagaren och returnerar PermError: din SPF är ogiltig, och DMARC räknar ett PermError som ett fel.

Lösningen har en strikt ordning, och de flesta guider gör det bakvänt. Räkna dina verkliga, lösta uppslag; ta bort döda och oanvända includes — det ensamt åtgärdar de flesta poster; flytta bulk-avsändare till underdomäner med sin egen SPF-budget; platta ut bara som sista utväg, och bara med automatiserad omutplattning, för statisk utplattning ruttnar och bryter leveransen i tysthet.

Vad betyder “SPF PermError: för många DNS-uppslag”?

RFC 7208 §4.6.4 begränsar varje SPF-kontroll till 10 DNS-uppslag. Över tio avbryter mottagaren och returnerar PermError — hela posten behandlas som trasig, inte bara den del som överstiger budgeten. Samma avsnitt lägger till ett mindre känt andra tak: maximalt 2 “void lookups” (frågor som inte ger svar eller NXDOMAIN), så ett par döda include:-poster för avslutade tjänster kan ogiltigförklara din SPF på egen hand.

Konsekvensen är värre än “ingen SPF”: DMARC behandlar ett PermError som ett SPF-fel, så en domän som bryter sin egen SPF är oautentiserad på SPF-benet i varje DMARC-utvärdering. Om DKIM inte är konfigurerat eller bryts under transit, misslyckas den e-posten nu med DMARC helt och hållet.

En censussiffra visar hur grym detta felsätt är: 112,215 domäner publicerar en strikt -all-post som är ogiltig på grund av uppslags-overflow — av de 54,655,923 domäner som publicerar -all alls. Deras ägare gjorde det svåra — valde det strikta avslutningen — och ett include för mycket stängde av hela posten. De ser strikta ut; de är trasiga. För hela databilden, se SPF PermError-rapporten.

Varför bröt min SPF utan att jag ändrade något?

Eftersom budgeten till stor del spenderas av andras poster. Varje include: utvärderas rekursivt, och varje uppslagsmekanism inuti den räknas mot dina tio. En rad i din DNS-panel kan kosta fyra eller fem uppslag när den är löst. En leverantör lägger till ytterligare ett include, och din SPF dör utan att ett enda tecken ändrats i din zon.

De stora plattformarna är inte problemet: Google och Microsoft har båda plattnat ut sin egen SPF — _spf.google.com och spf.protection.outlook.com expanderar till rena IP-listor och kostar noll interna uppslag (verifierat mot aktiv DNS, juli 2026). Verkliga överskridanden kommer från hosting-panels include-kedjor nästlade flera lager djupt, och från ärlig SaaS-stacking — postlåda plus nyhetsbrev plus CRM plus helpdesk, var och en “bara ett include”. Ingen lägger till det elfte uppslaget med avsikt; det anländer som summan av rimliga beslut. Det är därför klippkanten är så trång: 2,119,539 domäner befinner sig på exakt 9–10 lösta uppslag — ungefär 1 av 66 av alla SPF-publicerare, bra idag, ogiltiga den dag någon klistrar in ett include till. SPF-postens 99:e percentil löser redan till 9 uppslag. Om ditt stacken är SaaS-tung, täcker guiden SPF misslyckas för SaaS-verktyg versionen per leverantör.

Vilka delar av en SPF-post räknas som DNS-uppslag?

Räkna det lösta totalet, inte de synliga raderna. Fyra includes kan vara fyra uppslag eller fjorton.

Hur åtgärdar jag “för många DNS-uppslag” utan att bryta e-post?

1. Kör den kostnadsfria sökningen innan du rör DNS. Den löser upp hela din include-kedja och visar ditt verkliga uppslags­antal, så att du åtgärdar det faktiska problemet — inte posten som den ser ut i din panel. (Om det säger att du inte har någon SPF alls, är det ett annat fel — se “SPF-post hittades inte”.)
2. Ta bort döda och oanvända includes först. Verktyget du slutade med 2023, den gamla hostens include som överlevde en migration, dubbletter, eventuella ptr-mekanismer. Döda includes är dubbelt giftiga: de bränner uppslags­budget och är den vanliga källan till void lookups. De flesta övergräns-poster kommer under 10 i det här steget ensamt. Om din post fortfarande innehåller en tidigare leverantörs mekanismer, följ migreringsrensnings­guiden.
3. Kontrollera att varje kvarvarande include gör något. Mottagare utvärderar SPF mot Return-Path (RFC5321.MailFrom)-domänen, inte From-rubriken — och många SaaS-verktyg sätter sin egen studs­domän på Return-Path, så deras include i din post gör ingenting utom att spendera budget. Behåll includes bara för tjänster som använder din domän som Return-Path; aktivera leverantörens anpassade domän-DKIM för resten.
4. Flytta bulk­avsändare till underdomäner. Nyhetsbrev från news.yourdomain.com, transaktionsmail från mail.yourdomain.com. Varje underdomän får sin egen SPF-post med en ny budget på 10 uppslag, och ett problem i en ström slutar blöda in i de andra.
5. Överväg sedan bara utplattning — och bara automatiserad utplattning. Se nedan.
6. Scanna igen för att bekräfta att du är bekvämt under 10 — sikta på utrymme, inte exakt 10, annars har du precis återgått till de 2.1 miljoner domänerna på klippkanten. Arbeta sedan igenom allt annat som sökningen flaggar på sidan åtgärda SPF.

Ska jag platta ut min SPF-post?

Utplattning ersätter includes med deras underliggande ip4:/ip6:-block, som kostar noll uppslag. Det fungerar — och gjort för hand är det en fördröjd leveransavstängning.

Leverantörer roterar avsändar-IP-adresser rutinmässigt och meddelar ingen. En statisk IP-lista är korrekt den dag du klistrar in den och tyst fel inom månader — och eftersom felet visar sig som andras misslyckande att ta emot din e-post, får du reda på det sent. Om beskärning och underdomäner tar dig under gränsen, stanna där; kopiera aldrig en tredje parts IP-block till din post som en permanent lösning.

Vanliga frågor

Innebär ett SPF PermError att min e-post slutar levereras? Inte omedelbart — det är vad som gör det farligt. DMARC räknar ett PermError som ett SPF-fel, så leveransen lutar helt på DKIM; om DKIM saknas eller bryts under transit, misslyckas du med DMARC. Av 139 miljoner SPF-publicerare i vårt census (per 2026-06-29) befinner sig minst 797,263 i detta tillstånd — de flesta utan att veta om det.

Min post har bara fyra includes — hur kan den överskrida 10 uppslag? Includes räknas rekursivt: allt inuti varje include (och inuti dess includes) debiteras din budget, så fyra synliga rader kan lösa sig till fjorton uppslag. Räkna med ett lösande verktyg, inte med blotta ögat — lösning av kedjorna är hur vår PermError-rapport hittade ~100× fler trasiga domäner än ytantalet visar.

Jag avslutar min post med -all — är jag inte skyddad? Bara om posten utvärderas. Vårt census (per 2026-06-29) hittade 112,215 domäner vars strikta -all-poster är ogiltiga på grund av uppslags-overflow. En strikt kvalificerare på en PermError-post skyddar ingenting.

Är gränsen 10 uppslag per include eller för hela posten? Hela utvärderingen: RFC 7208 §4.6.4 begränsar hela kontrollen till 10, plus maximalt 2 void lookups. Varje underdomän har sin egen post och budget — vilket är varför steg 4 fungerar.

Räknas ip4- och ip6-poster mot gränsen? Nej — IP-mekanismer kostar ingenting, vilket är exakt varför utplattning minskar antalet.

Skicka ägaren rapporten

Om du åtgärdar detta för en kund eller din arbetsgivare, avsluta jobbet med bevis. Kör den kostnadsfria sökningen igen efter dina ändringar och vidarebefordra den graderade rapporten till ägaren: klarspråk, daterad, PermError borta. Det är den artefakt de behöver vid förnyelse av cyberförsäkring och nästa kunds säkerhetsenkät — skillnaden mellan “jag ändrade några DNS-poster” och en dokumenterad före-och-efter.

Kontrollera din domän kostnadsfritt

Se ditt verkliga, lösta uppslags­antal — och allt annat om SPF, DKIM och DMARC — privat och enbart för ägaren.

Kontrollera din domän → · Åtgärda SPF → · SPF misslyckas för SaaS-verktyg → · Konfigurera SPF på GoDaddy → · Hur vi graderar → · Enbart aggregerade data. Data lagras och behandlas inom EU.