Overview.
Email remains one of the most vital business communication tools, but it is also the most frequently exploited attack vector.
Threats such as phishing, spoofing, impersonation, and Business Email Compromise (BEC) continue to succeed largely because recipients trust what they see in the “From” address. Without authentication controls, any attacker can send an email that appears to come from your organisation’s domain.
To mitigate this risk, three email authentication protocols form the modern foundation of email security: SPF, DKIM, and DMARC. Each protocol validates a different aspect of trust, sender authority, message integrity, and domain alignment, and when used together, they create a layered, standards-based defence against domain abuse.
SPF – Authorising Sending Servers.
Sender Policy Framework (SPF) allows a domain owner to specify which mail servers are authorised to send messages on their behalf. It does this via a DNS TXT record, which lists the permitted IP addresses or hostnames.
For example:
v=spf1 include:spf.protection.outlook.com -all
This record instructs receiving mail servers to accept messages only from Microsoft 365’s authorised infrastructure. Messages sent from any other source will fail SPF validation.
On the other hand, a soft-fail version uses a tilde ~ rather than a hyphen -:
v=spf1 include:spf.protection.outlook.com ~all
In this case, messages from unauthorised servers will soft-fail, meaning the recipient’s mail server should accept but flag them as suspicious instead of rejecting them outright. Soft-fail mode is often used temporarily during testing or migration, allowing legitimate senders to be identified before enforcing a strict reject policy.
SPF Implementation.
SPF is simple to deploy: you add a single TXT record to your public DNS zone. Most email service providers, such as Microsoft 365 and Google Workspace, provide pre-defined SPF values. You should include all legitimate third-party mail senders (for example, marketing tools or CRM systems) to prevent delivery issues.
However, SPF validates the envelope sender (Return-Path), not the visible “From” header that end users see. This means attackers can still forge the visible sender name. SPF can also fail for forwarded emails unless the forwarder supports Sender Rewriting Scheme (SRS).
What SPF Prevents.
SPF protects against:
It does not protect against:
DKIM – Protecting Message Integrity.
DomainKeys Identified Mail (DKIM) uses public-key cryptography to verify that an email was not modified in transit and that it originated from an authorised domain.
When DKIM is enabled, the sending mail server applies a digital signature to the message header and body using a private key. The receiving server retrieves the corresponding public key from a DNS TXT record to verify the signature’s authenticity.
A simplified DKIM record looks like this:
selector._domainkey.example.com
The selector is a label that points to a specific key pair. It allows multiple keys to exist for one domain, which is useful for key rotation or when several systems send mail on behalf of the same organisation.
Not every DNS zone will visibly show a selector-based subdomain, depending on how the platform implements DKIM.
In some configurations:
The mail provider abstracts the selector behind a fixed or default subdomain, such as _domainkey.example.com, instead of selector._domainkey.example.com.
The selector may be implied or embedded within the signing mechanism, not visible in the admin interface.
Certain older or simplified DKIM setups (especially legacy on-prem appliances or custom scripts) use a single static key published at _domainkey.example.com, effectively acting as a “default” selector.
So, while it might look like there’s no selector, one is always present conceptually, it may simply not be customisable or visible.
DKIM Implementation.
Setup varies by platform. In Microsoft 365 or Google Workspace, you generate the DNS records in the admin centre, publish them, and enable DKIM signing. From then on, every outbound message includes a DKIM-Signature header that recipients can validate.
What DKIM Prevents.
DKIM protects against:
Message tampering or alteration during transit.
Header forgery, ensuring that selected headers (such as “From” and “Subject”) have not been changed.
It does not prevent:
DMARC – Alignment, Enforcement, and Visibility.
Domain-based Message Authentication, Reporting and Conformance (DMARC) is the protocol that links SPF and DKIM together. It enforces that either SPF or DKIM (or both) pass and align with the domain in the visible “From” address. This ensures that messages truly originate from your domain.
A DMARC policy is published as another DNS TXT record, for example:
_dmarc.example.com IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; adkim=s; aspf=s; fo=1"
The p= tag sets the policy (none, quarantine, or reject), while the rua= tag defines where to send aggregate reports.
_dmarc.example.com — Subdomain used to host the DMARC record.
v=DMARC1 — Version tag (always required).
p=reject — Policy (none, quarantine, or reject) determining what to do with failing messages.
rua=mailto:dmarc-reports@example.com — Address for aggregate XML reports.
adkim=s / aspf=s — Alignment mode (strict or relaxed).
fo=1 — Requests failure reports when SPF or DKIM fails.
DMARC Implementation.
DMARC requires both SPF and DKIM to be configured correctly first. Organisations typically begin with p=none to monitor mail flows without blocking messages. Once legitimate senders are confirmed as aligned, the policy can be moved to quarantine and eventually reject for full enforcement.
DMARC’s reporting capability offers powerful insight into how your domain is being used and abused across the internet. Reports can be analysed manually or using specialist tools such as dmarcian, Postmark, or Microsoft Defender for Office 365 reporting.
What DMARC Prevents.
DMARC protects against:
Direct domain spoofing, where attackers forge your exact domain in the “From” field.
Unauthorised senders that fail SPF and DKIM alignment.
Unmonitored abuse of your domain identity (through reporting visibility).
It does not prevent:
Lookalike domain attacks, such as “yourd0main.co.uk”.
Compromised legitimate accounts within your domain.
Why All Three Matter — Together.
SPF checks that the sending IP is allowed. DKIM ensures the message hasn’t been tampered with.
DMARC enforces that either SPF or DKIM aligns with the domain in the visible From address, and allows the domain owner to instruct how to handle failures.
Each protocol addresses a specific gap. Using just one leaves room for abuse:
SPF alone doesn’t protect against message tampering.
DKIM without DMARC leaves enforcement weak.
DMARC without properly configured SPF and DKIM won’t function effectively. Without DMARC, attackers can still spoof the visible “From” domain, even if they fail SPF and DKIM, because recipient mail servers don’t know how to handle the failure.
When used together, these protocols form a layered defence that blocks most domain-spoofed email, improves deliverability of legitimate messages, and provides much-needed visibility into how your domain is used.
Getting Started.
SPF: Add a TXT record with authorised sending IPs or include mechanisms (e.g. include:spf.protection.outlook.com for Microsoft 365).
DKIM: Enable signing through your email provider, generate DNS key(s), and publish the two DKIM TXT record(s).
DMARC: Start with a p=none policy and monitoring address (rua), then gradually move to quarantine or reject.
Make sure to test each configuration using tools like MXToolbox, Google Admin Toolbox, or Microsoft's Remote Connectivity Analyzer.
Final Thoughts.
SPF, DKIM, and DMARC are not difficult to implement, but they do require attention to detail and ongoing monitoring. Each one contributes a vital layer to email authentication, but the real strength comes from their combined use.
In today’s threat landscape, failing to implement these standards exposes your domain to impersonation and users to risk. Done properly, these DNS-based defences help secure your brand, protect your users, and stop attackers before the message even hits the inbox.
Resources:
https://checkcybersecurity.service.ncsc.gov.uk/email-security-check/form
https://mxtoolbox.com/dmarc.aspx
https://emailspooftest.com/
https://emailstuff.org/
https://multirbl.valli.org/
