DMARC-tietueen tarkistus: näin luet lookup-tuloksen ennen kylmäpostituksen aloittamista
Uuden lähettävän domainin käyttöönotossa DMARC-tietueen tarkistus jää usein SPF:n ja DKIM:n varjoon, vaikka juuri se kertoo vastaanottavalle palvelimelle, kuinka tiukasti domainia valvotaan. Kun tavoite on kohdennettu B2B-kylmäpostitus muutamalle kymmenelle päättäjälle päivässä, väärin tulkittu dmarc lookup -tulos voi näkyä hiljaisena roskapostikansioon ohjautumisena ilman yhtään bounce-viestiä. Tämä artikkeli käy läpi, miten dmarc check tehdään käytännössä ja mitä tietueen kentät tarkoittavat.
- Dmarc record check kuuluu domainin lähetysvalmiuden tarkistuslistaan yhtä lailla kuin SPF ja DKIM
- Selaimessa toimiva dmarc lookup tool (esim. MXToolbox) riittää useimmille tiimeille — komentorivi on vaihtoehto teknisille käyttäjille
- Policy-arvo (p=) ratkaisee, mitä vastaanottava palvelin tekee, jos viesti epäonnistuu tarkistuksessa — none, quarantine tai reject
- Uudella domainilla kannattaa aloittaa p=none-tilasta ja siirtyä quarantineen vasta rua-raporttien perusteella
- Puuttuva DMARC-tietue ei estä viestin lähtöä, mutta heikentää mainetta erityisesti Gmail- ja Microsoft 365 -vastaanottajien silmissä
Miksi DMARC-tietueen tarkistus kuuluu domainin käyttöönottoon
Kun B2B-tiimi ottaa käyttöön uuden lähettävän domainin kylmäpostitusta varten, dmarc check kuuluu samaan listaan kuin SPF- ja DKIM-tietueiden julkaisu. Ilman sitä ei tiedetä, hyväksyykö vastaanottava palvelin viestit sellaisenaan vai hylkääkö se ne hiljaa roskapostikansioon — ja hiljainen hylkäys on kohdennetussa kylmäpostituksessa pahin skenaario, koska sitä ei näy missään raportissa.
Toisin kuin SPF ja DKIM, DMARC ei ole pakollinen tekninen edellytys viestin perillemenolle, mutta se on signaali siitä, että domainia aktiivisesti valvotaan eikä sitä käytetä huijausviesteihin. Gmail ja Microsoft 365, jotka muodostavat suurimman osan suomalaisesta B2B-kohderyhmästä, painottavat DMARC-linjausta yhä enemmän toimituspäätöksissä — myös silloin kun viestimäärä on pieni ja henkilökohtainen.
Miten teet dmarc lookupin käytännössä
Nopein tapa tehdä dmarc record check on komentorivillä: dig TXT _dmarc.yritys.fi +short tai Windowsissa nslookup -type=TXT _dmarc.yritys.fi. Tulos on yksi tekstirivi, joka alkaa merkinnällä v=DMARC1 ja sisältää joukon avain-arvo-pareja puolipisteillä eroteltuna.
Tiimeille, jotka eivät halua avata terminaalia, riittää selaimessa toimiva dmarc lookup tool. Esimerkiksi dmarc lookup mxtoolbox on yksi yleisimmin käytetyistä — kirjoitat domainin osoitekenttään, ja työkalu palauttaa tietueen jäsenneltynä sekä kertoo suoraan, jos tietue puuttuu tai on virheellisesti muotoiltu. Vastaava dmarc record checker löytyy myös dmarc.org-sivustolta ja useilta deliverability-työkaluilta.
- v=DMARC1 — protokollan versio, aina pakollinen ensimmäinen kenttä
- p= — policy: none (vain seuranta), quarantine (roskapostiin) tai reject (hylätään)
- rua= — osoite, johon koostetut aggregate-raportit lähetetään
- ruf= — osoite forensic-raporteille (harvoin käytössä, moni operaattori ei enää tue)
- pct= — kuinka suureen osaan viesteistä policy sovelletaan (oletus 100)
- adkim= / aspf= — tiukka (s) vai löysä (r) alignment-vaatimus DKIM:lle ja SPF:lle
Tyypillinen aloitusvaiheen tietue näyttää tältä: v=DMARC1; p=none; rua=mailto:dmarc@vaasatekniikka.fi; pct=100. Dmarc lookup domain -haku palauttaa tämän rivin sellaisenaan — p=none tarkoittaa, että viestejä ei vielä hylätä, mutta kaikki tarkistustulokset kootaan raporttiin osoitteeseen dmarc@vaasatekniikka.fi.
Mitä lookup-tulos kertoo domainin todellisesta tilasta
LDM:n onboarding-auditoinneissa tehdyt dmarc lookup -tarkistukset uusille B2B-lähettäjädomaineille näyttävät toistuvan kaavan: valtaosa domaineista löytää tietueen, mutta policy jää usein löysäksi tai raportointiosoite on jäänyt asettamatta kokonaan. Tämä ei ole virhe sinänsä — p=none on turvallinen aloituspiste — mutta se tarkoittaa, että kukaan ei vielä lue, mitä raportteja tulee.
Alla olevat luvut kuvaavat karkeasti, missä vaiheessa DMARC-elinkaarta uudet kohdennettuun B2B-postitukseen otetut domainit tyypillisesti ovat, kun tarkistus tehdään ensimmäistä kertaa.
Luvut ovat suuntaa-antavia ja perustuvat LDM:n käytäntöön uusien B2B-lähettäjädomainien onboarding-tarkistuksissa.
Yleisimmät virheet dmarc-tietueen tulkinnassa
Suurin osa DMARC-ongelmista ei liity itse tietueen syntaksiin vaan siihen, miten sen sisältöä tulkitaan tai jätetään tulkitsematta.
- Tietue julkaistaan mutta rua-raportteja ei koskaan lueta — dmarc lookup näyttää kunnossa olevan tietueen, vaikka mikään ei tosiasiassa muutu ajan myötä
- Policy hypätään suoraan reject-tilaan ilman none-vaihetta, jolloin legitiimit viestit (esim. follow-up-automaation kautta lähetetyt) voivat hylkääntyä alignment-virheen takia
- Alidomainia varten ei julkaista erillistä tietuetta, jolloin oletuksena käytetään juuridomainin policya (sp= puuttuu kokonaan)
- SPF- tai DKIM-alignment ei täsmää lähettävän palvelun kanssa, jolloin DMARC epäonnistuu vaikka SPF ja DKIM erikseen tarkistettuna ovat kunnossa
- Dmarc lookup tehdään vain kerran käyttöönotossa eikä enää sen jälkeen, vaikka lähetysinfrastruktuuri (esim. uusi ESP tai CRM-integraatio) muuttuu myöhemmin
Tarkistuslista ennen ensimmäistä kylmäpostituskampanjaa
LDM:ssä dmarc record check on osa jokaisen uuden lähettävän domainin käyttöönottoa, ennen kuin domainilta lähtee yhtään kylmäpostiviestiä. Käytännössä tarkistus tehdään sekä komentorivillä että selaintyökalulla, koska kahden lähteen vertailu paljastaa nopeasti, jos DNS-propagointi on vielä kesken.
- Aja dmarc lookup domain -haku ja varmista, että v=DMARC1-rivi löytyy _dmarc-aliverkkotunnuksesta
- Tarkista policy-arvo: uudella domainilla p=none on turvallinen lähtökohta ensimmäisten 2–4 viikon ajan
- Varmista, että rua= osoittaa toimivaan sähköpostilaatikkoon, jota joku oikeasti seuraa
- Vertaa tulosta kahdella eri dmarc lookup tool -palvelulla (esim. MXToolbox ja dmarc.org) DNS-propagoinnin varmistamiseksi
- Kirjaa tarkistuspäivä ylös ja toista dmarc check aina, kun lähetysinfrastruktuuriin tulee muutoksia
- Siirry quarantine- ja myöhemmin reject-tilaan vasta, kun rua-raportit eivät enää näytä alignment-virheitä
Usein kysytyt kysymykset
Mikä on nopein tapa tehdä dmarc lookup ilman komentoriviä?
Selaimessa toimiva dmarc lookup tool, kuten dmarc lookup mxtoolbox, riittää useimmille tiimeille. Kirjoitat domainin hakukenttään ja saat jäsennellyn tuloksen sekä ilmoituksen, jos tietue puuttuu tai on virheellinen.
Voiko viestejä lähettää, jos DMARC-tietuetta ei ole julkaistu?
Kyllä, DMARC ei ole tekninen pakko viestin lähtemiselle, mutta ilman sitä domain ei anna vastaanottajalle signaalia aktiivisesta valvonnasta. SPF ja DKIM voivat silti olla kunnossa, mutta erityisesti Gmail-vastaanottajat huomioivat DMARC:n puuttumisen mainearvioinnissa.
Mikä policy-arvo sopii uudelle B2B-lähettäjädomainille?
Aloita p=none, jotta näet raporttien kautta, mitkä lähetyskanavat läpäisevät SPF/DKIM-alignmentin, ilman että mikään viesti hylätään virheellisesti. Siirry quarantineen ja myöhemmin rejectiin vasta, kun raportit ovat puhtaita muutaman viikon ajan.
Miksi dmarc record check näyttää eri tuloksen eri työkaluilla?
Yleisin syy on kesken oleva DNS-propagointi tai eri työkalujen käyttämä eri DNS-resolveri. Jos tulokset eroavat, odota muutama tunti ja toista dmarc lookup useammalla palvelulla ennen johtopäätöksiä.
Tarvitseeko jokainen alidomain oman DMARC-tietueen?
Ei välttämättä, mutta jos haluat eri policyn esimerkiksi kylmäpostitukseen käytetylle alidomainille kuin pääverkkotunnukselle, se pitää määritellä erikseen sp=-kentällä tai omalla _dmarc-tietueella alidomainissa.
Miten LDM varmistaa DMARC:n kunnossaolon asiakkaan puolesta?
LDM tekee dmarc check -tarkistuksen jokaiselle uudelle lähettävälle domainille onboardingin yhteydessä, seuraa rua-raportteja ja neuvoo policy-tason nostossa vasta kun alignment on todistetusti kunnossa useamman viikon ajan.
Haluatko soveltaa tätä omaan outreach-toimintaasi?
Näytämme ennen töiden aloittamista, miten tämä toimii juuri sinun segmentissäsi ja tuotteessasi.
Keskustele kanssamme