Anyone Can Send an Email as Your CEO. Here Is What Actually Stops Them

While email is in many ways like our digital passport, it was built in 1982 with zero authentication. SPF, DKIM, and DMARC are the patch. Here is how each one works and how they stop phishing TOGETHER

Think about what your email actually protects.

Your bank sends password resets there. Your cloud accounts send login codes there. Your company sends contracts, invoices, and credentials there.

Email is your digital passport. If someone can convincingly pretend to be you, they can walk through almost any door you own.

And here is the uncomfortable part:

Email was never designed to verify who is sending it.

The protocol behind email, SMTP, was created in 1982. Back then, the internet was a small club of researchers who trusted each other. So nobody built in authentication.

That means I can send an email that says it is from ceo@yourcompany.com. The protocol will happily deliver it.

So how is it possible that your inbox is not full of fake emails from your bank?

Because of three mechanisms bolted on top of email decades later: SPF, DKIM, and DMARC.

Most people can name them. Very few can explain what each one actually does. And in interviews, that difference gets noticed immediately.

In this article, you will:

• Understand why email spoofing is possible in the first place

• Learn what SPF, DKIM, and DMARC each verify

• See why SPF and DKIM alone do NOT stop spoofing

• Check any domain’s email security yourself, with two commands

Have you ever been asked about SPF, DKIM, or DMARC in an interview? Give this article a like and help others prepare for the same question!

First, understand the trick: an email has TWO senders

This is the concept everything else depends on.

Every email has:

1. The envelope sender. A hidden address used by mail servers to route the message. You never see it.

2. The From header. The address displayed in your inbox.

Here is the problem:

These two addresses do not have to match.

The envelope can say attacker@evil.com while your inbox displays ceo@yourcompany.com.

It is like a physical letter. The post office only looks at the envelope. Whatever name is written inside the letter is up to the sender.

SPF: The Guest List

Definition: SPF (Sender Policy Framework) is a DNS record that lists which servers are allowed to send email on behalf of a domain.

Think of SPF as a guest list published by the domain owner.

When a mail server receives an email, it asks:

Is the server that sent this email allowed to send for the envelope sender’s domain?

Simple enough. So, where is the problem? The receiving server checks if the sender is allowed to send emails on behalf of this domain, and it stops phishing, right?

Well, no.

Remember that every domain publishes its own guest list.

The attacker owns, for example, the evil.com domain. So the attacker writes the guest list for evil.com, and puts his own server on it.

Let me show it to you on one simple example:

Envelope sender:  attacker@evil.com
                  ↓
                  Server checks evil.com's guest list
                  ↓
                  Attacker's server IS on it. SPF PASSES.

From header:      Decoded Security <info@decodedsecurity.com>
                  ↓
                  Never checked. At all.

Note: The receiving mail server checks evil.com's SPF record because that's the envelope sender.

The mail server verified that evil.com was allowed to send the email. It never verified that the visible From address belonged to the same domain.

SPF checked the envelope. Not the sender shown to the recipient.

Do you see the problem now?

DKIM: The Wax Seal

Definition: DKIM (DomainKeys Identified Mail) adds a cryptographic signature to an email, which receivers verify using a public key published in DNS.

In other words: DKIM is a wax seal on the letter.

The sending server signs the message with a private key. The receiving server fetches the matching public key from DNS and verifies the signature.

If the signature is valid, two things are proven:

• The message really was signed by that domain

• The content was not modified in transit

That second part matters. Change one character in a signed email, and the seal breaks.

So DKIM solves spoofing, right?

Still no.

DKIM proves an email was signed by SOME domain. Not by the domain shown in the From header.

An attacker can sign an email with a perfectly valid DKIM signature from evil.com, while the From header says your bank.

Valid seal. Wrong sender.

Are you seeing the pattern?

Both SPF and DKIM can pass while the From header, the only thing a human ever looks at, is completely fake. If this surprised you, give this article a like. This is the part most people get wrong.

DMARC: The Enforcer

Definition: DMARC (Domain-based Message Authentication, Reporting and Conformance) requires that SPF or DKIM align with the visible From header, and tells receivers what to do when they do not.

DMARC adds the one check that was missing the whole time. It is called alignment:

• SPF passed? Fine. Does the envelope domain match the From header domain?

• DKIM passed? Fine. Does the signing domain match the From header domain?

At least one of them must align. Otherwise, DMARC fails.

So the full system works like this:

SPF   → WHO is allowed to send (the guest list)
DKIM  → Was the message signed and unmodified (the wax seal)
DMARC → Does any of it match the sender you SEE (the enforcer)

You now know what a missing DMARC policy means. Want to see how many well-known domains are missing one?

Check any domain in the Decoded Security Spoof-Check

Try it yourself, right now

Two commands. On Windows, use nslookup -type=TXT instead of dig.

dig +short TXT decodedsecurity.com
dig +short TXT _dmarc.decodedsecurity.com

Mine returns:

v=spf1 include:zohomail.eu include:eu.zcsend.net include:_spf.mlsend.com ~all
v=DMARC1; p=quarantine; sp=quarantine; rua=mailto:...

Three approved senders, and a policy that sends anything unaligned to spam.

Now run it on your employer’s domain. Or your bank’s.

Check the p= value: none means watching without stopping, quarantine means spam, reject means the email never reaches the inbox.

What did you find? Drop the domain and its policy in the comments. I read every response!

Doesn’t it work on your local machine? Use the Decoded Security spoof-check and check your favorite domain there!

Drop the result in the comments! I am curious!

Conclusion

Congratulations! You now understand something most IT professionals only pretend to.

You know why spoofing is possible, what each of the three mechanisms actually verifies, and why only DMARC alignment protects the address a human sees.

Next time someone tells you “we have SPF, we are safe,” you will know exactly what question to ask them.

Thank you for reading Decoded Security!

Erich

Where To Go Next

Email security builds directly on DNS and phishing fundamentals:

👉 This Is How I Explain DNS To Beginners

👉 How Phishing Works in 5 Steps

Want a clear 90-day plan for turning knowledge like this into a job offer?

Let’s Connect

If you want to collaborate, discuss, or just geek out over networking and cybersecurity, reach out:

Email: erich.winkler@decodedsecurity.com
LinkedIn: Erich Winkler
Gumroad community: Decoded Security
Start Here: Decoded Security Roadmap

Enjoyed this article? Like it or drop a comment. I’d love to hear your thoughts and questions!

Let’s learn and grow together!