SPF record published and aligned
Demonstrate that the organization has published valid SPF records for all active email-sending domains and that these records are properly aligned with actual sending infrastructure to prevent domain spoofing.
Description
What this control does
Sender Policy Framework (SPF) is a DNS-based email authentication mechanism that allows domain owners to publish authorized mail servers in a TXT record. When properly aligned with the organizational domain, SPF records enable receiving mail servers to verify that inbound messages claiming to originate from the domain were sent from authorized infrastructure. This control prevents email spoofing by allowing recipients to reject or flag messages that fail SPF validation, protecting both the organization's brand reputation and external parties from phishing attacks impersonating the domain.
Control objective
What auditing this proves
Demonstrate that the organization has published valid SPF records for all active email-sending domains and that these records are properly aligned with actual sending infrastructure to prevent domain spoofing.
Associated risks
Risks this control addresses
- Attackers spoof the organization's domain to send phishing emails to customers, partners, or employees, damaging brand reputation and enabling fraud
- Legitimate organizational emails are rejected or marked as spam by recipient servers due to missing or misconfigured SPF records, disrupting business communications
- Unauthorized third-party services or compromised systems send email from the organization's domain without detection or blocking
- SPF records contain overly permissive mechanisms (e.g., +all) that fail to restrict sending sources, rendering the control ineffective
- Multiple subdomain or regional domains lack SPF records, creating exploitable gaps in email authentication coverage
- SPF records exceed the 10-lookup DNS query limit, causing validation failures and unpredictable email delivery
- Outdated SPF records reference decommissioned mail servers or exclude newly deployed infrastructure, causing false positives or false negatives
Testing procedure
How an auditor verifies this control
- Inventory all organizational domains and subdomains used to send email, including marketing, transactional, regional, and application-generated messages by reviewing DNS zones, email gateway configurations, and application service accounts.
- Query DNS TXT records for each identified domain using nslookup, dig, or online SPF validation tools to retrieve published SPF records.
- Verify that each SPF record begins with 'v=spf1' and ends with an appropriate enforcement mechanism (-all, ~all, or ?all, noting organizational policy).
- Parse each SPF record to identify all authorized sending sources (ip4, ip6, include, a, mx mechanisms) and compare against documented email infrastructure including on-premises mail servers, cloud email services, marketing platforms, and third-party senders.
- Count the total number of DNS lookups required for each SPF record by recursively resolving all include and redirect mechanisms, ensuring the count does not exceed the RFC 7208 limit of 10 lookups.
- Test email authentication by sending sample messages from authorized sources and verifying SPF pass results in email headers (Received-SPF or Authentication-Results headers).
- Attempt to send a test email from an unauthorized source (with appropriate coordination) and verify that SPF evaluation results in a fail or softfail outcome.
- Review change management records for the most recent SPF record updates to confirm alignment with infrastructure changes such as new mail servers, service provider migrations, or decommissioned systems.
Where this control is tested