SPF DKIM DMARC België: waarom e-maildomeinbeveiliging een prioriteit wordt

Een gekend domein is een digitale identiteit: als het kan worden vervalst, werkt het vertrouwen dat de organisatie heeft opgebouwd in het voordeel van de aanvaller. Het valse bericht kan vragen om een bankrekening te wijzigen, een valse factuur verspreiden, uitnodigen om zich aan te melden op een phishingpagina of zich voordoen als de directie. De aanvaller hoeft geen toegang tot de tenant te hebben om het zichtbare adres te imiteren.

Safeonweb@work, de dienst voor organisaties van het Centrum voor Cybersecurity België, presenteert SPF, DKIM, DMARC en DNSSEC als complementaire mechanismen tegen spoofing en phishing. De aanbeveling van 2 september 2025 over het beveiligen van DNS en e-mail bevat afzonderlijke implementatiegidsen voor SPF, DKIM en DMARC. Deze Belgische bron beperkt het onderwerp niet tot marketingdeliverability.

De pagina de cyberbeveiliging van GVISION plaatst deze bescherming in een breder geheel: identiteiten, eindpunten, netwerken, gegevens, sensibilisering en incidentrespons. Dit is belangrijk, omdat DMARC noch een bericht blokkeert dat vanuit een daadwerkelijk gecompromitteerde mailbox wordt verzonden, noch een lookalike-domein dat door een fraudeur is aangekocht.

SPF, DKIM, DMARC, DNSSEC, MTA-STS en DANE: wie doet wat?

SPF DKIM DMARC België: de standaarden zijn geen alternatieven: ze behandelen verschillende vraagstukken en versterken elkaar wanneer ze samen worden geïmplementeerd. SPF vraagt of de server gemachtigd is om te verzenden. DKIM vraagt of een geldige handtekening het bericht beschermt. DMARC vraagt of een van deze resultaten overeenkomt met het zichtbare domein. MTA-STS en DANE beschermen het traject tussen servers.

Uitlijning is het punt dat vaak wordt vergeten. Microsoft legt uit dat SPF het domein van MAIL FROM controleert en dat DKIM ondertekent met een domein dat in de handtekening is vermeld; zonder DMARC kunnen deze domeinen verschillen van het domein dat aan de gebruiker wordt weergegeven. De Microsoft-documentatie over e-mailauthenticatie toont hoe DMARC deze resultaten koppelt aan het zichtbare veld «From».

Begin met de inventarisatie van afzenders, niet met een DNS-record

De implementatie slaagt wanneer elke legitieme bron gekend is, aan een eigenaar is toegewezen en getest is; DNS komt daarna. Een onvolledige inventarisatie leidt tot twee mogelijke resultaten: een te zwak beleid dat spoofing doorlaat, of een strikt beleid dat nuttige facturen, bevestigingen of waarschuwingen blokkeert.

Maak een matrix per domein en per flow

Noteer het hoofddomein, secundaire domeinen, voormalige merken, defensieve domeinen en subdomeinen. Documenteer voor elk domein het zichtbare adres, het envelopdomein, het DKIM-domein, de dienstverlener, de business owner, het geschatte volume, de gebruikelijke ontvangers en de criticaliteit. De DMARC-rapporten bevestigen de observaties, maar vervangen gesprekken met finance, marketing, HR en operationele teams niet.

Schrijf beleid en privacytekst. Leg zichtbaarheid, verantwoordelijkheden, support, verlies, vertrek en updates uit.

• Exchange Online, SMTP-servers, relays en hybride connectors;
• CRM, ERP, elektronische facturatie, betalingsplatformen en ondertekeningsdiensten;
• nieuwsbrieven, rekruteringstools, enquêtes, ticketing en evenementen;
• webapplicaties, contactformulieren, monitoring en ticketsystemen;
• scanners, multifunctionele printers, NAS-systemen, alarmsystemen en technische apparatuur;
• dienstverleners die daadwerkelijk met uw domein verzenden, en niet alleen namens zichzelf.

Scheid flows wanneer dat nuttig is

Domeinen die nooit e-mails versturen, moeten een expliciet beleid krijgen. Ze hoeven geen servers in SPF te autoriseren of DKIM-sleutels te publiceren. Een strikt DMARC-beleid vermindert hun aantrekkelijkheid voor spoofing. Documenteer wel de bedoeling: een domein dat vandaag «ongebruikt» is, kan morgen door een vergeten project worden geactiveerd.

SPF, DKIM en DMARC configureren rond Microsoft 365

In Microsoft 365 is de juiste volgorde SPF, DKIM op elk aangepast domein en vervolgens een geleidelijke invoering van DMARC, met een externe test van de headers. Microsoft verduidelijkt dat DKIM niet automatisch met het aangepaste domein ondertekent zolang de configuratie ervan niet is geactiveerd. Het verzenden met het initiële domein onmicrosoft.com volgt een andere logica.

1. SPF consolideren

Schrijf beleid en privacytekst. Leg zichtbaarheid, verantwoordelijkheden, support, verlies, vertrek en updates uit. v=spf1. Controleer de mechanismen includeBedrijfstoestel de Microsoft SPF-procedure benadrukt dat SPF alleen niet volstaat.

2. DKIM activeren op aangepaste domeinen

Maak de twee vereiste CNAME-records aan in het Microsoft Defender-portaal, wacht tot ze zijn opgelost en activeer vervolgens de ondertekening. De waarden zijn specifiek voor de tenant en het domein: neem geen voorbeeld over dat u in een artikel vindt. Stuur vervolgens een bericht naar een externe mailbox en controleer dkim=pass evenals het ondertekeningsdomein. Voorzie ook DKIM bij elke externe dienstverlener die met uw domein kan ondertekenen.

3. DMARC publiceren in observatiemodus

Een eerste beleid kan gebruikmaken van p=none Schrijf beleid en privacytekst. Leg zichtbaarheid, verantwoordelijkheden, support, verlies, vertrek en updates uit.

De service Microsoft 365 van GVISION Aankoop, logistiek en privégebruik moeten worden geregeld.

Zonder incidenten van p=none naar quarantine en vervolgens naar reject gaan

De DMARC-progressie moet gebaseerd zijn op bewijsmateriaal: legitieme flows slagen met uitlijning, onbekende bronnen worden gekwalificeerd en er bestaat een terugvalprocedure. Microsoft raadt uitdrukkelijk een geleidelijke aanpak aan richting p=reject om te voorkomen dat goede berichten worden geweigerd door onbedoelde fouten.

Mobile Application Management past regels toe op professionele apps en gegevens zonder het toestel volledig in te schrijven. Microsoft beschrijft MAM for unenrolled devices als een model waarbij appconfiguratie en appbeveiligingsbeleid bedrijfsdata binnen ondersteunde toepassingen beschermen. Mogelijke maatregelen zijn een app-pincode, beperkingen op kopiëren naar privéapps, voorwaarden voor lokale opslag en selectieve verwijdering van werkdata.

De overgang naar quarantine stelt compatibele ontvangers in staat om fouten strenger te behandelen, vaak door ze naar de ongewenste e-mail te sturen. De parameter pct Bedrijfstoestel reject vereist dat de relevante flows onder controle zijn. Gebruik ook sp om het gedrag van subdomeinen te bepalen wanneer het beleid moet verschillen.

Behoud een wijzigingsprocedure

Elk nieuw hulpmiddel dat berichten verzendt, moet vóór de ingebruikname in productie een review doorlopen: subdomein, adressen, DKIM, SPF, uitlijning, testontvangers en eigenaar. Zonder deze toegangspoort verslechtert de configuratie binnen enkele maanden. De DMARC-rapporten moeten ook na reject verder worden opgevolgd om een gewijzigde dienstverlener, een verlopen sleutel, een nieuwe niet-geautoriseerde bron of een spoofingcampagne te detecteren.

MTA-STS of DANE: het SMTP-transport beveiligen na de identiteit

SPF, DKIM en DMARC authenticeren de afzender; MTA-STS en DANE proberen te voorkomen dat een verzendende server het bericht aflevert bij een niet-geauthenticeerde bestemming of zonder betrouwbare TLS. Ze beantwoorden dus aan een andere risicolaag.

SMTP gebruikt vaak opportunistische TLS: versleuteling wordt gebruikt wanneer beide servers dit ondersteunen, maar een aanvaller die DNS of de onderhandeling kan beïnvloeden, kan proberen om te leiden of de beveiliging te verlagen. MTA-STS, gedefinieerd door RFC 8461, publiceert via HTTPS een beleid waarin de verwachte MX-servers en de TLS-vereiste worden aangegeven. TLS-RPT, gedefinieerd door RFC 8460, levert rapporten over onderhandelings- of validatiefouten.

DANE voor SMTP gebruikt TLSA-records die door DNSSEC worden geauthenticeerd. Microsoft vat het verschil als volgt samen: DANE vereist DNSSEC, terwijl MTA-STS steunt op het systeem van certificaatautoriteiten. De documentatie over Exchange Online voor DANE en MTA-STS, bijgewerkt op 21 juli 2026, legt ook uit waarom opportunistische TLS niet volstaat tegen bepaalde DNS-resolutieaanvallen.

Pas de implementatie aan de werkelijke werking van de organisatie aan

De omvang bepaalt de complexiteit niet: het aantal domeinen, dienstverleners en businessflows is veelzeggender. Schrijf beleid en privacytekst. Leg zichtbaarheid, verantwoordelijkheden, support, verlies, vertrek en updates uit.

Vzw, school of overheidsorganisatie

Tools nemen vaak toe per project, schooljaar of subsidie. Houd een register bij met een eigenaar en einddatum. Schakel de SPF-autorisatie en sleutels van een vertrokken leverancier uit. Beveilig inactieve domeinen en oude varianten. Controleer bij distributielijsten die het onderwerp of de inhoud wijzigen de impact op DKIM en overweeg ARC-mechanismen wanneer de doorstuurketen legitiem is.

Multi-sitegroep of grote onderneming

De governance moet gefedereerd zijn zonder de centrale controle te verliezen. Wijs subdomeinen toe per gebruik, automatiseer de DNS-inventarisatie, leg contractuele vereisten op aan leveranciers en centraliseer de rapporten. Eén team valideert de standaarden; elke entiteit blijft verantwoordelijk voor haar applicaties. Bij overnames is een inventarisatie nodig voordat een overgenomen beleid wordt gewijzigd.

Website en formulieren

De webserver mag het adres van de bezoeker niet willekeurig vervalsen in het veld «From». Gebruik een correct geauthenticeerd adres van uw domein en plaats het adres van de aanvrager in Reply-To. Dit onderscheid voorkomt dat DMARC wordt verbroken en maakt antwoorden toch mogelijk. Voor meldingen die bij een dienstverlener worden gehost, geeft u de voorkeur aan uitgelijnde DKIM en een specifiek subdomein.

Fouten die de e-mailomgeving verzwakken of verstoren

De meeste incidenten zijn het gevolg van een onvolledig overzicht van de flows, een verkeerd begrepen uitlijning of een gepubliceerd beleid zonder observatie. De DNS-syntaxis is zelden het enige probleem.

1. Meerdere SPF-records publiceren: een domein mag slechts één SPF-beleid hebben. Meerdere records veroorzaken een permanente fout.
2. Het aantal DNS-lookups overschrijden: alle include Bedrijfstoestel
3. pass en uitlijning verwarren: SPF of DKIM kan slagen op een domein van een derde partij, terwijl DMARC faalt tegenover het zichtbare domein.
4. Rechtstreeks naar reject gaan: vergeten printers, CRM-systemen, formulieren of facturen worden nevenschade.
5. p=none onbeperkt behouden: de organisatie verzamelt rapporten, maar vraagt ontvangers nooit om fouten te blokkeren.
6. Te ruim autoriseren: het opnemen van een groot platform kan ervoor zorgen dat andere klanten van de dienstverlener SPF doorstaan; uitgelijnde DKIM vermindert deze afhankelijkheid.
7. Slapende domeinen negeren: ze blijven aantrekkelijk voor spoofing, terwijl een strikt beleid er vaak eenvoudig te implementeren is.
8. Een allowlist als permanente oplossing gebruiken: Microsoft waarschuwt dat bepaalde allowlists authenticatie- en filtercontroles kunnen omzeilen.
9. Operationeel beheer vergeten: een sleutel, connector of dienstverlener verandert; zonder monitoring wordt de compliance van vandaag het incident van morgen.

SPF DKIM DMARC België: checklist vóór een strikt beleid

Een strikt beleid is klaar wanneer de organisatie kan aantonen wie verzendt, hoe elke flow wordt geauthenticeerd en wie op een fout reageert. Gebruik deze lijst als wijzigingscontrole, niet als certificering.

• Alle domeinen en subdomeinen zijn geïnventariseerd, inclusief inactieve domeinen.
• Elke bron heeft een business owner en een technische verantwoordelijke.
• Bedrijfstoestel
• DKIM is geactiveerd en geverifieerd voor Microsoft 365 en belangrijke externe platformen.
• Het SPF- of DKIM-domein is uitgelijnd met het veld «From» voor elke kritieke flow.
• De DMARC-rapporten dekken zeldzame cycli: loonadministratie, facturatie, campagnes en seizoensgebonden meldingen.
• Doorsturen, distributielijsten en gateways zijn getest.
• Subdomeinen en slapende domeinen hebben een gedocumenteerd beleid.
• Er zijn een waarschuwingskanaal, een terugvalprocedure en een eigenaar.
• Toekomstige wijzigingen aan CRM, ERP, website of leverancier worden aan een e-mailreview onderworpen.
• MTA-STS of DANE wordt afzonderlijk geëvalueerd op basis van de mate waarin DNSSEC en connectors worden beheerd.
• De datum, het bewijsmateriaal en de beslissing om over te schakelen naar quarantine of reject worden bewaard.