Defaults.Exposed › Korjaukset › Guides

Edelleenlähetetty sähköposti epäonnistuu SPF:ssä — Miksi et voi korjata sitä, ja mikä todella toimii (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.

Et voi saada SPF:ää läpäisemään edelleenlähetetylle sähköpostille — edelleenlähetys rikkoo SPF:n rakenteellisesti, ja rehellinen korjaus on linjautunut DKIM, joka selviää edelleenlähetyksestä. Laajuus on koko väestölaskennan kattava: 7,355,985 138,927,207:sta SPF:ää julkaisevasta verkkotunnuksesta valtuuttaa pelkästään Namecheapin edelleenlähetyksen includin, tiukka-SPF-osuuden ollessa <0.1%, Defaults.Exposed-palvelun 261 miljoonan verkkotunnuksen väestölaskennan mukaan.

Alla: miksi mikään kirjoittamasi SPF-tietue ei selviä edelleenlähetyksestä, miksi SRS ja ARC eivät ole sinun hallittaviasi työkaluja, ja korjaus, joka pitää — DKIM-allekirjoitus omalla verkkotunnuksellasi DMARC-läpäisyksesi — sekä yksi tapaus, joka rikkoo myös DKIMin (viestejä kirjoittavat postituslistat) ja mitä tehdä tälle jäänteelle.

Miksi edelleenlähetys rikkoo SPF:n?

Vastaanottajat arvioivat SPF:n Return-Path (RFC5321.MailFrom) -verkkotunnusta vastaan, ei From-otsiketta. Kun lähetät suoraan, palvelimesi IP on SPF-tietueessasi ja tarkistus läpäisee. Kun vastaanottajasi automaattisesti välittää viestin eteenpäin — henkilökohtaiseen Gmailiin, yliopiston aliaksen kautta, rekisterin edelleenlähetystuotteen kautta — edelleenlähettäjän palvelin välittää sen uudelleen, yleensä pitäen verkkotunnuksesi Return-Path:ssa. Lopullinen vastaanottaja kysyy nyt: onko tämä edelleenlähettäjäpalvelin valtuutettu sinun SPF-tietueessasi?

Se ei ole, eikä koskaan tule olemaan: et valinnut edelleenlähettäjää, et tiedä sen olemassaolosta, ja sama viesti edelleenlähetettynä eri palvelun kautta huomenna epäonnistuisi eri IP:stä. SPF vastaa yhteen kysymykseen — “tuliko tämä IP palvelimelta, jonka Return-Path-verkkotunnus valtuutti?” — ja edelleenlähetetylle postille oikea vastaus on ei. Epäonnistuminen on SPF, joka toimii määritellyllä tavalla, ei tietueesi väärässä olevan.

Väestölaskenta näyttää, kuinka valtavirran polku tämä on: 7,355,985 verkkotunnusta valtuuttaa Namecheapin sähköpostin edelleenlähetyksen includin (spf.efwd.registrar-servers.com) — yhden tarjoajan edelleenlähetystuote, vedetty 139 miljoonasta SPF-julkaisijasta — tiukka-SPF-osuuden ollessa <0.1% ja vain 0.2%:n valvoessa DMARC:ia. Tuo pehmeä malli ei ole huolimattomuutta: edelleenlähetys on täsmälleen se missä tiukka -all laukaisee väärin, ja tarjoaja, jonka tuote on edelleenlähetys, toimittaa sen vastaavasti. Koko kvalifiointitarina on ~all vs -all -raportissamme, ja tarjoajakohtainen kuva mikä sähköpostipalveluntarjoaja antaa vahvimman SPF:n -oppaassa.

Enkö voisi vain lisätä edelleenlähettäjän palvelimen SPF-tietueeseen?

Ei — ja miksi ei, on koko artikkeli:

1. Et voi luetella edelleenlähettäjiä. Mikä tahansa vastaanottaja missä tahansa voi edelleenlähettää postisi minkä tahansa palvelun kautta. SPF-tietueesi tarvitsisi listata palvelimet, joista et voi tietää etukäteen.
2. Niiden listaaminen kumoaisi tarkoituksen. Suuret edelleenlähetyspalvelut välittävät postia miljoonille asiakkaille. Laita niiden alueet tietueeseen ja jokainen viesti, jonka kukaan heidän käyttäjistään välittää — mukaan lukien huijarin — läpäisee SPF sinuna.

Sama logiikka sulkee pois kvalifioinnin löysäämisen “edelleenlähetyksen toimintaan saattamiseksi”: kvalifioija ei ole se miksi edelleenlähetetty posti epäonnistuu, ja kun DMARC on pelissä, se muuttuu vähemmän kuin useimmat oppaat väittävät — katso kvalifioija-data. Tietue ei ole vipuvarsi tässä. Lopeta sen vetäminen.

Entä SRS ja ARC — eivätkö ne korjaa edelleenlähetystä?

Ne käsittelevät sitä — mutta kumpikaan ei ole sinun ottamasi käyttöön:

Tiedot ja mekanismin status 2026-06-29 mukaan.

SRS saa edelleenlähettäjän SPF-ongelman häviämään, ei sinun: Return-Path:n uudelleenkirjoittaminen muuttaa kenen SPF:ää tarkistetaan, kun taas From-otsikkeesi — verkkotunnus, jota DMARC puolustaa — on koskemattomana. ARC on luottamuspäätös infrastruktuurioperaattoreiden välillä. Jos opas käskee sinua “ottamaan SRS:n käyttöön” verkkotunnuksen omistajana, se on sekoittanut sinut edelleenlähetyspalveluntarjoajaan.

Miten saan sähköpostini selviämään edelleenlähetyksestä?

Tee DKIMista, linjautuneena verkkotunnuksellesi, DMARC-läpäisysi. DKIM-allekirjoitus on kryptografiaa, joka kulkee viestin otsakkeissa: se vahvistuu missä tahansa viesti päätyy, riippumatta kuinka monta palvelinta sen välitti, niin kauan kuin allekirjoitettu sisältö ei ole muuttunut. DMARC tarvitsee vain yhden linjautuneen läpäisyn — SPF tai DKIM — joten kun edelleenlähetys tappaa SPF-jalan, linjautunut DKIM pitää viestin todennettuna.

1. Aja ilmainen skannaus osoitteessa defaults.exposed ennen DNS:n koskemista. Se näyttää, onko sinulla DKIM lainkaan, allekirjoittaako se verkkotunnuksellasi ja missä DMARC seisoo — jotta korjaat todellisen aukon eikä taistele SPF-tietueesi kanssa.
2. Vahvista, että edelleenlähetys on todella ongelmasi. Authentication-Results-otsakkeessa asianomaisessa viestissä suora posti läpäisee SPF:n kun taas edelleenlähetetty kopio epäonnistuu edelleenlähetyspalvelun IP:stä. Jos SPF ja DKIM läpäisevät mutta DMARC epäonnistuu silti, sinulla on linjautumisongelma sen sijaan — katso DMARC epäonnistuu mutta SPF ja DKIM läpäisevät.
3. Kytke päälle DKIM-allekirjoitus omalla verkkotunnuksellasi kaikissa lähetyspalveluissa — postilaatikkopalveluntarjoaja ensin, sitten ESP:t ja transaktiolähettäjät. Tarjoajan oletukset allekirjoittavat usein tarjoajan verkkotunnuksella, joka ei linjaudu; haluat d=sinunverkkotunnuksesi. Aloita kohdasta miten korjata DKIM, klikkauspolut Google Workspacelle ja Microsoft 365:lle.
4. Varmista linjautuminen, ei vain läpäisy. Allekirjoituksessa olevan d=-verkkotunnuksen täytyy vastata From-verkkotunnustasi; dkim=pass jonkun toisen verkkotunnuksella ei tee mitään DMARC:ille.
5. Jätä SPF-tietueesi rauhaan. Pidä se tarkkana suoralle postillesi — se edelleen todentaa suurimman osan liikenteestäsi ja pysyy toisena DMARC-jalkanasi. Lopeta vain yritys saada se kattamaan edelleenlähetykset.
6. Skannaa uudelleen, sitten vaiheista DMARC-valvonta harkitusti — seuraava osio, ja p=none:sta p=reject -käyttöönotto-opas.

Tämä yhdistelmä — SPF plus valvova DMARC nojaten linjautuneeseen DKIMiin — on edelleenlähetyksensuojaava malli, ja se on harvinainen: 77.5 miljoonasta ~all:a julkaisevasta verkkotunnuksesta vain 9.2% (7,116,774) tukee sitä valvovalla DMARC-käytännöllä, ja vain 3.87% 261 miljoonasta arvioidusta verkkotunnuksesta (10,092,481) suorittaa täydellisen SPF + DKIM + valvottu-DMARC -triadon väestölaskennan mukaan (2026-06-29).

Entä postituslistat, jotka kirjoittavat viestejä uudelleen?

Yksi edelleenlähetyspolku, jota linjautunut DKIM ei selviä: postituslistat, jotka muokkaavat viestiä — [list-name]-aihetunniste, peruuttamisen alatunniste, poistettu liite. Muuta allekirjoitettua sisältöä ja runkotiiviste ei enää vastaa, joten myös DKIM epäonnistuu (dkim=fail: body hash did not verify on kyseisen epäonnistumisen oma oppaansa). Nyt molemmat DMARC-jalat ovat kuolleet, ja vain lista voi lieventää sitä (From-uudelleenkirjoitus, ARC-sinetöinti).

Tämä jäänne on täsmälleen sitä varten mitä vaiheistettu DMARC-valvonta on. Siirtyminen p=quarantine:in läpi pct-lisäyksellä samalla kun seuraat aggregoituja raportteja näyttää kuinka suuri osa todellisesta postistasi kulkee uudelleenkirjoittavien listojen kautta ennen kuin p=reject-käytäntö alkaa palautella sitä. Älä hyppää suoraan reject:iin verkkotunnuksella, jonka käyttäjät asuvat postituslistoilla; älä myöskään pysähdy p=none:een ikuisesti. Vaiheistettu käyttöönotto-opas kävelee lisäyksen läpi.

Usein kysytyt kysymykset

Rikkoo edelleenlähetys myös DKIMin? Pelkkä edelleenlähetys, ei: allekirjoitus matkaa viestin mukana ja vahvistuu lopullisella vastaanottajalla. DKIM hajoaa vain kun allekirjoitettu sisältö muutetaan siirrossa — postituslistojen aihetunnisteet ja alatunnisteet ovat klassinen tapaus — minkä vuoksi lista-jäänne käsitellään DMARC-käytännön vaiheistuksella, ei millään DNS:ssä.

Pitäisikö minun vaihtaa -all:ista ~all:iin jotta edelleenlähetys lakkaa epäonnistumasta? Kvalifikaation muuttaminen ei saa edelleenlähettäjiä läpäisemään — se ei ole syy miksi ne epäonnistuvat. On merkitsevää, että Namecheapin edelleenlähetyksen include, 7,355,985 verkkotunnusta ja väestölaskennan suurin omistettu edelleenlähettäjäpopulaatio (2026-06-29), toimitetaan tiukka-SPF-osuuden ollessa <0.1%: pehmeä SPF on kiistatta oikea malli edelleenlähetystuotteelle. Katso ~all vs -all -raportti siitä mitä kvalifioija oikeasti muuttaa.

Miksi postini läpäisee SPF suoraan lähetettäessä mutta epäonnistuu kun joku välittää sen? Vastaanottaja tarkistaa, onko viimeisimmän välittävän palvelimen IP valtuutettu Return-Path-verkkotunnuksesi SPF-tietueessa. Suoraan: palvelimesi, tietueessasi, läpäisy. Edelleenlähetettynä: edelleenlähettäjän palvelin, ei tietueessasi, epäonnistuminen. Tietueesi ei muuttunut — välittävä IP muuttui.

Voinko ottaa SRS:n käyttöön korjatakseni tämän? Vain jos olet edelleenlähettäjä. SRS pyörii palvelimella, joka tekee edelleenlähetyksen, ja jopa missä se pyörii, tuloksena oleva SPF-läpäisy kuuluu edelleenlähettäjän verkkotunnukselle eikä linjaudu From:si kanssa — DMARC:si tarvitsee edelleen DKIM-jalan.

Onko SPF turha jos edelleenlähetys rikkoo sen joka tapauksessa? Ei. Suurin osa postista toimitetaan suoraan, missä SPF toimii täsmälleen tarkoitetulla tavalla, ja se pysyy toisena DMARC-jalkana. 261,086,232 verkkotunnuksesta väestölaskennassa (2026-06-29), 138,927,207 julkaisee SPF — pidä omasi tarkkana SPF-korjaussivun kautta, ja anna DKIMin kantaa edelleenlähetetty jäänne.

Lähetä omistajalle raportti

Jos korjaat tätä asiakkaalle tai työnantajallesi, sulje silmukka todisteella. Kun oman verkkotunnuksen DKIM on käytössä ja DMARC on vaiheistettu, aja ilmainen skannaus uudelleen ja lähetä arvioitu raportti yrityksen omistajalle: päivätty, selkokielinen, näyttäen verkkotunnuksen pysyvän todennettuna jopa kun sen posti välitetään eteenpäin. Se on artefakti kyberturvallisuusvakuutuksen uusimiseen ja seuraavaan toimittajakyselyyn — dokumentoitu ennen-jälkeen, ei “laitoin jotain päälle”.

Tarkista verkkotunnuksesi → · DMARC epäonnistuu mutta SPF ja DKIM läpäisevät → · Korjaa DKIM → · Miten arvioimme → · Vain aggregoitua dataa. Tiedot tallennettu ja käsitelty EU:ssa.