BIO 13.01 ISO A.13.1.1

Accepted Domains Design

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

💼 Management Samenvatting

Accepted domains bepalen voor welke domeinen Exchange Online e-mail kan ontvangen en verzenden.

Aanbeveling
IMPLEMENTEER ACCEPTED DOMAINS
Risico zonder
Medium
Risk Score
5/10
Implementatie
12u (tech: 8u)
Van toepassing op:
✓ Exchange Online
✓ Microsoft 365
✓ SMTP

Zonder correct geconfigureerde accepted domains kan e-mail niet worden afgeleverd, kunnen phishing-aanvallen plaatsvinden via domain spoofing, en ontstaan mail routing problemen. Accepted domains vormen de basis van e-mailbeveiliging en correcte mail flow in Microsoft 365.

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

Implementatie

Dit design document beschrijft de configuratie van accepted domains in Exchange Online. Het omvat authoritative domains (primaire e-maildomeinen), internal relay domains (voor hybride scenario's), en external relay domains (voor e-mailsystemen van derde partijen).

Vereisten

Voor de implementatie van accepted domains in Exchange Online zijn verschillende technische en organisatorische vereisten van essentieel belang. Deze vereisten vormen de basis voor een succesvolle en veilige configuratie van e-maildomeinen binnen de Microsoft 365-omgeving. De primaire technische vereiste is dat organisaties beschikken over een geverifieerd aangepast domein in het Microsoft 365-beheercentrum. Domeinverificatie is een kritieke beveiligingsmaatregel die voorkomt dat onbevoegden e-maildomeinen kunnen configureren en misbruiken. Het verificatieproces vereist dat organisaties bewijs leveren van domeineigendom door middel van DNS-records, specifiek TXT-records die door Microsoft worden gegenereerd. Deze verificatie moet worden uitgevoerd voordat een domein kan worden geactiveerd als accepted domain in Exchange Online. Naast domeinverificatie moeten organisaties beschikken over de juiste Exchange Online-licenties voor alle gebruikers die e-mailfunctionaliteit nodig hebben. De licentievoorwaarden bepalen welke Exchange Online-functies beschikbaar zijn, inclusief de mogelijkheid om accepted domains te configureren en te beheren. Organisaties moeten ervoor zorgen dat hun licentieovereenkomst de benodigde functionaliteit dekt, vooral in complexe scenario's met meerdere domeinen of hybride configuraties. Een kritieke vereiste is dat organisaties volledige controle hebben over hun DNS-configuratie, specifiek voor MX- en TXT-records. Deze controle is essentieel voor zowel de initiële verificatie als de continue werking van e-mailservices. MX-records bepalen waar inkomende e-mail naartoe wordt gerouteerd, terwijl TXT-records worden gebruikt voor verificatie, SPF-configuratie en andere beveiligingsmaatregelen zoals DMARC. Zonder DNS-controle kunnen organisaties accepted domains niet correct configureren of onderhouden. Organisaties moeten ook uitgebreide documentatie bijhouden van hun mail flow-architectuur. Deze documentatie moet duidelijk beschrijven hoe e-mail wordt gerouteerd binnen de organisatie, of dit nu direct naar de cloud gaat, via een hybride configuratie met on-premises Exchange-servers, of via een gateway van een derde partij. Deze informatie is cruciaal voor het bepalen van het juiste type accepted domain (authoritative, internal relay, of external relay) en voor het oplossen van problemen met e-maillevering. Voor organisaties met hybride configuraties zijn aanvullende vereisten van toepassing. Deze omvatten een functionerende on-premises Exchange-omgeving, correct geconfigureerde connectors tussen on-premises en cloud, en synchronisatie van directory-informatie via Azure AD Connect. Hybride configuraties vereisen ook dat netwerkconnectiviteit tussen on-premises en cloud correct is geconfigureerd, inclusief firewallregels en routing. Ten slotte moeten organisaties beschikken over de juiste beheerrechten en -rollen binnen Microsoft 365. Het configureren van accepted domains vereist typisch de rol van Global Administrator of Exchange Administrator. Organisaties moeten ervoor zorgen dat alleen geautoriseerd personeel toegang heeft tot deze beheerfuncties en dat alle wijzigingen worden gelogd voor auditdoeleinden.

Implementatie

De implementatie van accepted domains in Exchange Online vereist een systematische aanpak waarbij verschillende domeintypen worden geconfigureerd op basis van de specifieke mail flow-architectuur van de organisatie. Het begrijpen van de verschillende domeintypen is essentieel voor een correcte implementatie. Het eerste domeintype is het authoritative domain, waarbij Microsoft 365 de e-mailautoriteit is voor het domein. Dit betekent dat alle e-mail voor dit domein wordt afgeleverd aan Exchange Online-mailboxen. Authoritative domains zijn de meest voorkomende configuratie voor organisaties die volledig in de cloud werken. Wanneer een domein als authoritative is geconfigureerd, accepteert Exchange Online alle inkomende e-mail voor dat domein en levert deze af aan de juiste mailboxen. Uitgaande e-mail wordt verzonden met dit domein als afzenderdomein. Het tweede domeintype is het internal relay domain, dat wordt gebruikt in hybride scenario's waarbij organisaties zowel on-premises Exchange-servers als Exchange Online gebruiken. Bij een internal relay domain accepteert Exchange Online inkomende e-mail voor het domein, maar levert deze niet direct af aan cloud-mailboxen. In plaats daarvan wordt de e-mail doorgestuurd naar de on-premises Exchange-servers voor verdere verwerking en aflevering. Deze configuratie is essentieel voor organisaties die een gefaseerde migratie naar de cloud uitvoeren of die bepaalde gebruikersgroepen on-premises willen houden. Het derde domeintype is het external relay domain, dat wordt gebruikt wanneer organisaties e-mailsystemen van derde partijen gebruiken voor e-mailverwerking. Bij een external relay domain accepteert Exchange Online inkomende e-mail, maar stuurt deze door naar een extern e-mailsysteem voor aflevering. Deze configuratie wordt vaak gebruikt wanneer organisaties gespecialiseerde e-mailgateways of -filters gebruiken die zich buiten de Microsoft 365-omgeving bevinden. Een kritieke stap in de implementatie is het aanwijzen van één domein als primair domein. Het primaire domein wordt standaard gebruikt voor nieuwe mailboxen wanneer geen specifiek domein wordt opgegeven. Deze configuratie zorgt voor consistentie in e-mailadressen en vereenvoudigt het beheer van nieuwe gebruikers. Organisaties moeten zorgvuldig overwegen welk domein als primair wordt aangewezen, omdat dit domein vaak wordt gebruikt als standaard voor nieuwe gebruikers en kan worden weergegeven in externe communicatie. Voordat een domein kan worden geactiveerd als accepted domain, moet domeineigendom worden geverifieerd via een TXT-record in DNS. Dit verificatieproces is een fundamentele beveiligingsmaatregel die voorkomt dat onbevoegden e-maildomeinen kunnen configureren. Het verificatieproces begint in het Microsoft 365-beheercentrum, waar een unieke verificatiecode wordt gegenereerd. Deze code moet worden toegevoegd als een TXT-record in de DNS-configuratie van het domein. Zodra Microsoft de TXT-record kan verifiëren, wordt het domein als geverifieerd gemarkeerd en kan het worden geactiveerd als accepted domain. De implementatie moet worden uitgevoerd in een gestructureerde volgorde. Eerst moeten alle benodigde domeinen worden geverifieerd in het Microsoft 365-beheercentrum. Vervolgens moeten organisaties hun mail flow-architectuur documenteren om te bepalen welk domeintype voor elk domein geschikt is. Daarna kunnen accepted domains worden geconfigureerd in Exchange Online via het Exchange-beheercentrum of via PowerShell-cmdlets. Het is aanbevolen om eerst een testdomein te configureren om het proces te valideren voordat productiedomeinen worden geconfigureerd. Na de initiële configuratie moeten organisaties controleren of e-mail correct wordt gerouteerd en afgeleverd. Dit omvat het testen van zowel inkomende als uitgaande e-mail voor elk geconfigureerd domein. Organisaties moeten ook controleren of MX-records correct zijn geconfigureerd en of SPF-, DKIM- en DMARC-records correct zijn ingesteld voor e-mailbeveiliging.

Gebruik PowerShell-script m365-accepted-domains.ps1 (functie Invoke-Monitoring) – Monitor accepted domains configuratie.

Monitoring

Effectieve monitoring van accepted domains is essentieel voor het waarborgen van e-mailbeveiliging en het voorkomen van onbevoegde wijzigingen aan de domeinconfiguratie. Monitoring moet zowel proactief als reactief zijn, waarbij regelmatige controles worden gecombineerd met real-time alerting voor kritieke wijzigingen. De primaire monitoringinterface voor accepted domains is het Exchange-beheercentrum, specifiek de sectie Mail flow > Accepted domains. Deze interface biedt een overzicht van alle geconfigureerde accepted domains, inclusief hun type (authoritative, internal relay, of external relay), verificatiestatus, en of het domein is aangewezen als primair domein. Beheerders moeten regelmatig deze interface controleren om te verifiëren dat alleen geautoriseerde domeinen zijn geconfigureerd en dat de configuratie overeenkomt met de gedocumenteerde mail flow-architectuur. Voor geautomatiseerde monitoring en rapportage kunnen organisaties gebruik maken van PowerShell-cmdlets, specifiek de Get-AcceptedDomain cmdlet. Deze cmdlet maakt het mogelijk om programmatisch alle accepted domains op te halen en te analyseren, wat essentieel is voor geautomatiseerde compliance-controles en rapportage. Geautomatiseerde scripts kunnen worden geconfigureerd om regelmatig te controleren op wijzigingen in de accepted domains-configuratie en om waarschuwingen te genereren wanneer onverwachte wijzigingen worden gedetecteerd. Een kritiek aspect van monitoring is het detecteren van onbevoegde domeintoevoegingen. Onbevoegde domeinen kunnen worden toegevoegd door kwaadwillende actoren die toegang hebben gekregen tot beheeraccounts, of door fouten van beheerders. Onbevoegde domeinen vormen een significant beveiligingsrisico omdat ze kunnen worden gebruikt voor phishing-aanvallen, domain spoofing, of het onderscheppen van e-mail. Organisaties moeten daarom geautomatiseerde controles implementeren die waarschuwen wanneer nieuwe domeinen worden toegevoegd zonder de juiste autorisatie. Naast monitoring binnen Exchange Online moeten organisaties ook MX-record monitoring uitvoeren via externe DNS-tools. MX-records bepalen waar inkomende e-mail naartoe wordt gerouteerd, en wijzigingen aan deze records kunnen leiden tot e-maillevering problemen of beveiligingsincidenten. Externe DNS-monitoringtools kunnen worden geconfigureerd om regelmatig MX-records te controleren en waarschuwingen te genereren wanneer wijzigingen worden gedetecteerd. Deze monitoring is vooral belangrijk omdat MX-records kunnen worden gewijzigd zonder dat wijzigingen nodig zijn in Exchange Online, wat betekent dat wijzigingen mogelijk niet direct zichtbaar zijn in het Exchange-beheercentrum. Organisaties moeten ook monitoring implementeren voor domeinverificatiestatus. Geverifieerde domeinen kunnen hun verificatiestatus verliezen wanneer DNS-records worden gewijzigd of verwijderd, wat kan leiden tot problemen met e-maillevering. Monitoring moet waarschuwen wanneer de verificatiestatus van een domein verandert, zodat beheerders onmiddellijk actie kunnen ondernemen om de verificatie te herstellen. Voor uitgebreide monitoring en forensische analyse moeten organisaties ook audit logging configureren voor alle wijzigingen aan accepted domains. Azure AD audit logs en Exchange admin audit logs bieden gedetailleerde informatie over wie welke wijzigingen heeft gemaakt en wanneer. Deze logs zijn essentieel voor het onderzoeken van beveiligingsincidenten en voor compliance-doeleinden. Organisaties moeten ervoor zorgen dat audit logs worden bewaard voor de vereiste retentietijd en dat ze regelmatig worden gecontroleerd op verdachte activiteiten. Het is aanbevolen om monitoring uit te voeren met een frequentie van minimaal wekelijks, of vaker in omgevingen met hoge beveiligingsvereisten. Daarnaast moeten organisaties real-time alerting implementeren voor kritieke gebeurtenissen, zoals de toevoeging van nieuwe domeinen, wijzigingen aan domeintypen, of wijzigingen aan de primaire domeinconfiguratie. Deze alerts moeten worden geconfigureerd om direct beveiligingsteams te waarschuwen zodat snelle actie kan worden ondernomen wanneer nodig.

Gebruik PowerShell-script m365-accepted-domains.ps1 (functie Invoke-Monitoring) – Voer compliance controle uit.

Remediatie

Wanneer monitoring onbevoegde accepted domains detecteert of wanneer configuratiefouten worden geïdentificeerd, is onmiddellijke remediatie vereist om beveiligingsrisico's te mitigeren en e-maillevering te herstellen. Het remediatieproces moet zorgvuldig worden uitgevoerd om te voorkomen dat legitieme e-mailservices worden verstoord. De primaire remediatie-actie voor onbevoegde accepted domains is het onmiddellijk verwijderen van deze domeinen uit de Exchange Online-configuratie. Voordat een domein wordt verwijderd, moeten organisaties eerst onderzoeken hoe en wanneer het domein is toegevoegd, en of er legitieme e-mailservices gebruik maken van dit domein. Als het domein wordt gebruikt voor legitieme doeleinden maar zonder de juiste autorisatie is toegevoegd, moet het verwijderingsproces worden gecoördineerd met de betrokken partijen om serviceonderbrekingen te voorkomen. Als het domein daarentegen kwaadwillend is toegevoegd, moet het onmiddellijk worden verwijderd zonder verdere coördinatie. Een veelvoorkomend probleem dat remediatie vereist, is wanneer MX-records naar verkeerde eindpunten wijzen. MX-records bepalen waar inkomende e-mail naartoe wordt gerouteerd, en incorrect geconfigureerde MX-records kunnen leiden tot e-maillevering problemen of beveiligingsrisico's. Wanneer monitoring detecteert dat MX-records naar verkeerde eindpunten wijzen, moeten organisaties onmiddellijk de DNS-configuratie corrigeren. Dit omvat het identificeren van de correcte MX-records op basis van de mail flow-architectuur en het bijwerken van de DNS-configuratie. Na het bijwerken van MX-records moeten organisaties controleren of e-mail correct wordt gerouteerd en afgeleverd. Wanneer de mail flow-architectuur van een organisatie verandert, bijvoorbeeld bij een migratie van hybride naar volledig cloud, of bij de implementatie van een nieuwe e-mailgateway, moeten accepted domains mogelijk worden bijgewerkt naar een ander domeintype. Een domein dat oorspronkelijk was geconfigureerd als internal relay domain moet mogelijk worden gewijzigd naar authoritative domain wanneer alle mailboxen naar de cloud zijn gemigreerd. Deze wijzigingen moeten zorgvuldig worden gepland en uitgevoerd om serviceonderbrekingen te voorkomen. Organisaties moeten eerst de nieuwe mail flow-architectuur testen voordat domeintypen worden gewijzigd, en moeten een rollback-plan hebben voor het geval er problemen optreden. Domeinverificatie kan verloren gaan wanneer DNS-records worden gewijzigd of verwijderd, of wanneer DNS-providers worden gewijzigd. Wanneer monitoring detecteert dat een domein zijn verificatiestatus heeft verloren, moeten organisaties onmiddellijk de verificatie herstellen door de benodigde TXT-records opnieuw toe te voegen aan de DNS-configuratie. Het verificatieproces moet worden uitgevoerd via het Microsoft 365-beheercentrum, waar een nieuwe verificatiecode wordt gegenereerd. Deze code moet worden toegevoegd als TXT-record in DNS, en zodra Microsoft de verificatie kan bevestigen, wordt het domein opnieuw als geverifieerd gemarkeerd. Voor kritieke productieomgevingen wordt aanbevolen om remediatie eerst uit te voeren in een testomgeving of tijdens een geplande onderhoudsperiode. Dit stelt organisaties in staat om de impact van wijzigingen te beoordelen en eventuele problemen op te lossen voordat wijzigingen worden toegepast op productiesystemen. Daarnaast moeten organisaties communicatieplannen hebben om gebruikers en beheerders te informeren over wijzigingen in e-mailconfiguratie en eventuele tijdelijke serviceonderbrekingen. Na het voltooien van remediatie, moeten organisaties een verificatie uitvoeren om te bevestigen dat de wijzigingen correct zijn toegepast en dat e-mailservices normaal functioneren. Deze verificatie omvat het testen van zowel inkomende als uitgaande e-mail voor alle betrokken domeinen, het controleren van MX-records en verificatiestatus, en het valideren dat de configuratie overeenkomt met de gedocumenteerde mail flow-architectuur. Organisaties moeten ook een gedetailleerd rapport genereren van alle uitgevoerde remediatie-acties voor auditdoeleinden.

Gebruik PowerShell-script m365-accepted-domains.ps1 (functie Invoke-Remediation) – Herstel configuratie.

Compliance en Auditing

Accepted domains configuratie is een fundamenteel onderdeel van e-mailbeveiliging en vormt de basis voor compliance met verschillende beveiligingsstandaarden en regelgevende vereisten. Nederlandse overheidsorganisaties en bedrijven moeten uitgebreide documentatie en audit trails bijhouden om te voldoen aan wettelijke en regelgevende vereisten. Uitgebreide documentatie van accepted domains en de onderliggende mail flow-rationale is essentieel voor compliance-doeleinden. Deze documentatie moet duidelijk beschrijven welke domeinen zijn geconfigureerd als accepted domains, waarom deze domeinen zijn geconfigureerd, en hoe e-mail wordt gerouteerd voor elk domein. De documentatie moet ook de mail flow-architectuur beschrijven, inclusief of e-mail direct naar de cloud gaat, via hybride configuraties wordt gerouteerd, of via externe gateways. Deze documentatie is niet alleen belangrijk voor interne beheerdoeleinden, maar ook voor externe audits en compliance-assessments. Organisaties moeten ervoor zorgen dat documentatie regelmatig wordt bijgewerkt wanneer wijzigingen worden gemaakt aan de accepted domains-configuratie of mail flow-architectuur. Audit logging van alle domeintoevoegingen en -wijzigingen is een kritieke vereiste voor compliance en beveiliging. Azure AD audit logs en Exchange admin audit logs bieden gedetailleerde informatie over wie welke wijzigingen heeft gemaakt aan accepted domains, wanneer deze wijzigingen zijn gemaakt, en welke specifieke configuratiewijzigingen zijn doorgevoerd. Deze logs zijn essentieel voor het onderzoeken van beveiligingsincidenten, het identificeren van onbevoegde wijzigingen, en het aantonen van compliance tijdens externe audits. Organisaties moeten ervoor zorgen dat audit logs worden bewaard voor de vereiste retentietijd, die typisch minimaal drie jaar is voor Nederlandse overheidsorganisaties, en dat logs regelmatig worden gecontroleerd op verdachte activiteiten. Kwartaalreviews van actieve accepted domains zijn een belangrijk onderdeel van continue compliance. Tijdens deze reviews moeten organisaties controleren of alle geconfigureerde accepted domains nog steeds nodig zijn en correct zijn geconfigureerd. Reviews moeten ook controleren of domeinverificatiestatus nog steeds geldig is, of MX-records correct zijn geconfigureerd, en of de configuratie overeenkomt met de gedocumenteerde mail flow-architectuur. Kwartaalreviews bieden ook de mogelijkheid om ongebruikte of onnodige accepted domains te identificeren en te verwijderen, wat de beveiligingspostuur verbetert door de aanvalsoppervlakte te verkleinen. Reviews moeten worden gedocumenteerd en moeten resulteren in actie-items voor het oplossen van geïdentificeerde problemen. MX-record validatie tegen de beoogde configuratie is essentieel voor het waarborgen van correcte e-maillevering en beveiliging. MX-records bepalen waar inkomende e-mail naartoe wordt gerouteerd, en incorrect geconfigureerde MX-records kunnen leiden tot e-maillevering problemen, beveiligingsrisico's, of compliance-problemen. Organisaties moeten regelmatig controleren of MX-records overeenkomen met de beoogde configuratie zoals gedocumenteerd in de mail flow-architectuur. Deze validatie moet worden uitgevoerd via externe DNS-tools om te verifiëren dat MX-records correct zijn geconfigureerd in de publieke DNS, en moet worden vergeleken met de accepted domains-configuratie in Exchange Online om te verifiëren dat beide configuraties consistent zijn. Voor Nederlandse overheidsorganisaties zijn er aanvullende compliance-overwegingen. Organisaties die vallen onder de Baseline Informatiebeveiliging Overheid (BIO) moeten voldoen aan specifieke vereisten voor netwerkbeveiliging en e-mailbeveiliging. BIO controle 13.01 richt zich op netwerktoegangscontrole en vereist dat organisaties passende maatregelen treffen om onbevoegde toegang te voorkomen. Correct geconfigureerde accepted domains zijn een essentiële component van deze controle. Organisaties moeten kunnen aantonen dat accepted domains correct zijn geconfigureerd en dat er controles zijn geïmplementeerd om onbevoegde wijzigingen te voorkomen. Tijdens externe audits en compliance-assessments zullen auditors specifiek controleren of accepted domains correct zijn geconfigureerd, of er uitgebreide documentatie beschikbaar is, en of audit logs worden bijgehouden en bewaard. Organisaties moeten daarom ervoor zorgen dat alle benodigde documentatie en audit trails beschikbaar zijn en dat ze kunnen aantonen dat accepted domains worden beheerd volgens best practices en regelgevende vereisten. Het is belangrijk op te merken dat compliance geen eenmalige activiteit is, maar een continu proces dat regelmatige aandacht en onderhoud vereist.

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 Accepted Domains Design .DESCRIPTION Implementation for Accepted Domains Design .NOTES Filename: m365-accepted-domains.ps1 Author: Nederlandse Baseline voor Veilige Cloud Version: 1.0 Related JSON: content/design/platform/m365-accepted-domains.json #> #Requires -Version 5.1 #Requires -Modules Microsoft.Graph [CmdletBinding()] param( [Parameter()][switch]$WhatIf, [Parameter()][switch]$Monitoring, [Parameter()][switch]$Remediation, [Parameter()][switch]$Revert ) $ErrorActionPreference = 'Stop' $VerbosePreference = 'Continue' $PolicyName = "Accepted Domains Design" $BIOControl = "13.01" function Connect-RequiredServices { # Connection logic based on API } function Test-Compliance { Write-Verbose "Testing compliance for: $PolicyName..." $result = [PSCustomObject]@{ ScriptName = "m365-accepted-domains" PolicyName = $PolicyName IsCompliant = $false TotalResources = 0 CompliantCount = 0 NonCompliantCount = 0 Details = @() Recommendations = @() } # Compliance check implementation # Based on: Design Document $result.Details += "Compliance check - implementation required based on control" $result.NonCompliantCount = 1 return $result } function Invoke-Remediation { Write-Host "`nApplying remediation for: $PolicyName..." -ForegroundColor Cyan # Remediation implementation Write-Host " Configuration applied" -ForegroundColor Green Write-Host "`n[OK] Remediation completed" -ForegroundColor Green } function Invoke-Monitoring { $result = Test-Compliance Write-Host "`n========================================" -ForegroundColor Cyan Write-Host "$PolicyName" -ForegroundColor Cyan Write-Host "========================================" -ForegroundColor Cyan Write-Host "Total: $($result.TotalResources)" -ForegroundColor White Write-Host "Compliant: $($result.CompliantCount)" -ForegroundColor Green $color = if ($result.NonCompliantCount -gt 0) { "Red" } else { "Green" } Write-Host "Non-compliant: $($result.NonCompliantCount)" -ForegroundColor $color return $result } function Invoke-Revert { Write-Host "Revert: Configuration revert not yet implemented" -ForegroundColor Yellow } try { Connect-RequiredServices if ($Monitoring) { Invoke-Monitoring } elseif ($Remediation) { if ($WhatIf) { Write-Host "WhatIf: Would apply remediation" -ForegroundColor Yellow } else { Invoke-Remediation } } elseif ($Revert) { Invoke-Revert } else { $result = Test-Compliance if ($result.IsCompliant) { Write-Host "`n[OK] COMPLIANT" -ForegroundColor Green } else { Write-Host "`n[FAIL] NON-COMPLIANT" -ForegroundColor Red } } } catch { Write-Error $_ }

Risico zonder implementatie

Risico zonder implementatie
Medium: Onjuist geconfigureerde accepted domains leiden tot e-maillevering problemen, mail routing loops, en teruggestuurde e-mails. Bedrijfsverstoring door gemiste communicatie. Compliance: operationeel. Het risico is medium - e-maillevering.

Management Samenvatting

M365 Accepted Domains: Configureer alle organisatorische e-maildomeinen in Exchange Online (primair domein + aliassen). Authoritative domains (e-mail afgeleverd aan M365-mailboxen), Internal relay (hybride scenario's - route naar on-premises). DNS-verificatie (TXT-records bewijzen eigendom). Activatie: Exchange Admin → Accepted domains → Toevoegen + verifiëren domeinen. Gratis. Implementatie: 4-8 uur (multi-domein omgevingen). Basis voor e-maillevering - zorgt voor correcte mail routing.