Aloita ilmaiseksi

Miksi edelleenvälitetty posti ei läpäise DMARC-tarkistusta?

Kun viesti välitetään eteenpäin, sen lähettää edelleen palvelin, joka ei ole lähettäjän. SPF-tarkistus epäonnistuu silloin lähettäjän verkkotunnukselle, koska lähettäjän SPF-tietue ei mainitse sitä palvelinta. DKIM-allekirjoitus säilyy, jos edelleenvälittäjä jättää viestin ennalleen, ja posti läpäisee silti DMARC-tarkistuksen. Posti epäonnistuu, jos edelleenvälittäjä muuttaa viestiä, kuten moni postituslista tekee, tai jos lähettäjä ei ole allekirjoittanut sitä DKIM:llä oman verkkotunnuksensa nimissä. Korjata voi siis kaksi tahoa: lähettäjä allekirjoittamalla jokaisen viestinsä DKIM:llä ja edelleenvälittävän osoitteen ylläpitäjä jättämällä viestit muuttamatta.

Mitä edelleenvälitetylle viestille tapahtuu

Oletetaan, että lähetät laskun osoitteesta laskutus@example.com osoitteeseen info@asiakas.example, joka välittää kaiken edelleen Gmail-postilaatikkoon. Gmail saa viestin edelleenvälittävältä palvelimelta eikä sinun palvelimeltasi.

  • SPF tarkistaa, saako viestin toimittanut palvelin lähettää postia kuoren lähettäjän verkkotunnuksen eli palautusosoitteen nimissä. Edelleenvälittävä palvelin ei ole SPF-tietueessasi, joten SPF-tarkistus epäonnistuu. Jos edelleenvälittäjä vaihtaa kuoren lähettäjäksi oman verkkotunnuksensa, SPF menee läpi, mutta sen verkkotunnukselle eikä sinun. Siksi DMARC ei voi ottaa sitä huomioon.
  • DKIM on viestin sisällä oleva allekirjoitus, joten se kulkee viestin mukana. Allekirjoitus pysyy voimassa, kun allekirjoitetut osat saapuvat muuttumattomina. Google luettelee, mikä sen matkalla rikkoo: MIME-rajojen, aiherivin tai viestin rungon muuttaminen, viestin uudelleenkoodaus sekä allekirjoituksen kattamien otsakkeiden, kuten To, Cc, Date ja Message-ID, muuttaminen.

DMARC-tarkistus menee läpi, kun SPF tai DKIM menee läpi verkkotunnuksellesi. Edelleenvälityksen jälkeen siihen pystyy enää DKIM. Microsoft sanoo saman Microsoft 365:n omasta edelleenvälityksestä: se vaihtaa kuoren lähettäjän, ja DKIM säilyy, jos viestin runkoa ei muuteta.

Se, mitä epäonnistuneelle viestille tapahtuu, riippuu käytännöstäsi. Käytännöllä p=none mikään ei muutu. Käytännöillä p=quarantine ja p=reject edelleenvälitetty posti voi päätyä roskapostiin tai jäädä kokonaan perille menemättä. Mitä palautusviestin virhekoodi tarkoittaa? selittää palautusviestin koodit. Cloudflare kertoo saman oman edelleenvälityspalvelunsa ohjeissa: tiukat DMARC-käytännöt voivat estää edelleenvälitetyn postin perillemenon.

Jos lähetät postin itse

SPF-tietueeseesi et voi luetella jokaista palvelinta, joka saattaa välittää postisi eteenpäin. DKIM on se osa, johon voit vaikuttaa.

  • Allekirjoita jokaisen lähteen posti DKIM:llä omalla verkkotunnuksellasi. Jokaisen palvelun, joka lähettää postia verkkotunnuksesi nimissä, DKIM-allekirjoituksessa pitää olla sinun verkkotunnuksesi eikä palvelun oma: oma DKIM. Pelkän SPF:n varassa läpäisevä posti läpäisee DMARC-tarkistuksen vain siihen asti, kun joku välittää sen eteenpäin. Ohje DKIMin käyttöönotto lähettävässä palvelussa kertoo vaiheet.
  • Osa postituslistojen postista epäonnistuu joka tapauksessa. Lista, joka lisää viestiin alatunnisteen tai merkinnän aiheriville, rikkoo DKIM-allekirjoituksen, eikä sitä voi muuttaa sinun puolellasi. Postilaatikkopalvelu, joka tunnistaa listapostin, voi silti toimittaa sen perille ja kertoa siitä raportissaan.

Miltä se näyttää raporteissasi

DMARC-raportti näyttää edelleenvälitetyn postin kahdella tavalla. Jos DKIM säilyi, rivi läpäisee DMARC-tarkistuksen, vaikka SPF epäonnistui. Jos molemmat epäonnistuivat, postilaatikkopalvelu voi silti toimittaa viestin ja kirjata riville syyn:

<policy_evaluated>
  <disposition>none</disposition>
  <dkim>fail</dkim>
  <spf>fail</spf>
  <reason>
    <type>trusted_forwarder</type>
  </reason>
</policy_evaluated>

RFC 9990 nimeää kaksi tähän sopivaa syytä: trusted_forwarder, kun postilaatikkopalvelu tuntee edelleenvälittäjän, ja mailing_list. Vanhemman RFC 7489:n muotoisissa raporteissa voi lukea myös forwarded.

Mailmoni lukee nämä rivit puolestasi. Lähde, jonka DKIM menee läpi mutta SPF ei, saa lauseen, joka mainitsee edelleenvälityksen yhtenä syynä. Rivi, jolla on jokin näistä syistä, saa lauseen, jonka mukaan posti välitettiin edelleen tai tuli postituslistan kautta eikä sinun puolellasi ole korjattavaa. Sivulla Edelleenvälitetyt ja postituslistan viestit eivät läpäise DMARC-tarkistusta on jokainen lause. Edelleenvälitetyn postin ei myöskään tarvitse estää tiukempaa käytäntöä: valmiuden sääntö ottaa lähteen huomioon vasta, kun sen kautta kulkee riittävä osa postistasi.

Jos ylläpidät edelleenvälittävää osoitetta

Sellainen voi olla sinulla huomaamattasi: työosoite, joka välittää postin henkilökohtaiseen postilaatikkoon, sähköpostialias verkkotunnuksesi palveluntarjoajalla tai reitityspalvelu, kuten Cloudflare Email Routing. Välittämäsi posti tulee muiden verkkotunnuksista, ja niiden DMARC-käytännöt ratkaisevat, mitä sille tapahtuu. Googlen ohjeet sähköpostin edelleenvälittämisestä Gmailiin kertovat, mitä voit muuttaa:

  1. Jätä viesti sellaiseksi kuin se saapui. Ei alatunnistetta, ei merkintää aiheriville eikä uudelleenkoodausta. Silloin lähettäjän DKIM-allekirjoitus pysyy voimassa, ja juuri se vie edelleenvälitetyn postin DMARC-tarkistuksen läpi.
  2. Vaihda kuoren lähettäjäksi edelleenvälittävä verkkotunnuksesi ja lisää edelleenvälittävät palvelimesi sen SPF-tietueeseen. Näin toimii Sender Rewriting Scheme (SRS). Cloudflaren Email Routing tekee näin eikä muuta From-otsaketta. SPF menee silloin vastaanottajalla läpi, mutta sinun verkkotunnuksellesi eikä lähettäjän, joten DMARC nojaa yhä lähettäjän DKIM-allekirjoitukseen.
  3. Kerro, että viesti on välitetty edelleen, otsakkeella X-Forwarded-For: tai X-Forwarded-To:.
  4. Pysäytä roskaposti, ennen kuin välität sen. Google varoittaa, että jos vastaanottajat merkitsevät verkkotunnuksesi kautta välitettyjä viestejä roskapostiksi, myös verkkotunnuksesi tulevat viestit merkitään todennäköisemmin roskapostiksi.

Jotkin edelleenvälittäjät lisäävät viestiin myös ARC-otsakkeet (Authenticated Received Chain). Cloudflaren mukaan ARC:n avulla välissä olevat palvelimet, kuten edelleenvälittäjät, voivat liittää viestiin tiedon alkuperäisistä todentamistuloksista. Vastaanottava palvelu päättää, luottaako se niihin. Jos posti välitetään Microsoft 365:een, sen ylläpitäjä voi merkitä edelleenvälityspalvelun luotetuksi ARC-sinetöijäksi (trusted ARC sealer). Microsoft suosittelee sitä ensisijaiseksi tavaksi ottaa vastaan aitoa postia, joka ei läpäise DMARC-tarkistusta.

Mikään tästä ei pelasta postia, jota lähettäjä ei ole allekirjoittanut DKIM:llä oman verkkotunnuksensa nimissä. Sellainen posti epäonnistuu jokaisessa edelleenvälityksessä, ja vain lähettäjä voi korjata sen. Ohjaa lähettäjä tämän oppaan lähettäjän osaan.

Jos edelleenvälityspalvelusi ei anna muuttaa mitään näistä, lisää alkuperäinen postilaatikko sähköpostiohjelmaasi ja lue posti siellä edelleenvälittämisen sijaan. Postia, jota ei välitetä eteenpäin, ongelma ei koske.

Lähteet

Tarkistettu 27. lokakuuta 2026.

Julkaistu 27. lokakuuta 2026 · Tarkistettu 27. lokakuuta 2026

Katso oman verkkotunnuksesi tilanne