Email authentication—SPF, DKIM and DMARC—is a core technical control required by Compliance Framework Control 2-4-3 (ECC – 2 : 2024) to prevent spoofing and business email compromise; this post provides actionable implementation steps, configuration examples, and small-business scenarios to help you meet the control with measurable outcomes.
Why SPF, DKIM and DMARC matter for Control 2-4-3
Control 2-4-3 requires organisations to implement email authentication to ensure senders are legitimate and messages cannot be trivially spoofed; SPF identifies authorized sending IP addresses, DKIM cryptographically signs messages so recipients can verify integrity and origin, and DMARC ties the two together to instruct receivers how to treat unauthenticated mail and to provide reporting for compliance monitoring.
Implementation overview (Compliance Framework-specific)
To satisfy the Compliance Framework practice, treat email authentication as a single program: (1) inventory all sending sources, (2) publish an accurate SPF record, (3) enable DKIM signing for every mail path, (4) publish a DMARC policy and collect reports, and (5) iterate to enforcement. Document each step (owner, timestamps, DNS changes) because auditors will want evidence mapping these activities to Control 2-4-3.
Step 1 — Inventory and mapping (practical)
Start by creating a sending-source inventory: in-house mail servers, cloud mail platforms (Office 365, Google Workspace), marketing platforms (Mailchimp, SendGrid), CRM transactional senders (Stripe, Zendesk), and embedded services (webhooks). For a small business example: Acme Co. may have Office 365 for corporate mail, Mailchimp for newsletters and Shopify for transactional receipts—each must be listed with sending IPs/domains and contact owners. This inventory drives SPF includes, DKIM key placement, and DMARC reporting addresses; keep it in your compliance evidence package.
Step 2 — Publish a correct SPF record (technical details)
SPF syntax example for a small business that uses Office 365, a marketing vendor, and one static mail server:
"v=spf1 ip4:198.51.100.5 include:spf.protection.outlook.com include:servers.mcsv.net -all". Practical notes: keep your SPF record to a single TXT record at the domain root, avoid exceeding the 10 DNS-lookup limit (each "include", "mx", "a", "ptr", "exists" can cause lookups), and use "-all" (fail) only after testing—start with "~all" (softfail) during validation. Use SPF flattening services or vendor guidance if you exceed DNS lookup limits, and remember TXT chunks over 255 characters need to be quoted segments in DNS providers.
Step 3 — Configure DKIM signing (technical details and examples)
Generate a 2048-bit RSA key pair (recommended minimum) and publish the public key in DNS as a TXT record under the selector, e.g. selector "mail2026":
_dns record: mail2026._domainkey.example.com TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqh...".
On the mail server side, enable signing: for Postfix + OpenDKIM, generate keys with "opendkim-genkey -s mail2026 -d example.com", configure the milter, and restart services. For cloud providers (Office 365, Google Workspace, SendGrid), follow their DKIM setup pages—usually they provide the selector and TXT value. Use selectors to support key rotation (publish new selector, update signing policy, then revoke old keys). Test with tools like "dkimvalidator.com" or command-line utilities to ensure headers are properly signed and canonicalization (relaxed/simple) works for your mail pipeline, especially if messages pass through MTAs that modify headers.
Step 4 — Publish DMARC and operationalize reporting
Start with monitoring: create a DMARC record to collect aggregate reports (RUA) and optionally forensic reports (RUF), for example:
_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:dmarc-aggregate@example.com; ruf=mailto:dmarc-forensic@example.com; pct=100; adkim=s; aspf=s".
Practical advice: point rua to a dedicated mailbox (and use a parser or a service—examples: open-source dmarcts-report-parser, paid services like dmarcian or Valimail) because XML aggregate reports can be large and frequent. Use "p=none" while you validate, then move to "quarantine" and eventually "reject" after 30–90 days of stable successful authentication. Consider "sp=" for subdomain policy if you use third-party marketing domains. Monitor reports weekly, remediate failing sources (update SPF includes, fix DKIM signing), and record changes in your Compliance Framework evidence log for Control 2-4-3.
Risks of not implementing and compliance tips
Without SPF/DKIM/DMARC you expose the organisation to phishing, business email compromise (BEC), brand abuse, reduced deliverability, and potential blacklisting—risks that directly undermine Control 2-4-3. Compliance tips: maintain the sending inventory as a living document, require vendors to support DKIM or include them in your SPF, rotate DKIM keys annually or after any suspected compromise, keep DMARC reports for at least 6 months for audit trails, and automate report parsing so you can identify rogue senders quickly.
In summary, implementing SPF, DKIM and DMARC is a measurable, auditable control that satisfies Compliance Framework Control 2-4-3 by preventing email spoofing and enabling operational monitoring; follow the inventory → SPF → DKIM → DMARC progression, test gradually, use monitoring tools to validate behavior, and document every change so you can demonstrate compliance during assessments.
