SPF, DKIM and DMARC are three email-authentication controls with different jobs. SPF checks whether the server sending an email is authorised. DKIM checks whether selected parts of the message carry a valid digital signature. DMARC checks whether a successful SPF or DKIM result aligns with the domain visible to the recipient — and tells receiving systems what to do when it does not.
The shortest useful explanation is:
- SPF checks the route.
- DKIM checks the message.
- DMARC checks whether the authenticated identity supports the name the recipient sees.
They work together. Having one does not make the other two unnecessary, and a technical "pass" does not prove that an email is harmless.
Use Wuluf's Domain Security Check to inspect the live SPF and DMARC records published for your domain. If you haven't already, our companion guide on how to check SPF and DMARC records and fix common problems walks through the checking process itself in detail.
Why email needs three different checks
Email was not originally designed to prove that a sender is who they claim to be. More importantly, an email can contain several different sender identities.
Two are particularly relevant:
- The envelope sender, sometimes called the return-path or
MAIL FROM, is used by mail systems while delivering the message. Most recipients never see it. - The visible From address is the name and address displayed in the recipient's inbox.
Those domains can be different. A criminal could authenticate a domain they control while placing another organisation's domain in the visible From address. To an employee glancing at an inbox, the message may appear to come from a trusted colleague or supplier.
SPF and DKIM perform authentication, but neither automatically proves that the authenticated domain matches the one the recipient sees. DMARC adds that relationship through alignment.
SPF, DKIM and DMARC compared
| Control | What it checks | Where it's configured | Main strength | Important limitation |
|---|---|---|---|---|
| SPF | Whether the sending server is authorised for the envelope-sender domain | DNS TXT record on the sending domain | Identifies permitted sending infrastructure | Can fail after forwarding and does not, by itself, protect the visible From domain |
| DKIM | Whether a digital signature is valid and signed content has remained intact | Signature in the email; public key in DNS | Survives ordinary forwarding better than SPF and helps verify message integrity | A valid signature may use a different domain from the visible From address |
| DMARC | Whether SPF or DKIM passes and aligns with the visible From domain | DNS TXT record at _dmarc |
Protects the visible brand domain and provides policy and reporting | Requires accurate configuration, monitoring and control of legitimate senders |
What does SPF protect?
SPF stands for Sender Policy Framework. A domain owner publishes an SPF record in DNS listing the systems authorised to send email using that domain as the envelope sender.
A receiving mail server can then ask: is the server delivering this message authorised by the domain used in the SMTP transaction?
A simplified SPF record might look like this:
v=spf1 include:example-email-provider.com -all
This authorises the infrastructure represented by the included provider and states that other sources are not authorised.
What SPF is good at
SPF is useful for controlling which mail systems may send using a domain. It can help expose unauthorised sending infrastructure and provides one of the authentication results DMARC can use.
It is particularly valuable when an organisation has an accurate inventory of:
- its corporate email service
- marketing and CRM platforms
- finance and invoicing systems
- service desks and recruitment tools
- website forms and application-generated mail
- any other third party sending on its behalf
What SPF does not protect
SPF checks the envelope-sender identity. It does not automatically compare that identity with the visible From address.
That means an attacker can configure valid SPF for a domain they own and still display a different brand's address to the recipient. SPF passes for the attacker's domain, but it has not authenticated the brand shown in the inbox.
SPF also has an operational weakness: forwarding can change the server delivering the message. The forwarding server may not be authorised by the original domain's SPF record, causing a legitimate message to fail.
SPF therefore matters, but SPF alone is not complete anti-spoofing protection.
What does DKIM protect?
DKIM stands for DomainKeys Identified Mail. It applies a cryptographic signature to selected parts of an outgoing email.
The sending service signs the message with a private key. The corresponding public key is published in DNS under a named selector. A receiving system retrieves that public key and uses it to verify the signature.
In simplified terms, the receiver asks: does this message contain a valid signature from the stated signing domain, and have the signed elements remained intact?
What DKIM is good at
DKIM provides evidence that selected signed content has not been altered after signing. It also associates the message with the domain identified in the signature's d= value.
Because the signature travels with the message, DKIM often survives ordinary email forwarding better than SPF. It can provide a valid authentication result when the route has changed and SPF no longer passes.
What DKIM does not protect
A valid DKIM signature proves that the message was signed using a key associated with the signing domain. It does not necessarily prove that this domain matches the visible From address.
An attacker could sign a message using their own domain while displaying another organisation's address to the recipient. The DKIM signature can be technically valid without authenticating the brand being impersonated.
DKIM signatures can also fail when a service materially modifies signed content in transit. Mailing lists, gateways and forwarding services may change headers or the message body. The effect depends on what was signed and how the message was modified.
DKIM is therefore a powerful authentication and integrity control, but it needs DMARC alignment to protect the visible sender domain.
SPF and DKIM generate evidence; DMARC connects that evidence to the identity the recipient sees.
What does DMARC protect?
DMARC stands for Domain-based Message Authentication, Reporting and Conformance. It uses SPF and DKIM results but adds two crucial capabilities:
- Alignment: the domain authenticated by SPF or DKIM must align with the domain in the visible From address.
- Policy and reporting: the domain owner can request how failed messages are treated and receive reports about authentication activity.
The receiving system asks: has SPF or DKIM passed for a domain aligned with the one shown to the recipient?
A message passes DMARC when at least one of these routes succeeds:
- SPF passes and its authenticated domain aligns with the visible From domain; or
- DKIM passes and its signing domain aligns with the visible From domain
Both do not have to pass. In a well-managed environment, however, configuring both provides resilience because one method may survive where the other fails.
What DMARC policy does
A DMARC record can publish one of three policies:
- p=none — monitor failures without requesting quarantine or rejection
- p=quarantine — ask receiving systems to treat failing messages as suspicious
- p=reject — ask receiving systems to reject messages that fail DMARC
DMARC can also specify where aggregate reports should be sent. These reports show which systems are sending email associated with the domain and how those messages perform against SPF, DKIM and DMARC.
This visibility often reveals a much larger email estate than expected: an old marketing supplier, an application nobody remembered, a website server or an unauthorised source attempting to impersonate the domain.
What DMARC does not protect
DMARC makes direct domain spoofing harder. It does not prove that a message is safe, truthful or wanted.
It cannot, by itself, stop:
- an attacker using a lookalike domain such as a subtle misspelling
- abuse of a legitimate but compromised mailbox
- malicious content sent through an authorised platform
- display-name impersonation that does not use the protected domain
- every delivery issue caused by reputation, content or recipient policy
This is why DMARC should form part of a wider email-security programme rather than being presented as a complete phishing solution.
Why SPF or DKIM can pass while DMARC fails
This is the point most likely to cause confusion.
Imagine a message that displays:
From: [email protected]
But the hidden envelope sender and DKIM signing domain belong to:
mail-example.net
If mail-example.net has configured its own SPF and DKIM correctly, those individual checks may pass. But neither result supports the visible trusted-company.co.uk identity.
DMARC should therefore fail because there is no alignment.
If mail-example.net is a legitimate supplier, it should normally be configured to authenticate using a domain aligned with the customer's visible From domain. If it is not a legitimate supplier, the failed alignment is doing exactly what it was designed to do.
Do you need all three?
For effective domain-based email authentication, organisations should deploy SPF, DKIM and DMARC together.
| If you only have… | The remaining gap |
|---|---|
| SPF | Forwarded mail may fail, and the visible From domain is not necessarily protected |
| DKIM | A valid signature may belong to a domain unrelated to the visible From address |
| SPF and DKIM without DMARC | There is no published alignment policy protecting the visible domain and no DMARC reporting |
| DMARC without working SPF or DKIM | Legitimate messages have no reliable aligned authentication path |
The controls are not three competing alternatives. SPF and DKIM generate evidence; DMARC connects that evidence to the identity the recipient sees.
What about domains that do not send email?
Unused and parked domains still need protection. If a domain is never intended to send email, its DNS can explicitly state that no servers are authorised and that messages should be rejected under DMARC.
Without those controls, an unused brand domain may still be attractive for impersonation. This applies not only to the main corporate domain but also to campaign domains, acquired brands and defensive registrations.
The exact configuration should be confirmed before publishing, because a supposedly unused domain may still send operational email from an overlooked system.
A sensible implementation order
Email authentication should be treated as a controlled discovery and remediation exercise:
- Inventory every domain and subdomain. Include parked, defensive and legacy domains.
- Identify every legitimate sender. Corporate email is often only part of the picture.
- Publish and validate SPF. Keep one valid record within the DNS-lookup limit.
- Enable DKIM signing. Use aligned domains where supported and manage selector/key rotation.
- Publish DMARC in monitoring mode. Configure aggregate reporting and establish ownership.
- Analyse and remediate. Correct alignment problems and investigate unknown senders.
- Move towards enforcement. Introduce quarantine and rejection when legitimate mail has been validated.
- Continue monitoring. Reassess the configuration whenever suppliers or infrastructure change.
Moving directly to p=reject can disrupt genuine business email. Remaining indefinitely at p=none, however, collects information without requesting protection against failing messages. Monitoring should lead to decisions.
Wuluf's free Domain Security Check shows the SPF and DMARC records currently published for your domain and highlights configuration issues that require attention. A clean automated result is a useful starting point, not proof that every legitimate sender is aligned or that reports are being acted upon.
Where the email estate is complex, Wuluf can assess the wider environment, identify gaps, and help build a controlled path towards enforcement. Get in touch with the Wuluf team.
Frequently asked questions
Is DMARC better than SPF or DKIM?
DMARC is not a replacement for SPF or DKIM. It depends on their authentication results and adds alignment, policy and reporting. The three controls solve different parts of the same problem.
Does DMARC need both SPF and DKIM to pass?
No. DMARC passes when at least one aligned method passes: SPF or DKIM. Configuring both is still advisable because it provides more than one route to successful authentication.
Why does forwarded email sometimes fail SPF?
Forwarding changes the server that delivers the message. That server may not appear in the original sender domain's SPF policy. A DKIM signature may continue to validate if the forwarded message has not been modified in a way that breaks the signature.
Does DKIM encrypt an email?
No. DKIM applies a digital signature; it does not encrypt the message or hide its contents. Transport encryption such as TLS addresses a different part of email security.
Can SPF, DKIM and DMARC stop phishing?
They help prevent criminals from directly spoofing a protected domain, but they do not stop every form of phishing. Lookalike domains, compromised accounts and malicious messages sent from legitimate infrastructure require additional controls.
Will SPF, DKIM and DMARC guarantee email delivery?
No. Authentication supports trust and deliverability, but receiving systems also consider reputation, message content, user engagement and their own policies. Passing authentication does not guarantee inbox placement.
How can I check whether my domain has SPF and DMARC?
Use Wuluf's free Domain Security Check to inspect the live records. A full assessment should also verify DKIM signing on messages, alignment across legitimate sending services and the handling of DMARC reports.