DMARC vs SPF vs DKIM

If You’ve Ever Said “We’ve Got SPF and DKIM”, This One’s for You

Somewhere in almost every business is this sentence:

“We’ve already got SPF and DKIM, so we’re covered.”

It’s usually said confidently.
It’s usually wrong.

Not completely wrong – just wrong enough to still get your domain spoofed, your brand impersonated, and your finance team targeted.

SPF, DKIM, and DMARC are not alternatives.
They are components of a single control system.

Using one or two without the third is like:

• Installing CCTV
• Buying a door lock
• Never actually locking the door
• Or plugging in the TV’s

Let’s untangle what each one really does – and why DMARC is the piece that turns email authentication from “nice effort” into actual protection.

If you haven’t read our main guide yet, start here: DMARC: The Email Security Standard You Can’t Afford to Ignore. This article dives deeper into the technical relationship between these three controls.

The Real Problem: Email Identity, Not Email Content

Before we touch acronyms, we need to reset the problem.

Most email attacks today don’t rely on:

• Malware
• Exploits
• Fancy payloads

They rely on identity deception.

Attackers don’t need to break into your systems if they can simply:

• Pretend to be you
• Send emails from your domain
• Look legitimate enough to be trusted

Email authentication exists to answer one core question:

“Is this email really from who it claims to be from?”

SPF, DKIM, and DMARC each answers part of that question individually.
Only together do they answer it fully.

SPF Explained: Who Is Allowed to Send Email for Your Domain

What SPF Actually Does

SPF (Sender Policy Framework) is a DNS-based control that answers this:

“Is the server that sent this email authorised to send mail for this domain?”

You publish a DNS record listing approved sending servers.
Receiving mail servers check that list.

If the server is authorised → SPF passes.
If not → SPF fails.

Simple. Useful. Necessary.

Where SPF Falls Short (And Why Attackers Love That)

SPF has some fundamental limitations:

• It checks the envelope sender, not the visible “From” address
• It breaks when emails are forwarded
• It does not enforce brand identity
• It does not tell receivers what to do when it fails

Which means an attacker can:

• Spoof your visible From address
• Pass SPF using a different domain
• Still land in inboxes

SPF alone does not stop brand impersonation.

SPF in the Morse Reality Check

SPF answers:

“Was this server allowed to send something?”

It does not answer:

“Is this email really from you?”

Necessary? Yes.
Sufficient? Absolutely not.

DKIM Explained: Was the Email Altered and Authorised?

What DKIM Actually Does

DKIM (DomainKeys Identified Mail) cryptographically signs outgoing emails.

That signature allows receivers to verify:

• The message hasn’t been altered in transit
• The sending domain authorised the email

If the signature matches → DKIM passes.
If it doesn’t → DKIM fails.

DKIM is excellent at proving message integrity.

Where DKIM Alone Still Fails

DKIM has its own blind spots:

• It doesn’t enforce what happens on failure
• It doesn’t require alignment with the visible From address
• A valid DKIM signature can exist on an impersonated email

Without additional rules, DKIM says:

“This message was signed by a domain”

Not necessarily:

“This message is from the domain the user sees”

Attackers exploit that ambiguity constantly.

DKIM in Plain English

DKIM answers:

“Was this email tampered with, and did someone authorise it?”

It does not answer:

“Is this email genuinely from the brand the recipient trusts?”

Again: required, but incomplete.

DMARC Explained: The Control Layer That Makes SPF and DKIM Matter

This is where everything finally clicks.

DMARC (Domain-based Message Authentication, Reporting & Conformance) sits on top of SPF and DKIM and does three critical things:

1. Alignment
   It requires that SPF and/or DKIM align with the visible From address
2. Policy Enforcement
   It tells receiving servers what to do if authentication fails
3. Reporting
   It sends you reports showing who is sending as your domain – legitimately or otherwise

Understanding which policy to use is critical—we break down each option in detail here: DMARC policy types explained: none vs quarantine vs reject.

Without DMARC:

• SPF and DKIM are advisory
• Receivers guess
• Attackers exploit the gaps

With DMARC:

• You define the rules
• Receivers enforce them
• Spoofing stops

This is covered in depth in our main guide: DMARC: The Email Security Standard You Can’t Afford to Ignore

The Key Concept Everyone Misses: Alignment

Alignment is the quiet hero of DMARC.

DMARC checks whether:

• The domain used by SPF or DKIM
• Matches the domain shown in the “From” address

If they don’t align, DMARC fails – even if SPF or DKIM passed individually.

That’s the point.

Alignment stops attackers from saying:

“Yes, this email was authenticated… just not by you.”

Why You Need All Three (Not One, Not Two)

Let’s make this painfully clear:

• SPF alone → Easily spoofed
• DKIM alone → Ambiguous trust
• SPF + DKIM without DMARC → No enforcement, no visibility

Only SPF + DKIM + DMARC gives you:

• Identity assurance
• Policy enforcement
• Spoofing prevention
• Brand protection
• Deliverability improvements

Anything less is half-security.

How This Fails in the Real World (A Common Scenario)

1. Business has SPF and DKIM
2. No DMARC, or p=none forever
3. Attacker spoofs domain
4. Email looks legitimate
5. Invoice fraud succeeds
6. Everyone says “but we had email security…”

You had components.
You didn’t have control.

DMARC Turns Email from Guesswork into Rules

With DMARC in place, you can say:

• If authentication fails → reject it
• If alignment fails → quarantine it
• If someone spoofs us → block it
• And tell us who’s trying

That’s the difference between hoping and knowing.

If you want to understand enforcement levels next, read:DMARC Policy Types Explained: none vs quarantine vs reject

The Morse Take

SPF and DKIM are like ID checks.
DMARC is the policy that says what happens when the ID is fake.

If your email security relies on:

• “Probably”
• “Should be fine”
• “We’ve never had an issue”

You don’t have security.
You have luck.

And luck doesn’t scale.

Ready to Go Deeper?

This article is part of our DMARC & Email Authentication cluster, anchored by our main guide:

DMARC: The Email Security Standard You Can’t Afford to Ignore

Next in the series:

• DMARC policy types explained: none vs quarantine vs reject
• Common DMARC mistakes that break legitimate email
• How to read DMARC reports properly
• Email authentication and cyber insurance requirements

Dot. Dash. Verified.