Exchange Online email security review
An Exchange Online email security review is an independent check of how your Microsoft 365 tenant is configured to filter and authenticate email. It compares threat policies (with Microsoft Defender for Office 365 settings where licensed), email authentication (SPF, DKIM, and DMARC), external forwarding, mail flow rules, and mailbox auditing with Microsoft’s published recommendations, and reports each finding with evidence.
What Microsoft recommends for email protection
Microsoft’s public documentation recommends settings for email threat policies, sender allow lists and mail flow rules, external forwarding, and domain authentication. The review checks your tenant against each recommendation below that your licensing and the agreed scope include, quoted from the Microsoft Learn page it comes from.
Use the Standard or Strict security level for email threat policies
What the review checks: The review records whether the Standard and Strict preset security policies are turned on and which recipients each one covers. Recipients covered only by default or custom policies have their anti-spam, anti-malware, and anti-phishing settings compared with Microsoft’s Standard and Strict values.
“We recommend two security levels: Standard and Strict.”
Recommended email and collaboration threat policy settings for cloud organizations, Microsoft Learn Use the Strict preset security policy for priority accounts
What the review checks: The review checks that priority accounts, such as CEOs, CFOs, and infrastructure admin accounts, receive Strict protection in its Exchange Online Protection assignment and, where Microsoft Defender for Office 365 is licensed, its Defender for Office 365 assignment, with no exceptions removing them.
“You can implement this stringent approach for priority accounts by using the Strict profile in preset security policies.”
Security recommendations for priority accounts in cloud organizations, Microsoft Learn Add senders in key roles to user impersonation protection
What the review checks: Anti-phishing policies are checked for senders in key roles, such as the CEO and CFO, in the users to protect list, for protection of domains you own, and for whether any trusted senders or domains excluded from impersonation protection are justified.
“We recommend adding users (message senders) in key roles.”
Recommended email and collaboration threat policy settings for cloud organizations, Microsoft Learn Licensing: Microsoft states that only Defender for Office 365 includes impersonation settings in anti-phishing policies.
Leave zero-hour auto purge (ZAP) for phishing and spam turned on
What the review checks: Each anti-spam policy is checked for zero-hour auto purge turned on for phishing and spam messages. Anti-malware policies are checked for ZAP for malware, which Microsoft also recommends leaving on.
“By default, ZAP for phishing and ZAP for spam are turned on, and we recommend that you leave them on.”
Anti-spam protection in cloud organizations, Microsoft Learn Set automatic external forwarding explicitly to On or Off, not system-controlled
What the review checks: Outbound spam policies left on the system-controlled forwarding option are flagged, as Microsoft’s recommended Standard and Strict value is Off. Remote domains and mail flow rules are cross-checked, and the Auto forwarded messages report shows cloud-based accounts that automatically forward externally.
“Because the behavior can differ by organization, configure On - Forwarding is enabled or Off - Forwarding is disabled instead of Automatic - System-controlled.”
Control automatic external email forwarding from cloud mailboxes, Microsoft Learn Never skip spam filtering with a mail flow rule based only on the sender domain
What the review checks: Mail flow rules that bypass spam filtering are listed and their conditions inspected. Rules whose only condition is the sender domain, or that use your own accepted domains or popular domains as conditions, are flagged.
“Never configure mail flow rules with only the sender domain as the condition to skip spam filtering.”
Create sender allowlists for cloud mailboxes, Microsoft Learn Generally avoid allowed sender and allowed domain lists in anti-spam policies
What the review checks: Allowed sender and domain lists in default and custom anti-spam policies should be empty or temporary, with allow entries kept in the Tenant Allow/Block List, which Microsoft ranks as most recommended. IP Allow List entries in the default connection filter policy are reviewed too.
“You should generally avoid using allowed sender lists or allowed domain lists in custom anti-spam policies or in the default anti-spam policy.”
Create sender allowlists for cloud mailboxes, Microsoft Learn End the SPF record for Microsoft 365 domains with -all (hard fail)
What the review checks: Each sending domain and subdomain should have exactly one SPF record that includes spf.protection.outlook.com for Microsoft 365 mail, ends in -all rather than ~all or ?all, and does not exceed 10 DNS lookups. Domains that send no mail should publish v=spf1 -all.
“For Microsoft 365 domains, we recommend -all (hard fail) because we also recommend DKIM and DMARC for the domain.”
Set up SPF to identify valid email sources for your custom cloud domains, Microsoft Learn Configure DKIM signing with your custom domains or subdomains
What the review checks: Each custom domain or subdomain that sends mail should show DKIM signing enabled with a Valid status. Key size, key creation time, and rotation date are also read, since Microsoft advises changing the DKIM key periodically.
“Configure DKIM signing using custom domains or subdomains: A message needs to be DKIM signed by the domain in the From address.”
Set up DKIM to sign mail from your cloud domain, Microsoft Learn Reach DMARC p=reject on all custom domains and subdomains, testing along the way
What the review checks: The DMARC record for each custom domain and sending subdomain is checked for its policy (none, quarantine, or reject), pct value, and aggregate report address. Domains that send no mail should publish p=reject, including the *.onmicrosoft.com domain if it isn’t used for email.
“The goal is to get to a p=reject DMARC policy for all of your custom domains and subdomains, but you need to test and verify along the way to prevent destination email systems from rejecting good mail because of unintentional DMARC failures.”
Set up DMARC to validate the From address domain for cloud senders, Microsoft Learn
What the email review covers
The review examines how mail protection is configured in your tenant and in the DNS records for your domains. Microsoft Defender for Office 365 settings are reviewed where licensed.
Part of the audit's email protection area.
- Preset security policies
- Whether the Standard and Strict preset security policies are turned on, which recipients they apply to, and which recipients are covered only by default or custom policies.
- Threat policy settings
- Anti-phishing, anti-spam, and anti-malware policies compared setting by setting with Microsoft’s Standard and Strict values, including zero-hour auto purge.
- Microsoft Defender for Office 365, where licensed
- Impersonation protection, Safe Links, and Safe Attachments compared with the Standard and Strict values, and any exclusions from Built-in protection checked against Microsoft’s guidance.
- Configuration analyzer and drift
- Configuration analyzer results are reviewed where the agreed access allows, to find threat policies with settings less secure than the Standard and Strict profiles. Where Unified Auditing is enabled, its drift history also shows changes that decreased security compared with those settings.
- Email authentication for your domains
- SPF, DKIM, and DMARC for every domain and subdomain that sends mail, and protective SPF and DMARC records for domains that send none.
- Forwarding and mail flow rules
- Automatic external forwarding in outbound spam policies, remote domain settings, and mail flow rules that skip spam filtering.
- Allow lists and exclusions
- Allowed senders and domains in anti-spam policies, IP Allow List entries and, where licensed, trusted senders excluded from impersonation protection, each checked for a current reason to exist.
- Mailbox auditing
- Whether mailbox auditing on by default remains turned on for the organization, which accounts bypass mailbox audit logging, and which mailboxes have customized audited actions.
When teams ask for it
- After phishing reaches users
- Check whether threat policies, impersonation protection, and allow lists match Microsoft’s guidance before deciding what to change.
- Moving DMARC toward enforcement
- Confirm that SPF and DKIM are in place for every domain that sends mail before moving DMARC beyond p=none.
- Concern about mail leaving the organization
- Find out whether automatic external forwarding is controlled, and which cloud-based accounts already forward mail automatically to outside recipients.
- Reviewing Microsoft Defender for Office 365 coverage
- Check how Safe Links, Safe Attachments, and impersonation protection are applied, and which users each policy covers.
- Exceptions that were never revisited
- Review allow entries, IP Allow List entries, and mail flow rules added for individual senders, and whether each is still needed.
What you receive
Each finding is reported with the configuration evidence behind it, its business context, and a recommended action. Findings are sequenced into a remediation roadmap, so your team knows what to change first.
Questions
Do we need Microsoft Defender for Office 365 for this review?
No. The review covers the built-in security features that Microsoft includes in all organizations with cloud mailboxes, and Microsoft Defender for Office 365 settings are reviewed where you license them.
Licensing determines which controls exist. Microsoft states that only Defender for Office 365 includes impersonation settings in anti-phishing policies, and it describes users without Defender for Office 365 licenses as not eligible for Safe Links and Safe Attachments protections. Findings state where a recommendation depends on a license you may not have.
Will the review show who automatically forwards email outside the organization?
Yes, for cloud-based accounts, where the agreed access allows. The review uses Microsoft’s Auto forwarded messages report, which shows cloud-based accounts that automatically forward messages to external recipients, alongside the settings that allow or block forwarding. For on-premises users who forward through Microsoft 365, Microsoft says a mail flow rule is needed to track them.
Microsoft advises setting automatic forwarding in outbound spam policies explicitly to On or Off rather than the system-controlled option, and its recommended Standard and Strict value is Off. Microsoft also describes using remote domains to control the external domains that users can forward messages to, so where forwarding is needed, the review checks how those exceptions are scoped.
Should we move our DMARC policy from p=none to p=reject?
Microsoft’s guidance points that way, in stages. Its stated goal is a p=reject policy for all of your custom domains and subdomains, reached by moving from p=none to p=quarantine and then to p=reject, monitoring the results at each step so that good mail isn’t rejected.
Microsoft also advises regularly reviewing DMARC aggregate reports to see where mail from your domains comes from. The review records the current policy and reporting for each domain and checks that SPF and DKIM are in place, so the move to enforcement can be sequenced in the remediation roadmap.
Does the review need access to our tenant?
The access depends on the agreed scope and method. The roles involved, who grants them, and how long access lasts are agreed before the engagement starts.
Access follows least privilege and is time-bound, with read-oriented roles preferred wherever the method allows.
The review does not change mail settings without your agreement. Whether the engagement includes any remediation, and who carries it out, is agreed during scoping.
How is this different from configuration analyzer or Microsoft Secure Score?
They are complementary. Microsoft describes configuration analyzer as a central location to find and fix threat policies whose settings are less secure than the Standard and Strict profiles, and notes that Microsoft Secure Score isn’t an absolute measurement of how likely your system or data could be breached.
The review can draw on configuration analyzer results where the agreed access allows, then adds business context: which users and domains each policy covers, how policies interact with mail flow rules and allow lists, and the order in which to make changes. Secure Score remains a useful way to track progress.
How much does an Exchange Online email security review cost?
Pricing follows scoping. It depends on the size and complexity of your tenant, the control areas included, and the deliverables you need. Scope, timing, and pricing are confirmed in writing before the engagement starts.
Get a clear view of your tenant’s configuration.
Tell us about your environment and the questions you need answered. We’ll help define an appropriate assessment scope.
Discuss your audit