Module 7 · 7.4

Nieuwsbrief- en verzenddiensten

Module 7: Externe diensten koppelen · Leestijd: 8 minuten

Leerdoel: Na deze les kun je een nieuwsbrief- of verzenddienst zo koppelen dat je mail niet in de spam belandt.

Kernbegrippen: domeinverificatie (authenticatie), DKIM via CNAME, selector, SPF-include alleen als de dienst erom vraagt, limiet van 10 opzoekingen, DMARC-uitlijning via DKIM, MX niet aanraken

Waarom een nieuwsbriefdienst records vraagt

Een nieuwsbriefdienst zoals Mailchimp, Brevo of MailerLite, of een verzenddienst voor facturen en bevestigingen, verstuurt mail met jouw adres als afzender, bijvoorbeeld nieuws@example.com. Maar de mail komt van de servers van die dienst, niet van jouw mailserver.

Ontvangers als Gmail en Outlook.com controleren dan: mag deze server namens example.com mailen, en klopt de handtekening (les 4.3 tot en met 4.5)? Is dat niet geregeld, dan komt je nieuwsbrief in de spam, of herschrijft de dienst je afzender naar een eigen adres. Daarom vraagt de dienst je om je domein te authenticeren: een paar records in je DNS.

Wat de dienst niet nodig heeft: je MX-records. Die bepalen waar jouw inkomende mail heen gaat. Een nieuwsbrief verstuur je alleen; antwoorden komen gewoon in je eigen mailbox. Wijzig je MX dus nooit voor een nieuwsbriefdienst.

DKIM via CNAME

De meeste diensten laten je DKIM regelen met CNAME-records. De dienst houdt de sleutel zelf bij; jij wijst er alleen naar. Zo kan de dienst de sleutel vervangen zonder dat jij iets hoeft te doen.

Mailchimp gebruikt op het moment van schrijven bij nieuwere accounts twee records:

k2._domainkey.example.com.   3600   IN   CNAME   dkim2.mcsv.net.
k3._domainkey.example.com.   3600   IN   CNAME   dkim3.mcsv.net.

Oudere accounts hebben vaak één record k1._domainkey naar dkim.mcsv.net. Andere diensten gebruiken andere selectors, zoals brevo1._domainkey of ml._domainkey. Neem over wat het dashboard van jouw dienst toont. De namen en doelen verschillen per dienst en per account, en ze veranderen soms.

k2 en k3 zijn selectors (les 4.4). Elke dienst heeft een eigen selector, dus de records zitten elkaar en de DKIM-sleutel van je eigen mailserver niet in de weg.

Drie fouten die bijna iedereen een keer maakt

Dubbele domeinnaam. Je paneel zet je domeinnaam vaak zelf achter de naam. Vul je k2._domainkey.example.com in, dan wordt het k2._domainkey.example.com.example.com. Vul alleen k2._domainkey in, tenzij je paneel uitdrukkelijk om de volledige naam vraagt. Onder het veld staat meestal hoe de naam wordt.
De punt aan het eind van de waarde vergeten. Zonder punt maakt je paneel van dkim2.mcsv.net misschien dkim2.mcsv.net.example.com. Sommige panelen zetten de punt zelf; kijk na het opslaan hoe het record eruitziet (les 2.2).
TXT in plaats van CNAME. Vraagt de dienst om een CNAME, maak dan een CNAME. Een TXT-record met dkim2.mcsv.net als tekst doet niets.

SPF: alleen als de dienst erom vraagt

Bij SPF denken veel mensen: elke dienst die mailt, moet in mijn SPF-record. Dat is niet altijd zo.

SPF controleert het adres in de envelop van de mail (het Return-Path), niet het afzenderadres dat je ziet. Veel nieuwsbriefdiensten, waaronder Mailchimp, gebruiken in de envelop een eigen domein. Hun SPF-controle loopt dus over hun eigen domein, en jouw SPF-record speelt geen rol. Mailchimp vraagt daarom geen include in jouw SPF-record.

Andere diensten gebruiken wel een adres op jouw domein in de envelop, of laten je een eigen subdomein instellen (bijvoorbeeld bounce.example.com). Die vragen om een include: in je SPF-record, of om een SPF-record op dat subdomein. Doe dus precies wat de dienst vraagt:

vraagt de dienst om een include, zet die dan in je bestaande SPF-record, nooit in een tweede (les 4.3);
vraagt de dienst er niet om, voeg dan niets toe.

Waarom zuinig zijn? Een SPF-record mag bij een controle maximaal 10 DNS-opzoekingen veroorzaken. Elke include, a, mx, exists en redirect telt mee, en de includes van een dienst bevatten zelf vaak ook weer includes. Met een webhost, Microsoft 365, een nieuwsbriefdienst, een boekhoudpakket en een CRM zit je zo over de grens. Dan is je hele SPF-record ongeldig (permerror). Haal includes weg van diensten die je niet meer gebruikt, of die er niet om vragen.

DMARC: hier draait het om

DMARC (les 4.5) keurt een mail goed als SPF of DKIM slaagt en bij het domein in het afzenderadres hoort (uitlijning). Bij een nieuwsbriefdienst die een eigen domein in de envelop gebruikt, kan SPF nooit uitlijnen met example.com. DMARC kan dan alleen slagen via DKIM: een handtekening met d=example.com, en die krijg je alleen als je de CNAME-records hebt gezet.

Daarom:

zet eerst de DKIM-records van de dienst;
wacht tot de dienst meldt dat je domein geauthenticeerd is;
stuur een test naar jezelf en kijk in de headers of DKIM pass is met d=example.com;
pas daarna je DMARC-beleid aan van none naar quarantine of reject.

Heb je nog geen DMARC-record, dan vragen veel diensten om er een te maken. Begin met p=none (les 4.5). Grote ontvangers zoals Gmail en Yahoo eisen sinds 2024 dat bulkverzenders een DMARC-record hebben.

Antwoorden en bounces

Antwoordt een lezer op je nieuwsbrief, dan gaat dat naar het antwoordadres dat je in de dienst instelt, en via jouw MX naar je eigen mailbox. Onbestelbare berichten (bounces) gaan naar het envelopadres en dus naar de dienst, die ze verwerkt. Ook daarvoor hoef je niets aan je MX te doen.

DKIM van een nieuwsbriefdienst als CNAME 0:52

In de praktijk: zo ziet het eruit in een paneel

In het voorbeeldpaneel DirectAdmin open je DNS Beheer, klik je op Record toevoegen, kies je CNAME, vul je bij Naam alleen k2._domainkey in en bij Waarde dkim2.mcsv.net. met de punt. Daarna doe je hetzelfde voor k3. In Mijn WebOké gaat het op het tabblad DNS op dezelfde manier; het venster toont onder het naamveld de volledige naam en waarschuwt als de punt ontbreekt.

In andere panelen, zoals cPanel, Plesk, Cloudflare of het DNS-scherm van je registrar, heten de knoppen anders, maar het zijn dezelfde velden. Let bij Cloudflare op de proxy: zet records voor DKIM op "DNS only" (Cloudflare doet dat bij CNAMEs met _domainkey meestal al zelf).

Samenvatting

Een nieuwsbriefdienst heeft je MX-records niet nodig; laat ze staan.
DKIM gaat meestal via CNAME-records met een eigen selector. Neem over wat je dashboard toont.
Vul alleen het eerste deel van de naam in en let op de punt aan het eind van de waarde.
Zet een SPF-include alleen als de dienst erom vraagt, in je bestaande record, en blijf onder de 10 opzoekingen.
DMARC slaagt bij zulke diensten via DKIM-uitlijning; scherp je beleid pas aan als DKIM werkt.

Quiz

Opdracht

Z7.4 (opzoeken). Kijk hoe een nieuwsbriefdienst zelf zijn DKIM regelt.

Zoek het CNAME-record van k2._domainkey.mailchimp.com en van k3._domainkey.mailchimp.com. Schrijf de doelnamen over.
Zoek het SPF-record van mailchimp.com en tel hoeveel include:-onderdelen erin staan.

De controle vraagt de records live op bij het inleveren.

O7.4 (zelf instellen, oefenzone). Koppel een nagebootste nieuwsbriefdienst aan je oefenzone <code>.dnspractice.eu. In de oefenzone gebruik je de nepdienst newsletter-demo.dnspractice.eu; bij je echte domein neem je de waarden over uit het dashboard van je nieuwsbriefdienst.

Maak een CNAME k2._domainkey.<code>.dnspractice.eu naar dkim2.newsletter-demo.dnspractice.eu. Let op de naam: geen dubbele zone erachter.
Maak een CNAME k3._domainkey.<code>.dnspractice.eu naar dkim3.newsletter-demo.dnspractice.eu.
Zorg dat er op <code>.dnspractice.eu precies één SPF-record staat dat begint met v=spf1 en eindigt op ~all of -all. Voeg voor deze dienst geen include toe.
Laat je MX-records op <code>.dnspractice.eu staan: deze dienst heeft ze niet nodig.

Opdracht O7.4 Deze opdracht doe je in je eigen oefenzone. De oefenzone komt later beschikbaar.

Verder lezen

Deze pagina's beschrijven de stappen in de panelen van WebOké (DirectAdmin en Mijn WebOké). In andere panelen werkt het op dezelfde manier.

Cookies op WebOké

Cookie-instellingen

Noodzakelijk

Marketing