Email Authentication Explained: SPF, DKIM, DMARC and Why All Three Matter

Every day, attackers send billions of emails pretending to be someone they are not. Your bank. Your CEO. Your payroll provider. In most cases, they succeed. Not because your staff are careless, but because email was never designed to verify who is actually sending it.

Email authentication is the set of technical controls that fixes this problem. SPF, DKIM, and DMARC are the three protocols that together tell the world: this email genuinely came from us.

This guide explains what each one does, why all three are necessary, where each one falls short on its own, and what your organisation needs to do about it. No jargon. No filler.

What Is Email Authentication and Why Does It Matter?

When someone sends you an email, there is no built-in mechanism in standard email that proves the sender is who they claim to be. The "From" address you see in your inbox is just a piece of text. Anyone can write anything in that field.

This is the root cause of email spoofing, and spoofing is the foundation of phishing, business email compromise (BEC), invoice fraud, and most other email-based attacks.

Consider what happens in a typical BEC attack:

1. An attacker registers a domain that looks like your supplier's, for example acme-invoices.com instead of acme.com
2. They send your finance team an email that appears to come from a trusted contact
3. The email requests a payment to a new bank account
4. Your team pays

Or worse, the attacker does not even need a look-alike domain. Without proper email authentication in place, they can spoof your actual domain exactly. Your customers or partners then receive emails that appear to come directly from yourcompany.com.

SPF, DKIM, and DMARC exist specifically to prevent this.

They work by publishing verifiable records in your domain's DNS (Domain Name System). These records allow receiving mail servers to check whether an email genuinely came from you. If it does not pass the checks, the receiving server knows something is wrong.

Key stat: More than 90% of email-based cyberattacks involve some form of spoofing. Yet only 34% of the world's largest 5,000 companies have DMARC properly configured.

The Three Protocols at a Glance

Before going deeper on each one, here is the simplest possible summary:

A useful way to think about it:

• SPF is the approved sender list. Think of it like a visitor register at your front door.
• DKIM is the tamper-proof seal on an envelope. It proves the contents have not been changed since they were sent.
• DMARC is the security policy and reporting layer. It decides what happens when the checks above fail, and it reports back to you.

Each one solves a different problem. All three are needed.

What Is SPF (Sender Policy Framework)?

The plain-English explanation

SPF lets you publish a list of servers that are authorised to send email on behalf of your domain. When an email arrives claiming to be from yourcompany.com, the receiving mail server looks up your SPF record in DNS and asks: is the server that sent this email on the approved list?

If yes, the email passes SPF.
If no, the email fails SPF and may be rejected or flagged as suspicious.

How SPF works in practice

Your SPF record lives as a TXT record in your domain's DNS. It looks something like this:

1v=spf1 include:_spf.google.com include:mailchimp.com ip4:203.0.113.50 -all

This record says: emails from yourcompany.com may be sent via Google Workspace, Mailchimp, or the IP address 203.0.113.50, and nothing else. The -all at the end means reject everything outside that list.

When a receiving server gets an email from your domain, it does the following:

1. Looks up the SPF record for your domain in DNS
2. Checks whether the sending server's IP address is on your approved list
3. Passes or fails the message based on the result

What SPF protects against

SPF stops attackers from sending email from unauthorised servers while claiming to be from your domain. It catches many basic spoofing attempts and forms the first line of defence in email authentication.

Where SPF falls short

SPF has a significant blind spot that most people are not aware of.

SPF checks the Return-Path address, also called the envelope sender. It does not check the visible From address that your recipients actually see in their email client.

This means an attacker can send an email that passes SPF because it was sent from a legitimate server they control, while the visible "From" address in your inbox still shows ceo@yourcompany.com. SPF would pass. Your recipient would see your CEO's name and address. The attack would succeed.

This is precisely why SPF alone is not enough, and why DKIM and DMARC exist.

The practical implication: SPF is a necessary foundation, but it cannot prevent display-name spoofing or From-address impersonation on its own.

What Is DKIM (DomainKeys Identified Mail)?

The plain-English explanation

DKIM works like a tamper-proof wax seal on a letter. When you send an email, your mail server adds a digital signature to the message. When the email arrives, the receiving server uses a public key stored in your DNS to verify that the signature is genuine.

If the signature checks out, the email came from your domain and has not been altered in transit.
If the signature does not check out, the email may have been forged or modified.

How DKIM works in practice

Your organisation holds a private key that only your mail server knows. This key creates a unique digital signature for every email you send. The signature is embedded in the email's header, invisible to end users but checked automatically by receiving servers.

A corresponding public key is stored in your DNS as a TXT record. Anyone can look it up. Receiving servers use it to verify your email's signature.

If an attacker intercepts your email and changes even a single character in the body or headers, the signature immediately becomes invalid. This is what makes DKIM powerful. It catches tampering that SPF cannot.

What DKIM protects against

• Email tampering in transit, also known as man-in-the-middle attacks
• Replay attacks where legitimate emails are re-sent maliciously
• Phishing from servers that attempt to mimic your identity

Where DKIM falls short

DKIM verifies that the email was signed by your domain and has not been altered. But it does not verify that the domain in the DKIM signature matches the visible From address the recipient sees.

In other words, an attacker can sign an email with their own domain's DKIM signature while displaying your domain in the From field. DKIM would pass for their domain. Your recipient would see your domain in the From field. The attack could still work.

This is why both SPF and DKIM need a unifying enforcement layer on top. That layer is DMARC.

What Is DMARC (Domain-based Message Authentication, Reporting and Conformance)?

The plain-English explanation

DMARC is the policy layer that sits on top of SPF and DKIM. It does three things:

1. Alignment check. It verifies that the domains authenticated by SPF and DKIM actually match the visible From address the recipient sees. This closes the blind spots that SPF and DKIM each carry on their own.
2. Policy enforcement. It tells receiving mail servers what to do with emails that fail: deliver them anyway, send them to spam (quarantine), or reject them outright.
3. Reporting. It sends you regular reports showing who is sending email using your domain, including attackers attempting to impersonate you.

How DMARC works in practice

Your DMARC record is published as a TXT record in DNS. A typical DMARC record looks like this:

1v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourcompany.com; pct=100

Breaking this down:

• p=reject means emails that fail DMARC should be rejected outright
• rua= specifies where aggregate reports should be sent
• pct=100 means the policy applies to 100% of failing emails

The three policy options are:

The alignment check is what makes DMARC genuinely powerful. For an email to pass DMARC, either SPF or DKIM, or both, must pass. The authenticated domain must also align with the visible From address. This closes the loopholes that SPF and DKIM leave open individually.

Why DMARC reporting is underused and incredibly valuable

DMARC sends you aggregate reports showing:

• Every server that sent email using your domain
• Whether those emails passed or failed SPF and DKIM
• Where in the world those emails originated

This gives you visibility into two things. First, your own legitimate email infrastructure, so you can confirm everything is properly configured. Second, attackers actively trying to impersonate your domain.

Most organisations set up DMARC and never look at the reports. That is a missed opportunity. The reports are your early warning system for spoofing campaigns targeting your customers, partners, or staff.

Why You Need All Three, Not Just One or Two

This is the question most IT teams get wrong. "We have SPF set up, is that not enough?" It is not. Here is why each combination falls short:

SPF only: Passes the envelope check but an attacker can still spoof the visible From address. Display-name and From-header spoofing still works without DMARC enforcement.

DKIM only: Proves the email was not tampered with, but does not stop someone from signing emails with their own domain while displaying yours in the From field.

SPF and DKIM without DMARC: Both authentication mechanisms are running but there is no policy telling receiving servers what to do when they fail, and no reporting to tell you about active attacks. Enforcement is completely absent.

SPF and DMARC without DKIM: DMARC can function without DKIM, but DKIM adds an important verification layer that is especially critical in email forwarding scenarios where SPF often breaks.

All three together: SPF confirms the sending server is authorised. DKIM confirms the message has not been tampered with. DMARC confirms the authenticated domains align with what recipients see and enforces consequences when they do not.

Think of it like a front door with both a lock and a deadbolt. Either one alone could be bypassed. Together, the combination is significantly harder to defeat.

The Current State of Email Authentication: Why Most Organisations Are Still Exposed

Despite these protocols being available for over a decade, adoption remains alarmingly low:

• Only 34% of the world's largest 5,000 companies have DMARC configured
• Only 7.7% of major domains enforce DMARC at the strongest level (p=reject)
• 92% of domains are still effectively vulnerable to spoofing

The enforcement gap is the most dangerous part. Many organisations have DMARC set to p=none, which is monitoring mode only. This means attackers can spoof their domain all day and the emails will still be delivered. The organisation receives reports about it, but nothing is blocked.

In 2025 this became significantly more urgent. Microsoft introduced mandatory requirements for SPF, DKIM, and DMARC for high-volume email senders, following similar moves by Google and Yahoo in 2024. Emails from non-compliant domains are now being routed to junk folders, with full rejection coming next. This is no longer optional infrastructure. It is table stakes.

What SPF, DKIM, and DMARC Do Not Protect Against

Being honest about the limits of these protocols matters. SPF, DKIM, and DMARC are authentication protocols. They prove identity. They are not a complete email security solution on their own.

They do not protect against:

• Phishing from legitimately authenticated domains. If an attacker sets up SPF, DKIM, and DMARC for their own domain and sends from it, all three checks will pass. The email will be delivered. Authentication cannot distinguish a genuine sender from an attacker who has correctly configured their own domain.
• Malicious links inside authenticated emails. Authentication verifies the sender. It says nothing about whether the links inside a legitimate-looking email lead to malicious websites.
• Compromised legitimate accounts. If an attacker gains access to a real email account within your domain, they will send from an authenticated source and pass all three checks without any difficulty.
• Zero-day phishing URLs. Newly registered malicious domains will not yet appear in threat intelligence blocklists, regardless of how well your authentication is configured.

Authentication protocols are the foundation, but the foundation alone is not a complete defence. A properly authenticated phishing email is still a phishing email.

The most sophisticated attacks today involve emails that pass all authentication checks without issue. The threat is in the link, which is why link-level inspection and sandboxing are the next layer every organisation needs.

How to Check Whether Your Domain Is Protected Right Now

Before making any changes, check your current status. You can do this in under two minutes using free tools.

Check your SPF record:
Go to mxtoolbox.com/spf.aspx, enter your domain, and run the lookup. You should see a valid SPF record. If you see "No SPF record found", you have no SPF protection in place.

Check your DKIM:
DKIM is checked per selector, which is a label that identifies which DKIM key is being used. Your email provider's documentation will tell you your selector. Tools like easydmarc.com/tools/dkim-lookup can help you look it up.

Check your DMARC:
Go to mxtoolbox.com/dmarc.aspx and enter your domain. If you see p=none, you have DMARC in monitoring mode only. If you see no record at all, you have no DMARC protection whatsoever.

Recommended Implementation Order

If you are starting from scratch or tightening up an existing configuration, follow this sequence:

Step 1: Set up SPF
Publish an SPF record that lists all servers authorised to send email on your behalf. Do not forget to include third-party services like your CRM, marketing platform, or HR system.

Step 2: Enable DKIM
Work with your email provider, whether that is Google Workspace, Microsoft 365, or your own mail server, to generate and publish your DKIM keys. Most providers have step-by-step guides for this.

Step 3: Deploy DMARC at p=none first
Start with a monitoring-only policy. This lets you see who is sending email using your domain without risking disruption to legitimate mail.

Step 4: Review DMARC reports for two to four weeks
Use a DMARC reporting tool to understand your full email ecosystem. Identify all legitimate senders and confirm they pass SPF and DKIM.

Step 5: Move to p=quarantine, then p=reject
Once you are confident your legitimate email is fully authenticated, tighten the policy. Move to quarantine first, monitor for issues, then move to reject.

Important: Never jump straight to p=reject without the monitoring phase. Organisations that skip this step often inadvertently block their own legitimate email.

What Happens When These Checks Pass and When They Do Not

Here are three real-world scenarios showing how the three protocols interact:

Scenario 1: Legitimate email from your company
Your finance director sends an invoice reminder from their Google Workspace account.

• SPF check: The sending server (Google) is on the SPF approved list. Pass.
• DKIM check: The message carries a valid digital signature from your domain. Pass.
• DMARC check: Both SPF and DKIM align with the From address finance@yourcompany.com. Pass.
• Result: Email delivered normally.

Scenario 2: Attacker spoofing your domain
An attacker sends a fake payment request claiming to be from ceo@yourcompany.com.

• SPF check: The attacker's server is not on your SPF approved list. Fail.
• DKIM check: The email carries no valid signature from your domain. Fail.
• DMARC check: Both checks fail and your policy is set to p=reject.
• Result: Email rejected before it reaches any inbox.

Scenario 3: Sophisticated phishing that passes all checks
An attacker registers yourcompany-billing.com, correctly sets up SPF, DKIM, and DMARC for that domain, and sends a convincing invoice with a malicious payment link inside.

• SPF check: Their server is authorised for their domain. Pass.
• DKIM check: Their email is signed for their domain. Pass.
• DMARC check: Authentication passes for their domain. Pass.
• Result: Email is delivered. Authentication cannot stop this attack.

The link inside the email is the threat. This is exactly why authentication must be paired with link-level inspection.

Frequently Asked Questions

Do small businesses need SPF, DKIM, and DMARC?

Yes. The assumption that attackers only target large organisations is both outdated and dangerous. Small businesses are frequently targeted precisely because their email security is weaker. A 30-person law firm or accountancy practice handling client payments is an extremely attractive target. The good news is that SPF, DKIM, and DMARC cost nothing to implement. They are DNS records.

Will setting up DMARC break my email?

Only if you skip the monitoring phase. If you follow the recommended sequence, starting at p=none, reviewing reports, moving to p=quarantine, and then to p=reject, you will identify any configuration issues before they cause disruption.

We use Microsoft 365. Does Microsoft handle this for us?

Microsoft 365 sets up DKIM and basic SPF for the onmicrosoft.com subdomain automatically, but not for your custom domain such as yourcompany.com. You still need to publish SPF, DKIM, and DMARC records for your own domain. Microsoft's own documentation confirms this.

What is the difference between SPF soft fail (~all) and hard fail (-all)?

A soft fail (~all) marks emails from unauthorised servers as suspicious but still delivers them. A hard fail (-all) instructs receiving servers to reject them entirely. For maximum protection, use -all in your SPF record, but only once you are confident all legitimate senders are included.

How often should we review our DMARC reports?

At minimum, monthly. Review more frequently if you are in the process of tightening your policy. Any time you add a new email service such as a new CRM, marketing tool, or support platform, check your DMARC reports to confirm the new service is properly authenticated.

Our DMARC reports show emails we do not recognise. What does that mean?

It means someone is attempting to send email using your domain. It could be a misconfigured legitimate service, or it could be an active spoofing campaign targeting your customers. This is exactly the intelligence DMARC reporting is designed to surface. Investigate the source before tightening your policy.

Summary: What to Take Away

Email authentication is not optional in 2026. It is the baseline level of protection every organisation that sends email should have in place.

SPF prevents unauthorised servers from sending email on your behalf.
DKIM prevents email from being tampered with in transit and proves message origin.
DMARC enforces alignment between authentication results and what recipients actually see, and gives you visibility into spoofing attempts targeting your domain.

All three work together. None of them is sufficient on its own.

Authentication is the foundation, not the complete solution. It tells receiving servers whether an email came from where it claims. It cannot inspect the links inside those emails, detect malicious payloads, or catch zero-day phishing attacks from legitimately authenticated domains. That requires an additional layer of protection working at the link and content level.

CyberCheck360 is an email security platform that works at the link level, inspecting every URL inside every email in an isolated sandbox before it reaches your team. See how it works alongside your existing authentication setup at cybercheck360.com.

Related reading:

• What is SPF? The Sender Policy Framework Explained in Plain English
• What is DKIM? How Email Signatures Prove Your Messages Are Genuine
• What is DMARC? Why 66% of Companies Still Don't Have It Configured