Defaults.Exposed › Fikser › Guides

«SPF-post ikke funnet» — men du har en? De 5 reelle årsakene (2026)

Publisert 2026-07-08

Tall per 2026-06-29 · metodikk v7. Samlet sensusdata for 261 millioner graderte domener. Se hvordan vi graderer.

Hvis en sjekketjeneste sier «SPF-post ikke funnet», men du er sikker på at du publiserte en, er posten vanligvis usynlig heller enn manglende: 1,013,416 domener — omtrent ett av 138 av de som forsøker SPF — publiserer to eller flere SPF-poster, en PermError (RFC 7208 §3.2) som mange sjekketjenester rapporterer som ikke-funnet, ifølge Defaults.Exposed-sensus over 261 millioner domener.

Det er fem reelle årsaker, alle kan fikses i én økt: feil vert, duplikatpost, feil DNS-type eller ødelagte anførselstegn, inkonsistente navnetjenere, eller en lengde-/CNAME-kollisjon. Nedenfor: 60-sekunders-testen for hver enkelt, i den rekkefølgen du bør sjekke dem, etterfulgt av fiksetrinnene.

Er du sikker på at posten faktisk finnes?

Begynn med den ubehagelige muligheten, fordi det er den klart vanligste: av de 261,086,232 domenene gradert i Defaults.Exposed-sensus, har 121,145,609 — 46.4% — ingen SPF-post i det hele tatt. Mange «men jeg satte dette opp»-tilfeller viser seg å handle om en post lagt til i en stagingssone eller hos en gammel DNS-leverandør som ikke lenger er autoritativ. Sjekk DNS-leverandøren som navnetjenerne dine faktisk peker mot (ofte ikke registraren din) for en TXT-post som starter v=spf1. Hvis den genuint ikke finnes der, hopp over detektivarbeidet og gå direkte til fiks SPF-posten din.

Hvordan sjekker du en SPF-post riktig?

Nettbaserte sjekketjenester spør DNS via sin egen bufring-resolver. For å se sannheten, spør domenets autoritative navnetjener direkte:

# finn de autoritative navnetjenerne
dig NS yourdomain.com +short

# spør én av dem direkte om TXT-poster
dig TXT yourdomain.com @ns1.yourdnshost.com +short

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

To tolkningsregler. Først teller du linjene som starter v=spf1 — antallet er like viktig som innholdet. For det andre kontrollerer du at du spurte om riktig navn: mottakere evaluerer SPF mot domenet i Return-Path (RFC5321.MailFrom, «konvolutt-fra») — ikke Fra-adressen mottakerne ser. Hvis nyhetsbrevverktøyet ditt spretter e-post via bounce.yourdomain.com, er en perfekt post på apex-domenet ikke den posten mottakerne slår opp.

Hva er de fem reelle årsakene?

Data per 2026-06-29.

1. Er posten hos feil vert?

Den klassiske feilen: SPF lagt til på mail.yourdomain.com når e-post hevder å komme fra yourdomain.com, eller omvendt. SPF arver ikke nedover — en post på apex-domenet sier ingenting om subdomener, og omvendt. Publiser nøyaktig på det navnet i Return-Path. En leverandør som sender fra sitt eget sprett-subdomene trenger en post på det subdomenet — vanligvis en CNAME eller TXT som leverandøren oppgir (veiledningen for GoDaddy SPF-oppsett viser hvor disse feltene befinner seg).

2. Har du to SPF-poster?

Hovedårsaken, og den mest villedende feilmeldingen innen e-postautentisering. RFC 7208 §3.2 er klar: et domene må ha nøyaktig én SPF-post. To eller flere er en PermError — mottakere behandler SPF som ugyldig. Noen sjekketjenester rapporterer dette nøyaktig («flere poster funnet»); andre rapporterer nettoresultatet: ingen gyldig SPF-post funnet. Du ser en post i panelet og konkluderer med at sjekketjenesten er ødelagt. Det er den ikke — du har én post for mange.

Sensus fant 1,013,416 domener med to eller flere SPF-poster — omtrent ett av 138 av domenene som forsøker SPF — alle med SPF i praksis slått av. Det skjer vanligvis under leverandørskifte: den nye leverandørens veiviser legger til en ny post i stedet for å redigere den gamle. Løsningen er sammenslåing, aldri en ny post: kombiner alt til én enkelt v=spf1 … ~all-linje og slett resten. Vår datarapporten to SPF-poster er lik ingen bryter ned hvordan en million domener endte opp her; hvis det startet etter en migrering, se SPF sluttet å virke etter leverandørbytte. Mens du slår dem sammen, ikke blind-sammenkobler du hver include: — hver koster DNS-oppslag mot SPFs harde grense på 10, og bytter ikke-funnet mot PermError: for mange DNS-oppslag.

3. Publiserte du feil posttype — eller ødela brukergrensesnittet det?

Tidlig SPF hadde sin egen DNS-posttype (type 99, bokstavelig talt kalt «SPF»). Den ble utfaset: RFC 7208 krever TXT, og mottakere spør ikke om type 99. Noen DNS-paneler tilbyr fortsatt «SPF» i posttype-nedtrekksmenyen; velger du den, er posten din reell, velformet og usynlig. Sjekk typekolonnen og republiser som TXT.

Den mer subtile søskenfeilen er anførselstegn. Å lime inn en verdi pakket inn i anførselstegn i et felt som legger til sine egne anførselstegn, produserer ""v=spf1 …"" — som ikke lenger starter med v=spf1, så for en bekreftelsestjeneste finnes den ikke. Din dig-utdata viser sannheten; DNS-panelet skjuler det gjerne kosmetisk.

4. Er det virkelig «fortsatt i ferd med å propagere»?

«Gi det 24–48 timer for å propagere» er det mest overprescriberte rådet i DNS. Propagering er bare at buffere utløper: når postens TTL er utløpt (vanligvis 1 time, sjelden mer enn 24), kan alle resolvere se det nye svaret. Fortsatt ikke-funnet etter 24 timer? Propagering er ikke årsaken.

De to virkelige synderne: negativ bufring — en resolver som slo deg opp før du la til posten, bufrer «ingen slik post»-svaret til den negative TTL-en utløper — og inkonsistente navnetjenere etter en migrering, der domenet fortsatt lister opp den gamle leverandørens navnetjenere ved siden av de nye, og halvparten av verden leser en sone du ikke lenger redigerer. Spør hver opplistede navnetjener direkte; hvis svarene avviker, har du funnet det. Fiks registrarens NS-delegering slik at bare den leverandøren du faktisk redigerer er autoritativ.

5. Er posten for lang, eller blokkert av en CNAME?

Én enkelt streng i en TXT-post kan maks være 255 tegn. Lengre SPF-poster er lovlige, men må splittes i flere anførselstegnomsluttede strenger innenfor én post — og DNS-leverandørers nettgrensesnitt er beryktet for å ødelegge splittingen, kutte verdien eller bryte den midt i en mekanisme slik at den ikke lenger kan tolkes. Hvis posten er lang, sjekk dig-utdataen for en verdi som slutter brått.

I tillegg forbyr DNS en TXT-post på et navn som allerede har en CNAME. Hvis mail.yourdomain.com er en CNAME til leverandøren din, kan du ikke også legge SPF der — noen paneler aksepterer det og serverer deretter bare CNAME. Legg posten der CNAME peker (om du kontrollerer det), eller restrukturer slik at avsendernavnet ikke er CNAME-ert. Leverandører med ryddig TXT-håndtering gjør begge deler enklere — se Cloudflare SPF-oppsettsveiledningen.

Hvordan fikser du det, steg for steg?

1. Kjør den gratis skanningen på defaults.exposed — den leser live DNS og forteller deg hvilken av de fem tilstandene du befinner deg i, før du rører noe som helst.
2. Bekreft hvilke navnetjenere som er autoritative (dig NS) og at de alle er enige.
3. Spør TXT hos den autoritative navnetjeneren for det eksakte Return-Path-domenet.
4. Tell v=spf1-linjene: null → publiser én; to eller flere → slå dem sammen til én.
5. Verifiser at typen er TXT, at verdien starter nøyaktig med v=spf1, og at det ikke har sneket seg inn tilfeldige anførselstegn eller trunkering.
6. Vent én TTL, og skann deretter på nytt for å bekrefte at den løses opp riktig overalt.

Ofte stilte spørsmål

Hvorfor sier sjekketjenesten «ikke funnet» når jeg kan se posten i DNS-panelet mitt? Vanligvis årsak 2 eller 4: en ekstra v=spf1-post gjør begge ugyldige — en PermError som noen verktøy rapporterer som ikke-funnet, den tilstanden 1,013,416 domener befinner seg i per 2026-06-29 — eller panelet ditt er ikke den DNS som faktisk er autoritativ.

Hvor lang tid tar det før sjekketjenestene ser fiksen min? Én TTL — vanligvis én time, maks 24. Utover det er «propagering» ikke forklaringen; sjekk de fem årsakene på nytt, begynn med navnetjenerkonsistens.

Bør jeg bruke «SPF»-posttypen DNS-panelet mitt tilbyr? Nei. Type 99 er utfaset; RFC 7208 krever bare TXT. En type 99-post er usynlig for moderne mottakere.

Posten finnes nå — hvorfor feiler e-posten min fortsatt SPF? Fordi SPF sjekkes mot Return-Path-domenet, ikke Fra-overskriften, og posten må faktisk liste opp serverne som sender for deg. Funnet er trinn én; veiledningen for fiks SPF-posten din dekker bestått.

Er det virkelig så vanlig å ikke ha noen SPF-post? Ja — 121,145,609 domener, 46.4% av de 261,086,232 gradert i Defaults.Exposed-sensus (per 2026-06-29), publiserer ingen SPF i det hele tatt. Ikke-funnet er internettets standardtilstand.

Send eieren rapporten

Når posten løses opp riktig, kjør skanningen på nytt og videresend den graderte rapporten til bedriftseieren eller klienten dette domenet tilhører. Den viser, på enkelt språk, hva som var ødelagt, hva du fikset, og hvor domenet nå står — nøyaktig det beviset de vil bli spurt om ved fornyelse av cyberforsikring og leverandørsikkerhets-spørreskjemaer. Rapporten er kvitteringen for arbeidet.

Sjekk SPF-posten din gratis

Se hvilken av de fem ikke-funnet-tilstandene domenet ditt befinner seg i — privat og kun for eieren.

Sjekk domenet ditt → · Fiks SPF → · SPF sluttet å virke etter leverandørbytte → · Hvordan vi graderer → · Kun aggregerte data. Data lagret og behandlet i EU.