Moduuli 4 · 4.4
DMARC-käyttöönotto: arvosta p=none arvoon p=reject
Moduuli 4: Toimitettavuus: SPF, DKIM ja DMARC käytännössä · Lukuaika: 12 minuuttia
Oppimistavoite: Tämän oppitunnin jälkeen osaat selittää, miten kohdistus (alignment) toimii, suunnitella DMARC-käyttöönoton vaiheittain arvosta p=none arvoon p=reject, valita oikeat tagit (rua, sp, np, t) ja varautua tunnettuihin sudenkuoppiin uudelleenohjauksessa ja postituslistoilla.
Keskeiset käsitteet: DMARC (RFC 9989), Author Domain (Lähde-kentässä oleva domain), kohdistus (alignment), relaxed ja strict (adkim, aspf), organisaatiodomain, DNS tree walk, p=none, p=quarantine, p=reject, rua, sp, np, t=y (testitila), poistuneet tagit pct, rf, ri, postituslistat, From-kentän uudelleenkirjoitus, ARC
Mitä DMARC tarkalleen tarkistaa
DMARC vastaa yhteen kysymykseen jokaisen saapuvan viestin kohdalla: onko SPF tai DKIM onnistunut sellaisen domainin kohdalla, joka kuuluu Lähde-osoitteeseen? Lähde-osoitteessa olevaa domainia kutsutaan standardissa nimellä Author Domain. Tietueen perusteet löytyvät DNS-kurssin oppitunnilta 4.5. Toukokuussa 2026 julkaistiin uudistettu standardi: RFC 9989, sekä RFC 9990 koosteraporteille ja RFC 9991 virheraporteille. Vanhat tietueet, joissa on v=DMARC1, ovat edelleen voimassa.
Kohdistus käytännössä
"Kuuluu" tarkoittaa kohdistusta (alignment). Siinä on kaksi tasoa:
- relaxed (oletus): domaineilla on sama organisaatiodomain.
nieuws.example.comjaexample.comovat kohdistettuja;example.comjaexample.neteivät ole. - strict (
adkim=staiaspf=s): domainien on oltava täsmälleen samat.
SPF:n kohdalla DMARC vertaa Return-Path-kentän domainia Lähde-domainiin. DKIM:n kohdalla kelvollisen allekirjoituksen d=-domainia. Muutama esimerkki viestille, jossa on Lähde: info@example.com:
| SPF-tulos (Return-Path) | DKIM-tulos (d=) | DMARC |
|---|---|---|
pass domainille example.com | ei allekirjoitusta | pass (SPF kohdistettu) |
pass domainille bounce.mailer.example | pass domainille mailer.example | fail (molemmat onnistuvat, kumpikaan ei kohdistu) |
pass domainille bounce.mailer.example | pass domainille example.com | pass (DKIM kohdistettu) |
| fail (uudelleenohjattu) | pass domainille example.com | pass (DKIM säilyy) |
pass domainille bounce.example.com | ei mitään | pass relaxed-tilassa, fail kun aspf=s |
Jätä siis adkim ja aspf relaxed-tilaan, ellei sinulla ole hyvää syytä muuhun.
Mistä vastaanottaja tietää, mikä organisaatiodomain on? Ennen käytettiin Public Suffix Listia, luetteloa domaineista kuten .nl, .co.uk ja github.io. RFC 9989 korvaa tämän DNS tree walk -menetelmällä: vastaanottaja hakee _dmarc-tietueita domainilta ja sitä ylempää olevilta domaineilta. Tavalliselle käyttäjälle tämä ei muuta mitään; huomaat sen vain, jos työskentelet aladomainien tietueiden kanssa.
Käyttöönotto neljässä vaiheessa
Tavoite on p=reject: tällöin vastaanottajat hylkäävät viestit, jotka esiintyvät sinuna, ja tämä on paras suoja väärennettyjä laskuja ja nimissäsi tehtyä phishingiä vastaan. Mutta jos siirryt suoraan reject-tilaan tuntematta lähettäjiäsi, saatat pian hylätä omat laskusi. Siksi tämä järjestys (tämän kurssin suosittelema linja):
Vaihe 0: valmistelu
- Tee luettelo kaikista lähettäjistäsi (oppitunti 4.2).
- Varmista, että jokaisella lähettäjällä on SPF tai DKIM kohdistettuna; mieluiten DKIM, koska se säilyy uudelleenohjauksessa.
- Luo erillinen osoite raportteja varten, esimerkiksi
dmarc@example.com, tai käytä raportointipalvelua. Raportteja tulee pian useita päivässä.
Vaihe 1: mittaaminen arvolla p=none
_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"p=none ei tee mitään itse viestille. Vastaanottajat toimittavat kaiken kuten ennenkin, mutta lähettävät sinulle päivittäin koosteraportin (aggregate report), jossa näkyy jokainen domainisi nimissä lähettänyt palvelin ja se, onnistuivatko SPF, DKIM ja DMARC. Näin täytät myös Gmailin, Yahoon ja Microsoftin vähimmäisvaatimuksen joukkolähettäjille (oppitunti 5.3).
Pidä tämä voimassa vähintään kaksi neljä viikkoa, ja pidempään, jos käytät palveluita, jotka lähettävät vain silloin tällöin (vuosittainen muistutus, neljännesvuosittainen lasku). Lue raportit (oppitunti 4.5) ja korjaa jokainen oma lähde, joka epäonnistuu.
Vaihe 2: p=quarantine
_dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"Viestit, jotka eivät läpäise DMARC-tarkistusta, menevät vastaanottajalla roskapostikansioon. Jos unohdat silti jonkin lähteen, viesti ei katoa, mutta sen löytäminen on hankalaa. Jos haluat olla varovainen, lisää ensin t=y (testitila): vastaanottajat soveltavat silloin yhtä astetta lievempää käytäntöä (quarantine-tilassa siis none), mutta näet raporteista, mitä tapahtuisi. Tämä korvaa RFC 9989:ssä vanhan pct=-tagin.
Seuraa raportteja taas muutaman viikon ajan.
Vaihe 3: p=reject
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"Viestit, jotka eivät läpäise DMARC-tarkistusta, hylätään. Lähettäjä saa bouncen, esimerkiksi Microsoftilla koodilla 5.7.509 ja Gmaililla viittauksella DMARC-käytäntöön (moduuli 6). Seuraa raportteja edelleen: uusia palveluita tulee aina lisää.
Milloin voi edetä nopeammin?
Kulkeeko kaikki sähköpostisi yhden palveluntarjoajan kautta, joka hoitaa SPF:n ja DKIM:n puolestasi, eikä mitään muuta lähetetä domainisi nimissä? Silloin tiukan käytännön voi ottaa käyttöön heti. Tästä syystä jotkin hosting-yritykset asettavat oletuksena p=reject. Jos otat myöhemmin käyttöön uutiskirjepalvelun tai kirjanpito-ohjelman, aseta se väliaikaisesti takaisin tilaan p=none raportointiosoitteen kanssa, kunnes kyseinen palvelu toimii kunnolla.
Muut tagit
| Tagi | Mihin | Suositus |
|---|---|---|
rua=mailto:... | Osoite(et) koosteraportteja varten, pilkulla erotettuna | Täytä aina käyttöönoton aikana |
ruf=mailto:... | Osoite viestikohtaisia virheraportteja varten (RFC 9991) | Lähes kukaan vastaanottaja ei lähetä niitä, ja ne voivat sisältää henkilötietoja. Jätä yleensä pois |
sp= | Käytäntö olemassa oleville aladomaineille | Jätä pois (jolloin p= pätee), ellei aladomaineilla ole eri lähetyskäytäntöä |
np= | Käytäntö aladomaineille, jotka eivät ole olemassa | np=reject on hyvä lisäys heti kun pääkäytäntö on tiukka: silloin kukaan ei voi lähettää domainista factuur.example.com, jos sitä nimeä ei ole olemassa |
adkim=, aspf= | Strict vai relaxed | Pidä relaxed-tilassa |
t=y | Testitila: yksi aste lievempi | Kätevä siirryttäessä quarantine- tai reject-tilaan |
fo= | Milloin virheraportteja luodaan | Hyödyllinen vain yhdessä ruf:n kanssa |
pct=, rf=, ri= | Poistunut käytöstä RFC 9989:ssä | Älä käytä enää; uutta standardia noudattavat vastaanottajat ohittavat ne |
Raportointiosoite toisessa domainissa (esimerkiksi raportointipalvelussa) toimii vain, jos kyseinen domain antaa luvan tietueella kuten example.com._report._dmarc.rapportdienst.example. Palvelu hoitaa tämän yleensä itse (RFC 9990, luku 4).
Sudenkuopat
Postituslistat
Perinteinen postituslista lähettää viestisi edelleen kaikille jäsenille omalta palvelimeltaan, ja lisää usein otsikkoon tunnisteen [lijst] tai alatunnisteen. Tällöin SPF epäonnistuu (eri palvelin) ja DKIM epäonnistuu (viesti muuttunut). Kun käytössä on p=reject, vastaanottajat hylkäävät viestisi listalle. Moderni listaohjelmisto ratkaisee tämän kirjoittamalla Lähde-osoitteen uudelleen listan osoitteeksi ("Jan via Leden"), tai lähettämällä viestin muuttamattomana eteenpäin. Jos käytät listaa, joka ei tee näin, näet sen raporteissasi.
Uudelleenohjaus
Katso oppitunti 3.3: SPF rikkoutuu, DKIM yleensä säilyy. Vastaanottaja voi ARC:n avulla päättää luottaa tunnettuun uudelleenohjaajaan. Raporteissa tämän tunnistaa viestinä tuntemattomalta palvelimelta, jossa DKIM pass ja SPF fail; tämä ei ole syy lieventää käytäntöä.
Kaksi tietuetta tai kirjoitusvirhe
Kaksi DMARC-tietuetta domainissa _dmarc tekee käytännöstä mitättömän, samoin kirjoitusvirhe kohdassa p= (p=rejected ei ole olemassa). Tarkista jokaisen muutoksen jälkeen.
Käytännössä: miltä tämä näyttää paneelissa
WebOké-hosting-paketissa on oletuksena v=DMARC1;p=reject, ilman raportointiosoitetta. Tämä on turvallista, jos kaikki sähköpostisi kulkee näiden palvelimien kautta. Jos lähetät myös muiden palveluiden kautta, aseta se tilaan p=none rua-osoitteen kanssa ja käy vaiheet läpi. DirectAdminissa tämä tehdään kohdassa DNS Administration klikkaamalla kynäkuvaketta _dmarc-tietueen kohdalla (kentät Domain policy type ja Aggregate Email (RUA)); Oma WebOkéssa DMARC-apurin avulla DNS-välilehdellä. Muilla palveluntarjoajilla luot TXT-tietueen nimelle _dmarc ja kirjoitat tekstin itse; lopputulos on sama.
Yhteenveto
- DMARC onnistuu, kun SPF tai DKIM onnistuu sellaisen domainin kohdalla, joka on kohdistettu Lähde-domainin kanssa; relaxed-kohdistus hyväksyy aladomainit.
- Käyttöönotto: luettelo lähettäjistä,
p=nonejaruasekä raporttien lukeminen,p=quarantine(tarvittaessat=y:n kanssa), ja sittenp=reject. - Käytä
np=reject-tagia aladomaineille, joita ei ole olemassa, heti kun pääkäytäntö on tiukka.pct,rfjariovat poistuneet käytöstä. - Postituslistat ja uudelleenohjaus aiheuttavat odotettuja virheitä; DKIM ja ARC korjaavat osan niistä.
- Tasan yksi tietue domainissa
_dmarc, ilman kirjoitusvirheitä.
Tietovisa
Tehtävä
Tehtävä Z4.4: Verkkotunnuksesi DMARC:n tarkistaminen ja seuraavan vaiheen valinta. Syötä oma domainisi (tai internet.nl). Syötä löytämäsi DMARC-tietue, p=-arvo ja onko siinä rua-osoite. Valitse sitten, mikä käyttöönoton vaihe on mielestäsi seuraava askel, ja miksi. Ohjelma hakee tietueen suoraan, tarkistaa syntaksin RFC 9989:n mukaisesti (yksi tietue, kelvollinen p, tunnetut tagit, poistuneet tagit varoituksena) ja asettaa vastauksesi rinnalle.
Lue lisää
Näiden artikkelien vaiheet koskevat WebOkén paneeleita; muilla palveluntarjoajilla toiminta on vastaavaa.
- Ilmainen DNS-kurssi 4.5: DMARC: mitä vastaanottajien pitäisi tehdä huijausviesteille
- DirectAdmin-ohje 5.9: DMARC-tietueen määrittäminen
- Mitä on DMARC? Selitys selkeällä kielellä
- DMARC-tietue luominen DirectAdminissa
- RFC 9989 (DMARC), erityisesti kohta 4.7 (tagit) ja liite C (muutokset RFC 7489:stä)