Defaults.Exposed › Rettelser › Guides
SPF fejler for dine SaaS-værktøjer? Hvorfor det sker og løsningsrækkefølgen — Europaedition (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.
Når et SaaS-værktøj “fejler SPF”, er din post typisk ikke problemet: mailen fejler DMARC-justering, eller din include-kæde har sprængt SPFs grænse på 10 DNS-opslag. 2,119,539 af 138,927,207 SPF-udgivende domæner befinder sig på 9–10 opslag — ét SaaS-include fra kanten — ifølge Defaults.Exposed-census over 261,086,232 domæner.
Nedenfor: hvordan du afgør, hvilket af de to problemer du har, derefter løsningsrækkefølgen — scan først, find det domæne, som værktøjet rent faktisk sender fra, skift leverandøren til tilpasset-domæne DKIM, og tilføj kun et SPF include, hvor det faktisk hjælper — plus det specifikke for HubSpot, Salesforce, Mailchimp og SendGrid.
Hvorfor fejler mail fra et SaaS-værktøj SPF?
Tre mønstre dækker næsten alle tilfælde:
| Hvad rapporten eller returneringen siger | Hvad der rent faktisk er galt | Løsningen |
|---|---|---|
| SPF godkendt, DMARC fejler stadig | Justering: værktøjet godkendte SPF på dets bounce-domæne, ikke dit | Slå leverandørens tilpassede-domæne DKIM til (CNAMEs) |
SPF permerror | Din include-kæde overskrider SPFs grænse på 10 DNS-opslag | Beskær includes; se for-mange-opslag-løsningen |
SPF fail / softfail | Værktøjet sender faktisk med dit return-path, og det er ikke i din post | Tilføj leverandørens include eller aktivér dets tilpassede bounce-domæne |
Data pr. 2026-06-29.
Den fremhævede række er, hvor de fleste befinder sig. At tilføje include:-linjer til hvert værktøj rører ikke ved den — og hver linje bringer dig tættere på den anden række: mindst 797,263 domæner har allerede overskredet grænsen på 10 opslag, og deres SPF returnerer nu en PermError, der ikke beskytter noget. Se SPF PermError-rapporten for de fulde tal.
Hvilket domæne kontrollerer SPF egentlig?
Ikke det i din Fra-header. Modtagere evaluerer SPF mod Return-Path-domænet (RFC5321.MailFrom, også kaldet bounce- eller konvolut-fra-adressen) — Fra-headeren, som din modtager ser, spiller ingen rolle i selve SPF-kontrollen.
Denne ene kendsgerning forklarer de fleste “SaaS SPF-fejl”. Din marketingplatform sender med en Return-Path som [email protected]; SPF kontrolleres mod leverandor.dk og godkendes rent. DMARC spørger derefter, om det SPF-kontrollerede domæne matcher dit Fra-domæne. Det gør det ikke, og SPF-benet i DMARC fejler, og dit dashboard siger “SPF fejler”. At redigere din egen SPF-post kan ikke løse det — din post blev aldrig konsulteret.
Hvad er løsningsrækkefølgen?
- Kør den gratis scanning først. Den fortæller dig i ét overblik, om din SPF mangler, er duplikeret, over opslagsgrænsen eller fin, og hvor DMARC befinder sig — inden du rører DNS.
- Find den Return-Path, som værktøjet faktisk bruger. Send dig selv en test fra værktøjet og læs Return-Path-headeren (og Authentication-Results) i den rå besked. Det fortæller dig, hvilken række i tabellen ovenfor du befinder dig i.
- Slå leverandørens tilpassede-domæne DKIM til. Ethvert seriøst SaaS-værktøj tilbyder “domænegodkendelse”: et par CNAME-poster, der lader det DKIM-signere som dit domæne. Den signatur justerer med dit Fra-domæne, så DMARC godkendes via DKIM — holdbart, og selv når mailen videresendes. Det er den løsning, der varer.
- Tilføj kun leverandørens SPF include, hvis det bruger dit return-path — du har aktiveret dets tilpassede bounce-domæne, eller det sender faktisk med dit domæne i konvolutten. Et include til en leverandør, der bouncer via sit eget domæne, giver ingenting og bruger dit opslagsbudget.
- Tæl dine DNS-opslag inden du gemmer. Grænsen er 10 opløste opslag, includes tæller rekursivt, og 2,119,539 domæner befinder sig allerede på 9–10 — census p99 er 9. Nær kanten? Fjern includes til værktøjer, du ikke længere bruger, først. Har du netop skiftet e-mailudbyder? Tjek for en overskydende anden post — to SPF-poster svarer til en PermError.
- Scan igen og bekræft. SPF godkendt på det rigtige domæne, DKIM justeret, DMARC godkendt. Den fulde reference er på hvordan man retter SPF; udbydervejledninger som SPF på GoDaddy og DMARC på IONOS dækker DNS-panel-kliks.
Hvad bør du gøre for HubSpot, Salesforce, Mailchimp og SendGrid?
HubSpot. Tilslut dit afsenderdomæne i HubSpots indstillinger og udgiv de to DKIM-CNAMEs, det udsteder (hs1-… / hs2-…). Det justerer DKIM med dit Fra-domæne. Du behøver ikke et HubSpot SPF include, medmindre du har konfigureret HubSpot til at bruge dit eget bounce-domæne.
Salesforce. Opret en DKIM-nøgle i Salesforce Setup og udgiv det CNAME-par, det genererer. Hvis Salesforce sender med din organisations return-path, skal du tilføje include:_spf.salesforce.com og konfigurere bounce-domænet — dette er det ene store CRM, hvor SPF include’et ofte er reelt nødvendigt.
Mailchimp. Godkend dit domæne og udgiv k2- / k3-DKIM-CNAMEsene. Mailchimp-justering er kun DKIM — der er ikke noget SPF include at tilføje mere, og at tilføje et fra en gammel vejledning spilder blot opslag.
SendGrid. Afslut domænegodkendelse (“automated security”): tre CNAMEs, der håndterer både DKIM og return-path på dit eget underdomæne. Intet SPF include nødvendigt. Af de 740,321 domæner, hvis SPF godkender sendgrid.net, har kun 18.0% en håndhævet DMARC (data pr. 2026-06-29) — de fleste SendGrid-afsendere stopper ét trin for tidligt.
Zendesk og alt andet: samme mønster. Find værktøjets “domænegodkendelses”-side, udgiv dets DKIM-CNAMEs, og rør kun SPF, hvis værktøjet dokumenterer, at det bruger dit return-path.
Er SPF anderledes for europæiske virksomheder?
Nej — SPF, DKIM og DMARC fungerer identisk overalt. Hvad der adskiller sig i Europa er konteksten: hvem der spørger, og hvad dine naboer allerede har gjort.
Dit ccTLD sætter den lokale standard. Europæiske ccTLDs udgiver SPF godt over .com-niveauerne, men de domæner, der fuldfører jobbet — en håndhævet DMARC-politik ovenpå — er et mindretal overalt:
| TLD | SPF-adoption (af graderede domæner) | Håndhævet DMARC (af graderede domæner) |
|---|---|---|
| .nl | 75.91% | 29.43% |
| .ie | 70.89% | 8.79% |
| .de | 64.67% | 21.38% |
| .dk | 50.42% | 19.88% |
| .com | 54.14% | 9.50% |
Data pr. 2026-06-29. Frankrig: 13.65% håndhæver DMARC; Italien: 5.24%.
Din europæiske hosts standard betyder noget. 4,346,526 domæner godkender IONOS’ EU-mailservere (_spf-eu.ionos.com) i deres SPF — og kun 0.3% afslutter med streng -all, og 1.0% håndhæver DMARC. OVH’s 2,132,049 gør det bedre på strenghed (43.7%), men kun 2.2% håndhæver DMARC (data pr. 2026-06-29). Har du aldrig rørt din post, holder du dig til disse standarder.
Tilsynsmyndigheder navngiver nu dette. NIS2 artikel 21(2)(j) kræver, at entiteter inden for scope sikrer deres kommunikation, og Kommissionens gennemførelsesforordning (EU) 2024/2690 specificerer e-mail- og DNS-sikkerhedsforanstaltninger. E-mailgodkendelse er den konkrete, kontrollerbare del — og usædvanligt for compliance: gratis at rette.
Om dataopholdsted: Defaults.Exposed-scanneren og -census kører i AWS eu-west-1, vi udgiver kun aggregerede tal, og en scanning kontrollerer kun det domæne, du spørger om.
Ofte stillede spørgsmål
Min SPF-kontrollør siger “godkendt”, men værktøjets dashboard siger, at SPF fejler — hvorfor? Kontrolløren testede din post; modtageren testede det Return-Path-domæne, som værktøjet faktisk brugte, og derefter sammenlignede DMARC det med dit Fra-domæne. Det er et justeringsfejl, ikke et postfejl — løst med leverandørens tilpassede-domæne DKIM, ikke med SPF-redigeringer.
Bør jeg bare tilføje SPF include til hvert værktøj, vi bruger? Nej. Hvert include bruger en del af SPFs budget på 10 opslag, rekursivt: 2,119,539 af 138,927,207 SPF-udgivende domæner befinder sig på 9–10 opslag, og mindst 797,263 er over — deres SPF returnerer PermError og beskytter ingenting (data pr. 2026-06-29).
Løser include DMARC også? Kun hvis værktøjet sender med dit return-path, så SPF godkendes og justeres. For de fleste SaaS-værktøjer gør det ikke — og det er grunden til, at justeret DKIM, ikke SPF, er det ben, der godkender DMARC for SaaS-mail.
Er dette et lovkrav i EU? For entiteter inden for NIS2-scope gør artikel 21(2)(j) og gennemførelsesforordning (EU) 2024/2690 e-mailsikkerhed til en forpligtelse. Selv uden for scope spørger forsikringsselskaber og kundespørgeskemaer i stigende grad — og pr. 2026-06-29 når intet EU-ccTLD end ikke en tredjedel af sine domæner til en håndhævet DMARC-politik (29.43% i .nl er bedst; 5.24% i .it).
Send ejeren rapporten
Når CNAMEsene er live, skal du køre scanningen igen og videresende den graderede rapport til virksomhedsejeren eller klienten. Den viser på klart sprog, hvad der fejlede, hvad du rettede, og hvor domænet nu befinder sig — præcis det bevis, de har brug for til forsikringsfornyelsen eller leverandørens sikkerhedsspørgeskema, skriftligt frem for på dit ord.
Kontrollér dit domæne gratis
Se præcis, hvilket ben af SPF, DKIM og DMARC der fejler — privat og kun for ejeren.
Kontrollér dit domæne → · Ret SPF → · SPF PermError: “for mange DNS-opslag” → · Sådan graderer vi → · Kun aggregerede data. Data opbevares og behandles i EU.