Detections
Analytics

2.1.8 Ensure that SPF records are published for all Exchange Domains

Information

For each domain that is configured in Exchange, a corresponding Sender Policy Framework (SPF) record should be created.

SPF records enable Exchange Online Protection and other mail systems to verify which servers are authorized to send email for a domain. This helps those systems determine whether a message is legitimate or potentially spoofed. Enforcing a -all or ~all ensures that any undocumented or unauthorized networks attempting to send on behalf of the organization are immediately rejected, reducing the risk of impersonation.

If an organization does not have full visibility into where its email originates, this represents a significant security gap. For example, if an email server is sending mail from an unexpected location across the country without your knowledge, that is a serious issue. Addressing this requires a deliberate discovery process to identify all legitimate sending sources, rather than allowing unknown systems to continue sending email unchecked.

NOTE: Nessus has not performed this check. Please review the benchmark to ensure target compliance.

Solution

To remediate using a DNS provider:

For each domain identified as non-compliant during the audit, make the necessary updates in your DNS provider or through your third-party SPF management service.

Missing SPF Record:
If a domain does not currently have an SPF record, create one similar to the example below, assuming all email is routed through Exchange Online (Microsoft 365 or Microsoft 365 GCC):

# Hard fail
v=spf1 include:spf.protection.outlook.com -all
# Soft fail
v=spf1 include:spf.protection.outlook.com ~all

Additional Senders:
If other authorized email services are used, add their SPF entries using the include: mechanism as needed. For example:

v=spf1 include:spf.protection.outlook.com include:exampledomain.net -all

Impact:

Setting up SPF records typically has minimal operational impact. However, organizations must ensure proper configuration, as misconfigured SPF records can cause legitimate email to be flagged as spam or fail authentication checks. Additionally, identifying all legitimate senders outside of the default Microsoft 365 IP ranges may require extra time and coordination during the discovery phase.

See Also

https://workbench.cisecurity.org/benchmarks/24620

Item Details

Category: SYSTEM AND COMMUNICATIONS PROTECTION

References: 800-53|SC-7, CSCv7|7.8

Plugin: microsoft_azure

Control ID: 1f7956f46bbe8cfdc06fdcaf1f289b10f100a3ce91931b723a8aa5b186290cd3