Are SPF, DKIM and DMARC configured for your sending domains, with DMARC at p=reject?
Demonstrate that SPF, DKIM, and DMARC records are properly configured for all organizational sending domains, with DMARC enforcement set to reject unauthenticated messages.
Description
What this control does
This control requires the configuration of three email authentication protocols for all domains used to send email: SPF (Sender Policy Framework) to define authorized sending servers, DKIM (DomainKeys Identified Mail) to cryptographically sign outbound messages, and DMARC (Domain-based Message Authentication, Reporting and Conformance) to instruct receiving servers how to handle authentication failures. The DMARC policy must be set to 'p=reject' to ensure that emails failing SPF or DKIM checks are blocked entirely, rather than quarantined or allowed through. These mechanisms collectively prevent attackers from spoofing the organization's domains in phishing campaigns, business email compromise attacks, and brand impersonation schemes.
Control objective
What auditing this proves
Demonstrate that SPF, DKIM, and DMARC records are properly configured for all organizational sending domains, with DMARC enforcement set to reject unauthenticated messages.
Associated risks
Risks this control addresses
- Attackers spoof organizational email domains to conduct phishing attacks against customers, partners, or internal staff, undermining trust and enabling credential theft
- Business email compromise (BEC) attacks leverage spoofed executive or finance team addresses to authorize fraudulent wire transfers or data disclosures
- Brand reputation damage occurs when third parties receive fraudulent emails appearing to originate from the organization's domains
- Email delivery failures increase when legitimate messages are misclassified as spam due to missing authentication, impacting business communications
- Compliance violations arise when regulatory frameworks require demonstrable email security controls and domain authentication is absent
- Ransomware or malware distribution campaigns use spoofed organizational domains to bypass recipient email filters that whitelist trusted sender domains
- Lack of DMARC reporting prevents security teams from detecting ongoing domain spoofing attempts and understanding the scope of abuse
Testing procedure
How an auditor verifies this control
- Obtain a complete inventory of all domains owned by the organization that are used or could be used to send email, including primary domains, subdomains, and marketing or transactional email domains
- Query DNS records for each domain using command-line tools (dig, nslookup) or online DNS lookup services to retrieve SPF records (TXT record starting with 'v=spf1')
- Verify that each SPF record includes all legitimate sending sources (mail servers, third-party services) and terminates with either '-all' (hard fail) or '~all' (soft fail)
- Query DNS for DKIM selector records by identifying active DKIM selectors from outbound email headers or configuration documentation, then verifying the presence of corresponding public key TXT records
- Query DNS for DMARC policy records (TXT record at _dmarc.domain.com) and confirm the policy includes 'v=DMARC1' and 'p=reject' parameters
- Review DMARC record parameters to verify that 'rua' and 'ruf' tags are configured with valid email addresses for aggregate and forensic reporting
- Send test emails from each domain to a DMARC testing service or internal test mailbox, then inspect message headers to confirm SPF pass, DKIM pass, and DMARC alignment
- Review DMARC aggregate reports (if available) for a recent period to validate that the reject policy is actively enforced and to identify any legitimate sources failing authentication