The Email Authentication Trio
Email was designed in the 1980s without any built-in authentication. The protocol simply trusted that the sender was who they claimed to be. Decades later, three complementary standards have emerged to fill that gap: SPF, DKIM, and DMARC. Each solves a different part of the problem, and together they form a robust defence against email spoofing and phishing.
Think of it this way: SPF checks where the email came from, DKIM checks what arrived (and whether it was altered), and DMARC defines what to do when those checks fail.
SPF Explained
How SPF Works
SPF (Sender Policy Framework) is a DNS-based record that lists which mail servers are authorised to send email on behalf of your domain. When a receiving server gets an email, it checks the sending server's IP address against your SPF record. If the IP is listed, the check passes. If not, the email fails SPF.
An SPF record is a TXT record on your domain that looks something like this:
v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.5 -all
SPF Syntax
SPF records use several mechanisms to define authorised senders:
- include: — references another domain's SPF record (used for third-party services like Google Workspace, Microsoft 365, Mailchimp, etc.)
- ip4: / ip6: — authorises specific IP addresses or ranges
- a — authorises the IP addresses in your domain's A record
- mx — authorises your domain's mail servers
- -all — hard fail: reject anything not explicitly authorised
- ~all — soft fail: accept but mark as suspicious
The 10-Lookup Limit
One of the most common SPF issues is exceeding the 10 DNS lookup limit. Every include:, a, mx, and redirect mechanism counts as a lookup. Nested includes count too — if your SPF includes Google's SPF, and Google's SPF includes three more domains, that's four lookups from a single include. Exceeding 10 lookups causes your entire SPF record to fail with a "permerror", which means receivers can't validate any of your email.
If you're approaching the limit, consider replacing include: mechanisms with direct ip4: entries for services with static IPs, or use an SPF flattening service.
DKIM Explained
How Signing Works
DKIM (DomainKeys Identified Mail) adds a cryptographic signature to every outgoing email. The sending server uses a private key to generate a signature based on the email's headers and body. The receiving server retrieves the corresponding public key from your DNS records and uses it to verify the signature.
If the signature checks out, the receiver knows two things: the email genuinely came from (or was authorised by) the domain that signed it, and the message hasn't been modified in transit.
Key Pairs and Selectors
DKIM uses public/private key pairs. The private key stays on your mail server and is never shared. The public key is published as a DNS TXT record under a specific selector — a label that lets you have multiple DKIM keys for different services.
For example, Google Workspace typically uses the selector google, while Microsoft 365 uses selector1 and selector2. The DNS record for a Google DKIM key would be at google._domainkey.yourdomain.com.
Selectors allow you to rotate keys without downtime and let multiple services sign emails independently — your CRM, newsletter platform, and primary mail server can each have their own DKIM key.
DMARC Explained
Alignment
DMARC introduces the concept of alignment — the requirement that the domain authenticated by SPF or DKIM must match the domain in the email's visible "From" header. This is crucial because without alignment, an attacker could pass SPF using their own domain while spoofing your domain in the "From" field.
DMARC supports two alignment modes:
- Relaxed (default) — the authenticated domain and From domain must share the same organisational domain (e.g., mail.example.com aligns with example.com)
- Strict — the domains must match exactly
Policies and Reporting
Your DMARC record defines what happens when an email fails both SPF and DKIM alignment. The three policy levels — p=none, p=quarantine, and p=reject — give you increasing levels of protection. DMARC also enables aggregate reporting (rua) so you can monitor authentication results across all email sent using your domain.
How They Work Together
Here's the complete flow when a receiving server processes an incoming email:
- SPF check: Is the sending server's IP authorised in the domain's SPF record?
- DKIM check: Does the email have a valid DKIM signature, and does the public key in DNS verify it?
- DMARC alignment: Does at least one of the authenticated domains (from SPF or DKIM) align with the visible "From" domain?
- Policy enforcement: If alignment fails for both SPF and DKIM, the DMARC policy determines the outcome — deliver, quarantine, or reject.
An email only needs to pass either SPF or DKIM with alignment to pass DMARC. This redundancy is important because SPF can break when emails are forwarded (the forwarding server's IP isn't in your SPF record), while DKIM signatures typically survive forwarding. Having both ensures robust authentication across different email routing scenarios.
Common Mistakes
Even organisations that implement all three protocols often make configuration errors:
- Forgetting third-party senders — if you use a CRM, newsletter tool, helpdesk, or invoicing system that sends email on your behalf, each one needs to be included in your SPF record and configured for DKIM signing
- Exceeding the SPF lookup limit — adding too many include mechanisms causes the entire record to fail
- Jumping straight to p=reject — enforcing DMARC without first monitoring with p=none can block legitimate email from services you forgot about
- Not monitoring DMARC reports — without reviewing aggregate reports, you won't know about authentication failures until someone complains about missing emails
- Using ~all instead of -all in SPF — soft fail provides weaker protection than hard fail and should only be used during initial setup
Testing with DMARC Dashboard
The easiest way to check whether your SPF, DKIM, and DMARC are correctly configured is to use a free checker. DMARC Dashboard analyses all three records for any domain in seconds and provides a clear grade with specific recommendations for improvement.
Run a check on your domain now to see where you stand, identify any gaps in your email authentication, and get actionable guidance on what to fix first.