L1 BIO 13.01 ISO A.13.2.1 CIS Email Security

SPF, DKIM, DMARC Design

📅 2025-10-30
•
⏱️ 14 minuten lezen
•
🔴 Must-Have

💼 Management Samenvatting

SPF, DKIM en DMARC vormen samen het fundament voor betrouwbare e-mailauthenticatie waarmee organisaties domeinmisbruik, impersonatie en fraude structureel blokkeren voordat berichten de inbox bereiken.

Aanbeveling
Voer een geïntegreerde implementatie van SPF, DKIM en DMARC uit en borg deze maatregelen in zowel techniek als governance, zodat iedere uitgaande e-mail aantoonbaar afkomstig is van de organisatie en onbevoegde berichten automatisch worden geweigerd.
Risico zonder
Critical
Risk Score
9/10
Implementatie
24u (tech: 16u)
Van toepassing op:
✓ Exchange Online
✓ Email Security
✓ DNS

Aanvallers misbruiken vertrouwde domeinen om overtuigende phishingcampagnes richting Nederlandse overheden en leveranciers uit te voeren. Zonder een sluitende combinatie van SPF, DKIM en DMARC kunnen kwaadwillenden probleemloos berichten onder dezelfde afzendernaam versturen, wat leidt tot credential-phishing, ransomware en reputatieschade. Strikte DMARC-alignment, waarbij SPF en DKIM aantoonbaar slagen en overeenkomen met het verzendende domein, is daarom de onbetwiste norm voor volwassen e-mailbeveiliging.

PowerShell Modules Vereist
Primary API: Exchange Online PowerShell
Connection: Connect-ExchangeOnline
Required Modules: ExchangeOnlineManagement

Implementatie

Dit ontwerpdocument biedt een volledige blauwdruk voor een hoogwaardige e-mailauthenticatieketen. Het beschrijft hoe u een robuust SPF-record opstelt dat alle geautoriseerde verzendende platforms omvat, hoe DKIM-handtekeningen cryptografisch worden beheerd via zorgvuldig gepubliceerde CNAME-records, en hoe u een DMARC-beleid uitrolt dat begint met monitoren maar uiteindelijk ongeldige berichten afwijst. Succes vereist een integrale aanpak waarin DNS-governance, Exchange Online, rapportageprocessen en auditeisen naadloos samenwerken.

Vereisten

Stabiel en gecontroleerd DNS-beheer is essentieel omdat iedere stap van SPF, DKIM en DMARC neerkomt op nauwkeurige TXT- en CNAME-records. De organisatie moet beschikken over een changeproces met vier-ogenprincipe, logging van wijzigingen en duidelijke afhankelijkheden tussen primaire en secundaire zones. Alleen dan kan worden gewaarborgd dat nieuwe records snel worden gepubliceerd, sleutelrotaties zonder verstoringen verlopen en rollbackprocedures direct beschikbaar zijn wanneer een wijziging onverwachte impact heeft. Voeg hieraan toe dat documentatie van TTL-waarden, upstream providers en gedelegeerde subdomeinen actueel moet blijven zodat crisisteams in staat zijn om binnen minuten correct te reageren op een incident. Zonder deze gedisciplineerde aanpak kan zelfs een simpele tikfout leiden tot wijdverspreide spoofing of het blokkeren van legitiem verkeer.

Een volledig ingerichte Exchange Online-tenant vormt de centrale plaats waar DKIM wordt ingeschakeld, selectors worden beheerd en policies worden afgedwongen. Dit vereist accounts met juiste RBAC-rollen, inzicht in hybride mailstromen en aandacht voor edge-apparaten die berichten herschrijven. Zonder deze voorbereidingen kunnen de DKIM-sleutels wel worden gepubliceerd, maar blijven berichten alsnog ongetekend of raken extra relays buiten beeld. Bovendien moet de organisatie weten hoe transportregels, journaling of encryptieproducten headers aanpassen, omdat dit direct impact heeft op de valide DKIM-handtekening en dus op DMARC-alignment. Een volwassen tenantconfiguratie houdt rekening met toekomstige projecten, zodat nieuwe domeinen of service-desk functionaliteit al vanaf dag één voldoen aan dezelfde governance-eisen.

Een actuele inventarisatie van alle geautoriseerde verzendpartijen, waaronder marketingplatforms, facturatiesystemen, servicedesktools en partneroplossingen, is cruciaal. Elk van deze diensten heeft eigen IP-adressen en envelope-afzenders die in SPF moeten worden opgenomen en mogelijk een eigen DKIM-handtekening leveren. Wanneer ook maar één legitieme dienst ontbreekt, zal DMARC berichten later blokkeren, waardoor dienstverlening stokt en gebruikers het vertrouwen verliezen. Het inventarisdocument hoort daarom een eigenaar, reviewmoment en lifecycle-management te hebben zodat nieuwe projecten niet buiten het zichtveld van het securityteam vallen. Door de inventaris te koppelen aan vendor management en het contractregister ontstaat een volledig beeld dat ook tijdens aanbestedingen kan worden hergebruikt.

DMARC-rapportage vereist functionele mailboxen of adresgroepen die dagelijks de binnenkomende RUA- en RUF-berichten verwerken. Deze mailboxen moeten worden gekoppeld aan een analyseplatform zodat trends zichtbaar worden en afwijkingen automatisch tot incidenttickets leiden. Zonder deze rapportagestroom blijft het gissen of de uitrol succesvol is en kan richting bestuurders geen harde voortgang worden overlegd. Koppel de rapportageprocessen aan SIEM-regels en bewaartermijnen zodat gegevens compliant met de AVG worden opgeslagen en toch beschikbaar zijn voor trendanalyse over meerdere jaren. Maak tevens afspraken over bereikbaarheid buiten kantooruren, want spoofingcampagnes richten zich vaak op momenten waarop toezicht minimaal is.

Documentatie van de volledige mailflow-architectuur, inclusief forwarding-routes, applicatie-relays en uitzonderingen voor no-reply boxen, vormt de basis om beslissingen te verifiëren. Deze documentatie moet aangeven welke businessprocessen afhankelijk zijn van e-mail, welke afdelingen eigenaar zijn en welke servicelevels gelden. Met dit inzicht kan de organisatie bepalen hoe authenticatie-eisen per proces worden getest en hoe wijzigingen naar productie gaan zonder risico op uitval. Koppel deze architectuurkaart aan het enterprise architectuurregister zodat auditors kunnen traceren waar in de keten berichten worden herschreven, gescand of omgeleid. Het resulteert in een gedeelde bron die ook tijdens crisismanagement dient als leidraad voor snelle beslissingen.

Implementatie

**SPF-record:** Bouw de configuratie gefaseerd op door eerst de standaardwaarde "v=spf1 include:spf.protection.outlook.com -all" te publiceren en vervolgens per workload een gecontroleerde include toe te voegen. Combineer marketing- of CRM-platforms in gescheiden subdomeinen om lookup-limieten te beheersen en leg voor iedere wijziging vast wie verantwoordelijk is, welke IP-ranges worden afgedekt en hoe rollback verloopt. Automatiseer validatie via een PowerShell-script dat het record ophaalt, het aantal lookups telt en resultaten toevoegt aan de change-documentatie zodat elke auditor kan zien dat de limiet structureel onder controle blijft. Door deze aanpak ontstaat een transparant overzicht dat ook tijdens ketenoverleggen met leveranciers kan worden gebruikt om aan te tonen dat zij volgens contractuele eisen zijn opgenomen.

**DKIM-handtekeningen:** Activeer DKIM per domein vanuit het Exchange Admin Center of via het cmdlet "Set-DkimSigningConfig" en publiceer de twee vereiste CNAME-records (selector1 en selector2) binnen het primaire DNS. Controleer na publicatie of de selectors wereldwijd beschikbaar zijn, voer een testmail naar een externe mailbox uit en verifieer de headers zodat zichtbaar is dat de DKIM-signature met status "pass" doorkomt. Leg daarnaast vast hoe sleutelrotaties elke zes maanden worden bevestigd, hoe third-party platforms hun eigen selectors aanleveren en hoe u ervoor zorgt dat secure mail gateways geen headers strippen. Zorg ervoor dat deze controles worden gecombineerd met het certificate managementproces, zodat sleutelbeheer dezelfde maturiteit bereikt als TLS-certificaten binnen de organisatie.

**DMARC-beleid:** Definieer vooraf meetmomenten voor elke fase: vier weken monitoren met "p=none" om baselinegegevens te verzamelen, vervolgens acht weken "p=quarantine" met "pct" oplopend van 25 naar 100 procent, en tenslotte de definitieve stap naar "p=reject". Gebruik standaardinstellingen als "rua=mailto:dmarc@domein.nl" en voeg een tweede adres toe voor redundantie. Beschrijf in het projectplan hoe rapportages worden beoordeeld, hoe false positives worden uitgesloten en hoe crisisteams worden geïnformeerd voordat de handhavende fase live gaat. Koppel deze fasering aan acceptatiecriteria zodat duidelijk is welke KPI's gehaald moeten zijn voordat een volgende stap verantwoord is. Leg daarbij vast welke communicatiemiddelen worden ingezet om gebruikers, klanten en ketenpartners tijdig te informeren over de hogere mate van controle.

**Alignment en uitzonderingen:** Dwing strikte alignment af met "adkim=s" en "aspf=s" zodat alleen domeinen die exact overeenkomen met de From-header worden geaccepteerd. Leg per uitzonderingsscenario vast waarom relaxed alignment tijdelijk nodig is, welke compenserende maatregelen gelden (zoals dedicated subdomeinen of aangepaste From-adressen) en wanneer de uitzondering vervalt. Documenteer bovendien hoe forwarding, shared mailboxes en bulkverzendingen worden getest om zeker te weten dat DKIM en SPF intact blijven, en neem in het draaiboek op hoe u het enforcementpercentage tijdelijk verlaagt wanneer bedrijfscontinuïteit daarom vraagt. Dit zorgt ervoor dat uitzonderingen niet permanent worden en dat de organisatie aantoonbaar werkt aan volledige afschaffing ervan, wat essentieel is voor audittrail en BIO-naleving.

Gebruik PowerShell-script m365-spf-dkim-dmarc.ps1 (functie Invoke-Monitoring) – Controleer SPF/DKIM/DMARC configuratie.

monitoring

Elke wijzigingscyclus start met een externe verificatie via gespecialiseerde platforms zoals MXToolbox, Hardenize of de Microsoft Remote Connectivity Analyzer. Deze scanners toetsen de syntaxis van SPF, DKIM en DMARC, controleren de wereldwijde zichtbaarheid van records en waarschuwen wanneer cachingservers nog oude waarden teruggeven. Door deze controles te automatiseren in een dagelijkse runbook ontstaat een waarschuwingssignaal voordat eindgebruikers inboxproblemen ervaren. Het SOC gebruikt de resultaten bovendien als input voor dreigingsanalyses op domeinmisbruik.

DMARC-aggregatierapporten (RUA) worden gecentraliseerd verzameld in een dedicated mailbox en automatisch verwerkt in een analyseplatform zoals dmarcian, Valimail Monitor of een eigen Power BI-dashboard. Analisten brengen per bron-IP, provider en authenticatiestatus trends in kaart, waardoor onbekende verzenders of plotselinge volumestijgingen direct zichtbaar worden. Elke week wordt een overzicht gedeeld met de proceseigenaren zodat zij kunnen bevestigen dat hun diensten correct functioneren en eventuele misconfiguraties snel kunnen herstellen. De rapportages worden gearchiveerd voor minimaal drie jaar zodat audits kunnen terugkijken op structurele verbeteringen.

Het SPF-record wordt wekelijks gecontroleerd op het aantal DNS-lookups en op verouderde includes. Een PowerShell- of Python-script telt de lookups, vergelijkt de uitkomst met de afgesproken drempel en meldt afwijkingen aan het e-mailbeheerteam. Wanneer de limiet van tien in zicht komt, wordt een change voorbereid om records te flatten, subdomeinen te introduceren of verouderde referenties te verwijderen. Door dit preventief te doen, blijven DMARC-uitkomsten voorspelbaar en gaat het beleid niet onverwacht verkeer blokkeren. De uitkomsten worden gedeeld met vendor managers zodat zij leveranciers kunnen aanspreken op inefficiënte configuraties.

Binnen het Exchange Admin Center wordt de status van DKIM per domein actief gemonitord. Beheerders controleren of selectors zijn ingeschakeld, of sleutelrotaties in de afgelopen zes maanden hebben plaatsgevonden en of recente berichten de verwachting "DKIM=pass" invullen. Eventuele waarschuwingen worden gekoppeld aan het ITSM-systeem waardoor incidenten direct bij de juiste lijnorganisatie terechtkomen. Hierdoor blijft zichtbaar of aanpassingen in transportregels, DLP of encryptie een negatieve invloed hebben op de handtekeningen. De monitoringrapporten vormen een verplicht onderdeel van de kwartaalreview met de CISO.

Forensische DMARC-rapporten (RUF) leveren diepgaande details over individuele mislukte afleveringen en bevatten vaak volledige headerinformatie. Deze rapporten landen in een afgeschermde opslaglocatie waar alleen het SOC en de privacy officer toegang toe hebben. Door RUF-gegevens te correleren met Defender for Office 365 alerts en Exchange message traces kan men gericht bepalen of het gaat om malafide spoofing, verkeerde configuratie of forwarding door externe partijen. Bevindingen worden gedocumenteerd en gedeeld tijdens de maandelijkse security-review, inclusief advies aan procurement of communicatie-afdelingen wanneer partners extra ondersteuning nodig hebben.

Gebruik PowerShell-script m365-spf-dkim-dmarc.ps1 (functie Invoke-Monitoring) – Automated DNS checks.

Remediatie

Wanneer SPF-records het maximum van tien DNS-lookups naderen, voert het beheerteam een gecontroleerde flattening uit waarbij includes worden vertaald naar vaste IP-adressen of naar dedicated subdomeinen. Iedere wijziging doorloopt het CAB-proces, wordt getest in een secundaire zone en krijgt een rollback-scenario zodat fouten snel zijn terug te draaien. Door de wijziging direct te documenteren in het configregister blijft inzichtelijk waarom aanpassingen zijn gedaan en hoe de continuïteit is geborgd. Bovendien wordt vastgelegd welke leveranciers akkoord gaven, zodat discussies achteraf worden voorkomen.

Als DKIM onverwacht is uitgeschakeld, start het team met een root-causeanalyse: is er een wijziging geweest in permissies, tenantconfiguratie of hybride mailrouting? Vervolgens wordt DKIM opnieuw afgedwongen via PowerShell of het Exchange Admin Center, worden selectors geverifieerd en wordt een proefmail verstuurd om de geldige handtekening te bevestigen. Screenshots, command-output en ticketnummers worden toegevoegd aan het auditdossier zodat aantoonbaar is dat DKIM onafgebroken actief blijft. Het incident wordt afgesloten met een verbeteractie, bijvoorbeeld het automatiseren van health-checks.

Het aanscherpen van DMARC verloopt volgens een gedocumenteerd draaiboek met duidelijke criteria. Na iedere fase wordt een rapportage gedeeld met het CISO-office, inclusief cijfers over alignment, quarantainepercentages en meldingen van gebruikers. Pas wanneer alle betrokken proceseigenaren schriftelijk bevestigen dat hun stromen stabiel zijn, wordt het beleid naar de volgende fase gebracht. Mocht er onverhoopt legitiem verkeer worden afgewezen dan voorziet het draaiboek in een tijdelijke verlaging van het enforcementpercentage gecombineerd met een forensische analyse. Dit voorkomt paniekbesluiten waarbij DMARC volledig wordt uitgezet.

Wanneer DMARC-rapporten aantonen dat een geautoriseerde dienst ontbreekt in SPF, werkt het securityteam samen met de proceseigenaar om de benodigde IP-ranges, envelopedomeinen en DKIM-sleutels in kaart te brengen. De wijziging wordt ingevoerd in alle relevante DNS-zones, gevalideerd via externe checkers en geregistreerd in de inventaris van verzendende diensten. Op deze manier krijgt elke dienst een lifecyclebeheerder en wordt voorkomen dat dezelfde fout zich later opnieuw voordoet. Het proces eindigt pas zodra monitoring bevestigt dat de dienst een consistente "pass" levert.

Elk DMARC-failurerapport dat als legitiem verkeer wordt aangemerkt, krijgt een incident-eigenaar binnen het SOC. Die analyseert de volledige header, correlaties in Defender for Office 365 en eventuele forwarding-paden om vast te stellen waar de authenticatie werd verbroken. De oplossing kan variëren van het toevoegen van een aangepaste DKIM-selector tot het herconfigureren van een externe gateway. Bevindingen worden gedeeld met alle betrokken afdelingen en vastgelegd in het lessons-learned register. Op die manier groeit het collectieve kennisniveau en wordt herhaling voorkomen.

Gebruik PowerShell-script m365-spf-dkim-dmarc.ps1 (functie Invoke-Remediation) – Remediate common issues.

Compliance en Auditing

Een centraal governance-document beschrijft per businessproces welke e-mailverzenders zijn toegestaan, wie eigenaar is en welke contractuele verplichtingen gelden. Dit dossier wordt jaarlijks geactualiseerd, mede ondertekend door proceseigenaren en beschikbaar gesteld aan auditors zodat zij direct kunnen toetsen of iedere dienst binnen de afgesproken kaders opereert. Door het document te koppelen aan risk registers ontstaat een transparante lijn tussen technische maatregelen en beleidsafspraken.

Elk kwartaal verschijnt een DMARC-analyserapport waarin trends, opvallende spoofingpogingen en verbeteracties staan beschreven. Het rapport wordt besproken met het CISO-office, de CIO en de lijnverantwoordelijken zodat bestuurlijke aandacht gewaarborgd is en beslissingen rond handhaving traceerbaar blijven. Eventuele afwijkingen leiden tot corrigerende maatregelen met concrete deadlines. Het rapport wordt bovendien gearchiveerd als bewijsmiddel richting toezichthouders.

Alle DNS-wijzigingen rond SPF, DKIM en DMARC worden vastgelegd in het change management systeem, inclusief goedkeuring, effectanalyse, uitvoerder en testresultaten. Hiermee kan tijdens BIO- of ISO 27001-audits direct worden aangetoond dat kritieke records uitsluitend via het formele proces worden aangepast en dat elke wijziging herleidbaar is naar een ticket en bewijs van uitvoering. Het change-dossier bevat screenshots, exportbestanden en verwijzingen naar monitoringresultaten.

De tijdlijn van het DMARC-beleid, van "p=none" tot "p=reject", wordt opgenomen in een compliance-dossier samen met de risicoafweging en besluitvorming per stap. Auditors kunnen zo nagaan dat de organisatie weloverwogen heeft gehandeld en dat uitzonderlijke situaties, zoals forwarding of gedeelde diensten, expliciet zijn beoordeeld. Het dossier bevat ook communicatie richting ketenpartners om hen voor te bereiden op strengere handhaving. Hierdoor ontstaat draagvlak in de gehele keten en kan niemand claimen dat de verscherping onverwacht kwam.

Succespercentages van e-mailauthenticatie worden periodiek berekend op basis van Exchange message tracking, Defender for Office 365 statistieken en DMARC-rapportages. De cijfers worden uitgesplitst naar interne, externe en third-party bronnen en opgenomen in het reguliere KPI-dashboard voor informatiebeveiliging. Hierdoor kan het bestuur aantoonbaar sturen op verbetering en worden afwijkingen snel zichtbaar. Wanneer een KPI gedurende twee kwartalen onder de norm blijft, wordt automatisch een verbeterplan geëist.

Compliance & Frameworks

Automation

Gebruik het onderstaande PowerShell script om deze security control te monitoren en te implementeren. Het script bevat functies voor zowel monitoring (-Monitoring) als remediation (-Remediation).

PowerShell
<# .SYNOPSIS SPF/DKIM/DMARC Design .DESCRIPTION Email authentication: SPF record (authorized sending IPs), DKIM (digital signature), DMARC policy (reject spoofed emails), alignment (SPF + DKIM both pass = legitimate email). .NOTES Filename: m365-spf-dkim-dmarc.ps1 Author: Nederlandse Baseline voor Veilige Cloud Created: 2025-10-15 Last Modified: 2025-10-15 Version: 1.0 Related JSON: content/design/platform/m365-spf-dkim-dmarc.json Category: platform Workload: design .LINK https://github.com/m365-tenant-best-practise .EXAMPLE .\m365-spf-dkim-dmarc.ps1 -Monitoring Check compliance status .EXAMPLE .\m365-spf-dkim-dmarc.ps1 -Remediation Apply configuration #> #Requires -Version 5.1 [CmdletBinding()] param( [Parameter()] [switch]$Monitoring, [Parameter()] [switch]$Remediation, [Parameter()] [switch]$Revert, [Parameter()] [switch]$WhatIf ) $ErrorActionPreference = 'Stop' # ============================================================================ # HEADER # ============================================================================ Write-Host " ========================================" -ForegroundColor Cyan Write-Host "SPF/DKIM/DMARC Design" -ForegroundColor Cyan Write-Host "Nederlandse Baseline voor Veilige Cloud" -ForegroundColor Cyan Write-Host "======================================== " -ForegroundColor Cyan # ============================================================================ # FUNCTIONS # ============================================================================ function Test-Compliance { <# .SYNOPSIS Tests if current configuration is compliant #> [CmdletBinding()] param() return Invoke-Monitoring } function Invoke-Monitoring { <# .SYNOPSIS Monitors current configuration status #> [CmdletBinding()] param() Write-Host " Monitoring:" -ForegroundColor Yellow # Design document - no API calls $policies = Get-SafeLinksPolicy; $compliantPolicies = @(); $nonCompliantPolicies = @(); foreach ($policy in $policies) { $isCompliant = ($policy.EnableSafeLinksForEmail -eq $true -and $policy.EnableSafeLinksForTeams -eq $true -and $policy.EnableSafeLinksForOffice -eq $true -and $policy.TrackClicks -eq $true -and $policy.AllowClickThrough -eq $false -and $policy.ScanUrls -eq $true); if ($isCompliant) { $compliantPolicies += $policy.Name } else { $nonCompliantPolicies += [PSCustomObject]@{ PolicyName = $policy.Name; EnableForEmail = $policy.EnableSafeLinksForEmail; EnableForTeams = $policy.EnableSafeLinksForTeams; EnableForOffice = $policy.EnableSafeLinksForOffice; TrackClicks = $policy.TrackClicks; AllowClickThrough = $policy.AllowClickThrough; ScanUrls = $policy.ScanUrls } } }; $rules = Get-SafeLinksRule; $hasGlobalRule = $rules | Where-Object { $_.RecipientDomainIs -and $_.Priority -eq 0 }; @{ isCompliant = ($compliantPolicies.Count -gt 0 -and $hasGlobalRule); totalPolicies = $policies.Count; compliantPolicies = $compliantPolicies; nonCompliantPolicies = $nonCompliantPolicies; hasGlobalRule = ($hasGlobalRule -ne $null); message = if ($compliantPolicies.Count -gt 0 -and $hasGlobalRule) { 'Safe Links policy exists with correct settings and global rule' } elseif ($compliantPolicies.Count -eq 0) { 'No compliant Safe Links policies found' } else { 'Safe Links policy exists but no global rule at priority 0' } } } function Invoke-Remediation { <# .SYNOPSIS Applies recommended configuration #> [CmdletBinding()] param() Write-Host " Remediation:" -ForegroundColor Yellow # Design document - no API calls $policyName = 'CIS SafeLinks Policy'; $ruleName = 'CIS SafeLinks'; $existingPolicy = Get-SafeLinksPolicy -Identity $policyName -ErrorAction SilentlyContinue; if ($existingPolicy) { Write-Host 'Removing existing CIS SafeLinks policy...' -ForegroundColor Yellow; $existingRule = Get-SafeLinksRule | Where-Object { $_.SafeLinksPolicy -eq $policyName }; if ($existingRule) { Remove-SafeLinksRule -Identity $existingRule.Identity -Confirm:$false }; Remove-SafeLinksPolicy -Identity $policyName -Confirm:$false }; $params = @{ Name = $policyName; EnableSafeLinksForEmail = $true; EnableSafeLinksForTeams = $true; EnableSafeLinksForOffice = $true; TrackClicks = $true; AllowClickThrough = $false; ScanUrls = $true; EnableForInternalSenders = $true; DeliverMessageAfterScan = $true; DisableUrlRewrite = $false }; New-SafeLinksPolicy @params -ErrorAction Stop; Write-Host "Created policy: $policyName" -ForegroundColor Green; $domains = (Get-AcceptedDomain).Name; New-SafeLinksRule -Name $ruleName -SafeLinksPolicy $policyName -RecipientDomainIs $domains -Priority 0 -ErrorAction Stop; Write-Host "Created global rule: $ruleName" -ForegroundColor Green } function Invoke-Revert { <# .SYNOPSIS Reverts configuration to previous state #> [CmdletBinding()] param() Write-Host " Revert:" -ForegroundColor Yellow Write-Host "Reverting configuration..." -ForegroundColor Yellow Write-Host "Manual revert required - see JSON documentation" -ForegroundColor Gray } # ============================================================================ # MAIN EXECUTION # ============================================================================ try { if ($Revert) { if ($WhatIf) { Write-Host "WhatIf: Would revert configuration" -ForegroundColor Yellow } else { Invoke-Revert } } elseif ($Monitoring) { Invoke-Monitoring } elseif ($Remediation) { if ($WhatIf) { Write-Host "WhatIf: Would apply remediation" -ForegroundColor Yellow } else { Invoke-Remediation } } else { Write-Host "Available parameters:" -ForegroundColor Yellow Write-Host " -Monitoring : Check current status" -ForegroundColor Gray Write-Host " -Remediation : Apply configuration" -ForegroundColor Gray Write-Host " -Revert : Revert changes" -ForegroundColor Gray Write-Host " -WhatIf : Show what would happen" -ForegroundColor Gray } } catch { Write-Error "Error: $_" throw } finally { Write-Host " ======================================== " -ForegroundColor Cyan }

Risico zonder implementatie

Risico zonder implementatie
Critical: Wanneer SPF, DKIM en DMARC ontbreken of onvolledig zijn, kunnen aanvallers probleemloos berichten sturen die lijken op vertrouwde afzenders binnen de organisatie. Medewerkers en ketenpartners vertrouwen deze e-mails en lopen daardoor een hoog risico op credential-phishing, ransomware en datalekken, terwijl de reputatie van het primaire domein blijvende schade oploopt. Daarnaast voldoet de organisatie zonder deze maatregelen niet aan relevante normen zoals BIO 13.01, NIS2 en ISO 27001, wat leidt tot bevindingen bij audits en mogelijke bestuurlijke maatregelen.

Management Samenvatting

Publiceer een volledig SPF-record met uitsluitend geautoriseerde verzendplatforms, activeer DKIM voor alle domeinen en rol DMARC uit volgens het traject p=none → p=quarantine → p=reject met strikte alignment en uitgebreide rapportage. Analyseer dagelijks de binnenkomende rapporten, corrigeer afwijkingen en leg elke wijziging vast in het changeproces zodat auditors kunnen aantonen dat e-mailauthenticatie continu wordt bewaakt. Deze aanpak vereist voornamelijk DNS- en configuratiewerk (circa 24 uur) en levert een aantoonbare reductie van spoofingincidenten op.