Email Security: SPF, DKIM and DMARC Explained
Email remains the number-one attack vector for phishing, business email compromise and malware delivery. SPF, DKIM and DMARC are three complementary DNS-based standards that authenticate outgoing email and instruct receiving servers how to handle messages that fail verification. Implementing all three dramatically reduces the risk of your domain being spoofed and improves deliverability for legitimate mail.
Why Email Is the Number-One Attack Vector
The Simple Mail Transfer Protocol (SMTP) was designed in 1982 with no built-in authentication. By default, anyone can send an email claiming to be from any address — there is nothing in the protocol itself that prevents it. Attackers exploit this to send phishing emails that appear to come from trusted domains: your bank, your CEO, or your IT department. According to industry reports, over 90% of successful cyber attacks begin with a phishing email.
SPF, DKIM and DMARC were developed to retrofit authentication onto SMTP. They do not encrypt email content (that is the job of TLS and S/MIME), but they verify that the sender is who they claim to be — which is the critical first step in stopping spoofing and phishing at the domain level.
SPF: Sender Policy Framework
SPF answers one simple question: is this mail server authorised to send email on behalf of this domain? The domain owner publishes a DNS TXT record that lists every IP address or hostname permitted to send mail for that domain. When a receiving mail server gets a message, it checks the envelope sender (the Return-Path / MAIL FROM address) against the SPF record. If the sending server's IP is listed, the SPF check passes.
A typical SPF record looks like this:
v=spf1 ip4:203.0.113.0/24 include:_spf.google.com include:spf.protection.outlook.com -allThis record says: "Allow mail from the 203.0.113.0/24 range, from Google Workspace servers, and from Microsoft 365 servers. Reject everything else (-all)." The include mechanism lets you delegate to third-party services without listing their IP ranges manually.
Common SPF mistake: using ~all (soft fail) instead of -all (hard fail). A soft fail tells receiving servers that unauthorised senders should be treated with suspicion but not necessarily rejected. While soft fail is useful during initial rollout, leaving it in place permanently weakens your protection. Move to -all once you have confirmed all legitimate senders are included.
DKIM: DomainKeys Identified Mail
DKIM adds a cryptographic signature to every outgoing email. The sending mail server signs the message headers (and optionally the body) using a private key. The corresponding public key is published in a DNS TXT record. The receiving server retrieves the public key, verifies the signature, and confirms that the message has not been altered in transit.
A DKIM DNS record is published under a selector subdomain, for example:
selector1._domainkey.example.com.au TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."The selector allows you to have multiple DKIM keys simultaneously — one for your mail server, another for your marketing platform, and so on. This is important because each sending service needs its own key pair. Key rotation is also simplified: you publish a new key under a new selector before retiring the old one.
Where SPF validates the sending server, DKIM validates the message itself. This is a critical distinction: if an email is forwarded through an intermediate server (such as a mailing list), the SPF check will fail (because the forwarding server's IP is not in the original domain's SPF record), but the DKIM signature remains valid because the message content has not changed.
DMARC: Tying It All Together
DMARC (Domain-based Message Authentication, Reporting and Conformance) is the policy layer that tells receiving servers what to do when SPF and DKIM checks fail. Without DMARC, a receiving server might silently accept, quarantine or reject a failing message — the behaviour is inconsistent. DMARC removes the guesswork by publishing an explicit policy.
A DMARC record is a DNS TXT record published at _dmarc.example.com.au:
v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com.au; ruf=mailto:dmarc-forensics@example.com.au; pct=100Key tags include:
- p= the policy:
none(monitor only),quarantine(send to spam), orreject(block entirely). - rua= the address to receive aggregate reports (XML summaries of pass/fail statistics).
- ruf= the address to receive forensic reports (details of individual failures).
- pct= the percentage of failing messages to which the policy applies (useful for gradual rollout).
Crucially, DMARC also requires alignment. For a message to pass DMARC, at least one of SPF or DKIM must pass and the domain in the result must align with the domain in the visible "From" header. This prevents attackers from passing SPF with their own domain while spoofing your domain in the "From" field that the recipient actually sees.
How SPF, DKIM and DMARC Work Together
Think of the three standards as layers of defence:
- SPF checks that the email came from an authorised server.
- DKIM checks that the email has not been tampered with and was signed by the claimed domain.
- DMARC enforces a policy when either check fails and requires that the authenticated domain matches the visible sender address.
All three are essential. SPF alone can be bypassed by forwarding. DKIM alone does not tell the receiver what to do when verification fails. DMARC without SPF and DKIM has nothing to enforce. Together, they form a robust anti-spoofing framework.
Misconfiguration warning: jumping straight to p=reject without thorough testing can cause legitimate email to be blocked. Always start with p=none to collect aggregate reports, analyse which senders are passing and failing, ensure all legitimate services are covered by SPF and DKIM, then gradually move to p=quarantine and finally p=reject. This process typically takes 4–8 weeks.
Common Mistakes to Avoid
Even experienced administrators make these errors when configuring email authentication:
- Exceeding the SPF 10-lookup limit: SPF records are limited to 10 DNS lookups (including nested includes). Exceeding this limit causes SPF to return a permanent error, effectively disabling it. Use SPF flattening tools or dedicated services to manage complex records.
- Forgetting third-party senders: marketing platforms (Mailchimp, HubSpot), ticketing systems (Zendesk, Freshdesk), and transactional email services (SendGrid, Amazon SES) all send email on your behalf. Each must be included in your SPF record and configured with DKIM signing for your domain.
- Not monitoring DMARC reports: publishing a DMARC record without reviewing the aggregate reports means you are flying blind. Use a DMARC analysis service (such as DMARCian, Valimail, or the free Google Postmaster Tools) to visualise your authentication results.
- Using weak DKIM keys: RSA keys shorter than 2048 bits are considered weak. Always use 2048-bit keys and rotate them annually.
BIMI: The Next Step
Brand Indicators for Message Identification (BIMI) is an emerging standard that displays your organisation's verified logo next to emails in the recipient's inbox. BIMI requires a DMARC policy of p=quarantine or p=reject as a prerequisite, so it serves as an incentive to achieve full DMARC enforcement. A BIMI DNS record points to an SVG logo and, optionally, a Verified Mark Certificate (VMC) issued by a certificate authority. Gmail, Apple Mail and Yahoo Mail already support BIMI, giving compliant organisations a visual trust indicator that helps recipients identify legitimate messages at a glance.
Testing Tools
Before and after deploying SPF, DKIM and DMARC, use these free tools to validate your configuration:
- MXToolbox (mxtoolbox.com) — checks SPF, DKIM, DMARC and MX records with detailed diagnostics.
- Mail Tester (mail-tester.com) — send a test email and receive a score covering authentication, content and deliverability.
- Google Admin Toolbox — specifically useful if you use Google Workspace.
- DMARC Analyser — processes your DMARC aggregate reports into readable dashboards.
Send a test email to a Gmail address and click "Show original" in the message menu. Gmail displays the SPF, DKIM and DMARC results right at the top of the raw headers — it is the quickest way to verify your setup.
Yes. SPF and DKIM each cover different aspects of authentication, and DMARC ties them together with a policy. Implementing only one or two leaves gaps that attackers can exploit. All major email providers (Google, Microsoft, Yahoo) now require DMARC for bulk senders and strongly recommend it for all domains.
No. These standards prevent attackers from spoofing your domain. They do not stop phishing from lookalike domains (e.g., examp1e.com instead of example.com) or from compromised legitimate accounts. They are one layer in a broader email security strategy that should also include spam filtering, link scanning, attachment sandboxing, and user awareness training.
For a typical organisation, the journey from no DMARC to full p=reject takes 4–12 weeks. The timeline depends on how many third-party services send email on your behalf and how quickly you can configure SPF and DKIM for each one. Start with p=none, review aggregate reports for at least two weeks, fix any issues, then move to p=quarantine before graduating to p=reject.
Yes. When an email is forwarded by an intermediate server, the forwarding server's IP is not in the original domain's SPF record, so SPF fails. This is one reason DKIM is essential: the DKIM signature survives forwarding because the message content is unchanged. DMARC only requires one of SPF or DKIM to pass with alignment, so DKIM covers the forwarding scenario.
SPF flattening is the process of resolving all include mechanisms and nested lookups into a flat list of IP addresses. This reduces the number of DNS lookups to stay within the 10-lookup limit. Services like AutoSPF, SPF Flattener, and some DNS providers offer automatic flattening that updates dynamically as provider IP ranges change.
