Defaults.Exposed › Korjaukset › Guides

SPF epäonnistuu SaaS-työkaluillesi? Miksi se tapahtuu ja korjausjärjestys — Eurooppa-painos (2026)

Julkaistu 2026-07-08

Luvut päivätty 2026-06-29 · metodologia v7. Aggregoitu väestölaskentadata 261 miljoonan arvioidun verkkotunnuksen yli. Katso miten arvioimme.

Kun SaaS-työkalu “epäonnistuu SPF:ssä”, tietueesi ei yleensä ole ongelma: posti epäonnistuu DMARC-linjautumisessa, tai include-ketjusi on ylittänyt SPF:n 10 DNS-haun rajan. 2,119,539 138,927,207:sta SPF:ää julkaisevasta verkkotunnuksesta sijaitsee 9–10 haussa — yhden SaaS-includin päässä kliippireunan partaalta — Defaults.Exposed-palvelun 261,086,232 verkkotunnuksen väestölaskennan mukaan.

Alla: miten tunnistaa, kumman ongelman sinulla on, sitten korjausjärjestys — skannaa ensin, löydä verkkotunnus, josta työkalu todella lähettää, vaihda toimittaja oman verkkotunnuksen DKIMiin, ja lisää SPF include vain missä se todella auttaa — sekä erityispiirteet HubSpotille, Salesforcelle, Mailchimpille ja SendGridille.

Miksi SaaS-työkalun posti epäonnistuu SPF:ssä?

Kolme kaavaa kattaa lähes kaikki tapaukset:

Tiedot päivätty 2026-06-29.

Lihavoitu rivi on missä useimmat ihmiset seisovat. Lisäämällä include:-rivejä jokaiselle työkalulle ei korjata sitä — ja jokainen rivi siirtää sinua lähemmäksi toista riviä: vähintään 797,263 verkkotunnusta on jo ylittänyt 10 haun rajan, ja niiden SPF palauttaa nyt PermErrorin, joka ei suojaa mitään. Täydelliset luvut SPF PermError -raportissa.

Mitä verkkotunnusta SPF oikeasti tarkistaa?

Ei sitä From-otsikkeessasi olevaa. Vastaanottajat arvioivat SPF:n Return-Path-verkkotunnusta vastaan (RFC5321.MailFrom, kutsutaan myös palautus- tai kirjekuori-from-osoitteeksi) — From-otsikkeella, jonka vastaanottajasi näkee, ei ole osaa SPF-tarkistuksessa itsessään.

Tämä yksittäinen tosiasia selittää useimmat “SaaS SPF -epäonnistumiset”. Markkinointialustasi lähettää Return-Path:lla kuten [email protected]; SPF tarkistetaan vendor.com:ia vastaan ja läpäisee puhtaasti. Sitten DMARC kysyy, vastaako SPF:n tarkistama verkkotunnus From-verkkotunnustasi. Ei vastaa, joten DMARC:n SPF-jalka epäonnistuu ja hallintapaneelisi sanoo “SPF epäonnistuu”. Oman SPF-tietueesi muokkaaminen ei voi korjata sitä — tietuettasi ei koskaan kysytty.

Mikä on korjausjärjestys?

1. Aja ilmainen skannaus ensin. Se kertoo yhdellä kertaa, puuttuuko SPF, onko se kahtena, ylittääkö hakurajan vai onko hyvin, ja missä DMARC seisoo — ennen DNS:n koskemista.
2. Löydä Return-Path, jota työkalu todella käyttää. Lähetä itsellesi testi työkalusta ja lue Return-Path-otsake (ja Authentication-Results) raakaviesteistä. Se kertoo, missä rivi yllä olevassa taulukossa olet.
3. Kytke päälle toimittajan oman verkkotunnuksen DKIM. Jokainen vakava SaaS-työkalu tarjoaa “verkkotunnuksen todennuksen”: muutama CNAME-tietue, jonka avulla se voi DKIM-allekirjoittaa verkkotunnuksellasi. Kyseinen allekirjoitus linjautuu From-verkkotunnuksesi kanssa, joten DMARC läpäisee DKIMin kautta — kestävästi, jopa kun postiviestit välitetään edelleen. Tämä on korjaus, joka kestää.
4. Lisää toimittajan SPF include vain jos se käyttää return-path-osoitettasi — olet ottanut käyttöön sen mukautetun palautusosoiteverkkotunnuksen tai se todella lähettää verkkotunnuksellasi kirjekuoressa. Include toimittajalle, joka palauttelee omalla verkkotunnuksellaan, ei osta mitään ja kuluttaa hakubudjettisi.
5. Laske DNS-hakusi ennen tallentamista. Raja on 10 ratkaistua hakua, includit lasketaan rekursiivisesti, ja 2,119,539 verkkotunnusta on jo 9–10:ssä — väestölaskennan p99 on 9. Lähellä reunaa? Poista includet työkaluille, joita et enää käytä ensin. Vaihdoitko juuri sähköpostipalveluntarjoajaa? Tarkista jäänyttä toista tietuetta varten — kaksi SPF-tietuetta on PermError.
6. Skannaa uudelleen ja vahvista. SPF läpäisee oikealla verkkotunnuksella, DKIM linjautunut, DMARC läpäisee. Täydellinen viite löytyy kohdasta miten korjata SPF; tarjoajakohtaiset ohjeet kuten SPF GoDaddyllä ja DMARC IONOSilla kattavat DNS-paneelin klikkaukset.

Mitä pitäisi tehdä HubSpotille, Salesforcelle, Mailchimpille ja SendGridille?

HubSpot. Yhdistä lähettäjäverkkotunnuksesi HubSpotin asetuksissa ja julkaise kaksi DKIM-CNAMEa, jotka se antaa (hs1-… / hs2-…). Se linjaa DKIMin From-verkkotunnuksesi kanssa. Et tarvitse HubSpot SPF-includia, ellei olet konfiguroinut HubSpotia käyttämään omaa palautusosoiteverkkotunnustasi.

Salesforce. Luo DKIM-avain Salesforce Setupissa ja julkaise CNAME-pari, jonka se luo. Jos Salesforce lähettää organisaatiosi return-path-osoitteella, lisää include:_spf.salesforce.com ja konfiguroi palautusosoiteverkkotunnus — tämä on iso CRM, jossa SPF-include on usein todella tarpeen.

Mailchimp. Todenna verkkotunnuksesi ja julkaise k2- / k3-DKIM-CNAMEt. Mailchimp-linjautuminen on vain DKIM — SPF-includia ei enää lisätä, ja sellaisen lisääminen vanhasta opetusohjelmasta vain tuhlahtaa hakuja.

SendGrid. Suorita verkkotunnuksen todennus (“automated security”): kolme CNAMEa, jotka käsittelevät sekä DKIMin että return-path-osoitteen omalla aliverkkotunnuksellasi. SPF-includia ei tarvita. 740,321:stä verkkotunnuksesta, joiden SPF valtuuttaa sendgrid.net:n, vain 18.0%:lla on valvova DMARC (tiedot päivätty 2026-06-29) — useimmat SendGrid-lähettäjät pysähtyvät yhden askeleen lyhyemmäksi.

Zendesk ja kaikki muut: sama kaava. Löydä työkalun “verkkotunnuksen todennus” -sivu, julkaise sen DKIM-CNAMEt, ja koske SPF:ään vain jos työkalu dokumentoi käyttävänsä return-path-osoitettasi.

Onko SPF erilainen eurooppalaisille yrityksille?

Ei — SPF, DKIM ja DMARC toimivat samalla tavalla kaikkialla. Mikä Euroopassa eroaa on konteksti: kuka kysyy ja mitä naapurisi on jo tehnyt.

ccTLD:si asettaa paikallisen tason. Eurooppalaiset ccTLD:t julkaisevat SPF:ää hyvin yli .com-tason, mutta verkkotunnukset, jotka saattavat työn valmiiksi — valvova DMARC-käytäntö päälle — ovat vähemmistö kaikkialla:

Tiedot päivätty 2026-06-29. Ranska: 13.65% valvoo DMARC:ia; Italia: 5.24%.

Eurooppalaisella isäntäpalvelimellasi on oletuksen merkitys. 4,346,526 verkkotunnusta valtuuttaa IONOSin EU-postipalvelimet (_spf-eu.ionos.com) SPF:ssään — ja vain 0.3% päättyy tiukkaan -all:iin, 1.0%:lla on DMARC valvottuna. OVH:n 2,132,049 pärjää paremmin tiukkuudessa (43.7%) mutta vain 2.2% valvoo DMARC:ia (tiedot päivätty 2026-06-29). Jos et ole koskaan koskenut tietueeseen, seisot näillä oletuksilla.

Viranomaiset nimeävät tämän nyt. NIS2 artikla 21(2)(j) vaatii soveltamisalan yrityksiä turvaamaan viestintänsä, ja komission täytäntöönpanoasetus (EU) 2024/2690 täsmentää sähköposti- ja DNS-turvallisuustoimenpiteet. Sähköpostitodennus on konkreettinen, tarkistettava osa — ja, epätavallisesti vaatimustenmukaisuudelle, ilmainen korjata.

Tietojen sijainnista: Defaults.Exposed-skanneri ja väestölaskenta pyörivät AWS eu-west-1:ssä, julkaisemme vain aggregoituja lukuja, ja skannaus tarkistaa vain verkkotunnuksen, josta kysyt.

Usein kysytyt kysymykset

SPF-tarkistimeni sanoo “pass” mutta työkalun hallintapaneeli sanoo SPF epäonnistuu — miksi? Tarkistin testasi tietueesi; vastaanottaja testasi Return-Path-verkkotunnuksen, jota työkalu todella käytti, sitten DMARC vertasi sitä From-verkkotunnukseesi. Se on linjautumisvirhe, ei tietuevirhe — korjataan toimittajan oman verkkotunnuksen DKIMilla, ei SPF-muokkauksilla.

Pitäisikö minun vain lisätä SPF include jokaiselle käyttämällemme työkalulle? Ei. Jokainen include kuluttaa osan SPF:n 10 haun budjetista, rekursiivisesti: 2,119,539 138,927,207:sta SPF:ää julkaisevasta verkkotunnuksesta sijaitsee 9–10 haussa, ja vähintään 797,263 on ylittänyt — niiden SPF palauttaa PermErrorin eikä suojaa mitään (tiedot päivätty 2026-06-29).

Korjaako include myös DMARCin? Vain jos työkalu lähettää return-path-osoitteellasi, joten SPF läpäisee ja linjautuu. Useimmille SaaS-työkaluille ei — siksi linjautunut DKIM, ei SPF, on jalka, joka tekee DMARCista läpäisevän SaaS-postille.

Onko tämä lakisääteinen vaatimus EU:ssa? NIS2-soveltamisalassa oleville tahoille artikla 21(2)(j) ja täytäntöönpanoasetus (EU) 2024/2690 tekevät sähköpostiturvallisuudesta velvoitteen. Jopa soveltamisalan ulkopuolella, vakuuttajat ja asiakaskyselyt kysyvät tätä yhä enemmän — ja 2026-06-29 mukaan, yksikään EU:n ccTLD ei saa edes kolmasosaa verkkotunnuksistaan valvovaan DMARC-käytäntöön (29.43% .nl:ssä parhaimmillaan; 5.24% .it:ssä).

Lähetä omistajalle raportti

Kun CNAMEt ovat käytössä, aja skannaus uudelleen ja lähetä arvioitu raportti yrityksen omistajalle tai asiakkaalle. Se näyttää selkokielellä, mitä epäonnistui, mitä korjasit ja missä verkkotunnus nyt seisoo — täsmälleen todiste, jota he tarvitsevat vakuutusuusinnan tai asiakkaan turvallisuuskyselyn varalta, kirjallisena eikä vain sanassasi.

Tarkista verkkotunnuksesi ilmaiseksi

Katso tarkalleen mikä SPF-, DKIM- ja DMARC-jalka epäonnistuu — yksityisesti ja vain omistajalle.

Tarkista verkkotunnuksesi → · Korjaa SPF → · SPF PermError: “liian monta DNS-hakua” → · Miten arvioimme → · Vain aggregoitua dataa. Tiedot tallennettu ja käsitelty EU:ssa.