Defaults.Exposed › Korjaukset › Guides

DMARC epäonnistuu, mutta SPF ja DKIM läpäisevät? Kohdistumiskorjaus (2026)

Julkaistu 2026-07-08

Luvut 2026-06-29 alkaen · metodologia v7. Koottu väestönlaskentatiedot 261 miljoonan arvioidun verkkotunnuksen yli. Katso kuinka arvioimme.

DMARC tarvitsee enemmän kuin läpäisyn — sen verkkotunnuksen, joka läpäisi SPF:n tai DKIM:n, täytyy vastata From-verkkotunnustasi. Useimmat “SPF läpäisee, DMARC epäonnistuu” -postit läpäisivät SPF:n toimittajan palautusosoiteverkkotunnuksella, ei sinun. Vain 7.4% 261,086,232:sta arvioidusta verkkotunnuksesta läpäisee SPF:n kohdistettuna valvovan DMARC-käytännön alla Defaults.Exposed-väestönlaskennan mukaan (2026-06-29).

Korjaus on nopeampi kuin hämmennys antaa ymmärtää. Lue Authentication-Results-otsikko nähdäksesi, kumpi jalka — SPF vai DKIM — läpäisee väärällä verkkotunnuksella; sitten joko ota käyttöön lähetyspalvelusi mukautetun verkkotunnuksen DKIM-allekirjoittaminen (yleensä muutama CNAME, ja korjaus, joka selviää edelleenlähetyksestä) tai aseta sen mukautettu paluupolku, jotta SPF läpäisee verkkotunnuksellasi. Yksi kohdistunut jalka on kaikki mitä DMARC tarvitsee.

Miten DMARC voi epäonnistua, kun sekä SPF että DKIM läpäisevät?

Koska DMARC ei koskaan kysy “läpäisikö SPF?” Se kysyy: läpäisikö SPF tai DKIM verkkotunnuksella, joka vastaa vastaanottajien näkemää From-osoitetta? Tätä lisäehtoa kutsutaan kohdistumiseksi, ja se on DMARC:n koko tarkoitus — ilman sitä kuka tahansa voisi läpäistä SPF:n omistamallaan verkkotunnuksella näyttäen sinun From-otsikkosi.

Jokainen tarkistus todentaa eri verkkotunnuksen:

Näin osat menevät yleensä pieleen: uutiskirjealustasi tai CRM:si lähettää Return-Path-kentässä kuten [email protected], SPF tarkistetaan vendor.com:a vasten ja läpäisee, DKIM läpäisee d=vendor.com:lla — ja DMARC epäonnistuu, koska kumpikaan läpäisevä verkkotunnus ei vastaa yourcompany.com:ia. Jokainen tarkistus kertoi totuuden; yksikään ei todentanut sinua. Oman SPF-tietueesi muokkaaminen ei voi korjata tätä — sitä ei koskaan kysytty. Se on sama ansa, joka käsitellään kohdassa SPF epäonnistuu SaaS-työkalujesi kanssa.

Väestönlaskenta näyttää kuinka harvat lähettäjät suorittavat tämän viimeisen vaiheen: 27,640,987 261,086,232:sta arvioidusta verkkotunnuksesta (10.59%) omistaa ylipäätään valvovan DMARC-käytännön, ja vain 7.4% läpäisee SPF:n kohdistettuna sellaisen alla. 77.5 miljoonan verkkotunnuksen joukosta, joiden SPF päättyy softfail-tilaan (~all), vain 9.2% on valvovan DMARC-käytännön alla; hardfail (-all) julkaisijoista 12,142,351 on valvottuja, kun taas 42,514,532 ei ole. Useimmat verkkotunnukset pysähtyvät “SPF läpäisee” -tilaan — mikä ilman DMARC:n toimintaa ei suojaa juuri mitään.

Miten luen Authentication-Results-kentän nähdäkseni, kumpi jalka on kohdistumaton?

Lähetä itsellesi viesti epäonnistuvan palvelun kautta, avaa raaka lähde ja etsi Authentication-Results-otsikko. Tyypillinen kohdistumaton tulos näyttää tältä:

Authentication-Results: mx.google.com;
       spf=pass smtp.mailfrom=bounces.espmail.net;
       dkim=pass header.d=espmail.net;
       dmarc=fail (p=NONE) header.from=yourcompany.com

Lue se kolmena vertailuna:

• SPF-jalka: päättyykö smtp.mailfrom= verkkotunnukseesi? Tässä se on bounces.espmail.net — kohdistumaton.
• DKIM-jalka: päättyykö header.d= verkkotunnukseesi? Tässä se on espmail.net — kohdistumaton.
• DMARC-tuomio: header.from= on verkkotunnus, jota DMARC puolustaa. Kumpikaan jalka ei vastannut sitä, joten dmarc=fail — vaikka molemmat yksittäiset tarkistukset sanovat pass.

Kumpi jalka jo liittyy omaan verkkotunnukseesi (tai voidaan saada) on se, jonka voit korjata. Tarvitset vain yhden.

Mikä on ero relaxed- ja strict-kohdistumisen välillä?

DMARC tarjoaa kaksi vastaavuustilaa, asetettu DMARC-tietueesi aspf (SPF) ja adkim (DKIM) -tunnisteilla:

• Relaxed (r, oletus): kahden verkkotunnuksen täytyy jakaa sama organisaatioverkkotunnus — rekisteröitävä verkkotunnus julkisen suffiksilistan mukaan. bounce.yourcompany.com kohdistuu yourcompany.com:iin; niin myös DKIM d=mail.yourcompany.com. Siksi toimittajan mukautetut paluupolut ja mukautettu DKIM, jotka sijaitsevat aliverkkotunnuksissa, toimivat.
• Strict (s): verkkotunnusten täytyy täsmätä täsmälleen, merkki merkiltä. bounce.yourcompany.com ei enää kohdistu yourcompany.com:iin.

Jos tietueesi ei mainitse aspf:ää tai adkim:ia, olet relaxed-tilassa — ja todennäköisesti haluat pysyä siinä. Strict-tila ei lisää merkittävää turvallisuutta useimmille lähettäjille ja rikkoo hiljaa jokaisen laillisen aliverkkotunnuslähettäjäsi, jonka olet asettanut. Jos DMARC epäonnistuu ja tietueessasi on aspf=s tai adkim=s, se yksin voi olla virhe.

Miten korjaan DMARC-kohdistumisen?

1. Aja ilmainen tarkistus osoitteessa defaults.exposed ennen kuin kosket DNS:ään. Se näyttää DMARC-tietueesi ja käytäntösi, onko SPF:si ja DKIM:si asetettu kohdistumaan, ja mitä muuta on rikki — jotta korjaat oikean jalan ensin.
2. Testaa jokaista lähetyspalvelua ja lue sen Authentication-Results (kuten yllä). Listaa jokainen lähde — postilaatikkopalveluntarjoaja, uutiskirjetyökalu, CRM, laskutussovellus — ja merkitse per lähde, onko smtp.mailfrom ja header.d verkkotunnuksesi vai toimittajan.
3. Ota käyttöön mukautetun verkkotunnuksen DKIM-allekirjoittaminen jokaiselle toimittajalle — korjaus, joka kestää. Jokainen vakava lähetyspalvelu tarjoaa “verkkotunnuksen todennuksen”: muutaman CNAME-tietueen, jonka avulla se voi allekirjoittaa d=yourcompany.com:na (tai aliverkkotunnuksella, joka kohdistuu relaxed-tilassa). Kohdistunut DKIM on yleensä helpompi korjaus ja ainoa, joka selviää edelleenlähetyksestä, koska edelleenlähetys rikkoo SPF:n suunnitelmallisesti.
4. SPF-kohdistumiselle ota käyttöön toimittajan mukautettu paluupolku (kutsutaan usein mukautetuksi palautusosoitteeksi) — tyypillisesti yksi CNAME kuten bounce.yourcompany.com osoittamassa toimittajaan. SPF läpäisee sitten organisaatioverkkotunnuksellasi ja kohdistuu. Tee tämä missä tarjotaan, mutta käsittele sitä toisena jalkana, ei korvikkeena kohdistuneelle DKIM:lle.
5. Jätä kohdistuminen relaxed-tilaan, ellei sinulla ole erityistä, ymmärrettyä syytä aspf=s/adkim=s-asetuksille.
6. Aja tarkistus uudelleen ja vahvista molemmat jalat, sitten siirry valvontaan. p=none-DMARC-käytäntö raportoi mutta ei estä mitään; kun todelliset lähettäjäsi kohdistuvat, täydellinen polku suojaavaan käytäntöön on korjaa DMARC -sivulla, ja palveluntarjoajan läpikäynnit kuten DMARC IONOSissa kattavat DNS-paneelin klikkaukset.

Pitäisikö korjata SPF-kohdistuminen vai DKIM-kohdistuminen?

Tarvitset yhden kohdistuneista jalkoista per lähetyslähtde. Jos voit tehdä vain yhden, valinta ei ole lähellekään tasainen:

Erityistapaus, joka on hyvä tietää: Google Workspace ja Microsoft 365 DKIM-allekirjoittavat postisi oletuksena omien varatunnisteidensa kanssa (gappssmtp.com, onmicrosoft.com) — joten DKIM näyttää pass, kun DMARC silti epäonnistuu. Se on tämän koko ongelman yleisin yksittäinen instanssi, ja sillä on oma oppaansa: DKIM läpäisee, mutta DMARC epäonnistuu silti: oletusallekirjoituksen ansa.

Usein kysytyt kysymykset

Täytyykö molempien — SPF:n ja DKIM:n — kohdistua, jotta DMARC läpäisisi? Ei — yksi kohdistunut läpäisy riittää. Paras käytäntö on kohdistaa molemmat kuitenkin, jotta kun edelleenlähetys rikkoo SPF-jalan, DKIM-jalka kantaa silti DMARC-läpäisyn. 261,086,232:sta verkkotunnuksesta arvioidussa 2026-06-29 väestönlaskennassa vain 3.87% täydentää täydellisen SPF + DMARC + DKIM -kolmikon.

ESP-kojelautani sanoo SPF:n ja DKIM:n olevan “varmennettu” — miksi DMARC epäonnistuu silti? “Varmennettu” tarkoittaa yleensä, että toimittajan oma lähettäminen läpäisee toimittajan verkkotunnuksilla. Ellet suorittanut heidän mukautetun verkkotunnuksen vaiheitaan (DKIM CNAME:t, mukautettu paluupolku), posti todentautuu toimittajana, ei sinuna — ja DMARC vertailee From-verkkotunnuksesi kanssa.

Onko tiukka -all SPF-tietue tarpeeksi ilman kohdistumista? Ei. Tiukka kvalifioija vahvistaa SPF:n tuomion Return-Path-verkkotunnuksella, mutta DMARC tarvitsee silti sen verkkotunnuksen olevan sinun. 2026-06-29 väestönlaskennan mukaan vain 12,142,351 -all:ia julkaisevista verkkotunnuksista on valvovan DMARC-käytännön alla — muut 42,514,532 omistaa tiukan tietueen, jolla käytäntö ei toimi.

Pitäisikö minun siirtyä tiukkaan kohdistumiseen (aspf=s/adkim=s) turvallisuuden parantamiseksi? Lähes ei koskaan. Relaxed-kohdistuminen vaatii jo saman rekisteröitävän verkkotunnuksen, jota huijaaja ei hallitse. Strict-tila rikkoo lähinnä omat aliverkkotunnuslähettäjäsi — tarkista se aina kun kohdistuminen epäonnistuu odottamattomasti.

DMARC epäonnistuu vain postissa, jonka vastaanottajat edelleenlähettävät — sama korjaus? Se on SPF-jalka, joka kuolee siirron aikana: edelleenlähetyspalvelin ei ole kenenkään SPF-tietueessa paluupolkusi osalta. Et voi korjata SPF:ää edelleenlähetetylle postille; kohdistunut DKIM on vastaus, koska allekirjoitus selviää edelleenlähetyksestä ehjänä. Yksityiskohdat kohdassa edelleenlähetetty sähköposti epäonnistuu SPF:ssä.

Lähetä omistajalle raportti

Jos korjaat tätä asiakkaan tai työnantajasi puolesta, sulje silmukka todisteella. Aja ilmainen tarkistus uudelleen, kun CNAME:t on otettu käyttöön, ja välitä arvioitu raportti liike-elämän omistajalle: päivätty, selkokielinen, näyttäen SPF:n, DKIM:n ja DMARC:n kohdistuneena ja läpäisevänä. Se on artefakti, jota he tarvitsevat kyberturvallisuusvakuutuksen uusinnassa ja seuraavassa toimittajan turvallisuuskyselyssä — todiste toimivasta konfiguraatiosta, ei vain “lisäsin joitain DNS-tietueita”.

Tarkista verkkotunnuksesi → · DKIM läpäisee, mutta DMARC epäonnistuu silti → · Korjaa DMARC → · Kuinka arvioimme → · Vain koottua tietoa. Tiedot tallennetaan ja käsitellään EU:ssa.