Office 365 gids: Spam tegengaan met SPF, DKIM en DMARC

Zonder de juiste beschermingsmaatregelen is de afzender van een e-mail bericht heel gemakkelijk te vervalsen. Om deze vervalsing te voorkomen zijn er door de internetgemeenschap maatregelen getroffen in de vorm van SPF, DKIM en DMARC. Dit zijn technieken die de authenticiteit van een e-mail verifiëren. Deze technieken worden ook in Office 365 gebruikt.

SPF

In een zogenaamd SPF record wordt vastgelegd vanaf welke machines e-mails verstuurd mogen worden namens een domein (zoals bedrijf.nl). Een ontvangende mailserver kan dit record via DNS controleren en kijken of het verzendende adres is geautoriseerd om e-mail vanuit dit domein te versturen.

Het standaard SPF record in Office 365 is v=spf1 include:spf.protection.outlook.com -all . Dit kan als zogenaamd TXT record worden aangemaakt in het DNS beheer en wil zeggen dat alleen de servers gedefinieerd onder spf.protection.outlook.com geautoriseerde verzenders zijn.

Maak je ook nog gebruik van bijvoorbeeld een facturatiesysteem of nieuwsbrief systeem, dan zullen deze ook in datzelfde SPF record gedefinieerd moeten worden. Bijvoorbeeld voor Exact Online zou het dan worden: v=spf1 include:spf.protection.outlook.com include:_spf.exactonline.nl -all

DKIM

DKIM gaat nog een stapje verder dan SPF. Met DKIM wordt een cryptografisch sleutelpaar gecreëerd, met de privésleutel wordt door de verzendende server een handtekening gemaakt en toegevoegd aan uitgaande e-mails. De ontvangende server zoekt de publieke sleutel op die behoort bij het betreffende domein en verifieert daarmee de handtekening. Als het domein niet klopt of het bericht is onderweg aangepast dan faalt deze verificatie.

Alle Office 365 klanten maken sinds 2015 al gebruik van DKIM terwijl je hiervoor niets hoeft te doen. Microsoft maakt hierbij gebruik van het zogenaamde ‘onmicrosoft.com’ domein in plaats van de eigen bedrijfsdomeinnaam. Iedere klant heeft zo’n domeinnaam, vaak iets als bedrijfsnaam.onmicrosoft.com. Hierop heeft Microsoft het sleutelpaar gecreëerd en de publieke sleutel gepubliceerd in de DNS server. Een issue met deze werkwijze is echter dat een ontvangende server het bericht als problematisch kan aanmerken omdat het afzender e-mail domein @bedrijfsnaam.nl niet overeenkomt met het domein waarop de DKIM handtekening is gebaseerd, bedrijfsnaam.onmicrosoft.com.

Het is daarom dus aan te bevelen om DKIM ook voor het eigen domein in te schakelen:

Maak CNAME DNS records aan

Het format hiervoor is:

  • selector1._domainkey.<domain>  wijzend naar:  selector1-<domainGUID>._domainkey.<initialDomain>
  • selector2._domainkey.<domain>  wijzend naar:  selector2-<domainGUID>._domainkey.<initialDomain>

Waarbij <domain> je publieke domeinnaam is, <domainGUID> het eerste gedeelte van je MX record en <initialDomain> je onmicrosoft.com domein, bijvoorbeeld:

  • selector1._domainkey.cumulusit.nl  wijzend naar:  selector1-cumulusit-nl._domainkey.cumulusitnl.onmicrosoft.com
  • selector2._domainkey.cumulusit.nl  wijzend naar:  selector2-cumulusit-nl._domainkey.cumulusitnl.onmicrosoft.com

Schakel DKIM in voor het betreffende domein

  • Ga naar het Exchange beheercentrum
  • Ga naar beveiliging > DKIM
  • Klik rechts op ‘Inschakelen’

Herhaal bovenstaande stappen voor alle eigen domeinnamen.

DKIM inschakelen voor andere diensten

Als je gebruik maakt van een facturatie of nieuwsbrief systeem dan zul je hiervoor ook DKIM records in je DNS moeten aanmaken. Volg hiervoor de instructies op van de betreffende leverancier. Bij sommige diensten moet je een CNAME record aanmaken die verwijst naar een andere record waarop de publieke DKIM sleutel is opgeslagen (handig) maar soms moet je de publieke sleutel ook zelf in een TXT record publiceren (iets minder handig).

DMARC

Als laatste hebben we nog DMARC, dit is een TXT DNS record waarin je aangeeft wat er moet gebeuren als de SPF en DKIM verificatie mislukken. Met DMARC actief vindt er ook een controle plaats of het weergegeven ‘Van:’ e-mail adres authentiek is.

Het format van een DMARC TXT record is met de vereiste velden is:

  • _dmarc.domain  met de waarde v=DMARC1; p=policy

Optioneel wordt met pct aangegeven op hoeveel procent van de berichten de policy dient te worden toegepast, en met p de policy zelf. Bijvoorbeeld:

  • _dmarc.cumulusit.nl  met de waarde v=DMARC1; p=reject; pct=25; rua=mailto:rua@cumulusit.nl

Hiermee wordt aangegeven dat 25% van de berichten (dit biedt de mogelijkheid om de policy geleidelijk in te voeren) die niet door de DMARC-controles komen, moeten worden geweigerd (p=reject) en feedback (rua) verstuurd wordt naar rua@cumulusit.nl

Veel organisaties beginnen met een zogenaamd monitoring record met p=none, aan de hand van de teruggekoppelde rapporten kunnen issues dan worden opgelost waarna uiteindelijk p=quarantine, of p=reject of  kan worden ingesteld, bijvoorbeeld:

  • _dmarc.cumulusit.nl  met de waarde v=DMARC1; p=none; rua=mailto:rua@cumulusit.nl

Wanneer je de policy p=quarantine opgeeft adviseer je de ontvangende mailserver om de mail als ongewenste mail aan te merken, de mail wordt dan meestal in een aparte map ‘ongewenste e-mail’ / ‘junk e-mail’ afgeleverd in plaats van dat deze in het geheel niet aankomt (bij p=reject). Office 365 behandeld overigens voor inkomende berichten p=reject als zijnde p=quarantine.