SPF, DKIM en DMARC instellen: de complete stappen voor Google Workspace en Office 365

Zonder correct ingestelde SPF, DKIM en DMARC belandt zakelijke mail steeds vaker in spam of wordt hij helemaal geweigerd, ongeacht hoe goed de inhoud is. Sinds Gmail en Yahoo hun eisen voor bulkverzenders hebben aangescherpt, is dit geen optionele technische verfijning meer maar een randvoorwaarde om überhaupt de inbox te bereiken — ook bij kleinschalige, gerichte B2B-outreach.

Waarom deze drie records samen werken

SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail) en DMARC (Domain-based Message Authentication, Reporting and Conformance) zijn drie afzonderlijke DNS-records die elk een ander deel van hetzelfde probleem oplossen: bewijzen dat een mail écht van jouw domein komt.

SPF is een lijst van IP-adressen en diensten die namens jouw domein mogen versturen. DKIM voegt een digitale handtekening toe aan elke uitgaande mail, zodat de ontvanger kan verifiëren dat de inhoud onderweg niet is aangepast. DMARC koppelt beide aan elkaar en vertelt de ontvangende server wat te doen als een mail niet aan SPF of DKIM voldoet — en stuurt je rapporten terug.

Zonder DMARC werken SPF en DKIM los van elkaar en kan een aanvaller er nog steeds omheen. Zonder SPF of DKIM heeft DMARC niets om op te bouwen. Ze horen bij elkaar, en in deze volgorde stel je ze meestal ook in: eerst SPF, dan DKIM, dan DMARC.

Een veelgemaakte misvatting is dat één van de drie al genoeg is. SPF alleen controleert bijvoorbeeld het envelope-afzenderadres (het technische 'return-path'), niet noodzakelijk het adres dat de ontvanger in zijn mailclient ziet — een aanvaller kan dat verschil misbruiken. DKIM alleen bewijst dat een handtekening geldig is, maar niet per se dat die hoort bij het domein dat de ontvanger ziet. Pas DMARC dwingt die twee domeinen expliciet tot overeenstemming (alignment), en dát sluit het gat.

SPF instellen: stap voor stap

SPF is een TXT-record op je hoofddomein (niet op een subdomein) met een lijst van toegestane verzendbronnen. Voor Google Workspace begint dat record meestal met v=spf1 include:_spf.google.com, voor Office 365 met v=spf1 include:spf.protection.outlook.com, gevolgd door -all of ~all aan het einde.

Heb je naast Google Workspace of Office 365 ook andere diensten die namens je domein versturen — een CRM, een facturatietool, een marketingplatform — dan moet elke dienst als aparte include worden toegevoegd aan hetzelfde record. Een domein mag maar één SPF-record hebben; twee losse TXT-records met v=spf1 breekt de check voor alle verzenders.

Een record dat klaar is voor bijvoorbeeld Google Workspace plus een los outreach-platform kan er zo uitzien: v=spf1 include:_spf.google.com include:mail.outreachplatform.example ~all. De volgorde van de includes maakt inhoudelijk niets uit, maar het totaal aantal includes wel — elke include telt mee in de limiet van 10 DNS-lookups die het SPF-protocol toestaat.

• Log in bij je domeinregistrar of DNS-provider (niet bij Google of Microsoft) om het TXT-record aan te maken.
• Gebruik include: voor elke losse verzendende dienst, gescheiden door spaties in één record.
• Eindig met -all (streng, aanbevolen zodra alles getest is) of ~all (soft fail, handig tijdens het testen).
• Controleer het aantal DNS-lookups: SPF staat maximaal 10 include-lookups toe, meer breekt de check stilzwijgend.

DKIM instellen in Google Workspace en Office 365

DKIM werkt anders dan SPF: je genereert de sleutel niet zelf, maar activeert hem in het beheerpaneel van je mailprovider, die vervolgens een CNAME- of TXT-record teruggeeft dat je bij je DNS-provider moet plaatsen.

In Google Workspace ga je naar Beheerdersconsole, Apps, Google Workspace, Gmail, Authenticatie e-mail, en genereer je daar een nieuwe DKIM-sleutel voor het gewenste domein. Google geeft een TXT-record terug met een selector (vaak google._domainkey) dat je bij je DNS toevoegt; activeer de sleutel pas ná bevestiging dat het DNS-record zichtbaar is.

In Office 365 ga je naar het Microsoft 365 Defender-portaal, Email & collaboration, Policies & rules, DKIM, selecteer je het domein en laat je Microsoft twee CNAME-records genereren (selector1 en selector2). Beide moeten bij je DNS-provider worden toegevoegd voordat je DKIM daadwerkelijk aanzet.

DMARC instellen: het sluitstuk

Zodra SPF en DKIM allebei correct zijn en slagen voor je belangrijkste verzendbronnen, voeg je een DMARC-record toe op _dmarc.jouwdomein.nl, bijvoorbeeld: v=DMARC1; p=none; rua=mailto:rapporten@jouwdomein.nl; pct=100.

Begin altijd met p=none. Dat activeert alleen de rapportage, niet de blokkade, zodat je een paar weken kunt zien welke bronnen namens je domein versturen en of ze slagen. Pas daarna verhoog je naar p=quarantine en uiteindelijk p=reject, zoals in de opbouw die grote mailboxproviders inmiddels verwachten.

Waarom Gmail en Yahoo dit nu afdwingen

Sinds de aangescherpte bulkverzendeisen van Gmail en Yahoo is geldige SPF/DKIM-authenticatie en een DMARC-record op p=none of hoger verplicht voor iedereen die een substantieel aantal mails per dag naar hun gebruikers stuurt. Ontbreekt dit, dan weigert Gmail de mail steeds vaker direct, in plaats van hem naar spam te sturen.

Voor kleinschalige, gerichte B2B-outreach lijkt dat op het eerste gezicht niet te gelden — je verstuurt geen honderdduizenden mails. Maar mailboxproviders kijken naar domeinreputatie in de breedte, niet alleen naar volume, en een domein zonder deze records wordt sowieso met meer wantrouwen behandeld, ongeacht hoe klein de verzendlijst is.

Veelgemaakte fouten en hoe je ze voorkomt

De meest voorkomende fout is twee SPF-records naast elkaar laten staan, bijvoorbeeld één van Google Workspace en één losstaand voor een marketingtool — DNS staat dat toe, maar mailservers lezen dan willekeurig één van de twee en de check faalt. Voeg altijd alles samen in één record.

Een tweede fout is DKIM wel activeren in het beheerpaneel, maar vergeten het bijbehorende DNS-record te plaatsen — of andersom. Beide kanten moeten kloppen voordat de handtekening werkt.

Een derde fout is DMARC direct op p=reject zetten zonder eerst te testen. Als een legitieme tool nog niet in SPF staat, verdwijnt die mail dan net zo hard als een spoofpoging.

Een vierde, vaak over het hoofd geziene fout is de TTL (time to live) van een DNS-record te hoog laten staan tijdens het testen. Bij een TTL van 24 uur duurt het na elke correctie een volledige dag voordat mailservers wereldwijd de nieuwe waarde zien, wat het testen onnodig traag maakt. Verlaag de TTL tijdelijk naar bijvoorbeeld 300 seconden tijdens de instelfase, en zet hem pas na afronding weer omhoog.

• Eén SPF-record per domein, met alle verzendbronnen als losse include's.
• DKIM-sleutel zowel activeren in het beheerpaneel als het DNS-record daadwerkelijk plaatsen.
• DMARC altijd starten op p=none, pas na controle van de rapporten opschalen.
• Elke nieuwe verzendtool die je toevoegt, meteen meenemen in SPF en waar mogelijk DKIM.

Hoe dit samenkomt bij het versturen van cold e-mail

Bij gerichte B2B-cold-e-mail — persoonlijke berichten naar specifieke besluitvormers, in kleine volumes — is een correct ingericht drietal SPF, DKIM en DMARC de basisvoorwaarde om serieus genomen te worden door de ontvangende mailserver, nog vóórdat de inhoud van je mail ook maar wordt bekeken.

Bij LDM controleren we deze drie records altijd vóór de eerste verzending vanaf een nieuw domein, en adviseren we losse verzenddomeinen te gebruiken voor outreach, gescheiden van het hoofddomein waarop je facturen en interne mail draaien — zodat een probleem met het ene nooit de reputatie van het andere raakt.

Veelgestelde vragen