SPF, DKIM en DMARC instellen: stapsgewijze gids voor koude e-mail

Als u koude e-mails verstuurt vanaf uw eigen domein, bepalen drie DNS-records of ontvangende servers geloven dat de e-mail echt van u komt: SPF, DKIM en DMARC. Zonder deze records kan zelfs een goed geschreven eerste e-mail worden weggefilterd voordat iemand hem leest.

Deze gids is bedoeld voor oprichters en verkoopteams die outreach versturen vanaf een adres als you@yourcompany.com, meestal via Google Workspace. Wij (Outreach) lopen elk record door in de volgorde waarin u het zou moeten instellen, tonen de recordformaten precies zoals de helppagina's van Google en de RFC's ze publiceren en wijzen op de fouten waardoor een record er goed uitziet terwijl het ongemerkt faalt.

U hoeft geen DNS-expert te zijn. U hebt toegang nodig tot de DNS-instellingen van uw domein (bij uw registrar of DNS-host) en, voor DKIM, beheerderstoegang tot Google Workspace.

Wat zijn SPF, DKIM en DMARC, elk in één zin?

SPF vermeldt welke servers e-mail mogen versturen voor uw domein, DKIM voegt een cryptografische handtekening toe die bewijst dat een bericht niet is vervalst of gewijzigd, en DMARC vertelt ontvangers wat ze moeten doen wanneer een bericht die controles niet doorstaat. Alle drie worden gepubliceerd als TXT-records in de DNS van uw domein.

Ze werken samen. SPF en DKIM bewijzen elk iets heel beperkts; DMARC koppelt die bewijzen aan het adres dat mensen echt zien in de afzenderregel (From).

Zijn deze records echt verplicht voor koude e-mail?

Ja – minstens SPF of DKIM is vereist voor elke afzender naar Gmail en Yahoo, en bulkverzenders hebben alle drie nodig. Dit is geen best-practice-suggestie; het staat in de gepubliceerde afzenderregels van beide aanbieders.

De richtlijnen voor e-mailafzenders van Google zeggen dat alle afzenders “SPF- of DKIM-e-mailauthenticatie moeten instellen voor hun verzenddomeinen.” Afzenders van “meer dan 5.000 berichten per dag naar Gmail-accounts” moeten bovendien “SPF en DKIM instellen” plus “DMARC-e-mailauthenticatie voor hun verzenddomein”, en het From-domein moet zijn afgestemd op het SPF- of DKIM-domein. Deze regels zijn op 1 februari 2024 ingegaan.

De aanbevelingen in de Sender Hub van Yahoo komen daarmee overeen: elke afzender moet “minimaal SPF of DKIM implementeren”, en bulkverzenders moeten “zowel SPF als DKIM implementeren” en “een geldig DMARC-beleid publiceren met minstens p=none.”

Een klein programma voor koude e-mail zal misschien nooit 5.000 berichten per dag halen. Zet toch alle drie op: het kost niets, het kost een middag en u hoeft nooit uit te zoeken waar de grens precies ligt.

Hoe stelt u SPF in?

Voeg op uw hoofddomein één TXT-record toe dat begint met v=spf1, elke dienst opsomt die e-mail voor u verstuurt en eindigt op ~all. Voor een domein dat alleen via Google Workspace verzendt, geeft de pagina van Google over SPF instellen precies dit record:

v=spf1 include:_spf.google.com ~all

Stappen:

1. Log in bij de DNS-instellingen van uw domeinhost.
2. Maak een TXT-record aan. Voor het veld host of naam zegt Google dat u @ invoert als u het record aan het hoofddomein toevoegt in plaats van aan een subdomein.
3. Plak het record als waarde en sla op.
4. Wacht. Google merkt op: “Het kan tot 48 uur duren voordat SPF-authenticatie gaat werken.”

Als ook andere diensten e-mail vanaf uw domein versturen – een nieuwsbriefprogramma, een CRM-systeem, een dienst voor transactionele e-mail – heeft elk daarvan een eigen include: nodig in hetzelfde record. Op de pagina van Google staan deze gecombineerde voorbeelden:

v=spf1 include:_spf.google.com include:amazonses.com ~all
v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all
v=spf1 include:_spf.google.com include:_spf.salesforce.com ~all

Gebruik de include-waarde die elke verzenddienst zelf in de documentatie geeft; probeer die niet te raden.

Moet het SPF-record eindigen op ~all of -all?

In de installatiegids van Google staat ~all, en dat is de veilige standaard zolang u nog ontdekt welke diensten er allemaal voor u verzenden. De twee eindes betekenen iets anders in RFC 7208, de SPF-standaard:

• ~all (softfail) is “Een zwakke verklaring van de publicerende ADMD dat de host waarschijnlijk niet is geautoriseerd.”
• -all (fail) is “Een expliciete verklaring dat de client niet is geautoriseerd om het domein te gebruiken in de opgegeven identiteit.”

Met -all krijgt een verzenddienst die u bent vergeten op te nemen een harde afwijzing. Zodra DMARC is ingesteld en de rapporten laten zien dat elke legitieme bron slaagt, doet het einde van het SPF-record er minder toe, omdat het beleid van DMARC dan de instructie wordt die ontvangers volgen.

Waarom faalt SPF bij te veel includes?

Omdat een SPF-controle hooguit 10 DNS-opzoekingen mag veroorzaken; daarboven wordt het hele resultaat een fout. RFC 7208, paragraaf 4.6.4 zegt dat implementaties “het totale aantal van die termen tijdens de SPF-evaluatie MOETEN beperken tot 10” en dat “als deze limiet wordt overschreden, de implementatie ‘permerror’ MOET teruggeven.”

De termen die meetellen zijn include, a, mx, ptr, exists en de modifier redirect. Cruciaal is dat de telling de hele evaluatie omvat – een include: die zelf weer includes bevat, gebruikt dus meerdere van uw 10 op. Google formuleert het op zijn eigen pagina als “Een SPF-record kan maximaal 10 include:-tags bevatten”; de RFC is de strengere lezing, omdat geneste opzoekingen ook meetellen.

Als u in de loop der jaren meerdere verkoop- en marketingtools hebt toegevoegd, verwijder dan de tools die u niet meer gebruikt voordat u nieuwe includes toevoegt.

Wat gebeurt er als een domein twee SPF-records heeft?

SPF faalt met een fout – twee records worden behandeld als een kapotte configuratie, niet als twee lijsten die worden samengevoegd. RFC 7208 zegt dat wanneer er meer dan één v=spf1-record voor een domein bestaat, de controle “het resultaat ‘permerror’ oplevert.”

Een veelvoorkomende oorzaak: iemand voegt een tweede TXT-record toe voor een nieuwe tool in plaats van het bestaande record aan te passen. De oplossing is ze samen te voegen tot één record met meerdere include:-termen, zoals in de voorbeelden hierboven.

Hoe zet u DKIM aan in Google Workspace?

Genereer een sleutel in de Beheerdersconsole, publiceer die als TXT-record op google._domainkey en klik dan op “Verificatie starten.” De pagina van Google over DKIM instellen beschrijft het pad:

1. Ga in de Google Beheerdersconsole naar Apps > Google Workspace > Gmail > E-mail verifiëren. (U hebt het beheerdersrecht Gmail-instellingen nodig.)
2. Kies het domein en genereer een nieuw record.
3. Kies de sleutellengte. Google zegt dat u 2048 kiest “Als uw domeinprovider 2048-bits sleutels ondersteunt”, omdat “Langere sleutels veiliger zijn dan kortere sleutels”, en 1024 alleen “Als uw domeinhost geen 2048-bits sleutels ondersteunt.”
4. Behoud de standaard voorvoegselkiezer, google – Google noemt die voor Workspace “de aanbevolen optie”.
5. Google toont u een DNS-hostnaam, google._domainkey, en een TXT-waarde die begint met v=DKIM1. Kopieer beide naar een nieuw TXT-record bij uw DNS-host.
6. Klik terug in de Beheerdersconsole op Verificatie starten.

De TXT-waarde die Google genereert heeft deze vorm (de sleutel zelf is een lange tekenreeks die uniek is voor uw domein):

v=DKIM1; k=rsa; p=MIIBIjANBgkqh...(your public key continues)

Wachttijd: Google zegt dat “het tot 48 uur kan duren voordat DKIM-authenticatie gaat werken” nadat u de sleutel hebt toegevoegd. Als u Gmail pas net voor een nieuw domein hebt ingesteld, merkt Google op dat u “24–72 uur moet wachten” voordat de DKIM-sleutel zelfs maar beschikbaar is in de Beheerdersconsole.

Als een andere dienst e-mail voor u verstuurt, geeft die u een eigen DKIM-record met een eigen selector. Publiceer dat ook – meerdere DKIM-sleutels met verschillende selectors kunnen naast elkaar bestaan, anders dan bij SPF.

Hoe stelt u DMARC in zonder uw eigen e-mail te blokkeren?

Publiceer eerst een TXT-record op _dmarc.yourcompany.com met p=none, lees de rapporten en scherp het beleid pas daarna aan. De pagina van Google over DMARC instellen zegt: “Wanneer u DMARC gaat gebruiken, raden we aan de beleidsoptie (p) op none te zetten.” Ook adviseert de pagina u om “48 uur te wachten nadat u SPF en/of DKIM hebt ingesteld voordat u DMARC instelt.”

Op de pagina van Google staat dit volledige voorbeeldrecord:

v=DMARC1; p=reject; rua=mailto:postmaster@example.com, mailto:dmarc@example.com; pct=100; adkim=s; aspf=s

Dat voorbeeld toont de voltooide, strengste toestand. Voor een eerste record volstaat hetzelfde formaat met een bewakingsbeleid en één rapportadres – bijvoorbeeld v=DMARC1; p=none; rua=mailto:dmarc@yourcompany.com. De tag rua stuurt geaggregeerde rapporten naar die mailbox; Google adviseert een speciale mailbox of groep, omdat rapporten in grote aantallen kunnen binnenkomen.

De drie beleidswaarden, zoals gedefinieerd in de DMARC-specificatie:

Een domein krijgt één DMARC-record. Volgens RFC 9989 geldt: als er meerdere DMARC-records worden teruggegeven, “worden ze allemaal verworpen” – dat betekent dat er helemaal geen beleid van toepassing is.

Wat betekent “afstemming” (alignment), en waarom faalt DMARC als SPF slaagt?

DMARC slaagt alleen als SPF of DKIM slaagt voor een domein dat overeenkomt met het From-adres dat mensen zien. SPF kan slagen voor het eigen domein van uw verzenddienst terwijl in de From-regel het uwe staat – en dan faalt DMARC alsnog, omdat het domein dat slaagt niet is afgestemd.

De DMARC-specificatie bepaalt dat een bericht slaagt wanneer minstens één authenticatiemethode een positief resultaat geeft “op basis van een identificator die in afstemming is” (RFC 7489, nu voortgezet in RFC 9989). Standaard is de afstemming soepel (adkim en aspf staan standaard op r): mail.yourcompany.com en yourcompany.com tellen als een match omdat ze hetzelfde organisatiedomein delen. De strikte modus (s), zoals in het voorbeeld van Google, vereist een exacte overeenkomst.

In de praktijk is dit de reden dat DKIM zo belangrijk is voor koude e-mail: wanneer uw verzenddienst ondertekent met uw domein, slaagt de DKIM-afstemming ook als de SPF-afstemming dat niet doet.

Is de DMARC-standaard in 2026 veranderd?

Ja. RFC 9989, in mei 2026 gepubliceerd als document op de Standards Track, vervangt de oorspronkelijke RFC 7489 en schrapt de tag pct. Bestaande v=DMARC1-records blijven werken.

De belangrijkste wijziging die de meeste afzenders zullen merken: pct (het beleid toepassen op slechts een percentage van de mislukte berichten) is verdwenen. De RFC legt uit dat “de praktijk heeft uitgewezen dat de tag ‘pct’ meestal niet nauwkeurig werd toegepast, tenzij de opgegeven waarde 0 of 100 was.” In de plaats daarvan is er een testvlag, t=y, die ontvangers vraagt uw opgegeven beleid niet toe te passen terwijl u het test.

De helppagina van Google toont in het voorbeeld nog steeds pct=100. Dat breekt niets: RFC 9989 zegt dat “onbekende tags GENEGEERD MOETEN worden”, dus een overgebleven pct wordt gewoon overgeslagen. Wanneer u uw record de volgende keer bewerkt, kunt u het weglaten.

Hoe controleert u of alles werkt?

Zoek de records op die u hebt gepubliceerd, verstuur daarna een echt bericht naar een Gmail-adres en lees de authenticatieresultaten. Twee snelle controles:

1. Zoek de DNS-records op. Onze gratis checker zoekt de SPF-, DKIM- en DMARC-records op voor het domein van het adres dat u invoert – zonder dat u zich hoeft aan te melden. Hij controleert de standaard DKIM-selector van Google (google._domainkey); als uw verzenddienst een andere selector gebruikt, meldt de checker DKIM als niet bevestigd, ook als het wel is ingesteld. De tool is beschikbaar in het Engels en Koreaans; voer uw verzendende e-mailadres in.
2. Controleer een echt bericht. Stuur een e-mail naar een Gmail-account dat u beheert, open die, kies “Origineel tonen” en zoek naar SPF: PASS, DKIM: PASS en DMARC: PASS.

Geef de DMARC-rapporten daarna een of twee weken. Wanneer elke legitieme bron die u gebruikt als geslaagd wordt weergegeven, gaat u van p=none naar p=quarantine en later naar p=reject als u de sterkste bescherming tegen spoofing wilt.

Welke fouten breken authenticatie het vaakst?

Twee SPF-records, te veel SPF-opzoekingen, DKIM die is gegenereerd maar nooit is gestart, en DMARC dat is gepubliceerd voordat SPF en DKIM tijd hebben gehad om te werken. Een checklist:

• Eén SPF-record, met elke afzender als include: erin, en niet meer dan 10 opzoektermen.
• Klik op “Verificatie starten” nadat u de DKIM-sleutel hebt gepubliceerd – het DNS-record alleen is niet genoeg.
• Wacht ongeveer 48 uur na SPF en DKIM voordat u DMARC toevoegt, en publiceer het op _dmarc, niet op het hoofddomein.
• Verstuur vanaf een domein dat u beheert. U kunt geen DMARC publiceren voor een @gmail.com-adres.

Authenticatie zorgt ervoor dat uw e-mail in aanmerking komt; het zorgt er niet voor dat ontvangers hem willen. Spamklachten tellen nog steeds mee – Google en Yahoo zeggen allebei dat u uw spampercentage onder 0.3% moet houden, zoals we uitleggen in waarom koude e-mails in de spam belanden. En verzenden naar adressen die niet bestaan veroorzaakt bounces; daarom raden we u aan adressen te controleren voordat u verzendt.

De korte versie

• Google en Yahoo eisen SPF of DKIM van elke afzender, en alle drie plus afstemming van bulkverzenders (5.000+ berichten per dag naar Gmail).
• SPF: één TXT-record op @, bijvoorbeeld v=spf1 include:_spf.google.com ~all; blijf binnen 10 DNS-opzoektermen.
• DKIM: sleutel van 2048 bits, selector google, TXT op google._domainkey, daarna Verificatie starten.
• DMARC: één TXT-record op _dmarc, begin met p=none en een rapportadres, scherp later aan. RFC 9989 (mei 2026) heeft pct vervangen door t=y.
• Controleer uw records met onze gratis checker voor e-mailauthenticatie en bevestig het daarna op een echt bericht.