Handleiding SPF DKIM DMARC instellen voor e-mail

Een factuurmail die nooit aankomt, een offerte die in de spam belandt of een fraudeur die uit naam van uw bedrijf mailt: het zijn problemen die vaak beginnen bij ontbrekende e-mailauthenticatie. Met deze handleiding SPF DKIM DMARC instellen legt u vast welke systemen namens uw domein mogen verzenden en hoe ontvangende mailservers uw berichten moeten controleren.

Dat klinkt technisch, maar de basis bestaat uit DNS-records. Het echte aandachtspunt zit niet in het aanmaken van die records, maar in het volledig in kaart brengen van alle partijen die e-mail voor uw domein versturen. Denk naast uw gewone mailbox ook aan uw website, nieuwsbriefsoftware, facturatiepakket en CRM-systeem.

Waarom SPF, DKIM en DMARC samen nodig zijn

SPF, DKIM en DMARC lossen elk een ander deel van hetzelfde probleem op. SPF geeft aan welke verzendende servers toestemming hebben om e-mail te versturen. DKIM voegt een digitale handtekening toe, waarmee de ontvangende server kan controleren dat een bericht onderweg niet is aangepast. DMARC koppelt die controles aan uw zichtbare afzenderadres en vertelt de ontvangende partij wat te doen als een controle mislukt.

Alleen SPF instellen is daarom niet genoeg. Een legitieme mail kan bijvoorbeeld worden doorgestuurd, waardoor SPF bij de ontvanger faalt. DKIM kan die mail dan alsnog helpen verifiëren. DMARC geeft bovendien inzicht in misbruikpogingen en maakt het mogelijk om berichten die niet aan uw beleid voldoen in spam te plaatsen of te weigeren.

Voor een zzp’er met één mailbox is dit vooral bescherming van de eigen naam. Voor een mkb-organisatie gaat het ook om bedrijfscontinuïteit: klanten moeten erop kunnen vertrouwen dat facturen, wachtwoordresets en offertes werkelijk van uw organisatie komen.

Voor u begint: breng alle verzenders in beeld

Open eerst het DNS-beheer van uw domein en controleer wie daar wijzigingen mag uitvoeren. Maak vervolgens een overzicht van alle systemen die e-mail versturen met een adres als `naam@uwdomein.nl`. Dat overzicht voorkomt dat u een legitieme dienst per ongeluk blokkeert zodra DMARC strenger wordt ingesteld.

Neem in ieder geval uw e-mailprovider, websiteformulieren, webshop, boekhoudpakket, ticketomgeving, nieuwsbriefdienst en CRM mee. Controleer ook oude systemen. Een vergeten formulier op een oude landingspagina kan nog steeds berichten versturen en later voor foutmeldingen zorgen.

Vraag per dienst welke SPF-invoer, DKIM-selector en DKIM-sleutel nodig zijn. Gebruik altijd de gegevens van de betreffende leverancier. Kopieer geen voorbeeldrecord van een ander domein, want IP-adressen, selectors en sleutels zijn per omgeving verschillend.

SPF instellen: bepaal wie mag verzenden

Een SPF-record is een TXT-record op het hoofddomein. In de praktijk staat er maar één SPF-record per domein. Daarin combineert u de toegestane verzendbronnen.

Een vereenvoudigd voorbeeld ziet er zo uit:

“`text v=spf1 include:spf.uwmailprovider.nl include:mailingdienst.example -all “`

De onderdelen na `v=spf1` geven aan welke diensten e-mail mogen versturen. De afsluiting `-all` betekent dat andere verzenders niet zijn toegestaan. Gebruik deze strenge afsluiting pas wanneer uw overzicht compleet is. In een tijdelijke testfase kunt u `~all` gebruiken. Dat is minder streng, maar geen eindoplossing: het laat nog ruimte voor berichten die niet goedgekeurd zijn.

Het meest gemaakte SPF-probleem is het toevoegen van meerdere TXT-records die allemaal met `v=spf1` beginnen. Ontvangende servers kunnen zo’n configuratie als ongeldig zien. Voeg nieuwe verzenddiensten dus toe aan het bestaande record.

Let ook op de limiet van tien DNS-lookups binnen SPF. Elke `include` kan extra opzoekacties veroorzaken. Bij meerdere externe systemen raakt u die grens sneller dan verwacht. Het record inkorten door willekeurig onderdelen te verwijderen is geen goed idee. Kies liever voor een dienstspecifiek verzenddomein of laat de configuratie controleren voordat legitieme mail niet meer wordt afgeleverd.

DKIM instellen: geef e-mail een controleerbare handtekening

DKIM werkt met een sleutelpaar. De verzendende dienst bewaart de privésleutel en zet daarmee een handtekening in ieder uitgaand bericht. In uw DNS plaatst u de publieke sleutel. De ontvangende server gebruikt die om de handtekening te controleren.

U ontvangt meestal een selector, bijvoorbeeld `mail2026`, en een lange waarde voor een TXT-record. De naam van het record wordt dan bijvoorbeeld:

“`text mail2026._domainkey.uwdomein.nl “`

De waarde begint doorgaans met `v=DKIM1; k=rsa; p=` gevolgd door een lange tekenreeks. Plak deze sleutel zonder extra aanhalingstekens of handmatige regeleinden, tenzij uw DNS-paneel die zelf correct verwerkt. Eén ontbrekend teken is voldoende om DKIM te laten falen.

Meerdere DKIM-records zijn wel normaal. Uw zakelijke e-mailomgeving, nieuwsbriefsoftware en helpdesk kunnen elk een eigen selector gebruiken. Dat is juist wenselijk, omdat iedere partij met zijn eigen sleutel ondertekent.

DKIM is geen eenmalige actie. Sleutels kunnen worden vervangen, bijvoorbeeld na een beveiligingsincident of volgens het rotatiebeleid van een leverancier. Verwijder een oud record daarom pas als zeker is dat geen enkele dienst die selector nog gebruikt.

DMARC instellen: eerst meten, daarna handhaven

DMARC is het beleid boven op SPF en DKIM. Het record staat op `_dmarc.uwdomein.nl` en bevat onder meer een beleidswaarde: `p=none`, `p=quarantine` of `p=reject`.

Begin verstandig met een monitorende instelling:

“`text v=DMARC1; p=none; rua=mailto:dmarc-rapporten@uwdomein.nl; adkim=s; aspf=s; pct=100 “`

Met `p=none` vraagt u ontvangende partijen om berichten niet direct te blokkeren, maar wel rapporten te sturen. Die rapporten laten zien welke servers namens uw domein mailen, hoeveel berichten SPF of DKIM doorstaan en waar afwijkingen zitten. Gebruik hiervoor bij voorkeur een apart e-mailadres, want XML-rapporten zijn niet bedoeld voor dagelijks handmatig lezen.

De instellingen `adkim=s` en `aspf=s` vragen om strikte alignment. Dat betekent dat het domein in de zichtbare afzender nauw moet aansluiten op het domein dat SPF of DKIM controleert. Strikte alignment biedt betere bescherming, maar kan bij ingewikkelde verzendconstructies eerst aanpassingen vereisen. Als een externe dienst nog via een afwijkend subdomein verzendt, kan een ontspannen instelling tijdelijk praktischer zijn. Kies niet automatisch voor minder streng: onderzoek eerst of de dienst correct kan worden ingericht.

Analyseer de rapporten minimaal enkele weken, en langer wanneer u veel systemen of seizoensgebonden mailstromen heeft. Ziet u alleen bekende verzenders die correct slagen? Verhoog het beleid dan stapsgewijs naar:

“`text v=DMARC1; p=quarantine; rua=mailto:dmarc-rapporten@uwdomein.nl; pct=100 “`

Bij `quarantine` verzoeken ontvangende servers verdachte berichten in spam te plaatsen. Pas wanneer alles stabiel werkt, kiest u voor `p=reject`. Dan worden berichten die niet aan DMARC voldoen actief geweigerd. Dat is de beste bescherming tegen spoofing, maar alleen veilig als uw inventarisatie volledig is.

Controleer niet alleen DNS, maar ook echte e-mail

Na het aanpassen van DNS kan het door de ingestelde TTL enkele uren duren voordat wijzigingen overal zichtbaar zijn. Wacht daarna niet alleen op een groen vinkje in een configuratiescherm. Stuur testmails naar verschillende externe mailboxen en bekijk de berichtheaders. Daarin staat doorgaans of SPF, DKIM en DMARC als `pass` zijn beoordeeld.

Controleer ook de zichtbare afzender. Een technische controle kan slagen terwijl een nieuwsbriefdienst een afwijkend afzenderdomein gebruikt dat niet bij uw merk past. Voor ontvangers telt juist dat zichtbare adres mee.

Blijf na de invoering monitoren. Een nieuwe marketingtool, een verhuizing van uw website of een wijziging bij uw mailprovider kan de bestaande configuratie beïnvloeden. E-mailauthenticatie hoort daarom thuis in uw vaste beheerproces, net als back-ups, updates en toegangsbeheer.

Veelvoorkomende fouten bij SPF, DKIM en DMARC

De eerste fout is te snel `p=reject` activeren. Dat lijkt daadkrachtig, maar kan belangrijke berichten blokkeren als een vergeten applicatie nog niet is opgenomen. De tweede fout is denken dat een SPF-record alleen uw mailbox betreft. Mail vanaf de website of een facturatiepakket telt net zo goed mee.

Verder gaat het regelmatig mis door een DKIM-record op de verkeerde hostname, een selector die niet overeenkomt met de verzendende dienst of een DMARC-rapportadres dat nooit wordt bekeken. Ook DNS-records met oude waarden blijven soms staan na een migratie. Dat creëert onduidelijkheid en vergroot de kans op fouten bij later beheer.

Heeft u meerdere domeinen, behandel ieder domein apart. Een correct DMARC-record op uw hoofddomein beschermt niet automatisch een vergelijkbaar domein, een oud domein of een landendomein. Juist die vergeten domeinen zijn aantrekkelijk voor misbruikers.

E-mail is voor veel organisaties een bedrijfskritische voorziening. Wie SPF, DKIM en DMARC zorgvuldig instelt, maakt de kans kleiner dat klanten een nepbericht ontvangen én vergroot de kans dat echte bedrijfscommunicatie aankomt. Komt de configuratie samen met een migratie, meerdere verzenddiensten of een bredere IT-omgeving? Dan is een partij die uw domein, e-mail en beheeromgeving kent vaak de rustigste keuze – zodat problemen worden opgelost voordat ze uw werkdag raken.