When you receive an email claiming to be from your bank, how do you know it's actually from your bank and not a scammer? That's where email authentication comes in. Three protocols — SPF, DKIM, and DMARC — work together to verify the authenticity of emails.

The Problem: Email Spoofing

Email was invented in the 1970s, when the internet was a trusted network of academics. The protocol wasn't designed with security in mind. By default, anyone can send an email claiming to be from any address — there's no built-in verification.

This is called email spoofing, and it's the foundation of most phishing attacks. Without authentication, a scammer can easily send an email that appears to come from security@yourbank.com.

SPF: Sender Policy Framework

SPF is the first line of defense. It answers a simple question: "Is this server allowed to send emails for this domain?"

How SPF Works

A domain owner publishes a list of authorized mail servers in their DNS records
When you receive an email, your mail server checks if the sending server is on that list
If it's not on the list, the SPF check fails

Example

PayPal's SPF record lists their authorized email servers. If you receive an email claiming to be from PayPal, but it came from a server in Russia that's not on their list, SPF will fail.

SPF Limitations

Only checks the "envelope sender" (hidden from users), not the "From" address you see
Breaks when emails are forwarded
Doesn't prevent modification of email content

DKIM: DomainKeys Identified Mail

DKIM adds a digital signature to every email, proving two things: the email came from the claimed domain, and it wasn't modified in transit.

How DKIM Works

The sending server creates a cryptographic signature of the email content
This signature is added to the email header
The receiving server uses the sender's public key (published in DNS) to verify the signature

Think of it like a wax seal on a letter — if the seal is broken, you know someone tampered with it.

Example

Google signs all emails sent from Gmail. When you receive a Gmail message, your email provider can verify that Google actually sent it and that no one modified it along the way.

DKIM Limitations

Doesn't tell receiving servers what to do with failed emails
Can survive forwarding, but signature may break if content is modified
Only validates the signing domain, which might differ from the "From" address

DMARC: Domain-based Message Authentication

DMARC ties SPF and DKIM together and tells receiving servers what to do when authentication fails. It also enables domain owners to receive reports about authentication results.

How DMARC Works

Domain owner publishes a DMARC policy in DNS
Receiving server checks both SPF and DKIM
DMARC verifies "alignment" — the authenticated domain must match the "From" address
If authentication fails, DMARC policy tells the server what to do (report, quarantine, or reject)

Example DMARC Policies

none: Just monitor and report (don't take action)
quarantine: Send failed emails to spam folder
reject: Block failed emails entirely

How These Work Together

Email arrives

↓

SPF Check Is the server authorized?

↓

DKIM Check Is the signature valid?

↓

DMARC Check Do domains align?

↓

Decision Deliver, quarantine, or reject

What This Means for You

When our service analyzes an email, we check all three protocols:

All pass: Strong indicator the email is legitimate
Some fail: Could be legitimate (misconfigured) or suspicious
All fail: High likelihood of spoofing/phishing

Important: A passing authentication doesn't guarantee an email is safe — only that it really came from the stated sender. Scammers can set up their own domains with proper authentication. That's why we combine authentication checks with link analysis, content scanning, and pattern detection.

Check Your Emails

Want to know if an email passes authentication? Forward it to us and we'll tell you:

check@isthismailsafe.com