Enhancing Email Security: Stop Sender Fraud with SPF, DKIM, and DMARC

Totuutta ei voi suodattaa pois: yrityksesi sähköpostia on suojattava.

Vuonna 2013 lähetettiin ja vastaanotettiin päivittäin yli 100 miljardia yrityssähköpostia. Vain joka viides vuonna 2013 lähetetyistä sähköposteista oli laillinen, ja 92 prosenttia kaikista laittomista sähköposteista sisälsi linkkejä mahdollisesti haitalliseen sisältöön.

Parantumisen merkkejä on kuitenkin havaittavissa: tämä kuukausi on ensimmäinen 12 vuoteen, jolloin alle puolet Symantecin asiakkaiden sähköposteista oli roskapostia.

Voit kiittää roskapostin vähenemisestä kolmea sähköpostin tietoturvastandardia (ja muita aloitteita): SPF, DKIM ja DMARC. Silti tietoturvariskit ovat edelleen yleisiä. Minulle kerrottiin hiljattain tarina talousjohtajasta, joka joutui phishing-yrityksen kohteeksi. Yritys epäonnistui, mutta jos se olisi onnistunut, se olisi maksanut organisaatiolle 50 000 dollaria.

Sähköpostistandardeihin liittyy edelleen paljon hämmennystä. Toivon, että voin selventää asiaa tässä postauksessa ja kertoa, miten SPF, DKIM ja DMARC otetaan käyttöön.

Sender Policy Framework (RFC 4408)

Sender Policy Framework eli SPF on sähköpostin todentamisjuhlien vanha tekijä. SPF on avoin standardi, joka openspf.orgin mukaan määrittelee menetelmän lähettäjän osoitteen väärentämisen estämiseksi. Kyse ei ole roskapostin pysäyttämisestä, vaan lähettäjän väärentämisyritysten valvonnasta ja pysäyttämisestä.

SPF:n avulla voit tunnistaa verkkotunnuksesi lailliset sähköpostilähteet ja estää luvattomia lähteitä lähettämästä verkkotunnuksestasi tuhansia – tai jopa miljoonia – laittomia sähköposteja.

Sähköpostin lähettäjän väärentämiseen liittyy yleisesti neljää erilaista sähköpostin väärinkäyttöä:

• Spam (ei-toivottu massasähköposti & ei-toivottu kaupallinen sähköposti)
• Huijarit (419-huijaukset)
• Pahantaviset ohjelmat (mainosohjelmat, nollapäiväkirjat (zero days), virukset, troijalaiset jne.)
• Fisherit (spear-phishing)

Et halua organisaatiosi verkkotunnuksen liittyvän mihinkään näistä ilmeisistä syistä. SPF auttaa varmistamaan, että organisaatiosi sähköpostit todella tulevat sinulta.

DomainKeys Identified Mail (RFC 6376, korvaa RFC 4871:n ja RFC 5672:n, jotka ovat nyt vanhentuneet)

DKIM eli DomainKeys Identified Mail on TXT-tietue, joka julkaistaan DNS-järjestelmässä (Domain Name System). Siihen liittyy jotakin, mitä kaikkien IT-ylläpitäjien pitäisi oppia rakastamaan: avaimet, tarkemmin sanottuna julkiset avaimet.

Voittaaksemme perehtyä DKIM:ään, on tärkeää ymmärtää, mitä avaimet ovat ja miten ne toimivat. Avaimet, tässä tapauksessa julkisen avaimen kryptografia, koostuu julkisesta (kaikkien tiedossa olevasta) ja yksityisestä (usein salaiseksi kutsutusta) avaimesta. Julkiset ja yksityiset avaimet ovat matemaattisesti yhteydessä toisiinsa, mikä mahdollistaa turvallisen viestinnän julkisia kanavia pitkin.

Nämä avaimet ovat kuin läpinäkyvän kirjekuoren sinetti, jota ei voi väärentää. Viestiä ei välttämättä piiloteta, vaan ainoastaan todennetaan 100-prosenttisella varmuudella sekä lähettäjä että viesti.

Palataan takaisin DKIM:iin.

”Teknisesti DKIM tarjoaa menetelmän, jonka avulla voidaan kryptografisen todennuksen avulla validoida viestiin liitetyn verkkotunnuksen identiteetti”, dkim.orgin mukaan. Toisin sanoen DKIM käyttää avaimia varmistaakseen, että sähköpostin lähettäjä on se, joka hän väittää olevansa.

DKIM:n avulla luodaan julkiset ja yksityiset avainparit, jotta sähköpostipalvelimet ja viestintä pysyvät todennettuina. Jokainen lähtevä Simple Mail Transfer Protocol (SMTP) -palvelin tarvitsee oikean yksityisen avaimen ja etuliitteen, jotta se vastaa julkista DNS-tietuetta, jonka vastaanottava sähköpostipalvelin sitten tarkistaa.

Oletko koskaan miettinyt, miksi Gmailissa näkyy lukkokuvake, kun saat viestejä eBaysta, Paypalista tai pankistasi? Se johtuu DKIM:stä ja hieman DMARC:stä (jota käsittelemme pian). Alla mailed-by näyttää SPF-täsmäyksen ja signed-by DKIM-täsmäyksen. DMARC:n loi joukko organisaatioita rajoittamaan sähköpostipohjaista väärinkäyttöä ”ratkaisemalla pari pitkään jatkunutta sähköpostin todennusprotokolliin liittyvää toiminta-, käyttöönotto- ja raportointiongelmaa”, dmarc.org.

DMARC:n avulla viestin lähettäjä voi ilmoittaa, että hänen viestinsä on suojattu SPF:llä ja/tai DKIM:llä. DMARC-käytäntö antaa viestin vastaanottajalle selkeät ohjeet, joita hänen on noudatettava, jos sähköpostiviesti ei läpäise SPF- tai DKIM-todennusta – esimerkiksi hylättävä tai heitettävä se roskapostiin.

Lisäksi DMARC lähettää lähettäjälle raportin viesteistä, jotka ovat läpäisseet ja/tai jotka eivät läpäise DMARC-arviointia.

Miten SPF:n, DKIM:n ja DMARC:n toteuttaminen

Nyt kun olemme ymmärtäneet paremmin kutakin näistä kolmesta standardista (ja sen, miksi ne ovat tärkeitä), katsotaanpa, miten voit parantaa sähköpostin tietoturvaa ottamalla ne käyttöön.

Huomautus: Tämän vaiheittaisen läpikäynnin vuoksi kuvitellaan, että olet 301 Movedin, pienen Google Appsia käyttävän web-suunnitteluyrityksen, tietotekniikkapäällikkö.

Viime aikoina sinulla on ollut ongelmia venäläisten roskapostirobottien kanssa. Loppukäyttäjät ovat valittaneet saavansa sähköpostin palautusilmoituksia osoitteista, joita he eivät ole koskaan nähneet tai joille he eivät ole koskaan lähettäneet viestejä. Ymmärrät, että joku selvästi lähettää vilpillisiä sähköposteja verkkotunnuksestasi.

Miten siis pysäytät heidät?

Huomautus: Liitän mukaan tavallisen BIND-muodon pelkkänä tekstinä ja kuvakaappauksen siitä, miltä tietue näyttää GoDaddy DNS:ssä. GoDaddyssä kaikki tietueet ylätason verkkotunnukselle 301Moved.com käyttävät isäntää ”@”, sinun isäntäsi on todennäköisesti erilainen. Tässä harjoituksessa käsittelen vain lähtevää postia, enkä sitä, miten käsittelemme näitä standardeja ulkoisilta lähettäjiltä tulevassa postissa.

SPF:n käyttöönotto

Ensimmäinen askel: Googlen opas SPF-tietueiden määrittämisestä Google Appsin kanssa toimiviksi on hyvä paikka aloittaa. Näiden ohjeiden mukaisesti lisäämme uuden TXT-tietueen julkiseen DNS:ään.

301Moved.com. IN TXT "v=spf1 include:_spf.google.com ~all"

301 Moved käyttää myös Zendeskiä, tikettijärjestelmää, joka lähettää sähköpostia suoraan verkkotunnuksestasi. Sinun on varmistettava, ettei sieltäkään lähetetä roskapostia.

Vaihe kaksi: Etsi ja lisää Zendeskin SPF-tietue.

301Moved.com. IN TXT "v=spf1 include:mail.zendesk.com include:_spf.google.com ~all"

On tärkeää huomata, ettemme lisää toista SPF-tietuetta, sillä se rikkoisi asioita; sen sijaan yhdistämme ne yhdeksi tietueeksi, mikä pidentää tietuetta sitä mukaa, kun lisää lähettäjiä lisätään.

Huomaa: Voit lisätä vain yhden SPF-tietueen verkkotunnusta tai aliverkkotunnusta kohti.

Tiedät myös, että 301 Movedilla on tiloissa vanha sähköpostiportti, joka käsittelee joitain vanhoja asioita, joten lisätään myös niiden IP-lohko. 301 Moved käyttää ”IP4”-mekanismia määritelläkseen oman IP-lohkonsa-198.51.100.0/24 (192.51.100.0-254).

Käytä Dmarcian SPF Surveyor -ohjelmaa tarkastellaksesi SPF-tietueita.

Vaihe kolme: Lisää yksittäiset IPv4-osoitteet yksinään ja verkkolohkot CIDR (Classless Inter-Domain Routing) -merkinnällä. 198.51.100.0 yksittäiselle IP-osoitteelle (ei tarvitse /32:ta) ja 198.51.100.0/24 aliverkoille.

301Moved.com. IN TXT "v=spf1 ip4:198.51.100.0/24 include:mail.zendesk.com include:_spf.google.com ~all"

Vanhan sähköpostiyhdyskäytävän lisääminen varmistaa, että yhdyskäytävältä lähtevä sähköposti on SPF-valtuutettu.

Yllä olevat mekanismit ovat yleisimmin käytettyjä, mutta niitä on kaikkiaan kahdeksan – mukaanlukien oudot ja vanhentuneet. Nämä mekanismit määrittelevät vain vastaavuuden laajuuden, eivät itse toimia.

Seuraavassa osiossa olevissa määritteissä voidaan määritellä PASS, SOFTFAIL ja FAIL – vastaavuus johtaisi siihen, että jokin kolmesta (PASS, SOFTFAIL ja FAIL) toimesta käynnistyy.

• ALL: Kaikki, mitä ei ole jo määritelty muulla mekanismilla, täsmää all-mekanismilla
• A: Jos verkkotunnuksella on osoitetietue (A tai AAAA), joka voidaan ratkaista lähettäjän osoitteeseen, se täsmää.
• IP4: Jos lähettäjä on tietyllä IPv4-osoitealueella, se täsmää.
• IP6: Jos lähettäjä on tietyllä IPv6-osoitealueella, se täsmää.
• MX: Jos verkkotunnuksella on MX-tietue, joka ratkaisee lähettäjän osoitteeseen, se täsmää (eli posti tulee joltakin verkkotunnuksen saapuvan postin palvelimelta).
• PTR: Jos asiakkaan osoitteen verkkotunnus (PTR-tietue) on annetussa verkkotunnuksessa ja kyseinen verkkotunnus ratkaisee asiakkaan osoitteeseen (eteenpäin vahvistettu käänteinen DNS), täsmää. Tämä mekanismi on vanhentunut, eikä sitä pitäisi enää käyttää.
• EXISTS: Jos annettu verkkotunnus ratkaisee mihin tahansa osoitteeseen, se vastaa (riippumatta siitä, mihin osoitteeseen se ratkaisee). Tätä käytetään harvoin. Yhdessä SPF-makrokielen kanssa se tarjoaa monimutkaisempia vastaavuuksia, kuten DNSBL-kyselyt.
• INCLUDE: Jos sisällytetty (väärä nimitys) käytäntö läpäisee testin, tämä mekanismi vastaa. Tätä käytetään tyypillisesti useamman kuin yhden ISP:n käytäntöjen sisällyttämiseen.

Seuraavaksi tulevat määritteet. On olemassa miljoona tapaa yhdistää nämä mustan listan ja/tai valkoisen listan malliin, mutta tässä tarkoituksessamme käytämme vain kolmea edellä mainitsemaamme hakumekanismia ja yhtä karsintamekanismia lopussa saadaksemme aikaan valkoisen listan. Neljä karsintaa ovat:

• + PASS-tuloksen saamiseksi. Tämä voidaan jättää pois; esimerkiksi +mx on sama kuin mx.
• ? NEUTRAL-tulokselle, joka tulkitaan kuten NONE (ei käytäntöä).
• ~ (tilde) SOFTFAIL-tulokselle, joka on virheenkorjauksen apuväline NEUTRALin ja FAILin välissä. Tyypillisesti viestit, jotka palauttavat SOFTFAIL-tuloksen, hyväksytään, mutta merkitään.
• – (miinus) FAIL:lle, viesti on hylättävä (katso alla).

Vaihe neljä: Sovelletaan SOFTFAIL-käytäntöä.

Toistaiseksi 301 Moved käyttää tildeä SOFTFAILille. Kun käytetään tildeä, kaikki posti, joka ei vastaa Googlea, Zendeskiä tai mainittua IP-lohkoa, olisi SOFTFAIL. Posti toimitetaan edelleen, mutta se lähetetään todennäköisesti roskaposti- tai roskapostikansioon. Tämä riippuu kuitenkin täysin vastaanottajan sähköpostipalvelimesta. Sitä ei ole määritelty millään standardeilla.

A ”-” (miinus) tässä tilanteessa VIKAISI (ja todennäköisesti hylkäisi) vastaamattoman postin kokonaan. Voit kääntää sen päälle, kun alat saada enemmän näkyvyyttä lähtevään postiisi (odota DMARC:iä) ja kun olet tutustunut paremmin posti-infrastruktuuriin.

SPF on loistava, koska siinä ei tarvitse muuttaa itse postipalvelimia. Otsikot pysyvät samoina. Vain yksinkertainen TXT-tietue (varsinainen, oma SPF-tietuetyyppi ei koskaan ollut kovin suosittu, ja se on nyt vanhentunut), ja voit ohjeistaa suurinta osaa maailman postipalvelimista, joiden pitäisi vilauttaa nimeäsi ympäriinsä.

Vastaanottava SMTP-palvelin tarkistaa lähettäjän IP-osoitteen SPF-tietueeseesi, jota se kysyi, ja soveltaa sitten käytäntöä ohjeidesi perusteella. Toisin sanoen valtuutat itsesi ja palveluntarjoajasi lähettämään (enimmäkseen) luotettavaa postia, koska julkaiset yleisölle pääsynvalvontaluettelon (ACL).

Viestejä voidaan kuitenkin edelleen muokata kuljetuksen aikana, ja ovelat väärentäjät ja phisherit voivat kiertää SPF:ää mielenkiintoisilla tavoilla (ehkäpä tämä on toisen päivän aihe). Kyse on SMTP:stä: päästä päähän TLS:ää ei ole taattu, joten meidän on aina oletettava, että viesti on selvä. Viestejä voidaan peukaloida tai väärentää.

Mutta astu oikealle…

Implementing DomainKeys Identified Mail

Kun posti lähetetään, 301Moved.com allekirjoittaa (salaamatta) postin yksityisellä avaimella. Tästä lähtien kaikki muutokset viestiin, mukaan lukien runko, otsikot tai liitetiedostot, rikkovat allekirjoituksen ja tekevät viestistä pätemättömän. Katsomme jälleen Googlen artikkelia Authenticate email with DKIM

Step Five: Lisää julkinen avain DNS-tietueeseen.

google._domainkey.301Moved.com IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCsC1iZ3D7AR3FrKtBYfnoKztCGgExFIReC0b1MPY1rpGZa9aTBYq7cDV6F8lzDVr8/K+z9Xt1gUV4P7tT8wuwgacR4oqiAWaUprbnINAxinJr4ohB1TIW3diX2fEA2t5kyUGCGziJFlHicZyJbk5QEaVLcSFD4V8R9f0Voz4P4jQIDAQAB"

Kullakin DKIM-tietueella on yksilöllinen valitsimen etuliite, joten voimme julkaista useamman kuin yhden. Sen sijaan, että yhdistäisit ne yhteen tietueeseen, kuten teimme SPF:n kanssa, voit käyttää yksilöllisiä valitsimia ja julkaista niin monta julkista avainta kuin tarvitset. Näin voimme lisätä suuren määrän DKIM-valtuutettuja palvelimia ilman ylärajoja.

Huomaa, että yllä oleva etuliite on ”google”, joka on oletusarvo, jota Google Apps käyttää luodessaan DKIM-tietueen julkaistavaksi. Voit muuttaa tätä Googlessa ja useimmissa muissa asetuksissa, joten jos haluaisit etuliitteen ”dkimawesome”, mikään ei estä sinua.

Jotkut pilvipalveluntarjoajat tekevät sen eri tavalla. Sen sijaan, että he tuottaisivat yksilöllisiä avainpareja jokaiselle pilvipalvelun vuokralaiselle, he allekirjoittavat kaikkien verkkotunnusten kaiken lähtevän postin samalla avaimella – samalla kun sinun on julkaistava kanoninen nimi (CNAME) sen sijaan heidän avaimelleen.

Zendesk tekee näin, me CNAME kaksi eri avainta DNS:ssämme heidän DNS:äänsä. Zendeskillä on hyvä ohjeartikkeli- Sähköpostin digitaalinen allekirjoittaminen DKIM:n tai DMARC:n avulla (Plus ja Enterprise)

Vaihe kuusi (tarvittaessa): CNAME-avaimet DNS:ssäsi heidän DNS:äänsä. DNS-kysely, joka etsii zendesk1._domainkey.301Moved.com, ohjataan DNS:ssäsi osoitteeseen zendesk1._domainkey.zendesk.com. Zendesk tarjoilee sitten DKIM-avaimet suoraan.

zendesk1._domainkey.301Moved.com IN CNAME zendesk1._domainkey.zendesk.comzendesk2._domainkey.301Moved.com IN CNAME zendesk2._domainkey.zendesk.com

Voidaan nähdä, miltä tämä näyttää muille palvelimille käyttämällä nslookup-työkalua (Unixissa tai Windowsissa) paikallisesti.

Eivät kaikki lähtevät lähettäjät tue DKIM:ää. Google Apps ilmeisesti tukee, mutta vanhat sähköpostipalvelimesi eivät ehkä.

Toimialuepohjaisen viestien todennuksen, raportoinnin ja vaatimustenmukaisuuden käyttöönotto

DMARC eli toimialuepohjainen viestien todennus, raportointi ja vaatimustenmukaisuus (Domain-based Message Authentication, Reporting, and Conformance) on viimeinen keino, jolla voimme torjua haitallista sähköpostia. Kuunteleville sähköpostipalvelimille DMARC, välittää, miten SPF:ää ja DKIM:ää käsitellään sekä miten raportoidaan sinulle, jolloin saat kaivattua näkyvyyttä jakelumääristäsi ja tietueiden vaatimustenmukaisuudesta.

Ja kyllä, DMARC on jälleen yksi TXT-tietue.

Seitsemäs askel: Määritä DMARC-käytäntö, tunnista mailto-osoite, määritä kohdistustila ja määritä prosenttiosuus viesteistä, joihin käytäntöä tulisi soveltaa (älä huoli, tämä on yksinkertaisempaa kuin miltä se kuulostaa).

301Moved.com. IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]; adkim=r; aspf=r; pct=100; sp=none"

Yllä oleva käytäntö on nimetty p=none. Emme muuta postin kulkua vielä lainkaan – asetamme vain käytännöt ja niihin liittyvät raportoinnit. Osoite, johon DMARC-tilaa koskevat XML-raportit lähetetään, on merkitty merkinnällä rua=.

Vastaanottavat sähköpostipalvelimet lähettävät XML-liitetiedostoja, joista käy ilmi, miten verkkotunnuksestasi peräisin olevat viestit – ja viestit, jotka väittävät olevansa verkkotunnuksestasi peräisin – pärjäsivät nykyaikaisimmissa sähköpostipalvelimissa käytetyille SPF-, DKIM- ja DMARC-vaatimuksille.

Näistä raporteista selviää kirjekuoreen perustuen, läpäisikö SPF-palvelin SPF-palvelun, hylkäsikö SPF-palvelun vai ei. Ne osoittavat, onko DKIM epäonnistunut, epäonnistunut tai onnistunut – ja miten edellä mainittuja käytäntöjä on sovellettu.

Viimeiseksi näissä raporteissa ilmoitetaan viestin lopullinen toimitustapa. On olemassa hienoja työkaluja, jotka auttavat sinua näiden analysoinnissa. Vaikka et soveltaisikaan käytäntöjä viesteihin, se on kuin palomuuri-, DNS- ja IDS/IPS-lokit – on aina hyvä, että sinulla on jotain, jota voit palata taaksepäin ja tarkastella.

Adkim=r määrittelee rennon DKIM-kohdistustilan, ”r” tarkoittaa rentoa ja ”s” tiukkaa. Rento tila mahdollistaa DMARC-tarkastuksen läpäisemisen sähköpostin otsikko-From: -osoitteessa olevan yhteisen Organizational Domainin sisällä olevien autentikoitujen DKIM d= -verkkotunnusten avulla. Strict-tila edellyttää täydellistä vastaavuutta DKIM d= -verkkotunnuksen ja sähköpostin Header-From-osoitteen välillä. Ajattele aliverkkotunnuksia, jos käytät niitä.

aspf=r tekee täsmälleen saman asian, paitsi SPF-tarkistusten osalta.

Pct=100 on prosenttiosuus viesteistä, jotka todella käsitellään DKIM-käytännön mukaisesti. Satunnaisesti valittu vastaanottava sähköpostipalvelin soveltaa käytäntöä tähän prosenttiosuuteen verkkotunnuksestasi tulevista viesteistä. Käytämme toistaiseksi 100:aa, koska emme vielä sovella käytäntöä.

Ennen kuin sovellamme käytäntöä, kuristamme tämän arvoon viisi, jotta käytäntöä sovelletaan vain yhteen 20:stä viestistä, kun käännämme p=-käytäntölippua karanteeniin tai hylkäämiseen. Tällä tavoin, jos mokaamme tämän täysin, 95 prosenttia sähköpostistamme toimitetaan silti, sen sijaan että toimitettaisiin 0 prosenttia, jos aloittaisimme pct=100:lla.

Viestit, jotka eivät läpäise DMARC-tarkistusta tai edellä asettamiamme adkim=- ja aspf=-kohdistustiloja, hylätään pehmeästi, kuten edellä, karanteenikäytäntöä varten, tai hylätään kokonaan, kun ne on asetettu hylkäämiseen.

On erittäin tärkeää huomata, että DMARC hyväksyy viestin, jos joko SPF tai DKIM hyväksytään, ja hylkää viestin vain, jos sekä SPF että DKIM hylätään. Näin vain SPF- ja ja DKIM-viestit voivat PASSata DMARC:n, mutta viestit, joissa ei ole kumpaakaan SPF:ää/DKIM:ää, hylätään aina. Tämä on hyvä uutinen, jos sinulla on sähköpostijärjestelmiä, jotka tukevat vain SPF:ää tai vain DKIM:ää.

Käytä Dmarcian DMARC Inspector -ohjelmaa nähdäksesi DMARC-tietueesi.

Dmarcian on maksullinen työkalu, jonka avulla voit hallita DMARC-raporttejasi helposti, on monia muitakin, mutta Dmarcian sattuu olemaan suosikkini.

Päivitys: Olemme saaneet muutamia (DMARC-yhteensopivia!) sähköpostiviestejä, joissa kysyttiin subdomain-käytännöstä sp=none. Käytännöllä, joka sisältää sp=none, et määritä DMARC-käytäntöä millekään aliverkkotunnukselle. Tämä tehdään manuaalisesti luomalla asianmukainen DMARC-tietue kullekin tietylle aladomainille tai sisällyttämällä se pää-DMARC-tietueeseen sp=quarantine- tai sp=reject-merkinnällä.

Minimum Config

Jos haluat kokeilla tätä, suosittelen, että aloitat hyvin avoimesti ja pysyt yksinkertaisena, kunnes sinulla on tarpeeksi DMARC-raportteja, jotta voit alkaa valvoa mitään.

301Moved.com. IN TXT "v=spf1 ip4:198.51.100.0/24 include:mail.zendesk.com include:_spf.google.com MX ?all"

Määrittele suuret palveluntarjoajat ”include:”-merkinnällä ja kaikki IP-verkkolohkot, joista voit lähettää postia ”IP4”- tai ”IP6”-merkinnällä. Käytä ”MX”-merkintää saapuvan postin palvelimien valtuuttamiseen. Ja ellet lähetä postia suoraan samasta laatikosta/palvelimelta, joka isännöi verkkosivustoasi (muuten huono, huono käytäntö), voit ohittaa edellä mainitun ”A”-mekanismin. ”?” ei sovella mitään käytäntöä viesteihisi, mutta saa SPF-tietueesi näkyviin, jotta DMARC voi tunnistaa sen.

google._domainkey.301Moved.com IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCsC1iZ3D7AR3FrKtBYfnoKztCGgExFIReC0b1MPY1rpGZa9aTBYq7cDV6F8lzDVr8/K+z9Xt1gUV4P7tT8wuwgacR4oqiAWaUprbnINAxinJr4ohB1TIW3diX2fEA2t5kyUGCGziJFlHicZyJbk5QEaVLcSFD4V8R9f0Voz4P4jQIDAQAB"

Hanki oikea valitsin, tässä tapauksessa ”google”, ja oikea avain. Muista, että voit julkaista useamman kuin yhden.

Huomautus: Älä julkaise tätä varsinaista avainta, tai pystyn DKIM-merkitsemään postisi.

301Moved.com. IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]; adkim=r; aspf=r; pct=5; sp=none"

DMARC:n osalta emme ole soveltaneet mitään käytäntöä, olemme rennossa tilassa, mutta pyydämme, että XML-raportit lähetetään postilaatikkoon, jota voimme käyttää. Siitä DMARC antaa meille melko nopeaa (ei reaaliaikaista) palautetta siitä, miten voimme tiukentaa eri käytäntöjä kaikissa kolmessa tietueessa.

Mutta odota, entä TLS?

Transport Layer Security eli TLS ei ole osa DMARC-standardia, eikä se ole DNS-tietue.

Sen sijaan TLS on pelkkä aikuismainen SSL-turvaliite (Secure Socket Layer, suojattu liityntäkerroin), jota sähköpostipalvelimet pystyvät käyttämään lähettäessään viestejä toistensa välille julkisten yhteyksien kautta. Se on SMTP käärittynä TLS:ään, kuten monia muitakin asioita voi tehdä TLS:n sisällä tai TLS:n kautta – SNMP TLS:n kautta ja FTP TLS:n kautta ovat yleisiä esimerkkejä. TLS salaa viestit vain kuljetuksen aikana, ei levossa.

Jos lähetämme DKIM-signoidun viestin TLS:n kautta, se on allekirjoitettu koko elinkaarensa ajan, mutta se on salattu vain, kun se siirtyy Google Apps -ohjelmistostasi Cisco Ironport -porttiin tai minne ikinä postisi kulkeekin. TLS ei varmastikaan suojaa viestejä levossa, vaikka sitä käytetään myös HTTPS://-istuntoon webmailiin, kun luet samaa viestiä, mutta sekin on vain kauttakulkua.

TLS:ää kannattaa käyttää aina, kun se on mahdollista, mutta sinun on myös oltava valmis puhumaan selkeää tekstiä muille julkisille sähköpostijärjestelmille. Jopa vuonna 2015 jotkut sähköpostipalvelimet eivät tue STARTTLS:ää (palvelinkielellä TLS-kättelyn aloittamista).

Voit pakottaa TLS:n käytön tiettyjen ulkoisten verkkotunnusten kanssa Google Appsissa yksinkertaisella määritysmuutoksella. Se on hyvä ottaa käyttöön niihin liittyviä ulkoisia yrityksiä, kumppaneita ja muita organisaatioita varten, mutta ota TLS käyttöön vasta sitten, kun olet varma, että se on luotettava ja että kaikki kyseisen verkkotunnuksen sähköpostipalvelimet tukevat sitä.

Sähköpostin tietoturvan merkitys ja lähettäjähuijausten välttäminen

Olitpa sitten kokenut tietotekniikan ylläpitäjä tai vasta aloitteleva IT-hallintahenkilö, näillä kolmella standardilla on sama merkitys. Myönnettäköön, että se, mitä kukin niistä tekee ja miten ne toimivat yhdessä, voi olla hieman sekavaa, mutta niiden toteuttaminen on suhteellisen yksinkertaista – ja hyödyt ovat aikasi arvoisia.