SPF käytännössä: kaikki lähettäjät kartalle

Moduuli 4: Toimitettavuus: SPF, DKIM ja DMARC käytännössä · Lukuaika: 12 minuuttia

Oppimistavoite: Tämän oppitunnin jälkeen osaat etsiä kaikki palvelut, jotka lähettävät sähköpostia domainisi puolesta, koota ne yhteen SPF-tietueeseen, laskea DNS-haut rekursiivisesti kymmenen rajaan asti, ja valita tietoisesti ~all:n ja -all:n väliltä.

Keskeiset käsitteet: lähettäjien inventaario, envelope sender (Return-Path), yksi SPF-tietue, include, redirect, 10 DNS-haun raja (RFC 7208 kappale 4.6.4), tyhjät haut (void lookups, enintään 2), rekursiivinen laskenta, permerror, flattening, SPF aladomaineille, SPF domainilla joka ei lähetä postia, ~all ja -all

Kertausta

SPF-tietue on domainisi TXT-tietue, joka alkaa merkeillä v=spf1 ja luettelee, mitkä palvelimet saavat lähettää sähköpostia domainisi puolesta. Rakenne, merkit + - ~ ? ja kolme yleisintä virhettä (kaksi tietuetta, +all, yli kymmenen hakua) käydään läpi DNS-kurssin oppitunnilla 4.3. Lue se ensin, jos SPF on sinulle uusi asia. Tämä oppitunti käsittelee vaikeinta osaa: käytännössä lähes kukaan ei tiedä tarkalleen, ketkä kaikki lähettävät sähköpostia hänen domaininsa puolesta.

Vaihe 1: inventaario

SPF toimii vain, jos kaikki lähettäjät ovat siinä mukana. Jos unohdat yhden, sen sähköposti päätyy roskapostiin tai hylätään heti kun tiukennat DMARC:ia. Käy siis tämä lista läpi. Keskikokoisessa pienyrityksessä niitä löytyy nopeasti viisi tai kuusi:

Kaksi hyvää tapaa löytää ne:

1. Lue otsikkorivit. Lähetä jokaisesta järjestelmästä sähköposti itsellesi (lasku, salasanan palautus, testiuutiskirje) ja katso otsikkorivien Return-Path ja Authentication-Results (oppitunti 1.5). Niistä näet, minkä domainin ja palvelimen kautta viesti tuli.
2. DMARC-raportit. Aseta DMARC tilaan p=none raportointiosoitteella (oppitunti 4.4). Muutaman viikon kuluttua näet raporteista (oppitunti 4.5) jokaisen palvelimen, joka lähetti postia domainisi puolesta, myös ne jotka olit unohtanut. Se on luotettavin tapa tehdä inventaario.

Kaikki palvelut eivät kuulu SPF:ääsi

Tässä kohtaa menee usein pieleen. SPF tarkistaa envelope senderin (Return-Pathin), ei Lähettäjä-kenttää. Monet uutiskirje- ja lähetyspalvelut lähettävät omalla domainillaan olevalla Return-Pathilla, esimerkiksi bounce-123@mail.mailer.example. Vastaanottaja tarkistaa silloin domainin mailer.example SPF-tietueen, ei sinun tietuettasi. Palvelun include omassa tietueessasi ei silloin tee mitään, paitsi kuluttaa yhden haun.

Mitä palvelu tarvitsee läpäistäkseen DMARC:in, on DKIM-allekirjoitus sinun domainillasi (oppitunti 4.3), tai oma Return-Path-aladomain sinulta (esimerkiksi bounce.example.com CNAME-tietueena palveluun). Lue siis palvelun ohjeesta, mitä se vaatii. Jos ohje sanoo "lisää include: SPF-tietueeseesi", tee niin. Jos se sanoo vain "luo nämä CNAME-tietueet DKIM:ia ja bounce-domainia varten", pääSPF-tietueeseesi ei tarvitse lisätä mitään. Moduuli 7 käsittelee tätä tarkemmin.

Vaihe 2: yksi tietue, ja oikea laskenta

Kaikki lähettäjät kuuluvat yhteen tietueeseen. Oletetaan, että inventaariosi tuottaa seuraavan listan: hosting-yrityksesi sähköpostipalvelin, Microsoft 365 muutamalle työntekijälle, kirjanpito-ohjelmasi ja helpdesk. Tietue voisi näyttää tältä:

example.com.  3600  IN  TXT  "v=spf1 a mx include:spf.hosting.example include:spf.protection.outlook.com include:_spf.boekhoud.example include:mail.helpdesk.example ~all"

Kuinka monta hakua tämä on? Laske jokainen a, mx, include, exists, ptr ja redirect, ja laske sen jälkeen myös kaikki, mitä löytyy jokaisen includen takaa löytyvistä tietueista:

Yhdellätoista vastaanottaja antaa permerror-virheen: koko SPF-tietue ei silloin päde, ei yhdellekään lähettäjälle. Oman sähköpostipalvelimesi posti arvioidaan siis huonommin, koska helpdesk kuluttaa kolme hakua. Ja kavalaa on, että tietueesi voi olla tänään 9 ja huomenna 11, vaikka et itse muuta mitään, koska jokin palvelu laajentaa omaa tietuettaan.

Lisäksi: enintään kaksi tyhjää hakua

RFC 7208 mainitsee myös void lookupit: haut, jotka eivät tuota mitään (nimeä ei ole olemassa, tai siltä puuttuu SPF- tai osoitetietue). Yli kaksi tällaista hakua johtaa myös permerror-virheeseen. Tämä tapahtuu etenkin vanhojen include-merkintöjen kanssa, jotka viittaavat palveluihin joita et enää käytä ja jotka ovat poistaneet oman tietueensa, tai a:-merkinnän kanssa, joka osoittaa palvelimeen jota ei enää ole. Siis siivoamaan.

Vaihe 3: takaisin kymmenen alle

Jos olet yli kymmenen, ratkaisuja on neljä, parhaasta huonoimpaan:

1. Poista tarpeeton. Palvelut joita et enää käytä. Palvelut jotka lähettävät omalla Return-Pathillaan (katso yllä) ja jotka siis eivät kuulu SPF:ääsi. a, jos verkkosivustosi itse ei lähetä postia. mx, jos MX osoittaa palveluun joka on jo mukana tietueessasi include-merkinnällä.
2. Käytä aladomainia. Anna palvelun lähettää osoitteesta nieuws.example.com tai factuur.example.com. Tämä aladomain saa oman SPF-tietueensa vain tätä palvelua varten, eikä se lasketa mukaan päädomainisi kymmeneen. Kohdistus DMARC:issa (oppitunti 4.4) toimii oletuksena myös aladomaineille.
3. Käytä ip4:- ja ip6:-merkintöjä omille kiinteille palvelimillesi. Ne eivät kuluta hakua. Tee näin vain osoitteille joita itse hallinnoit ja jotka eivät muutu.
4. Flattening (kaikkien includejen korvaaminen niiden tällä hetkellä sisältämillä IP-osoitteilla). Tämä tiputtaa luvun nollaan, mutta tietue ei enää pidä paikkaansa heti kun palvelu muuttaa osoitteitaan, ja isot palvelut tekevät sitä säännöllisesti. Tee näin vain työkalulla, joka pitää tiedot ajan tasalla automaattisesti, ja mieluummin ei ollenkaan.

redirect vai include?

redirect= tarkoittaa: käytä toisen domainin SPF-tietuetta tämän tietueen sijaan. Se kuluttaa yhden haun, aivan kuten include. Se on käytännöllinen, jos sinulla on monta domainia joilla pitää olla täsmälleen sama käytäntö: v=spf1 redirect=_spf.example.com jokaisella domainilla, ja varsinainen tietue yhdessä paikassa. Tietueessa, jossa on redirect=, ei saa olla all-merkintää, koska silloin redirect jätetään huomiotta. Gmail käyttää tätä itse: gmail.com:lla on v=spf1 redirect=_spf.google.com.

Vaihe 4: ~all vai -all?

Tämän kurssin suositus, sama kuin DNS-kurssissa:

• Aloita ~all:lla (softfail). Sähköposti palvelimelta, jota ei ole tietueessasi, luokitellaan epäilyttäväksi, mutta sitä ei yleensä hylätä heti. Jos unohdat lähettäjän, vahinko jää rajalliseksi.
• Siirry -all:iin (fail), kun olet varma, että kaikki lähettäjät ovat mukana, esimerkiksi tarkasteltuasi DMARC-raportteja muutaman viikon ajan ja todettuasi, ettei tuntemattomia lähteitä enää löydy.

DMARC:in kanssa ero on pienempi kuin usein luullaan. DMARC päättää sen perusteella, onko "SPF tai DKIM onnistunut ja kohdistunut". Softfail on DMARC:in kannalta yksinkertaisesti "ei onnistunut". Todellinen suoja tulee siis tiukasta DMARC-käytännöstä, ei -all:sta. Jotkin vastaanottajat hylkäävät viestin jo -all:n perusteella ennen DMARC-arviointia; tämä on syy valita -all vasta kun tietueesi on todella täydellinen.

Domain joka ei koskaan lähetä postia

Onko sinulla domaineja, jotka eivät koskaan lähetä sähköpostia (vanha tuotemerkki, kirjoitusvirhedomain)? Suojaa ne väärinkäytöltä näin:

example.org.         IN  TXT  "v=spf1 -all"
_dmarc.example.org.  IN  TXT  "v=DMARC1; p=reject"
example.org.         IN  MX   0 .

Tässä -all on heti oikea valinta: kukaan ei saa lähettää postia. Viimeinen rivi on null MX (RFC 7505): "tämä domain ei vastaanota sähköpostia". example.com itse on asetettu täsmälleen näin.

Käytännössä: miltä se näyttää paneelissa

WebOkén hosting-paketissa on oletuksena v=spf1 a mx include:webawere.nl ~all. Kun lisäät palvelun, muokkaat tätä tietuetta (DirectAdminissa: DNS Management, kynäkuvake SPF-tietueen kohdalla, kenttä Include Domain; Oma WebOkéssa: SPF-apuri DNS-välilehdellä). Jätä include:webawere.nl paikalleen niin kauan kuin sähköpostisi tai sivustosi kulkee niiden palvelinten kautta. Muilla palveluntarjoajilla oletusinclude on nimeltään erilainen, mutta periaate on sama: täydennä, älä luo toista tietuetta.

Yhteenveto

• Tee ensin inventaario kaikista lähettäjistä; DMARC-raportit ja otsikkorivit auttavat siinä.
• Palvelu, jolla on oma Return-Path, ei kuulu SPF:ääsi; se tarvitsee DKIM:in sinun domainillasi.
• Laske rekursiivisesti: jokainen include, a, mx, exists, ptr ja redirect, myös includejen sisällä. Yli kymmenen, tai yli kaksi tyhjää hakua, tarkoittaa permerroria.
• Pääse takaisin kymmenen alle siivoamalla ja käyttämällä aladomaineja; flattening vain automaattisella ylläpidolla.
• Aloita ~all:lla, siirry -all:iin kun olet varma. Domainit jotka eivät koskaan lähetä postia: -all, DMARC reject ja null MX.

Tietovisa

Tehtävä

Tehtävä Z4.2: Domeenisi SPF:n rekursiivinen laskeminen. Syötä oma domainisi (tai sidn.nl jos sinulla ei ole omaa domainia). Laske ensin itse, kuinka monta DNS-hakua SPF-tietue kuluttaa, mukaan lukien kaikki includejen sisällä oleva, ja syötä luku, sekä tietueen loppuosa (~all, -all, ?all tai +all). Ohjelma laskee tuloksen reaaliajassa, tyhjät haut mukaan lukien, ja näyttää puurakenteen.

Tehtävä O4.2: Lähettäjäluettelosi. Tee tämän oppitunnin taulukkoa käyttäen lista kaikista järjestelmistä, jotka lähettävät sähköpostia domainisi puolesta. Merkitse kunkin kohdalle: minkä palvelimen tai palvelun kautta, kuuluuko se SPF:ääsi (oma Return-Path vai ei), ja allekirjoittaako se DKIM:in sinun domainillasi. Lähetä vähintään kahdesta järjestelmästä testiviesti itsellesi ja kirjoita muistiin otsikkoriveistä Return-Path-domain ja DKIM-domain (d=).

Lue lisää

Näiden artikkeleiden vaiheet pätevät WebOkén paneeleihin; muilla palveluntarjoajilla toimintatapa on vastaava.

• Ilmainen DNS-kurssi 4.3: SPF: kuka saa lähettää sähköpostia verkkotunnuksesi puolesta?
• DirectAdmin-ohje 5.7: SPF:n määrittäminen ja täydentäminen
• Miten SPF-tietue toimii DNS:ssä?
• SPF-tietueen lisääminen tai muuttaminen DirectAdminissa
• WebOké-käyttöopas 5.5: DNS-apulaiset: MX, SPF, DMARC, CAA ja SRV
• RFC 7208 (SPF), kappale 4.6.4 (rajat) ja 6.1 (redirect); RFC 7505 (null MX)