Defaults.Exposed › Rettelser › Guides

\"SPF-post ikke fundet\" — men du har én? De 5 reelle årsager (2026)

Udgivet 2026-07-08

Tal fra 2026-06-29 · metodologi v7. Aggregerede censusdata på tværs af 261 millioner graderede domæner. Se hvordan vi graderer.

Hvis en kontrollør siger “SPF-post ikke fundet”, men du er sikker på, at du har udgivet en, er posten sædvanligvis usynlig snarere end manglende: 1,013,416 domæner — omtrent ét ud af 138 af dem, der forsøger SPF — udgiver to eller flere SPF-poster, en PermError (RFC 7208 §3.2), som mange kontrollører rapporterer som ikke-fundet, ifølge Defaults.Exposed-census over 261 millioner domæner.

Der er fem reelle årsager, som alle kan løses på én omgang: forkert vært, duplikeret post, forkert DNS-type eller mangelfuld angivelse med anførselstegn, inkonsistente navneservere, eller en kollision med for lange poster/CNAME. Nedenfor: 60-sekunders-testen for hver enkelt i den rækkefølge, du bør kontrollere dem, samt løsningstrinnene.

Er du sikker på, at posten faktisk eksisterer?

Start med den ubehagelige mulighed, fordi den er den langt mest almindelige: af de 261,086,232 domæner, der er graderet i Defaults.Exposed-census, har 121,145,609 — 46.4% — slet ingen SPF-post. Mange “men jeg har jo sat det op”-tilfælde viser sig at være en post tilføjet til en stagingzone eller en gammel DNS-udbyder, der ikke længere er autoritativ. Kontrollér DNS-udbyderen, som dine navneservere faktisk peger på (som ofte ikke er dit domæneregistrar) for en TXT-post, der starter med v=spf1. Er den virkelig ikke der, så spring detektivarbejdet over og gå direkte til ret din SPF-post.

Hvordan kontrollerer man en SPF-post korrekt?

Webtjenester forespørger DNS via deres egne cachende resolvere. For at se sandheden skal du spørge dit domænes autoritative navneserver direkte:

# find de autoritative navneservere
dig NS ditdomæne.dk +short

# spørg én af dem direkte om TXT-poster
dig TXT ditdomæne.dk @ns1.dindnsudbyder.dk +short

På Windows: nslookup -type=TXT ditdomæne.dk ns1.dindnsudbyder.dk.

To fortolkningsregler. For det første: tæl linjerne, der starter med v=spf1 — antallet er lige så vigtigt som indholdet. For det andet: kontrollér, at du forespørger det rigtige navn: modtagere evaluerer SPF mod domænet i Return-Path (RFC5321.MailFrom, “konvolut-fra”) — ikke Fra-adressen, som modtagerne ser. Hvis dit nyhedsbrevværktøj sender mail via bounce.ditdomæne.dk, er en perfekt post på apex-domænet ikke den post, modtagerne slår op.

Hvad er de fem reelle årsager?

Data fra 2026-06-29.

1. Er posten hos den forkerte vært?

Den klassiske fejl: SPF tilføjet på mail.ditdomæne.dk, når mail hævder at komme fra ditdomæne.dk, eller omvendt. SPF nedarver ikke nedad — en post på apex-domænet siger ingenting om underdomæner og omvendt. Udgiv præcis på det navn, der er i din Return-Path. En leverandør, der sender fra sit eget bounce-underdomæne, behøver en post på det underdomæne — som regel en CNAME eller TXT, som leverandøren leverer (i GoDaddy SPF-opsætningsvejledningen kan du se, hvor disse felter er).

2. Har du to SPF-poster?

Den vigtigste årsag og den mest vildledende fejlmeddelelse inden for e-mailgodkendelse. RFC 7208 §3.2 er klar: et domæne skal have præcis én SPF-post. To eller flere er en PermError — modtagere behandler din SPF som ugyldig. Nogle kontrollører rapporterer denne tilstand korrekt (“flere poster fundet”); andre rapporterer nettoeffekten: ingen gyldig SPF-post fundet. Du ser en post i dit kontrolpanel og konkluderer, at kontrolløreren er defekt. Det er den ikke — du har én post for mange.

Census fandt 1,013,416 domæner med to eller flere SPF-poster — omtrent ét ud af 138 af de domæner, der forsøger SPF — alle med SPF effektivt slået fra. Det sker typisk under et udbyderskifte: den nye udbyders guide tilføjer en frisk post i stedet for at redigere den gamle. Løsningen er at flette, aldrig at tilføje en anden post: kombinér alt i én enkelt v=spf1 … ~all-linje og slet resten. Vores dataartikel to SPF-poster svarer til ingen gennemgår, hvordan en million domæner er endt her; hvis det startede efter en migrering, se SPF holdt op med at virke efter skift af udbyder. Pas på med blot at sætte alle include:-referencerne sammen — hver enkelt koster DNS-opslag mod SPFs hårde grænse på 10, og du kan bytte ikke-fundet ud med en PermError: for mange DNS-opslag.

3. Udgav du den forkerte posttype — eller ødelagde brugergrænsefladen den?

Tidlig SPF havde sin egen DNS-posttype (type 99, bogstaveligt talt kaldet “SPF”). Den er forældet: RFC 7208 kræver TXT, og modtagere forespørger ikke type 99. Nogle DNS-paneler tilbyder stadig “SPF” i rullemenuen for posttype; vælger du det, er din post reel, velformet og usynlig. Kontrollér typekolonnen og genudgiv som TXT.

Den mere subtile variant er angivelse med anførselstegn. Indsætter du en værdi med anførselstegn i et felt, der selv tilføjer anførselstegn, ender du med ""v=spf1 …"" — som ikke længere starter med v=spf1, og for en verifikator eksisterer den dermed ikke. Din dig-output viser sandheden; DNS-panelet gemmer det ofte bag pæne visuelle effekter.

4. “Propagerer det stadig”?

“Giv det 24–48 timer at propagere” er det mest overordinerede råd inden for DNS. Propagering er blot cacher, der udløber: når postens TTL er udløbet (typisk 1 time, sjældent mere end 24), kan alle resolvere se det nye svar. Stadig ikke fundet efter 24 timer? Propagering er ikke årsagen.

De to reelle syndere: negativ caching — en resolver, der slog dig op inden du tilføjede posten, cacher “ingen post”-svaret, indtil den negative TTL udløber — og inkonsistente navneservere efter en migrering, hvor domænet stadig lister den gamle udbyders navneservere ved siden af de nye, og halvdelen af verden læser en zone, du ikke længere redigerer. Forespørg hver angivet navneserver direkte; er svarene forskellige, har du fundet problemet. Ret registrarens NS-delegation, så kun den udbyder, du rent faktisk redigerer, er autoritativ.

5. Er posten for lang, eller er den blokeret af en CNAME?

En enkelt streng i en TXT-post kan maksimalt være 255 tegn. Længere SPF-poster er lovlige, men skal opdeles i flere citerede strenge inden for én post — og DNS-udbydergrænseflader har det med at ødelægge opdelingen ved at afkorte værdien eller bryde den midt i en mekanisme, så den ikke kan parses. Er din post lang, skal du tjekke dig-output for en værdi, der slutter brat.

Desuden forbyder DNS en TXT-post på et navn, der allerede har en CNAME. Hvis mail.ditdomæne.dk er en CNAME til din udbyder, kan du ikke også placere SPF der — nogle paneler accepterer det og serverer derefter kun CNAME. Placer posten der, hvor CNAME’en peger (hvis du kontrollerer det), eller omstrukturér så afsendernavnet ikke er CNAME’d. Udbydere med god TXT-håndtering gør begge dele lettere — se Cloudflare SPF-opsætningsvejledningen.

Hvordan løser man det trin for trin?

1. Kør den gratis scanning på defaults.exposed — den læser din live DNS og fortæller dig, hvilken af de fem tilstande du befinder dig i, inden du rører noget som helst.
2. Bekræft, hvilke navneservere der er autoritative (dig NS), og at de alle er enige.
3. Forespørg TXT hos den autoritative navneserver for det præcise Return-Path-domæne.
4. Tæl v=spf1-linjerne: nul → udgiv én; to eller flere → flet til én.
5. Kontrollér, at typen er TXT, at værdien starter præcis med v=spf1, og at der ikke har sneget sig overflødige anførselstegn eller afkortning ind.
6. Vent én TTL, og scan derefter igen for at bekræfte, at den opløses korrekt overalt.

Ofte stillede spørgsmål

Hvorfor siger kontrolløreren “ikke fundet”, når jeg kan se posten i mit DNS-panel? Typisk årsag 2 eller 4: en anden v=spf1-post gør begge ugyldige — en PermError, som nogle værktøjer rapporterer som ikke-fundet, og som 1,013,416 domæner befinder sig i pr. 2026-06-29 — eller dit panel er ikke den DNS, der rent faktisk er autoritativ.

Hvor lang tid, før kontrollørerne ser min løsning? Én TTL — typisk en time, højst 24. Ud over det er “propagering” ikke forklaringen; gentjek de fem årsager, startende med navneserverkonsistens.

Skal jeg bruge “SPF”-posttypen, som mit DNS-panel tilbyder? Nej. Type 99 er forældet; RFC 7208 kræver kun TXT. En type 99-post er usynlig for moderne modtagere.

Posten findes nu — hvorfor fejler min mail stadig SPF? Fordi SPF tjekkes mod Return-Path-domænet, ikke Fra-headeren, og posten skal rent faktisk liste de servere, der sender for dig. Fundet er trin ét; vejledningen ret din SPF-post dækker, hvordan du opnår godkendelse.

Er det virkelig så almindeligt ikke at have en SPF-post? Ja — 121,145,609 domæner, 46.4% af de 261,086,232 graderede i Defaults.Exposed-census (pr. 2026-06-29), udgiver slet ingen SPF. Ikke-fundet er internettets standardtilstand.

Send ejeren rapporten

Når posten opløses korrekt, så kør scanningen igen og videresend den graderede rapport til den virksomhedsejer eller klient, hvis domæne det drejer sig om. Den viser på klart sprog, hvad der var i stykker, hvad du har rettet, og hvor domænet nu befinder sig — præcis det bevis, de vil blive bedt om ved fornyelse af cyberforsikring og i leverandørers sikkerhedsspørgeskemaer. Rapporten er kvitteringen for arbejdet.

Kontrollér din SPF-post gratis

Se, hvilken af de fem ikke-fundet-tilstande dit domæne befinder sig i — privat og kun for ejeren.

Kontrollér dit domæne → · Ret SPF → · SPF holdt op med at virke efter skift af udbyder → · Sådan graderer vi → · Kun aggregerede data. Data opbevares og behandles i EU.