Email authentication—SPF, DKIM, and DMARC—is a foundational control for preventing spoofing and phishing, and implementing these controls is required to demonstrate compliance with Essential Cybersecurity Controls (ECC – 2 : 2024) Control 2-4-3; this post gives practical, small‑business focused steps, DNS examples, testing commands, and evidence you can include in your compliance package.
Why implement SPF/DKIM/DMARC for ECC 2-4-3
The risk you mitigate by implementing these three controls includes domain spoofing, credential harvesting, and business email compromise—risks that directly undermine the integrity requirement of the Compliance Framework. Non‑implementation leads to increased phishing success against your customers and partners, reputational damage, and possible regulatory or contractual non‑conformance findings during audits. For ECC 2-4-3, auditors expect documented DNS records, evidence of correct signing, and operational monitoring (aggregate reports) showing policy adoption and enforcement.
How this maps to Compliance Framework evidence
For the Compliance Framework, collect: (1) DNS TXT record screenshots or dig outputs for SPF, DKIM selector entries, and DMARC; (2) MTA / email service configuration exports showing DKIM private key use and signing rules; (3) DMARC aggregate reports stored for the evidence retention period; and (4) change control records showing when and why you changed DNS policies. Include a brief risk assessment and remediation plan for messages flagged by DMARC.
SPF: practical steps and DNS examples
SPF authorizes sending IPs and services for your envelope-from domain. Steps: 1) Inventory all sending sources (mail servers, cloud providers, marketing platforms, CRM, backups). 2) Build a single SPF TXT record for the domain’s root (example: example.com) using include statements and explicit ip4/ip6 entries. Example: example.com. IN TXT "v=spf1 ip4:203.0.113.10 include:spf.protection.outlook.com include:_spf.sendgrid.net -all". Use -all for strict enforcement in production. Key limits: avoid PTR, keep mechanisms that cause DNS lookups under 10 (include, a, mx, ptr, exists count); use SPF flattening services only after validating TTLs and test results.
SPF best practices for small businesses
Small businesses often use a cloud email provider (e.g., Microsoft 365 or Google Workspace) plus a marketing tool. Add the provider’s recommended include and your mail server IPs. Set TTL to 3600 seconds while testing, then raise if stable. Test with: dig TXT example.com or online checkers (MXToolbox). Document the inventory of sending services and include it in your ECC 2-4-3 evidence pack so an auditor can see why each include exists.
DKIM: signing mail and managing keys
DKIM provides cryptographic signatures in the message header; DKIM alignment is used by DMARC to validate header-from. Implementation steps: 1) Choose selectors (use meaningful names like mail or provider tokens). 2) Generate a minimum 2048‑bit RSA key pair (use your MTA or provider tools). 3) Publish the public key as a DNS TXT at selector._domainkey.example.com. Example DNS TXT (wrapped for readability): mail._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQE...IDAQAB". 4) Configure your MTA (Postfix + OpenDKIM, Exchange, or provider) to sign outgoing mail with that selector and private key. 5) Test with opendkim-testkey -d example.com -s mail -k /path/to/private.key and by sending to Gmail (Gmail shows DKIM=pass in headers) or using validator services.
Key management and rotation
Store private keys with least privilege access, use filesystem permissions (root-only) or HSM/Key Vault when available, and rotate keys on a regular cadence (e.g., every 90 days or per your crypto policy). Keep retired selectors published for a period of overlap so older messages still validate, but document rotation in change logs for ECC 2-4-3. Ensure your signing policy includes canonicalization (relaxed/simple) settings and list which headers you sign — always include From and Date at minimum.
DMARC: policy, reporting, and staged rollout
DMARC ties SPF and DKIM to header-from alignment and enables reporting. Start with a monitoring policy (p=none) while you collect data, then move to p=quarantine and finally p=reject once you have confidence. Example DMARC TXT: _dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc-rua@example.com; ruf=mailto:dmarc-ruf@example.com; adkim=s; aspf=s; fo=1". Use adkim=s and aspf=s for strict alignment if your environment supports it. Configure an aggregate (rua) mailbox and, if desired, a forensic (ruf) mailbox—note many providers do not send ruf due to privacy and volume concerns.
Operational considerations and tools
Collect DMARC aggregate reports (XML) and parse them with a DMARC analyzer (open-source or SaaS). Look for sources that fail SPF/DKIM and update your SPF record or configure DKIM at the sending service. Use tools: dig, MXToolbox, dmarcian, Google Postmaster Tools, and your email provider’s message trace. For ECC evidence, include a month of DMARC aggregate reports showing trends, a remediation log for sources failing, and the staged policy timeline to demonstrate a controlled enforcement approach.
Summary and compliance tips
Implement SPF to authorize senders, DKIM to sign mail, and DMARC to enforce policy and receive reporting—start in monitoring mode, inventory your senders, test thoroughly, and move to a reject policy once you have coverage. For ECC 2-4-3 compliance: keep DNS screenshots/dig outputs, MTA configuration exports, DMARC reports, and change control records as artifacts. Failure to implement these controls increases phishing risk and will weaken your compliance posture; conversely, a documented rollout with evidence and monitoring is a strong auditor artifact that demonstrates control effectiveness.
