Komt je zakelijke mail niet aan of belandt hij in de spammap? Dan ontbreken er vrijwel zeker één of meer van deze drie DNS-records op je domein: SPF, DKIM en DMARC — de "legitimatiebewijzen" waarmee ontvangende mailservers controleren of een mail écht van jou komt. Gmail en Microsoft zijn daar sinds 2024 flink strenger in geworden en weigeren mail zonder deze records steeds vaker, of zetten hem stilletjes in spam. Het goede nieuws: de records zijn in een kwartier te controleren en meestal snel te repareren.
Waarom ontvangers je mail weren
E-mail is een oud systeem. Technisch kan iedereen een mail versturen met jouw domeinnaam als afzender — daar hoeft niemand toestemming voor te vragen. Spammers en phishers maken daar dankbaar misbruik van. Ontvangende mailservers moeten dus bij elke binnenkomende mail de vraag beantwoorden: komt dit echt van het domein dat in de afzender staat?
SPF, DKIM en DMARC zijn de manier waarop jij die vraag vooraf beantwoordt. Het zijn simpele tekstregels (TXT-records) in de DNS van je domein, waarmee je publiek vastlegt wie namens jou mag mailen en wat ontvangers moeten doen als iets niet klopt.
Jarenlang kon je hier laks in zijn: mail kwam meestal toch wel aan. Dat is veranderd. Begin 2024 hebben Gmail en Yahoo hun eisen aangescherpt, en Microsoft is gevolgd. Wie in bulk mailt móét sindsdien SPF, DKIM en DMARC op orde hebben, maar ook bij gewone zakelijke mail weegt het zwaar mee. Geen records betekent in de praktijk: grotere kans op de spammap, of een botte weigering. Ik heb er recent voor honderden klantdomeinen DKIM en DMARC bij gezet, precies om deze reden — de tijd dat je zonder kon, is voorbij.
SPF: wie mag er namens jouw domein versturen
SPF (Sender Policy Framework) is een lijstje van servers die namens jouw domein mail mogen versturen. Denk aan de mailserver van je hoster, maar ook je nieuwsbrieftool of je boekhoudpakket. Een ontvangende server kijkt van welk IP-adres de mail komt en checkt of dat op jouw lijstje staat.
Een realistisch SPF-record ziet er zo uit:
v=spf1 a mx include:_spf.ch-email.nl include:spf.brevo.com ~all
In mensentaal: mail mag komen van de server waar mijn website op draait (a), van mijn eigen mailserver (mx), van de mailomgeving van mijn hoster en van mijn nieuwsbriefdienst. Alles wat daarbuiten valt (~all), behandel met wantrouwen.
Belangrijk om te weten: een domein mag maar één SPF-record hebben. Heb je er twee, dan is het geheel ongeldig en doen veel ontvangers alsof je helemaal geen SPF hebt. Daarover zo meer, want dit is met afstand de vaakst gemaakte fout.
DKIM: de digitale handtekening onder je mail
DKIM (DomainKeys Identified Mail) is een digitale handtekening die je mailserver automatisch onder elke uitgaande mail zet. In de DNS van je domein staat de bijbehorende publieke sleutel. De ontvanger kan daarmee twee dingen controleren: dat de mail echt via een server ging die jouw sleutel heeft, én dat de inhoud onderweg niet is aangepast.
Een DKIM-record staat op een subdomein met een zogeheten selector en ziet er ongeveer zo uit:
default._domainkey.jouwbedrijf.nl TXT
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQ..."
Die lange reeks tekens is de publieke sleutel. Je hoeft hem niet te begrijpen — het gaat erom dat hij er staat en hoort bij de sleutel waarmee jouw mailserver ondertekent. DKIM stel je niet zelf samen: je mailserver of maildienst genereert het sleutelpaar en vertelt je precies welk record je moet plaatsen. Doet je hoster het goed, dan staat het er al zonder dat jij ernaar hoefde om te kijken.
Let op: elke dienst die namens jou mailt heeft zijn éígen DKIM nodig. Je nieuwsbrieftool ondertekent met een andere sleutel dan je mailserver, dus die krijgt een eigen record met een eigen selector. Dat kan prima naast elkaar — anders dan bij SPF mag je meerdere DKIM-records hebben, omdat elk op zijn eigen selector-subdomein staat.
DMARC: wat moet de ontvanger doen bij twijfel
SPF en DKIM zeggen hoe het hóórt. DMARC (Domain-based Message Authentication, Reporting and Conformance) zegt wat ontvangers moeten doen als het níét klopt: niks (alleen rapporteren), in quarantaine zetten (spammap), of keihard weigeren. Bovendien kun je een adres opgeven waar ontvangers rapporten naartoe sturen, zodat je ziet wie er allemaal namens jouw domein mailt — legitiem én niet-legitiem.
Een verstandig start-record:
_dmarc.jouwbedrijf.nl TXT
"v=DMARC1; p=quarantine; rua=mailto:dmarc@jouwbedrijf.nl; pct=100"
In mensentaal: mail die de checks niet haalt mag in de spammap (p=quarantine), en stuur rapporten naar dit adres. Begin je net, dan is p=none (alleen rapporteren) een prima eerste stap: je ziet dan een paar weken lang wie er allemaal mailt namens je domein, vóórdat je iets blokkeert.
De vier fouten die ik het vaakst tegenkom
Na het nalopen van honderden klantdomeinen zie ik steeds dezelfde problemen terugkomen. In volgorde van hoe vaak:
1. Twee SPF-records
Met stip op één. Het gaat meestal zo: er stond al een SPF-record, en toen kwam er een nieuwsbrieftool of een CRM bij. De handleiding zei "voeg dit TXT-record toe", en dat is letterlijk gebeurd — als twééde record, naast het bestaande. Resultaat: twee SPF-records, wat technisch niet mag, en ontvangers die het geheel als ongeldig afkeuren. Je bent dan slechter af dan zonder SPF.
De oplossing is samenvoegen tot één record:
Fout: v=spf1 mx include:_spf.hoster.nl ~all
v=spf1 include:spf.nieuwsbrieftool.com ~all
Goed: v=spf1 mx include:_spf.hoster.nl include:spf.nieuwsbrieftool.com ~all
2. Te veel includes
Elke include: in je SPF-record kost een DNS-opzoeking, en de limiet ligt op tien — inclusief de opzoekingen die binnen die includes zelf gebeuren. Ga je eroverheen, dan faalt je SPF-check alsnog. Dit gebeurt sluipend: elke nieuwe dienst voegt er eentje toe, en na een paar jaar zit je erboven. De remedie: gooi includes weg van diensten die je niet meer gebruikt. Vaak staat er nog een relict van een pakket dat drie jaar geleden is opgezegd.
3. Vergeten bronnen
De omgekeerde fout: er mailt iets namens jouw domein dat níét in je SPF staat en géén DKIM heeft. Klassiekers zijn de nieuwsbrieftool, het boekhoudpakket dat facturen mailt, en de webshop die orderbevestigingen verstuurt. Die mail faalt de checks en belandt in spam — terwijl je gewone mail prima aankomt, dus je merkt het pas als een klant zegt dat hij de factuur nooit heeft gezien. Loop na welke systemen er allemaal mailen met jouw domein als afzender, en zorg dat elk daarvan in SPF staat of (liever ook) met DKIM ondertekent.
4. DMARC meteen op p=reject
Enthousiast begonnen en direct het strengste beleid ingesteld, zonder eerst te monitoren. Klinkt veilig, maar als er nog een legitieme bron is die je over het hoofd zag — dat boekhoudpakket weer — dan wordt díé mail nu keihard geweigerd. Bouw het op: start met p=none en rapporten, kijk een paar weken mee, fix wat er faalt, en ga dan pas naar quarantine en eventueel reject.
Zo check je zelf of het goed staat
Je hoeft hier geen techneut voor te zijn:
- learndmarc.com — de leukste check die er is. Je krijgt een uniek e-mailadres, stuurt daar een mailtje naartoe (vanuit je gewone mailprogramma, of vanuit je webshop), en ziet stap voor stap geanimeerd hoe SPF, DKIM en DMARC worden gecontroleerd. Drie keer groen? Dan zit je goed. Stuur ook eens een testmail vanuit je nieuwsbrieftool of contactformulier — juist die bronnen falen vaak.
- mxtoolbox.com — vul je domeinnaam in bij de SPF-, DKIM- en DMARC-checks en je ziet direct wat er staat, inclusief waarschuwingen bij een dubbel SPF-record of te veel lookups.
Belangrijkste tip: test niet alleen je gewone mail, maar élke bron. Een groene check vanuit Outlook zegt niets over de facturen uit je boekhoudpakket.
Mail vanuit je website: contactformulier en WooCommerce
Een apart hoofdstuk, want dit is een verrassend grote bron van "mijn mail komt niet aan"-meldingen. Mail vanuit je website — een contactformulier, orderbevestigingen uit WooCommerce, wachtwoord-resets — wordt standaard verstuurd via de PHP-mailfunctie van de webserver. Dat is mail zonder SMTP-authenticatie: geen login, vaak geen DKIM-handtekening, en soms een afzender-IP dat niet in je SPF staat.
Vroeger kwam dat er nog wel doorheen. Bij de strengere filters van nu is het een recept voor de spammap, of erger: het bericht verdwijnt gewoon. Extra pijnlijk bij een webshop, want de klant die geen orderbevestiging krijgt, belt jou.
De oplossing: laat je website mailen via SMTP, met een echt mailaccount op je eigen mailserver. Voor WordPress en WooCommerce doe je dat met een SMTP-plugin (zoals WP Mail SMTP of FluentSMTP): je vult de mailserver, poort 465 met SSL, en de inloggegevens van bijvoorbeeld noreply@jouwbedrijf.nl in, en vanaf dat moment gaat alle websitemail via dezelfde geauthenticeerde route als je gewone mail — mét geldige SPF en DKIM. Tien minuten werk, structureel verschil.
Wat je hoster hoort te regelen
Eerlijk is eerlijk: het grootste deel van dit verhaal is werk voor je hoster, niet voor jou. Bij een hostingpakket met mail hoort wat mij betreft standaard:
- een correct SPF-record dat de eigen mailservers dekt (zie ook DNS-records uitgelegd);
- DKIM dat automatisch wordt aangemaakt en ondertekend voor elk maildomein;
- een DMARC-record, minimaal in monitoringstand;
- een correcte PTR (reverse DNS) en HELO-naam op de mailserver zelf — dat is servertechniek waar jij als klant nooit bij hoeft;
- hulp bij het samenvoegen van je SPF als je er een externe dienst bij neemt.
Wat je hoster níét voor je kan weten: welke externe diensten jij gebruikt. Neem je een nieuwsbrieftool of nieuw boekhoudpakket in gebruik, geef dat dan even door, zodat het record in één keer goed wordt aangepast in plaats van dat er een tweede SPF-record bij wordt geplakt.
Twijfel je of het bij jouw domein goed staat? Doe de test op learndmarc.com — die laat binnen een paar minuten precies zien wat er aan SPF, DKIM en DMARC ontbreekt.