I can send you an email right now that says it's from [email protected]. Or [email protected]. Or [email protected]. And unless the right protections are in place, it'll land in your inbox looking completely legitimate.
This isn't a hack. It's how email was designed. And understanding why — and what SPF, DKIM, and DMARC do about it — is one of the most useful things you can learn about email security.
The postal analogy (it's actually perfect here)
When you send a physical letter, you write a return address on the envelope. Nobody checks if it's real. You could write "10 Downing Street" as the return address and the Royal Mail would deliver it without blinking. They deliver based on the destination address, not the return address.
Email works almost identically. The "From" address you see in your inbox is just a text field. The sending server fills it in, and the receiving server displays it. For decades, nothing verified whether the sender actually controlled that domain.
That's domain spoofing. And it's why your spam folder is full of emails "from" PayPal, HMRC, and Netflix.
SPF: who's allowed to send on my behalf?
SPF (Sender Policy Framework) was the first attempt to fix this. The idea is simple:
A domain owner publishes a DNS record that says "these are the only mail servers authorised to send email from my domain." When a receiving server gets an email claiming to be from yourcompany.com, it checks: did this email come from one of the IP addresses listed in yourcompany.com's SPF record?
You can check any domain's SPF record right now. Open a terminal and type:
dig TXT yourcompany.com | grep spf
Or use an online tool like MXToolbox SPF Lookup.
A typical SPF record looks like this:
v=spf1 include:_spf.google.com include:sendgrid.net -all
Translation: "Google's servers and SendGrid's servers can send for us. Nobody else. Reject the rest."
The problem with SPF alone: SPF checks the envelope sender (the technical return address), not the header From (what you see in your inbox). An attacker can use a different envelope sender that passes SPF while still showing a spoofed "From" address in the email. Also, SPF breaks when emails are forwarded — the forwarding server's IP isn't in the original domain's SPF record.
DKIM: proving the email wasn't tampered with
DKIM (DomainKeys Identified Mail) takes a different approach. Instead of checking IP addresses, it uses cryptography.
When a mail server sends an email, it creates a digital signature of key parts of the message — the From header, the subject, the body — using a private key that only the domain owner has. This signature gets added to the email headers.
The receiving server looks up the corresponding public key (published in DNS) and verifies the signature. If it checks out, two things are confirmed:
The email really was sent by someone with the domain's private key
The signed parts of the email haven't been modified in transit
Check a domain's DKIM record (you'll need to know the selector, which varies):
dig TXT selector1._domainkey.yourcompany.com
The problem with DKIM alone: DKIM proves a message is authentic and unmodified, but it doesn't tell the receiving server what to do if the check fails. A failed DKIM signature might mean tampering, or it might mean the email went through a mailing list that modified the content. Without instructions, most receiving servers just... deliver it anyway.
DMARC: the policy layer that ties it together
DMARC (Domain-based Message Authentication, Reporting, and Conformance) is the final piece. It does two critical things that SPF and DKIM can't do alone:
1. Alignment. DMARC requires that the domain in the "From" header (what the recipient sees) matches the domain verified by SPF or DKIM. This closes the loophole where an attacker could pass SPF with their own domain while spoofing a different "From" address.
2. Policy. DMARC tells receiving servers what to do when authentication fails:
p=none— do nothing, just send me reports (monitoring mode)p=quarantine— send failures to spamp=reject— block failures entirely
Check any domain's DMARC record:
dig TXT _dmarc.yourcompany.com
Or visit dmarcian.com/dmarc-inspector.
A properly configured DMARC record looks like:
v=DMARC1; p=reject; rua=mailto:[email protected]
Translation: "If an email claims to be from our domain and fails both SPF and DKIM alignment, reject it. And send us reports about failures so we can monitor."
The sobering reality: almost nobody enforces DMARC
Here's where it gets frustrating. According to a 2024 analysis by EasyDMARC, over 80% of domains worldwide either have no DMARC record at all or have one set to p=none — which is just monitoring. It doesn't actually block anything.
Even among Fortune 500 companies, enforcement is patchy. Agari's research has consistently found that while most Fortune 500 companies have published a DMARC record, only a minority have it set to the strongest enforcement level (p=reject) — leaving the majority still vulnerable to domain spoofing.
Why? Because implementing DMARC enforcement is genuinely tricky:
- Discovery phase is slow. You start with
p=noneto collect reports and discover all the legitimate services sending email on your behalf. Marketing platforms, CRM systems, transactional email providers, third-party tools — miss one, and legitimate email gets blocked - Reports are XML. Raw DMARC reports are machine-readable XML. Most people look at them once, get overwhelmed, and never check again
- Fear of breaking email. Nobody wants to be the person who set DMARC to reject and accidentally blocked the company's invoice emails
But the cost of not enforcing is that anyone can send email pretending to be your domain. Your customers, your employees, your partners — all vulnerable to spoofed messages that look like they came from you.
How to check if a domain is protected (2-minute exercise)
Want to know if your bank, your employer, or your own domain has proper email authentication? Here's a quick check:
Option 1: Command line
# Check SPF
dig TXT example.com | grep spf
# Check DMARC
dig TXT _dmarc.example.com
Option 2: Online tools
- MXToolbox — enter domain, select the test
- DMARC Analyzer — paste domain, get instant results
- Google Admin Toolbox — comprehensive MX check
What you want to see:
- ✅ SPF record exists and ends with
-all(hard fail) rather than~all(soft fail) - ✅ DKIM record exists (harder to check without knowing the selector)
- ✅ DMARC record exists with
p=quarantineor ideallyp=reject
Red flags:
- ❌ No SPF record at all
- ❌ DMARC with
p=none(monitoring only, doesn't block spoofing) - ❌ No DMARC record (anyone can spoof the domain freely)
Why this matters for you personally
Even if you don't manage a domain, understanding SPF, DKIM, and DMARC helps you assess risk. If you receive a suspicious email "from" a company and want to check whether that company has protections in place, you now know how. If their DMARC is p=none or missing, that email could easily be spoofed. If it's p=reject, spoofing that domain is significantly harder (though not impossible — compromised accounts are a different problem).
For domain owners: getting to p=reject is a project, not a switch you flip overnight. Start with p=none, collect reports for a few weeks, make sure all your legitimate senders are covered by SPF and DKIM, then ratchet up to quarantine and finally reject. It's one of the highest-impact things you can do for your brand's email security.
