In deze blogpost gaan wij in op de grillige wereld van email, en hoe deze vorm van communicatie veilig gehouden dient te worden. Ook gaan we in op hoe de bezorging van bulk mail plaats moet vinden, om te voorkomen dat grote partijen als Google Gmail en Microsoft Outlook de mailing blokkeren. Want eenmaal geblokkeerd door zo’n partij, dan is het een langdurig proces om van de blokkade af te komen.

Een email omgeving dat niet goed is geconfigureerd kan resulteren in misbruik door middel van phishing en spoofing. In een recente zaak bij Pathé waarbij 19 miljoen euro verloren is gegaan wordt wel duidelijk dat dit een serieuze dreiging kan zijn met een dito schadepost.

En het mooie hiervan? De oplossingen kunnen zowel door het MKB als Groot Bedrijf gerealiseerd worden! Laat u niet met uw kluitje het riet in sturen met ‘dat het niet kan’.

Help, ik snap niks van deze blogpost, maar heb wel hulp nodig!

Hieronder wordt inderdaad heel veel uitgelegd. En hoewel we technische taal echt hebben proberen te voorkomen, begrijpen wij heel goed dat het voor u wellicht abracadabra is. Dat geldt voor ons net zo goed wanneer wij onze auto wegbrengen voor een onderhoudsbeurt.

U kunt uiteraard altijd even vrijblijvend contact met ons opnemen voor meer informatie en vragen. Zo nodig kunnen wij voor een kleine bedrag een quick scan van uw email-omgeving laten uitvoeren.

Mocht u toch meer willen weten? Lees dan gerust verder!

Email beveiliging

Email van zichzelf is een onveilig protocol. Het is ontwikkeld in de jaren 60 en de vorm zoals we die heden kennen is ontstaan in de jaren 70. In die jaren waren zaken als Cybercriminaliteit nog Science Fiction verhalen. In de recente periode zijn er enkele belangrijke zaken aan toegevoegd om de verifieerbaarheid en veiligheid van e-mail te verbeteren. Hieronder gaan we daar op in.

Anti-spoofing

Sender Policy Framework (SPF, Wikipedia) is een methode om de ontvangende mailserver het mogelijk te maken om te verifiëren of de afzender wel een gemachtigde afzender betreft. Wanneer hier een PASS of FAIL op terugkomt dan kan de ontvangende mailserver naar eigen inzicht maatregelen nemen. Dit voorkomt dat een onbevoegde derde zich ongemerkt voor kan doen als een ander.

De verzendende partij dient hiervoor een TXT-record in de DNS van het domein dat gebruikt wordt voor e-mail op te voeren. Dit geldt ook voor ieder subdomein dat gebruikt wordt voor email. Dit record geeft weer welke partijen gemachtigd zijn om te mailen namens het domein en hoe strikt deze policy door de ontvangende partij geïnterpreteerd zou moeten worden.

Een tool die hierbij kan helpen is: https://www.kitterman.com/spf/validate.html

Soms ‘plat’ maken

SPF heeft helaas één beperking die het benoemen waard is. Een SPF-check doet namelijk maximaal 10 recursive DNS-lookups. Dit betekent dat er in een SPF-record (en diens onderliggende SPF-records) maximaal sprake kan zijn van 10 DNS namen. Bij het ‘nesten’ van SPF-records kan dit aantal snel oplopen.

Deze beperking kan ‘omzeild’ worden door het zogenoemd toepassen van zogenoemde “flattening”. Dit komt erop neer dat een script de DNS-records allemaal gaat uitlezen en daarvan de IP-adressen teruggeeft. En deze worden weer toegevoegd aan een SPF-record.

Een tool die hierbij kan helpen is: https://dmarcian.com/spf-survey/

E-mail integriteit

E-mail reist standaard in leesbare formaat het Internet over. Dit betekent dat iedereen de inhoud kan lezen en de inhoud ook kan aanpassen. Een deel van de oplossing betreft versleuteling en daar komen we later op terug.

De andere deel van de oplossing betreft DomainKeys Identified Mail (DKIM, Wikipedia). Met DKIM wordt er een unieke sleutel genereert waarmee elke e-mail ondertekend wordt. De ontvangende partij kan aan de hand van die ondertekening valideren of de e-mail na het versturen ervan nog aangepast is. Hierdoor is het niet meer mogelijk om ongemerkt aanpassingen te doen aan een reeds verstuurde email.

De verzendende partij dient hiervoor eenmalig een sleutel te genereren en deze middels een TXT-record op te voeren in de DNS van het domein dat gebruikt wordt. Dit geldt ook voor ieder subdomein dat gebruikt wordt voor email.

De sleutel wordt in de regel in de anti-spam omgeving of op de mailserver ingesteld.

Een tool die hierbij kan helpen is: https://dmarcian.com/dkim-validator/ en https://dmarcian.com/dkim-inspector/

Email validatie

Domain-based Message Authentication, Reporting and Conformance (DMARC, Wikipedia) is in de kern datgene dat SPF en DKIM samen brengt. DMARC valideert of aan de SPF en DKIM voorwaarden is voldaan. Daarnaast valideert het ook of zowel de Enveloppe From Address, als de Header From Address beide van hetzelfde domein afkomen.

Hiermee wordt het voor de aanvaller het lastiger gemaakt om de veiligheidsmaatregelen van SPF en DKIM te omzeilen. De verzendende partij dient hiervoor een TXT-record in de DNS van het domein dat gebruikt wordt voor e-mail op te voeren. Dit geldt ook voor ieder subdomein dat gebruikt wordt voor email.

Een tool die hierbij kan helpen is: https://dmarcian.com/dmarc-record-wizard/ en https://dmarcian.com/dmarc-inspector/

Email validatie rapportage

In tegenstelling tot SPF en DKIM heeft DMARC ook een rapportage mogelijkheid. In de policy in de DNS kan een bestemming (email-adres) aangegeven voor de rapporten. Een dergelijke bestemming is een daarvoor speciaal ingericht DMARC-reporting-service die de rapporten kan inlezen. Zodoende kan er een goed beeld gecreëerd worden hoe het email verkeer t.a.v. dat domein verloopt. Ook kunnen eventuele SPF en DKIM problemen boven water gehaald worden.

De reporting kan op hoofdlijnen (Aggregated) en gedetailleerd (Forensic) gebeuren. Dienstverleners (in sommige gevallen kosten ze geld) zoals DMARCIAN en MXToolbox kunnen helpen bij dergelijke reporting.

E-mail versleuteling

Een ander belangrijk gebrek van email is dat het transportkanaal niet versleuteld is. Daarop zijn uiteindelijk twee antwoorden van de markt gekomen. De een betreft die van Transport Layer Security (TLS,
Wikipedia), en die ander STARTTLS (Wikipedia).

De werking verschilt van elkaar, maar ze hebben hetzelfde doel. Het grootste verschil zit in de opbouw van de verbinding voor het versturen en ontvangen van e-mail. De verbinding van TLS is namelijk altijd versleuteld. Maar die van STARTTLS hoeft dat niet te zijn. Wanneer mogelijk zal STARTTLS de verbinding ‘upgraden’ naar een veilig kanaal, maar dit is niet gegarandeerd.

Een tool die hierbij kan helpen is: https://www.checktls.com/TestReceiver en https://www.checktls.com/TestSender

Verplicht of optioneel versleutelen

Het versleutelen van het transportkanaal kan daarbij Opportunistic of Enforced gebeuren. Enforced houdt in dat de email simpelweg niet verstuurd en/of ontvangen wordt wanneer het transportkanaal niet versleuteld is. Opportunistic betekent dat eerst versleuteling wordt geprobeerd, en wanneer dat niet lukt wordt het geprobeerd zonder versleuteling.

Overwegend wordt Enforced alleen gebruikt voor specifieke partijen waarmee duidelijke afspraken zijn gemaakt dat email altijd versleuteld plaatsvindt. Alles op Enforced zetten kan er toe leiden dat ongeveer 10% van het emailverkeer niet aankomt of verzonden wordt.

Domeinnaam integriteit

De Domain Name System (DNS, Wikipedia) is het vertaalboek van het Internet om een domeinnaam te vertalen naar een IP-adres. Alle domeinen zouden tegenwoordig voorzien moeten zijn van zogenoemd DNSSEC (Wikipedia). Hiermee wordt voorkomen dat een antwoord van een DNS-server door een kwaadwillende onderschept en aangepast wordt. Dit helpt voorkomen dat email bestemd voor de organisatie naar andere plek op het Internet wordt omgeleid.

Mogelijke implicaties

De implicaties ten aanzien van DKIM zijn er eigenlijk niet. Dit op voorbehoud dat de gegenereerde sleutel goed overgenomen wordt in de DNS. De versleuteling vindt dan gewoon plaats en daar kan niks mis mee gaan.

Helaas zijn SPF en DMARC wat minder vanzelfsprekend. De grootste implicaties bij die twee maatregelen zijn als volgt.

Niet alle derde partijen zijn in kaart gebracht en opgevoerd in de SPF-record.

  • Gevolg: Hierdoor ontstaat de kans dat e-mail die een dergelijke derde partij verstuurd niet aankomt bij de uiteindelijke ontvanger en dat de e-mail door ontvangende mailservers als spam gemarkeerd wordt.
  • Maatregel: Een SPF-record in de DNS kan op een ‘luister’-stand gezet worden. Hierdoor wordt de policy als het ware toegepast, maar zonder dat het effect heeft. Hiervoor is wel DMARC-reporting nodig. Wanneer er meer zekerheid is kan de policy verder aangescherpt worden.

Derde partijen gebruiken verschillende domeinnamen bij de “Header From Address” en “Envelope From Address” en dit schendt de DMARC-validatie.

  • Gevolg: Om te voldoen aan DMARC dienen beide adressen hetzelfde domein te bevatten. In DMARC kan de SPF en DKIM check op optioneel gezet worden, maar dit geldt niet voor de check van de domeinnamen (dit is immers DMARC zelf).
  • Maatregel: Ook hier kan DMARC in een ‘luister’-stand gezet worden en middels DMARC-reporting analyseren of er ook DMARC issues zijn. Wanneer er meer zekerheid is kan de policy verder aangescherpt worden.

Ook is het mogelijk om de implicaties op te vangen door goed naar de huidige anti-spam of mail-gateway te kijken. Daarin staat vaak een schat aan informatie over verzendende derde partijen en de wijze waarop dat gebeurt. Dit vraagt wel een ervaren deskundige op dit vlak.

Richtlijnen Bulk Mail

Bovenstaande maatregelen zijn over de grote linie voldoende om reguliere e-mail goed in de postbus van de ontvanger te krijgen. Voor Bulk-mail dient echter echt nog wat extra’s te gebeuren. Het risico wanneer dit niet gebeurt kan verstrekkend zijn. Want wanneer dit verkeerd aangepakt wordt kan het maar zo zijn dat Google en andere grote namen de afzender op een blokkade-lijst zetten.

Hieronder wordt uiteengezet welke extra maatregelen getroffen dienen te worden om op een korte wijze een e-mail te versturen.

Reverse DNS (rDNS)

In het kort komt deze functie er op neer dat het IP-adres waarvan de email komt inderdaad bij het domein hoort van waaruit de e-mail is verstuurd. Het is letterlijk de omgekeerde route van de DNS.

Hiermee wordt het spoofen van domeinnamen een aanzienlijk stuk lastiger gemaakt. Echter vereist dit wel dat er gebruik gemaakt wordt van statische IP-adressen, en bij een dienst als Cloudflare gaat dat al niet.

Als de mailserver het al ondersteund, dan zal daar een PTR-record of rDNS geconfigureerd dienen te worden. De ontvangende partij kan dan valideren of het IP-adres dat bekend is in de ontvangen email past bij de domeinnaam.

Registratiedatum domeinnaam

Houd er rekening mee dat er veel spamfilters zijn die de registratiedatum van de domeinnaam opvragen. Wanneer deze te nieuw is (een week tot enkele weken) zal e-mail, en zeker bulk mail, sneller als spam gezien worden.

Opties om aan te melden

Aanmelden voor het ontvangen van bulk e-mail kan op verschillende wijzen. De kern hiervan betreft dat het altijd een expliciete aanmelding betreft.

  • Geef elke ontvanger de mogelijkheid om op basis van een “opt-in” mee te doen. Deze opt-in kan gevraagd worden via email of een vinkje wat handmatig aangeklikt moet worden op een webformulier.
  • Na aanmelding dient het email-adres bevestigd te worden (dit wordt ook wel eens een dubbele opt-in genoemd).
  • Vermijd in alle gevallen het aankopen of anderszins verkrijgen van email-adressen. Vermijd ook het automatisch vinken van een ‘opt-in’ op een webformulier.

Opties om af te melden

Afmelden voor het ontvangen van bulk e-mail dient net zo eenvoudig te zijn als aanmelden. De kern betreft hier dat het niet ‘verstopt’ mag zijn.

  • Een link in de hoofdtekst van elke e-mail met de tekst “uitschrijven” of “unsubscribe”.
  • Of duidelijk vermelden dat met het beantwoorden van de e-mail met “uitschrijven” of “unsubscribe” afgemeld kan worden.
  • Toevoegen van de header ‘List-Unsubscribe’ op basis van RFC 8058 in elke e-mail waarin kan worden aangegeven hoe van de bulk mail afgemeld kan worden (via een url of email-adres).

Bounces

Bounces van e-mails betekent dat de ontvangende email-adres niet bestaat of dat de mailserver niet bereikbaar is. Er kunnen nog legio andere redenen zijn, maar dat zijn de meest voorkomende. In de kern mag er vanuit gegaan worden dat wanneer een email-adres drie keer achter elkaar in een week tijd een bounce teruggeeft, dat het permanent niet bezorgd kan worden. Verwijder zo’n email-adres per direct van de lijst! Teveel bounces kunnen leiden tot een slechte mail-reputatie.

Verstuur de e-mail vanaf een bestaand email-adres, zelfs als dit een noreply adres is. Zet zo nodig een regel op de noreply inbox dat alle e-mail per direct permanent verwijderd wordt (al dan niet met een automatisch antwoord). En vermeld in een dergelijk geval ook in de e-mail tekst dat reageren op de e-mail geen zin heeft. Let dan wel op dan afmelden van de bulk mail via een url verloopt en niet door middel van het beantwoorden van de e-mail.

Opbouw van e-mail

De opbouw van een e-mail is ook belangrijk, zo belangrijk dat het zelfs een standaard is met RFC 5322, en zelfs ook voor HTML-mail. Daarbij gaat het vooral om de headers ‘Message-ID’ en ‘Precedence: bulk’, maar er zijn er meer.

Maar ook de wijze waarop de domeinnamen zijn opgebouwd zijn erg belangrijk. Denk hierbij aan zaken zoals ‘Authenticating domain’, ‘Envelope From domain’, ‘Payload domain’, ‘Reply-to domain’, en ‘Sender domain’. En het gebruik van een strikte Unicode is sterk aan te raden.

Voor wat betreft inhoud gaat het erom dat er geen sprake is van misleiding. Het onderwerp is duidelijk en de links in de e-mail laten de werkelijke bestemming zien.

Commerciële vs. financiële emails

Het is belangrijk om onderscheid te maken tussen bulk e-mail met marketing of commerciële doeleinden, en bulk e-mail met als doel van het bevestigen van financiële transacties en/of systeem wijzigingen.

Gebruik hiervoor dan ook verschillende email-adressen, (sub)-domeinen en/of IP-adressen.

Derde partijen voor bulk e-mail

Vaak wordt bulk e-mail door een derde partij verzorgd. Wees zorgvuldig voor welke dienstverlener gekozen wordt en in welke mate deze dienstverlener zich aan de richtlijnen voor bulk mail houdt. Want als zij een fout maken, dan ben ligt de verantwoordelijk bij uzelf.

Zorg er dan in ieder geval voor dat misbruik zo nodig gemeld kan worden via een adres als [email protected] Zorg er ook voor dat de WHOIS informatie van het domein volledig en accuraat is.

Soms zijn er ook affiliate programma’s die namens jouw merk of bedrijf bulk mail sturen. Waak ervoor dat het geen spam wordt, want dit kan zijn weerslag geven op het versturen van uw eigen bulk mail.

Reputatie bewaking en “melden als spam”

De mail reputatie is erg belangrijk en een slechte reputatie is moeilijk vanaf te komen. Bewaak de mail reputatie dan ook met de nodige tools. Google Postmaster Tools of de Microsoft Junk Mail Reporting Program kan hier bijvoorbeeld bij helpen.

Er zijn ook (betaalde) dienstverleners die helpen inzicht te krijgen in welke mate de ontvangers de ontvangen bulk mail melden als spam in hun inbox. Teveel van deze feedback naar bijvoorbeeld Gmail of Outlook kan er toe leiden dat de reputatie verslechterd wat weer impact heeft op de bereikbaarheid van e-mail.

Welke dienstverlener ook gekozen wordt, het is zaak om er goed bovenop te blijven zitten en de ontwikkelingen nauwkeurig in de gaten te blijven houden. En dit gedurende de levenscyclus van uw bulk e-mail. Het is dus geen eenmalige actie, maar bijna dagelijks werk (of in ieder geval na elke bulk mail campagne) dat de feedback van de systemen nauwlettend gevolgd worden.

Voorbeelden van partijen die hierbij kunnen helpen zijn Flowmailer en Postmastery.

Jezelf beschermen is net zo belangrijk

Jezelf beschermen tegen e-mail van kwaadwillende individuen is minstens net zo belangrijk. Denk hierbij aanvallen zoals die van malware, spam, phishing, en CEO-fraude. Bent u hier al tegen beschermd?

Vanuit Digicy.Cloud bieden wij de prachtige oplossing Mimecast aan. Mimecast helpt bij het beschermen tegen al deze dreigingen en kan daarbij ook nog eens helpen bij een hogere beschikbaarheid en archiveringsmogelijkheden. Wanneer u hierin geïnteresseerd bent kunt u vrijblijvend met ons in contact komen.

Slot conclusie

Het versturen van e-mail lijkt initieel heel erg eenvoudig, maar de realiteit is dus een stuk weerbarstiger. E-mail versturen werkt snel, en daarmee kan het ook snel fout gaan. Vele maatregelen zijn gratis en relatief eenvoudig door te voeren. De complexiteit zit hem vaak bij oudere omgevingen die al met vele partijen zaken doen.

Uit onze ervaring blijkt ook dat heel veel partijen dit gewoon weg niet goed voor elkaar hebben. En voor henzelf heeft het niet zo veel impact, maar voor u en uw organisatie is dat heel anders!

Zaak is om in ieder geval zoveel als mogelijk van al deze aanbevelingen, voor zover deze binnen uw bereik van invloed liggen, door te voeren. Dit kan mogelijk ook gedaan worden door uw ICT-dienstverlener, uw Cloud Service Provider, of uiteraard met hulp van ons!