Defaults.Exposed › Fikser › Guides
SPF feiler for SaaS-verktøyene dine? Hvorfor det skjer og fiksrekkefølgen — Europa-utgaven (2026)
Publisert 2026-07-08
Tall per 2026-06-29 · metodikk v7. Samlet sensusdata for 261 millioner graderte domener. Se hvordan vi graderer.
Når et SaaS-verktøy «feiler SPF», er posten din vanligvis ikke problemet: e-posten feiler DMARC-justering, eller include-kjeden din har sprengt SPFs 10-DNS-oppslagsgrense. 2,119,539 av 138,927,207 SPF-publiserende domener sitter på 9–10 oppslag — én SaaS-include fra klippen — ifølge Defaults.Exposed-sensus over 261,086,232 domener.
Nedenfor: hvordan fortelle hvilket av de to problemene du har, deretter fiksrekkefølgen — skann først, finn domenet verktøyet egentlig sender fra, bytt leverandøren til egendefinert-domene-DKIM, og legg bare til en SPF include der den genuint hjelper — pluss det spesifikke for HubSpot, Salesforce, Mailchimp og SendGrid.
Hvorfor feiler e-post fra et SaaS-verktøy SPF?
Tre mønstre dekker nesten alle tilfeller:
| Hva rapporten eller avvisningen sier | Hva som faktisk er galt | Fiksen |
|---|---|---|
| SPF bestås, DMARC feiler fortsatt | Justering: verktøyet besto SPF på sitt sprette-domene, ikke ditt | Slå på leverandørens egendefinerte-domene-DKIM (CNAME-er) |
SPF permerror | Include-kjeden din overskrider SPFs 10-DNS-oppslagsgrense | Beskjær includes; se for-mange-oppslag-fiksen |
SPF fail / softfail | Verktøyet sender virkelig med return-path-en din og er ikke i posten din | Legg til leverandørens include eller aktiver dens egendefinerte sprette-domene |
Data per 2026-06-29.
Den uthevede raden er der de fleste befinner seg. Å legge til include:-linjer for hvert verktøy berører den ikke — og hver linje flytter deg nærmere den andre raden: minst 797,263 domener har allerede krysset 10-oppslagsgrensen, og SPF returnerer nå en PermError som ikke beskytter noe. Fulle tall i SPF PermError-rapporten.
Hvilket domene sjekker SPF faktisk?
Ikke det i Fra-overskriften din. Mottakere evaluerer SPF mot Return-Path-domenet (RFC5321.MailFrom, også kalt sprette- eller konvolutt-fra-adressen) — Fra-overskriften mottakeren din ser spiller ingen rolle i selve SPF-sjekken.
Denne ene kjensgjerningen forklarer de fleste «SaaS SPF-feil». Markedsføringsplattformen din sender med en Return-Path som [email protected]; SPF sjekkes mot leverandor.com og bestås rent. Deretter spør DMARC om det SPF-sjekkede domenet samsvarer med Fra-domenet ditt. Det gjør det ikke, slik at SPF-beinet til DMARC feiler og dashbordet ditt sier «SPF feiler». Redigering av din egen SPF-post kan ikke fikse det — posten din ble aldri konsultert.
Hva er fiksrekkefølgen?
- Kjør den gratis skanningen først. Den forteller deg i én omgang om SPF mangler, er duplisert, over oppslagsgrensen eller i orden, og hvor DMARC står — før du rører DNS.
- Finn Return-Path verktøyet faktisk bruker. Send deg selv en test fra verktøyet og les Return-Path-overskriften (og Authentication-Results) i råmeldingen. Det forteller deg hvilken rad i tabellen over du er i.
- Slå på leverandørens egendefinerte-domene-DKIM. Alle seriøse SaaS-verktøy tilbyr «domeneautentisering»: noen CNAME-poster som lar det DKIM-signere som domenet ditt. Den signaturen justerer med Fra-domenet ditt, slik at DMARC bestås via DKIM — varig, og selv når e-post videresendes. Dette er fiksen som varer.
- Legg til leverandørens SPF include bare hvis det bruker return-path-en din — du har aktivert dens egendefinerte sprette-domene, eller det genuint sender med domenet ditt i konvolutten. En include for en leverandør som spretter via sitt eget domene kjøper ingenting og bruker oppslagsbudsjettet ditt.
- Tell DNS-oppslagene dine før du lagrer. Grensen er 10 løste oppslag, includes teller rekursivt, og 2,119,539 domener sitter allerede på 9–10 — sensus p99 er 9. Nær kanten? Fjern includes for verktøy du ikke lenger bruker først. Byttet nettopp e-postleverandør? Sjekk for en tilbakeværende andre post — to SPF-poster tilsvarer en PermError.
- Skann på nytt og bekreft. SPF bestås på riktig domene, DKIM justert, DMARC bestått. Den fulle referansen bor på hvordan fikse SPF; leverandørgjennomganger som SPF på GoDaddy og DMARC på IONOS dekker DNS-panel-klikkene.
Hva bør du gjøre for HubSpot, Salesforce, Mailchimp og SendGrid?
HubSpot. Koble til sendingsdomenet ditt i HubSpots innstillinger og publiser de to DKIM CNAME-ene den utsteder (hs1-… / hs2-…). Det justerer DKIM med Fra-domenet ditt. Du trenger ikke en HubSpot SPF include med mindre du har konfigurert HubSpot til å bruke ditt eget sprette-domene.
Salesforce. Opprett en DKIM-nøkkel i Salesforce Setup og publiser CNAME-paret den genererer. Hvis Salesforce sender med organisasjonens return-path, legg til include:_spf.salesforce.com og konfigurer sprette-domenet — dette er den ene store CRM-en der SPF include ofte genuint er nødvendig.
Mailchimp. Autentiser domenet ditt og publiser k2 / k3 DKIM CNAME-ene. Mailchimp-justering er kun DKIM — det finnes ingen SPF include å legge til lenger, og å legge til én fra en gammel opplæringsvideo bare kaster oppslag.
SendGrid. Fullfør domeneautentisering («automatisert sikkerhet»): tre CNAME-er som håndterer både DKIM og return-path på ditt eget underdomene. Ingen SPF include nødvendig. Av de 740,321 domenene hvis SPF autoriserer sendgrid.net, har bare 18.0% håndhevet DMARC (data per 2026-06-29) — de fleste SendGrid-avsendere stopper ett steg for kort.
Zendesk og alt annet: samme mønster. Finn verktøyets «domeneautentisering»-side, publiser DKIM CNAME-ene, og rør bare SPF hvis verktøyet dokumenterer at det bruker return-path-en din.
Er SPF forskjellig for europeiske bedrifter?
Nei — SPF, DKIM og DMARC fungerer identisk overalt. Det som er annerledes i Europa er konteksten: hvem som spør, og hva naboene dine allerede har gjort.
ccTLD-en din setter den lokale standarden. Europeiske ccTLD-er publiserer SPF godt over .com-rater, men domenene som fullfører jobben — en håndhevende DMARC-policy på toppen — er mindretallet overalt:
| TLD | SPF-adopsjon (av graderte domener) | Håndhevende DMARC (av graderte domener) |
|---|---|---|
| .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 per 2026-06-29. Frankrike: 13.65% håndhever DMARC; Italia: 5.24%.
Den europeiske vertens standard betyr noe. 4,346,526 domener autoriserer IONOS sine EU-e-postservere (_spf-eu.ionos.com) i SPF-en — og bare 0.3% slutter i streng -all, med 1.0% DMARC-håndhevet. OVHs 2,132,049 gjør det bedre på strenghet (43.7%) men bare 2.2% håndhever DMARC (data per 2026-06-29). Hvis du aldri rørte posten din, står du på disse standardene.
Regulatorer navngir dette nå. NIS2 artikkel 21(2)(j) krever at enheter i omfang sikrer kommunikasjonen sin, og Kommisjonens gjennomføringsforordning (EU) 2024/2690 spesifiserer e-post- og DNS-sikkerhetstiltak. E-postautentisering er den konkrete, kontrollerbare biten — og, uvanlig for samsvar, gratis å fikse.
Om dataopphold: Defaults.Exposed-skannneren og -sensus kjører i AWS eu-west-1, vi publiserer bare aggregerte tall, og en skanning sjekker bare domenet du spør om.
Ofte stilte spørsmål
SPF-kontrolløren min sier «bestått» men verktøyets dashbord sier SPF feiler — hvorfor? Kontrolløren testet posten din; mottakeren testet Return-Path-domenet verktøyet faktisk brukte, og deretter sammenlignet DMARC det med Fra-domenet ditt. Det er en justeringsfeil, ikke en postfeil — fikset med leverandørens egendefinerte-domene-DKIM, ikke med SPF-redigeringer.
Bør jeg bare legge til SPF include for hvert verktøy vi bruker? Nei. Hver include bruker deler av SPFs 10-oppslagsbudsjett, rekursivt: 2,119,539 av 138,927,207 SPF-publiserende domener sitter på 9–10 oppslag, og minst 797,263 er over — SPF returnerer PermError og beskytter ingenting (data per 2026-06-29).
Fikser include-en DMARC også? Bare hvis verktøyet sender med return-path-en din, slik at SPF bestås og justerer. For de fleste SaaS-verktøy gjør det ikke det — noe som er grunnen til at justert DKIM, ikke SPF, er beinet som gjør at DMARC bestås for SaaS-e-post.
Er dette et lovkrav i EU? For enheter i NIS2-omfang gjør artikkel 21(2)(j) og gjennomføringsforordning (EU) 2024/2690 e-postsikkerhet til en forpliktelse. Selv utenfor omfang spør forsikringsselskaper og kundespørreskjemaer i økende grad — og per 2026-06-29 får ingen EU-ccTLD engang en tredjedel av domenene til en håndhevende DMARC-policy (29.43% i .nl som beste; 5.24% i .it).
Send eieren rapporten
Når CNAME-ene er live, kjør skanningen på nytt og videresend den graderte rapporten til bedriftseieren eller klienten. Den viser, på enkelt norsk, hva som feilet, hva du fikset, og hvor domenet nå befinner seg — nøyaktig beviset de trenger for forsikringsfornyelsen eller kundenes sikkerhets-spørreskjema, skriftlig i stedet for på ditt ord.
Sjekk domenet ditt gratis
Se nøyaktig hvilken del av SPF, DKIM og DMARC som feiler — privat og kun for eieren.
Sjekk domenet ditt → · Fiks SPF → · SPF PermError: «for mange DNS-oppslag» → · Hvordan vi graderer → · Kun aggregerte data. Data lagret og behandlet i EU.