Je verstuurt een offerte, een orderbevestiging of een reactie op een contactformulier, en de ontvanger ziet hem nooit. Niet in de inbox, niet eens in spam. Of een klant belt met de vraag waarom jouw e-mails bij Gmail als verdacht worden gemarkeerd, terwijl er aan jouw kant niets bijzonders gebeurt.

De oorzaak is bijna altijd hetzelfde: SPF, DKIM of DMARC staat niet goed ingesteld. Of ontbreekt helemaal.

Dit zijn geen obscure instellingen voor grote bedrijven. Elke website met een eigen domeinnaam heeft ze nodig. Bij migraties zien we regelmatig dat SPF-records nog verwijzen naar een server van de vorige provider, dat DKIM nooit is geactiveerd, of dat DMARC überhaupt nooit is aangemaakt. Het gevolg is dat e-mails ergens onderweg verdwijnen, vaak zonder foutmelding, soms pas weken later opgemerkt.

E-maildeliverability is nooit alleen ‘een recordje zetten’. Hieronder leggen we uit wat deze drie records doen, hoe je ze instelt via DirectAdmin, en waar het in de praktijk meestal misgaat.

Inhoudsopgave

Wat is SPF?

SPF (Sender Policy Framework) legt vast welke mailservers namens jouw domein e-mail mogen versturen. Het is een TXT-record in DNS, en hoort bij de basis van een werkende mailflow.

Stel, jouw domein is bedrijf.nl. Met SPF zeg je tegen de buitenwereld welke servers namens dat domein mogen mailen. Ontvangende mailservers van Gmail, Outlook en Microsoft 365 checken dat record bij binnenkomst. Staat de verzendende server er niet in, dan is de kans groot dat het bericht in spam belandt of stilletjes wordt geweigerd. Wil je meer achtergrond bij hoe TXT-records zich verhouden tot A, MX en de andere records, dan staat dat in een aparte uitleg over DNS-records.

Voorbeeld van een SPF-record:

v=spf1 include:spf.lionserve.nl ~all
  • v=spf1: verplicht, geeft aan dat dit een SPF-record is
  • include:spf.lionserve.nl: verwijst naar de mailservers van Lionserve
  • ~all: softfail. Alles wat niet in de lijst staat, wordt als verdacht gemarkeerd maar niet altijd geweigerd
  • -all: hardfail. Alles wat niet in de lijst staat, wordt hard geweigerd

Softfail of hardfail?
Twijfel je of alle verzendende systemen in je record staan, dan is ~all de veilige keuze. Onbekende servers worden dan wel als verdacht gemarkeerd, maar niet per se geweigerd. Pas overstappen naar -all als je echt zeker weet dat alle legitieme verzenders dekking hebben, inclusief externe tools die namens jouw domein mailen. Een te vroege -all blokkeert in het slechtste geval je eigen factuur- of nieuwsbriefmail.

Veelgemaakte fout: meerdere SPF-records
Een domein mag maar één SPF-record hebben. Toch zien we dit regelmatig misgaan. De vorige hostingprovider had bij het opzetten al iets toegevoegd, en daar komt later een record voor een externe nieuwsbriefdienst bij. Twee SPF-records betekent permerror, en dan valt de hele SPF-controle om. Heb je meerdere verzendende systemen, voeg ze dan samen in één record:

v=spf1 include:spf.lionserve.nl include:sendgrid.net ~all

SPF en forwarding
Als een ontvanger jouw bericht doorstuurt naar een ander adres, verandert de verzendende server zonder dat het From-adres meewijzigt. De volgende ontvanger ziet dan een IP-adres dat niet in jouw SPF-record staat, en dat geeft een SPF-fail. Dat is geen fout in jouw configuratie, het is de manier waarop SPF werkt. DKIM lost dit op, want een geldige handtekening overleeft het doorsturen.

Wat is DKIM?

DKIM (DomainKeys Identified Mail) voegt een digitale handtekening toe aan elke uitgaande e-mail. Waar SPF kijkt naar welke server de e-mail verstuurt, controleert DKIM of de inhoud onderweg niet is aangepast.

Onder de motorkap zit een sleutelpaar. De mailserver ondertekent elke uitgaande e-mail met een privésleutel, en de ontvanger haalt de publieke sleutel op uit jouw DNS om de handtekening te verifiëren. Klopt die, dan is duidelijk dat het bericht authentiek is en niemand er tijdens transport iets aan heeft veranderd.

Voorbeeld van een DKIM-record in DNS:

default._domainkey.bedrijf.nl  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GN..."
  • default: de selector (naam van de sleutel)
  • _domainkey: verplicht achtervoegsel
  • k=rsa: versleutelingsmethode
  • p=...: de publieke sleutel

Bij Lionserve wordt de DKIM-sleutel automatisch aangemaakt zodra je een e-mailaccount activeert via DirectAdmin. Je hoeft zelf niets te genereren of te kopiëren; de sleutel staat al in de DNS-zone van jouw domein. Heb je nog geen e-mailaccount aangemaakt, dan beschrijven we dat stap voor stap in een aparte handleiding. Loop daarna kort door DirectAdmin → DNS Beheer om te bevestigen dat default._domainkey.jouwdomein.nl aanwezig is. Bij een herinstallatie van een account kan de sleutel veranderen, dus na ingrepen op accountniveau is dit altijd het moment om even te kijken.

DKIM en doorsturen
Een DKIM-handtekening overleeft het doorsturen van een bericht, zolang de inhoud onderweg niet wordt gewijzigd. Daarmee is DKIM het stabielere mechanisme voor mailflow die via aliassen of doorstuuradressen loopt, juist op de plekken waar SPF tegen zijn grenzen aanloopt.

Wat is DMARC?

DMARC (Domain-based Message Authentication, Reporting and Conformance) is de derde laag. Voor veel domeinen ook de ontbrekende. Het koppelt SPF en DKIM aan een beleid: wat moet een ontvangende server doen als een bericht de controles niet doorstaat?

DMARC is een TXT-record in je DNS, net als SPF en DKIM:

v=DMARC1; p=none; rua=mailto:[email protected]
  • v=DMARC1: verplicht, geeft aan dat dit een DMARC-record is
  • p=none: het beleid. none = alles toelaten en alleen rapporteren, quarantine = verdachte e-mail in spam, reject = verdachte e-mail weigeren
  • rua=mailto:[email protected]: e-mailadres voor de (wekelijkse) DMARC-rapportages

Het verschil met SPF en DKIM zit in de regie. DMARC bepaalt wat er gebeurt als SPF of DKIM faalt. Je kunt zeggen dat zulke berichten in de spammap moeten belanden (p=quarantine), of dat ze hard worden geweigerd (p=reject).

Welk beleid kiezen?

  • p=none: begin hier. Je ontvangt rapportages, maar al je e-mails worden nog doorgelaten, ook die niet authentiek zijn. Veilig voor een eerste fase.
  • p=quarantine: een tussenstap. Berichten die SPF/DKIM niet doorstaan belanden in spam, maar worden niet geweigerd.
  • p=reject: de strengste optie. Berichten die de controles niet doorstaan, komen niet aan. Pas zinvol als je echt zeker bent dat alle legitieme mailflow gedekt is.

Voor nieuwe domeinen kiezen we standaard p=none. Dat geeft inzicht in wie er namens jouw domein mailt, zonder dat legitieme berichten worden geblokkeerd. Pas als de rapportages een tijdje stabiel zijn, is het verstandig om door te schakelen naar quarantine of reject.

Waarom zijn SPF, DKIM en DMARC zo belangrijk?

Met deze drie records dek je drie problemen die anders moeilijk te grijpen zijn.

1. Spoofing. Iemand stuurt e-mail namens jouw domein en jij hoort daar pas over via een verbaasde klant. SPF maakt duidelijk welke servers namens jouw domein mogen mailen, en zorgt dat ontvangers de rest kunnen herkennen.

2. Spamfilters. Gmail, Outlook en Microsoft 365 wegen SPF, DKIM en DMARC zwaar mee. Zonder deze records komen ook legitieme berichten sneller in spam terecht, en in sommige gevallen worden ze stil geweigerd. De controles zijn de afgelopen jaren strenger geworden, vooral richting zakelijke ontvangers.

3. Verstoringen bij migraties. Wissel je van provider en blijft het oude SPF-record staan, dan verwijst het nog naar de servers van die oude provider. Op het moment van overstap zakt de deliverability dan in, vaak zonder duidelijke foutmelding. Dit is een van de meest voorkomende oorzaken van problemen na een migratie.

Sinds begin 2024 vereisen Gmail en Yahoo bovendien dat grote verzenders (meer dan 5000 e-mails per dag) DMARC hebben ingesteld. Voor de meeste domeinen geldt dat niet als harde verplichting, maar het is wel de richting waarin alle grote ontvangers bewegen.

Hoe controleer je of je records correct werken?

De snelste route is via MXToolbox (mxtoolbox.com). Een gratis online tool die je hele DNS-configuratie naloopt:

SPF controleren: ga naar mxtoolbox.com/spf.aspx en vul jouw domeinnaam in. Je ziet of het record geldig is, welke servers erin staan en of er foutmeldingen zijn (permerror, syntax error en dergelijke).

DKIM controleren: via mxtoolbox.com/dkim.aspx. Voer het domein en de selector in (meestal default). Het resultaat laat zien of de publieke sleutel geldig is.

DMARC controleren: via mxtoolbox.com/dmarc.aspx. Voer jouw domeinnaam in en je ziet het actieve DMARC-beleid.

Houd er rekening mee dat DNS-wijzigingen tot 24 uur kunnen duren om overal te propageren. Test je vlak na een wijziging, dan zie je vaak nog het oude record. Wil je sneller controleren, dan helpt het om de TTL alvast een dag van tevoren te verlagen.

Instellen via DirectAdmin

Hieronder de stappen voor het concrete werk in DirectAdmin.

Stap 1: Inloggen op DirectAdmin en naar DNS Beheer

  1. Log in op het WHMCS-klantportaal via lionserve.nl
  2. Klik op jouw pakketoverzicht
  3. Klik op DirectAdmin
  4. Ga naar DNS Beheer in het linkermenu
  5. Selecteer jouw domein

Je ziet nu alle DNS-records van jouw domein. Voor het volgende deel werken we vanuit dit scherm.

Stap 2: SPF-record instellen

Kijk eerst of er al een SPF-record bestaat. Bij domeinen die ergens anders vandaan komen, staat er vaak nog iets van de vorige provider. Pas dat in dat geval aan in plaats van een tweede record toe te voegen.

  1. Klik op “Record toevoegen” of “Domein toevoegen” (afhankelijk van jouw DirectAdmin-versie)
  2. Type: TXT
  3. Name: @ (of laat leeg; dit is je rootdomein)
  4. Value: v=spf1 include:spf.lionserve.nl ~all
  5. TTL: 3600 of 14400
  6. Klik Voeg toe

Twee SPF-records naast elkaar geeft permerror, en daarmee valt de SPF-controle voor jouw domein om. Eén combinatierecord is altijd de juiste route.

Stap 3: DKIM-record controleren

Heb je een e-mailaccount aangemaakt in DirectAdmin (via E-mail → E-mailaccounts), dan is de DKIM-sleutel meestal al gegenereerd. Loop dit kort na:

  1. Ga in DirectAdmin naar E-mail → DKIM Management
  2. Bekijk welke accounts er staan en of DKIM voor die accounts ingeschakeld is
  3. Ga terug naar DNS Beheer en zoek naar een record dat begint met default._domainkey
  4. Dat record bevat je publieke DKIM-sleutel, en staat er standaard al in

Mist DKIM in je DNS, dan komt dat in de praktijk meestal door een oudere migratie of een handmatig opgezet domein. Ga in dat geval naar E-mail → DKIM Management en forceer een herinstallatie. DirectAdmin plaatst de sleutel dan automatisch terug in je DNS.

Stap 4: DMARC-record toevoegen

DMARC is technisch optioneel, maar bij modernere spamfilters van Gmail en Microsoft 365 nauwelijks meer te missen. We adviseren om hem altijd te zetten, ook in zijn lichtste vorm:

  1. In DirectAdmin → DNS Beheer, klik weer op “Record toevoegen”
  2. Type: TXT
  3. Name: _dmarc
  4. Value: v=DMARC1; p=none; rua=mailto:[email protected]
  5. TTL: 3600
  6. Klik Voeg toe

Vervang jouwdomein.nl door je eigen domein. Met dit beleid ontvang je periodieke rapportages over wie er namens jouw domein mailt, zonder dat legitieme berichten worden geblokkeerd.

Veelgemaakte fouten

SPF van oude provider niet verwijderd

Bij provider-wissels blijft het oude SPF-record vaak gewoon staan, ook na de migratie. Het wijst dan nog naar de mailservers van de vorige partij. Op het moment dat de DNS-wijziging actief wordt, valt jouw deliverability stil omdat de nieuwe verzendende server niet in het oude record voorkomt. Oplossing: oude SPF-records opruimen en het juiste record terugzetten: v=spf1 include:spf.lionserve.nl ~all.

Twee SPF-records tegelijk

DNS staat maar één SPF-record per domein toe. Twee records geven permerror. Oplossing: verwijder het oude record. Heb je meerdere verzendende systemen, voeg ze dan samen in één record in plaats van afzonderlijk te laten staan.

DKIM zonder DMARC

DKIM op zichzelf helpt, maar zonder DMARC weet de ontvangende server niet wat te doen als SPF of DKIM faalt. Oplossing: voeg minimaal v=DMARC1; p=none toe. Dat kost niets en geeft je inzicht in wat er met jouw mailflow gebeurt aan de andere kant.

Verkeerde TTL

Test je vlak na een wijziging en zie je nog het oude record, dan is dat bijna altijd DNS-cache. Oplossing: verlaag de TTL een dag van tevoren naar 300 seconden. Zodra de records stabiel zijn, kan de TTL terug naar 3600 of 14400.

Problemen oplossen

MXToolbox zegt: permerror op SPF

Een permerror betekent dat je SPF-record syntactisch ongeldig is. De drie meest voorkomende oorzaken:

  • Twee SPF-records tegelijk in dezelfde zone
  • Een typefout (bijvoorbeeld includ: in plaats van include:)
  • Een TXT-record waar per ongeluk een tweede SPF-fragment in is geplakt

Oplossing: ga in DirectAdmin naar DNS Beheer, loop de TXT-records langs en zorg dat er precies één SPF-record overblijft. Controleer daarna de syntaxis.

MXToolbox zegt: DKIM-record niet gevonden

Dit gebeurt als er nog geen e-mailaccount is geactiveerd, of als DKIM Management om een of andere reden niet correct is opgezet.

  • Controleer: is er een e-mailaccount aangemaakt in DirectAdmin? Zo niet, maak er eentje aan en wacht een paar minuten.
  • Forceer een regeneratie: ga naar DirectAdmin → E-mail → DKIM Management, selecteer het account en klik op “Regenerate”.
  • Controleer DNS: kijk in DirectAdmin → DNS Beheer of default._domainkey aanwezig is. Zo ja, dan werkt DKIM aan jouw kant.

E-mails komen nog steeds in spam na SPF/DKIM/DMARC

SPF, DKIM en DMARC zijn noodzakelijk maar niet voldoende. In de praktijk wegen ontvangers zoals Gmail en Microsoft 365 meerdere factoren mee:

  • IP-reputatie: staat de mailserver-IP op een blacklist? Te checken via mxtoolbox.com/blacklists.aspx.
  • Inhoud: e-mails met veel links, grote bijlagen of typisch spammerige formuleringen vallen alsnog op.
  • Verzendgeschiedenis: bij een net opgezet domein duurt het soms een paar weken voordat Gmail en Outlook genoeg vertrouwen hebben opgebouwd.
  • DMARC-beleid: met p=none rapporteer je alleen. Berichten worden niet gemist door het ontbreken van een strenger beleid, maar door de andere factoren in deze lijst.

Veelgestelde vragen

Hoe weet ik of mijn SPF-record werkt?

Voer jouw domeinnaam in op mxtoolbox.com/spf.aspx. Je ziet meteen of het record geldig is, welke servers erin staan en of er fouten zijn.

Wat is het verschil tussen ~all en -all in SPF?

~all (softfail) markeert onbekende servers als verdacht, maar weigert ze niet altijd. -all (hardfail) weigert e-mail van onbekende servers direct. Begin met ~all en stap pas over op -all als alle legitieme verzenders bekend zijn.

Kan ik meerdere SPF-records hebben?

Nee. Een domein mag maar één SPF-record hebben. Meerdere records geven een permerror. Combineer alles in één record.

Wat gebeurt er als DKIM ontbreekt?

Zonder DKIM kan een ontvanger niet verifiëren dat de inhoud onderweg ongewijzigd is gebleven. Gmail en Outlook wegen DKIM zwaar mee in hun spamfilter, en bij DMARC-controles wordt een ontbrekende handtekening al snel als niet-authentiek beschouwd.

Is DMARC verplicht?

Technisch niet. Maar zonder DMARC heb je geen zicht op wie er namens jouw domein mailt en loop je risico op spoofing. Voor de meeste domeinen is een p=none-record al voldoende.

Hoe lang duurt DNS-propagatie?

Afhankelijk van de TTL tussen de 15 minuten en 24 uur. Verlaag de TTL alvast een dag van tevoren als je snel wilt testen na een wijziging.

Waarom komen mijn e-mails nog steeds in spam na het instellen van SPF en DKIM?

SPF en DKIM zijn noodzakelijk maar niet voldoende. IP-reputatie, inhoud en verzendgeschiedenis spelen ook mee. Controleer of het IP-adres van de mailserver op een blacklist staat via mxtoolbox.com/blacklists.aspx.

Wat betekent DMARC quarantine?

Met p=quarantine instrueer je ontvangende mailservers om berichten die de SPF/DKIM-controles niet doorstaan in spam te plaatsen in plaats van te weigeren. Een tussenstap tussen p=none en p=reject.

Hoe controleer ik welke DNS-records ik heb?

Via DirectAdmin → DNS Beheer zie je alle records van jouw domein. Vanaf de terminal werkt dig TXT jouwdomein.nl, en online kan het via dnschecker.org.

SPF, DKIM en DMARC zijn geen onderwerpen die je één keer instelt en daarna nooit meer aanraakt. Wijzigt er iets in je mailflow, komt er een externe tool bij die namens jouw domein verstuurt, of verhuist een onderdeel naar een andere provider, dan is het verstandig om de records opnieuw na te lopen. Loop je tegen iets aan dat je niet helemaal vertrouwt in DirectAdmin, dan helpt het Lionserve-supportteam graag mee kijken.

Reacties zijn gesloten.