Defaults.Exposed › Åtgärder › Guides

SPF misslyckas för dina SaaS-verktyg? Varför det händer och åtgärdsordningen — Europa-utgåvan (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.

När ett SaaS-verktyg “misslyckas med SPF” är din post vanligtvis inte problemet: e-posten misslyckas med DMARC-anpassning, eller din include-kedja har sprängts med SPF:s gräns på 10 DNS-uppslag. 2,119,539 av 138,927,207 SPF-publicerandade domäner befinner sig vid 9–10 uppslag — ett SaaS-include från klippkanten — enligt Defaults.Exposed censusdata för 261,086,232 domäner.

Nedan: hur du avgör vilket av de två problemen du har, sedan åtgärdsordningen — scanna först, hitta den domän verktyget faktiskt skickar från, byt leverantören till anpassad domän-DKIM och lägg bara till ett SPF-include där det faktiskt hjälper — plus det specifika för HubSpot, Salesforce, Mailchimp och SendGrid.

Varför misslyckas e-post från ett SaaS-verktyg med SPF?

Tre mönster täcker nästan varje fall:

Data per 2026-06-29.

Den fetstilta raden är där de flesta befinner sig. Att lägga till include:-rader för varje verktyg rör inte vid det — och varje rad för dig närmre den andra raden: minst 797,263 domäner har redan passerat gränsen på 10 uppslag, och deras SPF returnerar nu ett PermError som skyddar ingenting. Fulla siffror i SPF PermError-rapporten.

Vilken domän kontrollerar SPF faktiskt?

Inte den i din From-rubrik. Mottagare utvärderar SPF mot Return-Path-domänen (RFC5321.MailFrom, även kallad studs- eller kuvertsändaradressen) — From-rubriken som din mottagare ser spelar ingen roll i själva SPF-kontrollen.

Detta enda faktum förklarar de flesta “SaaS SPF-fel”. Din marknadsföringsplattform skickar med en Return-Path som [email protected]; SPF kontrolleras mot vendor.com och godkänns rent. Sedan frågar DMARC om den SPF-kontrollerade domänen matchar din From-domän. Det gör den inte, så SPF-benet i DMARC misslyckas och din instrumentpanel säger “SPF misslyckas”. Att redigera din egen SPF-post kan inte åtgärda det — din post rådfrågades aldrig.

Vad är åtgärdsordningen?

1. Kör den kostnadsfria sökningen först. Den talar om i ett svep om din SPF saknas, är duplicerad, överstiger uppslags­gränsen eller är korrekt, och var DMARC står — innan du rör DNS.
2. Hitta den Return-Path som verktyget faktiskt använder. Skicka ett test­meddelande från verktyget och läs Return-Path-rubriken (och Authentication-Results) i det råa meddelandet. Det talar om vilken rad i tabellen ovan du befinner dig på.
3. Aktivera leverantörens anpassade domän-DKIM. Varje seriöst SaaS-verktyg erbjuder “domänautentisering”: några CNAME-poster som låter det DKIM-signera som din domän. Den signaturen anpassar sig till din From-domän, så DMARC godkänns via DKIM — varaktigt, och även när e-post vidarebefordras. Det är lösningen som håller.
4. Lägg till leverantörens SPF-include bara om det använder din return-path — du har aktiverat dess anpassade studs­domän, eller det skickar faktiskt med din domän i kuvertet. Ett include för en leverantör som studsar via sin egen domän köper ingenting och spenderar din uppslags­budget.
5. Räkna dina DNS-uppslag innan du sparar. Gränsen är 10 lösta uppslag, includes räknas rekursivt, och 2,119,539 domäner befinner sig redan vid 9–10 — censusens p99 är 9. Nära kanten? Ta bort includes för verktyg du inte längre använder först. Bytte du just e-postleverantör? Kontrollera om det finns en kvarglömd andra post — två SPF-poster är lika med ett PermError.
6. Scanna igen och bekräfta. SPF godkänt på rätt domän, DKIM anpassat, DMARC godkänt. Den fullständiga referensen finns på hur man åtgärdar SPF; leverantörsgenomgångar som SPF på GoDaddy och DMARC på IONOS täcker DNS-panelens klick.

Vad ska du göra för HubSpot, Salesforce, Mailchimp och SendGrid?

HubSpot. Anslut din avsändardomän i HubSpots inställningar och publicera de två DKIM-CNAME:er den utfärdar (hs1-… / hs2-…). Det anpassar DKIM till din From-domän. Du behöver inte ett HubSpot SPF-include om du inte har konfigurerat HubSpot att använda din egen studs­domän.

Salesforce. Skapa en DKIM-nyckel i Salesforce Setup och publicera det CNAME-par den genererar. Om Salesforce skickar med din organisations return-path, lägg till include:_spf.salesforce.com och konfigurera studs­domänen — det här är det enda stora CRM:et där SPF-includet ofta faktiskt behövs.

Mailchimp. Autentisera din domän och publicera k2 / k3 DKIM-CNAMEerna. Mailchimp-anpassning är DKIM-only — det finns inget SPF-include att lägga till längre, och att lägga till ett från en gammal handledning slösar bara uppslag.

SendGrid. Slutför domänautentisering (“automatiserad säkerhet”): tre CNAMEs som hanterar både DKIM och return-path på din egen underdomän. Inget SPF-include behövs. Av de 740,321 domäner vars SPF auktoriserar sendgrid.net, har bara 18.0% en tillämpande DMARC (data per 2026-06-29) — de flesta SendGrid-avsändare stannar ett steg för tidigt.

Zendesk och allt annat: samma mönster. Hitta verktygets “domänautentisering”-sida, publicera dess DKIM-CNAMEs och rör bara SPF om verktyget dokumenterar att det använder din return-path.

Är SPF annorlunda för europeiska företag?

Nej — SPF, DKIM och DMARC fungerar identiskt överallt. Vad som skiljer sig i Europa är sammanhanget: vem som frågar, och vad dina grannar redan har gjort.

Din ccTLD sätter den lokala ribban. Europeiska ccTLDer publicerar SPF betydligt mer än .com-nivåer, men de domäner som avslutar jobbet — en tillämpande DMARC-policy ovanpå — är minoriteten överallt:

Data per 2026-06-29. Frankrike: 13.65% tillämpande DMARC; Italien: 5.24%.

Din europeiska hosts standard spelar roll. 4,346,526 domäner auktoriserar IONOS:s EU-e-postservrar (_spf-eu.ionos.com) i deras SPF — och bara 0.3% slutar med strikt -all, med 1.0% DMARC-tillämpade. OVH:s 2,132,049 gör det bättre på strikthet (43.7%) men bara 2.2% tillämpar DMARC (data per 2026-06-29). Om du aldrig har rört din post, du står på dessa standarder.

Tillsynsmyndigheter namnger nu detta. NIS2 Artikel 21(2)(j) kräver att organisationer i scope säkrar sina kommunikationer, och Kommissionens genomförandeförordning (EU) 2024/2690 specificerar e-post- och DNS-säkerhetsåtgärder. E-postautentisering är den konkreta, kontrollerbara delen — och, ovanligt för compliance, gratis att åtgärda.

Om dataresidensens: Defaults.Exposed-skannern och censuset körs i AWS eu-west-1, vi publicerar bara aggregerade siffror och en skanning kontrollerar bara den domän du frågar om.

Vanliga frågor

Min SPF-kontrollant säger “godkänt” men verktygets instrumentpanel säger att SPF misslyckas — varför? Kontrollanten testade din post; mottagaren testade Return-Path-domänen som verktyget faktiskt använde, sedan jämförde DMARC den med din From-domän. Det är ett anpassningsfel, inte ett postfel — åtgärdat med leverantörens anpassade domän-DKIM, inte med SPF-redigeringar.

Ska jag bara lägga till SPF-includet för varje verktyg vi använder? Nej. Varje include spenderar en del av SPF:s budget på 10 uppslag, rekursivt: 2,119,539 av 138,927,207 SPF-publicerandade domäner befinner sig vid 9–10 uppslag, och minst 797,263 är över — deras SPF returnerar PermError och skyddar ingenting (data per 2026-06-29).

Åtgärdar includet DMARC också? Bara om verktyget skickar med din return-path, så att SPF godkänns och anpassas. För de flesta SaaS-verktyg gör det inte det — vilket är varför anpassad DKIM, inte SPF, är det ben som gör att DMARC godkänns för SaaS-e-post.

Är detta ett lagkrav inom EU? För organisationer inom NIS2:s scope gör Artikel 21(2)(j) och Genomförandeförordning (EU) 2024/2690 e-postsäkerhet till en skyldighet. Även utanför scope frågar försäkringsbolag och kundenkäter alltmer — och per 2026-06-29 når ingen EU ccTLD ens en tredjedel av sina domäner till en tillämpande DMARC-policy (29.43% i .nl som bäst; 5.24% i .it).

Skicka ägaren rapporten

När CNAMEerna är aktiva, kör sökningen igen och vidarebefordra den graderade rapporten till ägaren eller kunden. Den visar, på klarspråk, vad som misslyckades, vad du åtgärdade och var domänen nu står — exakt det bevis de behöver vid försäkringsförnyelse eller kunds säkerhetsenkät, skriftligt snarare än på ditt ord.

Kontrollera din domän kostnadsfritt

Se exakt vilket ben av SPF, DKIM och DMARC som misslyckas — privat och enbart för ägaren.

Kontrollera din domän → · Åtgärda SPF → · SPF PermError: “för många DNS-uppslag” → · Hur vi graderar → · Enbart aggregerade data. Data lagras och behandlas inom EU.