Terug naar de blog
5 september 2026

Binnen 2–4 weken SPF, DKIM en DMARC voor MKB, met onderhoudsplan

IT-beheerder controleert instellingen voor e-mailauthenticatie

SPF, DKIM en DMARC vormen samen de DNS-basis voor betrouwbare e-mail: SPF autoriseert verzendende servers, DKIM waarborgt de integriteit van je bericht met een digitale handtekening, en DMARC voegt beleid en rapportage toe op basis van die twee. Begin met een controle van je bestaande records en publiceer daarna een DMARC-record met p=none en rua-rapportage. Zo zie je precies wat er misgaat, voordat je overstapt op strenger beleid en minder domeinspoofing riskeert.

Kort samengevat:

  • Alleen het publiceren van een DMARC-record met p=none en rapportage helpt je om problemen en afwijkingen in je e-mailverkeer te identificeren voordat je strengere beveiligingsregels toepast.
  • SPF moet alle verzendende systemen inclusief externe providers omvatten, met minder dan 10 DNS-lookups en altijd testen voor implementatie.
  • DKIM vereist periodieke sleutelrotatie en het correct configureren van selectors, zodat de ondertekening van je uitgaande e-mails betrouwbaar blijft.
  • Bij problemen met forwarding of externe diensten kun je beter connectors of ARC gebruiken dan te vertrouwen op SPF, omdat forwarding het authenticatiesysteem kan ondermijnen.
  • Een voortdurend proces van monitoren en regelmatige updates blijft essentieel omdat nieuwe systemen en tools je e-mailauthenticatie kunnen verstoren.
Astia
Houd e-mailauthenticatie onder controle
ASTIA IT helpt MKB-bedrijven met veilig en zorgeloos doorwerken, inclusief beheer van werkplekken, netwerken en telefonie.
Ontdek ASTIA IT

Inhoudsopgave

Wat zijn SPF, DKIM en DMARC en hoe werken ze samen?

SPF, DKIM en DMARC zijn geen aparte beveiligingsproducten, maar DNS-gebaseerde protocollen die je publiceert als TXT-records. Een ontvangende mailserver leest die records en beslist op basis daarvan of een bericht echt van jouw domein komt.

  • SPF (Sender Policy Framework) somt op welke servers namens jouw domein mogen mailen. De ontvanger vergelijkt het verzendende IP-adres met die lijst.
  • DKIM (DomainKeys Identified Mail) voegt een cryptografische handtekening toe aan elk bericht, zodat de ontvanger kan controleren of de inhoud onderweg niet is aangepast.
  • DMARC (Domain-based Message Authentication, Reporting & Conformance) bouwt hierop verder: het vereist dat SPF of DKIM slaagt én dat het resultaat “aligned” is met het domein in het zichtbare afzenderadres. Pas dan telt een bericht als geauthenticeerd.

Deze drie werken dus niet los van elkaar. DMARC heeft SPF of DKIM nodig als basis en voegt daar beleid (wat moet er gebeuren bij een fout?) en rapportage (wie krijgt te horen wat er misging?) aan toe. De technische fundamenten liggen vast in RFC 7208 voor SPF en RFC 6376 voor DKIM, terwijl DMARC zelf recent in RFC 9989 van mei 2026 is bijgewerkt. Grote mailboxproviders zoals Microsoft en Google verwachten inmiddels dat verzenders deze combinatie correct hebben ingesteld, anders belandt mail sneller in spam of wordt die geweigerd.

Praktische stappen: SPF instellen voor een MKB-domein

Een SPF-record is een enkele regel tekst in je DNS, maar de details bepalen of het werkt. Een basisvoorbeeld:

v=spf1 ip4:1.2.3.4 include:mailprovider.nl -all

Dit zegt: berichten mogen komen van IP-adres 1.2.3.4 en van alles wat de include van je mailprovider toestaat; alles daarbuiten wordt afgewezen (-all).

  1. Inventariseer al je verzendende systemen. Denk aan je mailprovider, je facturatiesysteem, je CRM en marketingtools die namens jouw domein mailen.
  2. Bouw het record op met ip4/ip6 voor eigen servers en include voor externe diensten.
  3. Houd het aantal DNS-lookups onder de 10. Elke include kan zelf weer meerdere lookups veroorzaken, en SPF faalt stil zodra je die limiet overschrijdt.
  4. Kies waar mogelijk voor een vast IP-adres in plaats van een include, dat is sneller te controleren en minder foutgevoelig.
  5. Test het record met een SPF-checker en verstuur een testmail om de uitkomst in de e-mailheaders te bekijken.

DNS-beheer ligt meestal bij je hostingpartij of IT-beheerder, en de wijziging zelf is binnen een uur door te voeren. DNS-propagatie kan daarna nog enkele uren duren.

Pro-tip: Vermijd geneste includes van includes. Elke extra laag kost lookups, en je merkt de limiet meestal pas als legitieme mail plotseling wordt afgewezen.

Praktische stappen: DKIM instellen en sleutels beheren

DKIM werkt met een sleutelpaar: een privésleutel die jouw mailserver gebruikt om te ondertekenen, en een publieke sleutel die je publiceert in DNS zodat ontvangers de handtekening kunnen controleren.

  1. Genereer een sleutelpaar, waar mogelijk met 2048-bit encryptie voor een sterkere handtekening dan de oudere 1024-bit standaard.
  2. Publiceer de publieke sleutel onder een DNS-record met de vorm selector._domainkey.jouwdomein.nl. De selector is een naam die jij of je mailprovider kiest, bijvoorbeeld mail of s1.
  3. Activeer signing in je mailplatform of bij je provider. Bij Microsoft 365 gebeurt dit via de beveiligingsinstellingen van Exchange Online.
  4. Verstuur een testmail en controleer in de headers of dkim=pass verschijnt.
  5. Documenteer elke selector als je meerdere verzendplatforms gebruikt, denk aan je factureringssysteem naast je reguliere mailserver, want elk platform kan een eigen selector en sleutel nodig hebben.

Sleutelrotatie is geen overbodige luxe. Wissel je DKIM-sleutel periodiek, bijvoorbeeld jaarlijks, en zorg dat de oude sleutel pas verdwijnt nadat de nieuwe volledig actief is.

Pro-tip: Verwijder verweesde selectors nooit voordat je zeker weet dat geen enkel systeem ze nog gebruikt. Een te vroeg verwijderde sleutel breekt de authenticatie van berichten die al onderweg zijn.

DMARC instellen: van monitoren naar afdwingen en rapportage gebruiken

Een DMARC-record ziet er zo uit:

v=DMARC1; p=none; rua=mailto:rapporten@jouwdomein.nl; adkim=r; aspf=r; pct=100

  • p bepaalt het beleid: none (alleen monitoren), quarantine (naar spam) of reject (weigeren).
  • rua is het adres waar geaggregeerde rapporten naartoe gaan.
  • adkim en aspf bepalen hoe strikt de alignment wordt gecontroleerd (r voor relaxed, s voor strict).
  • pct regelt op welk percentage van de mail het beleid van toepassing is, handig om geleidelijk op te schalen.

Begin altijd met p=none. Zo zie je via de rua-rapporten welke bronnen legitiem zijn en welke niet, zonder dat je risico loopt legitieme mail te blokkeren. Cloudflare noemt deze gefaseerde aanpak, monitor eerst en scherp daarna aan, als de veiligste route naar een streng beleid.

De volgorde is meestal:

  • Publiceer p=none en verzamel minstens twee tot vier weken rapporten.
  • Repareer elke bron die faalt: ontbrekende SPF-includes, verkeerde selectors, of afwijkende domeinen.
  • Verhoog naar p=quarantine zodra alle legitieme bronnen slagen.
  • Ga pas naar p=reject als je meerdere rapportageperiodes zonder onterechte fouten hebt gedraaid.

Pas op voor deze valkuil: een domein te snel op p=reject zetten zonder rapporten te hebben gelezen, is de meest gemaakte fout bij DMARC-implementaties. Het gevolg is dat legitieme facturen, nieuwsbrieven of geautomatiseerde meldingen plotseling niet meer aankomen.

Veelvoorkomende problemen: forwarding, externen en alignment

E-mailforwarding is de meest onderschatte oorzaak van gefaalde authenticatie. Zodra een bericht wordt doorgestuurd, verandert vaak het verzendende IP-adres, waardoor SPF faalt. DKIM overleeft forwarding meestal wel, omdat de handtekening op de inhoud zit en niet op het IP-adres, tenzij de forwarder de berichttekst of headers aanpast.

Microsoft raadt daarom aan om bij problemen te kijken naar de compauth-uitkomst en bestguesspass-waarde in de headers van Microsoft 365, en om waar mogelijk connectors of ARC-ondertekening te gebruiken in plaats van blind te vertrouwen op standaard SPF-checks.

Praktische oplossingen:

  • Gebruik connectors tussen Microsoft 365 en bekende doorstuurdiensten, zodat authenticatieresultaten behouden blijven.
  • Verplaats berichtaanpassingen zoals e-mailhandtekeningen naar je primaire mailplatform in plaats van via een externe tool die de inhoud na verzending wijzigt.
  • Stel subdomeinbeleid apart in als je meerdere SaaS-diensten via subdomeinen laat mailen, zodat een fout bij één dienst niet je hoofddomein raakt.

Pro-tip: Loopt een nieuwsbrieftool via een apart subdomein? Geef dat subdomein een eigen SPF- en DKIM-configuratie, zodat problemen daar nooit je hoofddomein blokkeren.

Checklist en onderhoudsplan voor MKB

De volgorde die in de praktijk het beste werkt: inventariseer alle verzendende systemen, publiceer SPF en DKIM voor elk daarvan, activeer DMARC in p=none met rua-rapportage, en scherp pas aan als de rapporten dat toelaten.

  • Controleer bij elke nieuwe SaaS-tool die namens jouw domein mailt of SPF en DKIM zijn bijgewerkt.
  • Roteer DKIM-sleutels periodiek en verwijder oude selectors pas na controle.
  • Lees DMARC-rapporten minstens maandelijks, niet alleen bij de eerste instelling.

E-mailauthenticatie is geen instelling die je één keer doet en daarna vergeet. Elke nieuwe marketingtool, factureringsdienst of helpdesksysteem die namens jouw domein mailt, vraagt om een update van je records. Voor teams die dit onderhoud liever structureel uitbesteden, sluit dit aan op bredere e-mailbeveiliging binnen je organisatie.

Hoe lees je een DMARC-rapport (RUA)?

DMARC-rapporten komen binnen als XML-bestanden, meestal dagelijks per verzendende partij die aan het protocol meedoet. Ruwe XML is niet prettig leesbaar, dus gebruik je meestal een rapportagetool die de gegevens omzet naar een overzicht per bron.

Een typisch rapport toont voor elke afzendende IP het aantal verstuurde berichten, of SPF slaagde, of DKIM slaagde, en of alignment werd behaald. Stel dat je rapport laat zien dat 950 van de 1.000 berichten van je factureringssysteem slagen op DKIM maar falen op SPF alignment: dat wijst meestal op een ontbrekende include in je SPF-record, niet op een probleem met DKIM zelf.

DMARC-rapport met SPF, DKIM en afstemming

Let bij het lezen op drie dingen:

Onbekende bronnen. Zie je een IP-adres dat je niet herkent en dat consequent faalt op zowel SPF als DKIM? Dat kan een teken zijn van iemand die jouw domein probeert te misbruiken voor phishing, en is precies het signaal waarvoor DMARC-rapportage bedoeld is.

Legitieme bronnen die falen. Een marketingtool of CRM die faalt op alignment, ondanks dat SPF of DKIM technisch slaagt, wijst vaak op een verkeerd geconfigureerde afzenderadres of een ontbrekende include in je SPF-record.

Consistentie over tijd. Eén slechte dag zegt weinig. Kijk naar patronen over twee tot vier weken voordat je conclusies trekt of het beleid aanscherpt. Rapporten van grote providers zoals Google en Microsoft zijn doorgaans het meest betrouwbaar, omdat zij zelf ook strikt controleren.

Waarom SPF, DKIM en DMARC phishing en spoofing tegenhouden

Domeinspoofing werkt simpel: een aanvaller stuurt een e-mail die eruitziet als afkomstig van jouw bedrijf, met jouw logo en jouw domeinnaam in het afzenderveld. Zonder authenticatie heeft de ontvangende mailserver geen manier om dat te controleren.

SPF sluit de meest basale vorm van spoofing af: een aanvaller kan technisch nog steeds een IP-adres gebruiken dat niet op jouw lijst staat, maar de ontvangende server ziet dan direct dat dit IP niet is geautoriseerd. Dat stopt veel automatisch verstuurde phishingmail die grof jouw domein imiteert.

DKIM voegt een andere laag toe: zelfs als een aanvaller een geautoriseerd IP-adres zou kunnen misbruiken, ontbreekt de geldige digitale handtekening. Elk bericht dat écht van jou komt, draagt een handtekening die is gekoppeld aan een sleutel die alleen jij beheert.

DMARC is de laag die deze twee mechanismen dwingend maakt. Zonder DMARC kan een ontvangende server SPF of DKIM laten falen en het bericht toch afleveren, “voor de zekerheid”. Met een DMARC-beleid op p=quarantine of p=reject geef je expliciet aan wat er moet gebeuren: berichten die niet aligned zijn, verdwijnen naar spam of worden geweigerd voordat een medewerker ze ooit ziet.

Dat is precies waarom phishingcampagnes vaak mislukken bij bedrijven met een streng DMARC-beleid, en waarom domeinen zonder DMARC een populair doelwit blijven voor factuurfraude waarbij aanvallers zich voordoen als een bekende leverancier.

Waarom SPF, DKIM en DMARC phishing en spoofing tegenhouden — overview diagram

Hoe SPF, DKIM en DMARC samenwerken met BIMI

BIMI (Brand Indicators for Message Identification) is de laag die je merklogo naast geauthenticeerde e-mail toont in de inbox van de ontvanger. Het werkt alleen als beloning bovenop een werkend authenticatiesysteem, niet als vervanging ervan.

Om BIMI te kunnen gebruiken, moet je domein al een DMARC-beleid hebben op p=quarantine of p=reject, met voldoende dekkingspercentage (pct). Providers als Google en Yahoo eisen dit bewust: BIMI zou anders een schild worden voor phishing, waarbij aanvallers een vertrouwd logo tonen zonder dat de onderliggende mail daadwerkelijk geauthenticeerd is.

Voor een MKB-bedrijf betekent dit dat BIMI de laatste stap is, niet de eerste. Eerst een werkend SPF-record, dan een correcte DKIM-configuratie, dan een DMARC-beleid dat je hebt opgebouwd via p=none naar een strenger niveau, en pas dan een BIMI-record met een verwijzing naar je gevalideerde logobestand.

De praktische winst is herkenbaarheid: een bericht met een zichtbaar, geverifieerd logo in de inbox wekt meer vertrouwen dan een kale afzendernaam. Voor bedrijven die veel factuur- of transactiemail versturen, zoals accountantskantoren of webshops, is dat een tastbaar verschil in hoe ontvangers reageren op legitieme communicatie.

Waarom de meeste MKB-bedrijven dit verkeerd aanpakken

De grootste misvatting over e-mailauthenticatie is dat het een eenmalig technisch klusje is. In de praktijk is het een doorlopend proces, want elke nieuwe SaaS-tool die namens je domein mailt, kan een bestaand record breken als niemand het bijwerkt.

Wat conventionele adviezen vaak onderbelichten, is de menselijke kant: DMARC-rapporten lezen en interpreteren kost tijd, en die tijd ontbreekt bij veel kleine IT-teams. Het gevolg is dat bedrijven een DMARC-record publiceren, één keer naar de rapporten kijken en daarna niets meer doen. Dat is riskanter dan geen DMARC hebben, omdat een verkeerd ingestelde p=reject legitieme mail permanent kan blokkeren zonder dat iemand het doorheeft.

Mijn advies: begin klein, blijf kijken. De volgorde SPF, dan DKIM, dan DMARC in monitor-mode is niet alleen technisch logisch, het is ook de enige manier om fouten te ontdekken voordat ze klanten raken. Bedrijven die te snel naar p=reject springen, onderschatten hoeveel legitieme diensten, van boekhoudsoftware tot marketingtools, per ongeluk buiten hun SPF-record vallen.

Wat écht telt, is niet de technische installatie zelf, maar wie de rapporten blijft lezen nadat de eerste opwinding voorbij is.

— Mick

Astia helpt bij de implementatie en het onderhoud van SPF, DKIM en DMARC

Astia neemt het volledige technische traject van e-mailauthenticatie over, zodat jouw team zich niet hoeft te verdiepen in DNS-syntaxis of rapportanalyse. Dat omvat het publiceren en beheren van SPF- en DKIM-records, het opzetten van sleutelrotatie, het analyseren van DMARC-rapporten en de integratie met Microsoft 365.

Astia

Veel MKB-bedrijven onderschatten hoeveel onderhoud e-mailauthenticatie vraagt zodra er meerdere verzendende systemen bijkomen, van factureringssoftware tot marketingtools. Sommige IT-partners monitoren die records structureel, signaleren wijzigingen bij nieuwe SaaS-koppelingen en helpen voorkomen dat een te snelle overstap naar p=reject legitieme mail blokkeert. Dat scheelt niet alleen technische risico’s, maar ook de tijd die een intern team zou besteden aan het uitpluizen van rapporten.

Wil je weten hoe jouw domein er nu voor staat op het gebied van SPF, DKIM en DMARC? Bekijk het aanbod voor IT-beveiliging en cybersecurity en vraag een vrijblijvende controle van je huidige e-mailconfiguratie aan.

Bronnen

Aanbevelingen