Mail deliverability is cruciaal voor een succesvolle mailserver. Je wilt immers niet dat de helft (of meer) van je berichten verloren gaat. In deze moderne tijd, waar spam nog nooit zo'n groot probleem is geweest als nu, is het creëren van een succesvolle mailservice echt een kunst. In dit artikel bespreek ik hoe we streven naar de perfecte mailbezorging met een score van 10/10.
Spam is de grootste ergernis van iedereen met een mailbox. Het is zelfs zo problematisch dat bijna 85% van alle e-mails wereldwijd als spam wordt gecategoriseerd. Daarom beland je tegenwoordig al snel in de spambox als je e-mails verstuurt vanaf een "slechte" mailserver. Er zijn namelijk tal van nieuwe factoren om rekening mee te houden bij het opzetten van een mailserver. We evalueren dit aan de hand van een deliverability-score.
De deliverability-score
De deliverability-score meet de waarschijnlijkheid dat e-mails van onze server daadwerkelijk op hun bestemming aankomen. Een score van 1 duidt op zeer lage kans, terwijl 10 bijna gegarandeerde aflevering betekent. Vaak belanden berichten onder een 5 in de spam- of junkmap, en berichten onder een 2 kunnen zelfs worden teruggestuurd voordat ze de ontvanger bereiken.
Als voorbeeld, standaard behaalt een maildienst zoals Microsoft 365 Outlook een score van 8/10. Met enkele aanpassingen is het mogelijk deze score te verhogen naar 10/10.
Wij maken deze aanpassingen standaard voor onze klanten ;)
Van scratch
Laten we nu een mail server opzetten van scratch. en streven naar een perfecte score van 10/10.
IP Blacklisting
Veel IP-adresreeksen worden automatisch aan zwarte lijsten toegevoegd, waaronder die van cloudproviders en zelfs internetproviders zoals KPN of Ziggo. Als één persoon spam verstuurt vanaf een IP-adres, worden vaak meteen de gehele reeks opgenomen door de beheerders van de zwarte lijsten. Dit betekent dat als je vanaf een IP-adres mailt dat op de zwarte lijst staat, je waarschijnlijk direct in de spamfolder terechtkomt. Daarom is stap één vaak het verwijderen van het IP-adres van je server van deze zwarte lijsten via handmatige beoordelingen. Dit kost wat tijd, maar in de tussentijd kunnen we doorgaan met het opzetten van de rest.
MXToolbox is een handige toolsite om bijvoorbeeld te checken of je IP Adres op een zwarte lijst staat.
E-mail valideringssysteem (SPF)
SPF staat voor Sender Policy Framework en is een e-mailvalidatiesysteem dat is ontworpen om spam te voorkomen door e-mailspoofing te herkennen. Het is daarom cruciaal dat dit goed is geconfigureerd. Anders kan de ontvangende mailserver niet verifiëren of jouw e-mail geautoriseerd is om van dat specifieke IP-adres te verzenden.
Hier een voorbeeld van hoe een DNS manager een spf record toevoegd aan het domein:
- Begin met v=spf1 (versie 1) tag en volg deze met de IP-adressen die gemachtigd zijn om e-mails te versturen. Bijvoorbeeld, dit is hoe de basisstructuur van een SPF-record eruitziet: v=spf1 ip4:1.2.3.4 ip4:2.3.4.5
- Als je een derde partij gebruikt om namens het betreffende domein e-mails te versturen, moet je een "include"-verklaring toevoegen aan jouw SPF-record (bijv. include:thirdparty.com) om dat derde partij aan te wijzen als een legitieme afzender.
- Zodra je alle gemachtigde IP-adressen en "include"-verklaringen hebt toegevoegd, eindig je jouw record met een ~all of -all tag. Een ~all tag geeft een zachte SPF-fout aan, terwijl een -all tag een harde SPF-fout aangeeft. In de ogen van grote mailboxproviders zullen zowel ~all als -all resulteren in een SPF-fout. De meestte professionals raden een -all tag aan, omdat dit het veiligste record is.
- SPF-records mogen niet langer zijn dan 255 tekens en mogen niet meer dan tien "include"-verklaringen, ook wel "lookups" genoemd, bevatten. Hier is een voorbeeld van hoe jouw record eruit zou kunnen zien: v=spf1 ip4:1.2.3.4 ip4:2.3.4.5 include:thirdparty.com -all
- Voor domeinen die geen e-mails versturen, zal het SPF-record alle modifiers uitsluiten, met uitzondering van -all. Hier is een voorbeeld van een record voor een domein dat geen e-mails verstuurt: v=spf1 -all
Het is sterk aanbevolen om de SPF-documentatie door te nemen om ervoor te zorgen dat je het naar wens, behoren en volgens het protocol instelt.
DKIM-Handtekening
DKIM, afkorting voor DomainKeys Identified Mail, is een methode om een domeinnaam te koppelen aan een e-mailbericht, waardoor een individu, rol of organisatie verantwoordelijkheid kan nemen voor de boodschap. DKIM is complexer dan SPF omdat het om een sleutel gaat in plaats van alleen een DNS-record. Deze sleutel moet worden geïmplementeerd in de mailserver, zoals bijvoorbeeld in Postfix (EN).
Nadat je de DKIM sleutels hebt gegenereerd en geïmplementeerd, kun je deze toevoegen aan de DNS van je domein. Dit doe je door een TXT-record aan te maken met de publieke sleutel.
Naam/Target = jouwselector._domainkey
Content = publieke sleutel (begint met: v=DKIM)
"jouwselector" is in de meeste gevallen "default"
DMARC
Nu we dat achter de rug hebben kunnen we de DMARC Policy opzetten. Een DMARC policy stelt een verzender in staat om aan te duiden dat zijn e-mails beschermd zijn door SPF en/of DKIM, en geeft instructies wanneer geen van deze verificatiemethoden slagen. Een DMARC (TXT) record kun je het makkelijkst met een tool genereren, maar ik zal even een voorbeeld geven.
v=DMARC1; p=reject; rua=mailto:dmarc@jouwdomein.com
Hier zie je drie tags: v, p, en rua met de waarden DMARC1, reject, en mailto:dmarc@jouwdomein.com.
Dit is wat die tags betekenen:
- De v-tag specificeert de versie van DMARC.
- De p-tag is het beleid (of de actie die moet worden uitgevoerd als de e-mails de DMARC-controles niet doorstaan).
- De rua-tag is het e-mailadres waar DMARC-rapporten naartoe worden gestuurd. Dit kan een specifieke e-mailadres van je hostingbedrijf zijn, het e-mailadres van je registrar of je eigen e-mailadres.
Dit is wat de 3 mogelijke DMARC-beleidsregels (p-tag) betekenen:
- None: Er wordt geen actie ondernomen voor berichten die de DMARC-controles niet doorstaan, maar er worden nog steeds rapporten naar je gestuurd zodat je kunt controleren wat er met je e-mails gebeurt. Je kunt een 'DMARC-beleid niet ingeschakeld' foutmelding krijgen als het beleid is ingesteld op none.
- Quarantine: Berichten die de DMARC-controles niet doorstaan, worden in de map met ongewenste e-mail van de ontvangers geplaatst.
- Reject: Alle e-mailberichten die de authenticatie niet doorstaan, worden volledig afgewezen en bereiken de ontvanger nooit. Met andere woorden, het hier gedefinieerde beleid is om een bericht af te wijzen wanneer het de authenticatie niet doorstaat.
Er zijn diverse andere optionele tags die je kunt gebruiken, zoals pct en ruf. Voor eenvoudigheid laten we deze even voor wat het is in het voorbeeld. Je kunt prima je DMARC-record instellen met de 3 essentiële tags uit het voorbeeld: v, p, en rua.
Vergeet alleen niet de rua tag te veranderen ;)
De basics
Dit zijn echt de meest rigoureuze beleidsmaatregelen die je moet hebben om een goede kans te maken met je deliverability-score. Vergeet ook niet je eigen mailserver te beveiligen als ontvanger; vaak zijn we zo gefocust op de bezorging van mail dat we de ontvangende beleidsmaatregelen over het hoofd zien.
Een paar goede aanpassingen en toevoegingen voor postfix bijvoorbeeld:
- Uitzetten van VRFY
- (start)TLS & SSL implementeren
- HELO (EHLO) Activeren
- CLAMAV & AMAVIS
- SpamAssassin
& nog veel meer! Maar dat is voor een ander artiekel.
Zijn we iets vergeten, kan het beter of hebben we iets mis? Laat het weten!
NEWS@DIODEMATRIX(.)COM
-Sepp@DiodeMatrix