Defaults.Exposed › Javítások › Guides
SPF meghibásodik a SaaS-eszközöknél? Miért történik ez, és a javítás sorrendje — Európai kiadás (2026)
Közzétéve 2026-07-08
Adatok: 2026-06-29 · módszertan v7. Összesített cenzusadatok 261 millió értékelt domain alapján. Lásd: hogyan osztályozunk.
Ha egy SaaS-eszköz „SPF-et hibáz”, a rekordja általában nem a probléma: a levél DMARC-igazítási hibán bukik el, vagy az include-lánc túllépte az SPF 10 DNS-kereséses korlátját. 2,119,539 az 138,927,207 SPF-közzétevő domainből 9–10 keresésénél ül — egyetlen SaaS include-ra van a sziklaéltől — a Defaults.Exposed 261,086,232 domaincenzusza szerint.
Alább: hogyan állapítsa meg, melyik két problémával küzd, majd a javítás sorrendje — először a vizsgálat, majd keresse meg a domain valódi küldési forrását, kapcsolja a szállítót egyéni domainű DKIM-re, és csak ott adjon hozzá SPF include-ot, ahol valóban segít — plusz a HubSpot, Salesforce, Mailchimp és SendGrid specifikus útmutatója.
Miért bukik el a SaaS-eszközből érkező levél SPF-en?
Három minta lefedi a szinte minden esetet:
| Mit jelez a jelentés vagy a visszapattanó levél | Mi a tényleges probléma | A megoldás |
|---|---|---|
| SPF átment, a DMARC mégis megbukik | Igazítás: az eszköz az SPF-et saját visszapattanó domainjén ment át, nem az Önén | Kapcsolja be a szállító egyéni domainű DKIM-jét (CNAME-ek) |
SPF permerror | Az include-lánc túllépte az SPF 10 DNS-kereséses korlátját | Tisztítsa az include-okat; lásd: a túl-sok-keresés javítása |
SPF fail / softfail | Az eszköz valóban az Ön return-path-jával küld, és nincs benne a rekordjában | Adja hozzá a szállító include-ját, vagy engedélyezze az egyéni visszapattanó domainjét |
Adatok: 2026-06-29.
A kiemelt sor az, ahol a legtöbb ember áll. Az include: sorok hozzáadása minden eszköznek nem érinti ezt — és minden sor közelebb visz a második sorhoz: legalább 797,263 domain már átlépte a 10-keresési korlátot, és SPF-jük PermError-t ad vissza, ami semmit nem véd. A teljes számok: az SPF PermError-jelentés.
Melyik domainnel szemben ellenőrzi valójában az SPF-et?
Nem azzal, amely a From fejlécben szerepel. A fogadók az SPF-et a Return-Path domain (az RFC5321.MailFrom, más nevén a visszapattanó vagy boríték-feladó cím) alapján értékelik — a megkapott From fejléc egyáltalán nem vesz részt magában az SPF-ellenőrzésben.
Ez az egy tény magyaráz meg legtöbb „SaaS SPF-hibát”. A marketing-platform a [email protected]-hoz hasonló Return-Path-tal küld; az SPF-et a vendor.com alapján ellenőrzik, és az tisztán átmegy. Majd a DMARC megkérdezi, hogy az SPF-ellenőrzött domain egyezik-e a From-domain névvel. Nem egyezik, tehát a DMARC SPF-lába megbukik, és az irányítópult azt mondja: „SPF meghibásodik”. A saját SPF-rekord szerkesztése nem javíthatja ezt — azt soha nem kérdezték le.
Mi a javítás sorrendje?
- Először futtassa az ingyenes vizsgálatot. Egyetlen menetben megmutatja, hogy az SPF hiányzik-e, duplikált-e, túllépi-e a keresési korlátot, illetve hol áll a DMARC — mielőtt a DNS-hez nyúlna.
- Keresse meg az eszköz tényleges Return-Path-ját. Küldjön magának egy tesztet az eszközből, és olvassa el a Return-Path fejlécet (és az Authentication-Results fejlécet) a nyers üzenetből. Ez megmutatja, hogy a fenti táblázat melyik sorában áll.
- Kapcsolja be a szállító egyéni domainű DKIM-jét. Minden komoly SaaS-eszköz kínál „domain-hitelesítést”: néhány CNAME rekordot, amelyek lehetővé teszik, hogy a domainje nevében DKIM-et írjon alá. Ez az aláírás igazodik a From-domainjéhez, tehát a DMARC DKIM-en keresztül megy át — tartósan, még ha a levelet továbbítják is.
- Csak akkor adja hozzá a szállító SPF include-ját, ha az az Ön return-path-ját használja — engedélyezte az egyéni visszapattanó domainjét, vagy az valóban a saját domainjével küldi a borítékot. Egy olyan szállítóhoz való include, amely a saját domainjén pattan vissza, semmit sem hoz, és felemészti a keresési költségvetést.
- Mentés előtt számolja meg a DNS-kereséseket. A korlát 10 feloldott keresés, az include-ok rekurzívan számítódnak, és 2,119,539 domain már 9–10-nél ül — a cenzusz 99. percentilise 9. A szélhez közel? Először távolítsa el a már nem használt eszközök include-jait. Nemrég váltott e-mail-szolgáltatót? Ellenőrizze, nincs-e felesleges második rekord — két SPF-rekord egyenlő a PermError-ral.
- Szkennelje újra és erősítse meg. SPF átment a megfelelő domainnel, DKIM igazított, DMARC átment. A teljes hivatkozás az SPF javítása oldalon található; a DNS-panel kattintásait a GoDaddy SPF-beállítás és az IONOS DMARC-beállítás útmutatók ismertetik.
Mit tegyen HubSpot, Salesforce, Mailchimp és SendGrid esetén?
HubSpot. Csatlakoztassa a küldő domainjét a HubSpot beállításaiban, és tegye közzé a két általa kiadott DKIM CNAME-et (hs1-… / hs2-…). Ez igazítja a DKIM-et a From-domainjéhez. HubSpot SPF include-ra nincs szüksége, hacsak nem konfigurálta a HubSpot-ot a saját visszapattanó domainjének használatára.
Salesforce. Hozzon létre DKIM-kulcsot a Salesforce Beállításokban, és tegye közzé az általa generált CNAME-párt. Ha a Salesforce a szervezet return-path-jával küld, adja hozzá az include:_spf.salesforce.com sort, és konfigurálja a visszapattanó domainjét — ez az egyetlen nagy CRM, ahol az SPF include-ra valóban szükség lehet.
Mailchimp. Hitelesítse a domainjét, és tegye közzé a k2 / k3 DKIM CNAME-eket. A Mailchimp igazítása kizárólag DKIM-alapú — nincs hozzáadandó SPF include-ja többé, és egy régi útmutatóból hozzáadva csak kereséseket pazarol.
SendGrid. Végezze el a domain hitelesítést („automatizált biztonság”): három CNAME, amely a DKIM-et és a return-path-t is kezeli a saját aldomainjén. Nincs szükség SPF include-ra. A 740,321 domain közül, amelynek SPF-je engedélyezi a sendgrid.net-et, csak 18.0% rendelkezik érvényesítő DMARC-cal (adatok: 2026-06-29) — a legtöbb SendGrid-küldő egy lépéssel leáll.
Zendesk és minden más: ugyanaz a minta. Keresse az eszköz „domain hitelesítés” oldalát, tegye közzé a DKIM CNAME-eket, és csak akkor nyúljon az SPF-hez, ha az eszköz dokumentálja, hogy a return-path-ját használja.
Különbözik-e az SPF az európai vállalkozások számára?
Nem — az SPF, DKIM és DMARC mindenhol azonosan működik. Ami Európában különbözik, az a kontextus: ki kérdez, és mit tett már meg a szomszédja.
A ccTLD meghatározza a helyi szintet. Az európai ccTLD-k az SPF-et a .com-nál magasabb arányban teszik közzé, de a munkát befejező domainek — egy végrehajtó DMARC-szabályzattal a tetején — mindenhol kisebbségben vannak:
| TLD | SPF-elfogadás (értékelt domainekből) | Végrehajtó DMARC (értékelt domainekből) |
|---|---|---|
| .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% |
Adatok: 2026-06-29. Franciaország: 13.65% érvényesítő DMARC; Olaszország: 5.24%.
Az európai tárhely alapértelmezése számít. 4,346,526 domain engedélyezi az IONOS EU-s levelezőszervereit (_spf-eu.ionos.com) az SPF-jében — és csak 0.3% végződik szigorú -all-lal, 1.0%-kal DMARC-végrehajtással. Az OVH 2,132,049 domainje jobban teljesít a szigorúságban (43.7%), de csak 2.2% érvényesíti a DMARC-ot (adatok: 2026-06-29). Ha soha nem nyúlt a rekordjához, ezeken az alapértelmezéseken áll.
A szabályozók most ezt nevesítik. A NIS2 21. cikk (2) bekezdés j) pontja kötelezi a hatálya alá tartozó szerveket a kommunikáció biztonságossá tételére, és a (EU) 2024/2690 Végrehajtási Rendelet részletezi az e-mail- és DNS-biztonsági intézkedéseket. Az e-mail hitelesítés a konkrét, ellenőrizhető rész — és szokatlan módon a megfelelés szempontjából ingyenesen javítható.
Az adatrezidenciáról: a Defaults.Exposed szkenner és cenzusz az AWS eu-west-1 régióban fut, csak összesített adatokat teszünk közzé, és egy vizsgálat csak a kért domaint ellenőrzi.
Gyakran ismételt kérdések
Az SPF-ellenőrzőm „átment”-et mond, de az eszköz irányítópultja szerint az SPF meghibásodik — miért? Az ellenőrző a rekordját tesztelte; a fogadó az eszköz által ténylegesen használt Return-Path domaint tesztelte, majd a DMARC összehasonlította a From-domainjével. Ez igazítási hiba, nem rekordhiba — a szállító egyéni domainű DKIM-jével javítható, nem SPF-szerkesztéssel.
Egyszerűen hozzáadjam az SPF include-ot minden általunk használt eszközhöz? Nem. Minden include az SPF 10-keresési költségvetésének egy részét emészti fel, rekurzívan: 2,119,539 az 138,927,207 SPF-közzétevő domainből 9–10 keresésénél ül, és legalább 797,263 már meghaladja — SPF-jük PermError-t ad vissza, és semmit nem véd (adatok: 2026-06-29).
Az include a DMARC-ot is javítja? Csak ha az eszköz az Ön return-path-jával küld, tehát az SPF átmegy és igazodik. A legtöbb SaaS-eszköznél nem — ezért az igazított DKIM, nem az SPF, az a láb, amelyen a SaaS-levelezés DMARC-on átmegy.
Ez jogi követelmény az EU-ban? A NIS2 hatálya alá tartozó szervek számára a 21. cikk (2) bekezdés j) pontja és a (EU) 2024/2690 Végrehajtási Rendelet az e-mail-biztonságot kötelezettséggé teszi. A hatályon kívüli szervek esetén is egyre inkább kérdeznek a biztosítók és az ügyfelek kérdőívei — és 2026-06-29 szerint egyetlen EU-s ccTLD sem éri el, hogy domaineinek harmada végrehajtó DMARC-szabályzathoz jusson (29.43% a .nl-nél a legjobb; 5.24% az .it-nél).
Küldje el a tulajdonosnak a jelentést
Amint a CNAME-ek élnek, futtassa újra a vizsgálatot, és továbbítsa az értékelt jelentést a cégtulajdonosnak vagy ügyfélnek. Egyszerű nyelven megmutatja, mi hibásodott meg, mit javított és hol áll most a domain — pontosan az a bizonyíték, amelyre a biztosítás megújításakor vagy az ügyfél biztonsági kérdőívénél szükség lesz, írásban, nem a szavára.
Ellenőrizze domainjét ingyen
Nézze meg pontosan, melyik SPF-, DKIM- és DMARC-szempont bukik meg — privát módon, csak a tulajdonos számára.
Ellenőrizze domainjét → · SPF javítása → · SPF PermError: „túl sok DNS-keresés” → · Hogyan osztályozunk → · Csak összesített adatok. Az adatok tárolása és feldolgozása az EU-ban történik.