Email Spoofing: Why It Still Works, and How SPF/DMARC/DKIM Stop It

// TL;DR

---

What is email spoofing?

Email spoofing is forging the sender address of an email so it appears to come from someone it didn’t. It’s a staple of phishing and spam because people are far more likely to trust — and act on — a message that looks like it came from a legitimate source: their bank, their employer, a colleague.

It isn’t new or clever. It’s one of the oldest tricks on the internet, and it persists precisely because the foundation it exploits was never designed with authentication in mind.

Why it’s possible: SMTP has no authentication

The reason spoofing works at all is structural. SMTP — the protocol that sends email — has no built-in mechanism to verify the sender. Nothing in the core protocol checks that the person sending a message from boss@company.com is actually authorised to use that address.

So, by default, anyone can send an email claiming to be from (almost) any address to (almost) anyone. The defences against spoofing aren’t part of SMTP itself — they’re bolted on afterward, as DNS records that let a receiving server check whether a message is legitimate. If a domain hasn’t set those records up properly, there’s nothing to catch the forgery.

The three defences: SPF, DKIM, DMARC

Three DNS-based mechanisms work together to detect and block spoofing:

SPF (Sender Policy Framework) — a DNS TXT record listing which mail servers are allowed to send email for your domain. The receiving server checks whether the sending IP is on that authorised list. It answers: “did this come from a server permitted to send for this domain?”

DKIM (DomainKeys Identified Mail) — a cryptographic signature. The sending server signs the message with a private key; the receiver verifies it using the public key published in the domain’s DNS. It answers: “was this message actually signed by the domain, and was it tampered with in transit?”

DMARC (Domain-based Message Authentication, Reporting & Conformance) — the policy layer built on top of SPF and DKIM. It tells receivers what to do when a message fails those checks (allow, quarantine, or reject), how to align the visible From: address with the authenticated domain, and where to send reports. It answers: “given the SPF/DKIM result, how should this message be treated?”

SPF and DKIM detect problems; DMARC is what actually enforces a consequence. Without it, failures often pass through anyway.

The misconfigurations that leave you exposed

This is the heart of it: many organisations have these records and still get spoofed, because the records are weak or incomplete.

SPF problems

• No SPF record at all.
• A soft policy. Ending the record in ~all (SoftFail) or ?all (Neutral) instead of -all (HardFail) tells receivers “this probably isn’t authorised… but accept it anyway.” Example of a soft record: v=spf1 include:spf.site.com ~all.
• Too many DNS lookups, duplicate records, or overly broad IP ranges — which can break SPF evaluation or effectively authorise far more senders than intended. As the saying goes: “Your SPF record authenticates the entire internet.”
• Invalid syntax, which can cause the whole record to be ignored.

DMARC problems

• No DMARC record. When a spoofed message fails SPF, the receiver looks to DMARC for what to do next — and if DMARC doesn’t exist, the message is often accepted anyway (SPF “fails open”).
• A policy of p=none. This is monitor-only: it reports failures but tells receivers to take no action. A domain with p=none is effectively still spoofable, even though DMARC is “present.”

The fix for the DMARC side is blunt: set an enforcing policy (p=reject or at least p=quarantine) rather than leaving it at none.

Impact: what spoofing enables

Spoofing is a force multiplier for social engineering. With a spoofable domain, an attacker can:

• Phish convincingly — most breaches start with phishing, and a message from a real-looking internal or trusted address clears the victim’s first instinct to doubt it.
• Impersonate a person or brand — send mail “from” an executive to staff, or “from” a company to its customers.
• Abuse email-driven features — if a service lets you create a support ticket or trigger an action by email, a spoofed message from the victim’s address can make requests as them (e.g. asking support to change account settings).
• Deliver malware or malicious links under a trusted identity.
• Damage trust and reputation — impersonation, scams, and blackmail that erode a brand’s or person’s credibility.

The common thread: spoofing doesn’t break your systems, it borrows your identity to attack the people who trust you.

Here’s the spoofed email demo

Prevention

It’s genuinely preventable — this is a configuration problem, not an unsolvable one:

• Publish all three records: SPF, DKIM, and DMARC.
• Use a strict SPF policy (-all), keep it within the DNS-lookup limit, and avoid overly broad IP ranges or duplicate records.
• Set an enforcing DMARC policy (p=reject, or p=quarantine as a stepping stone) — not p=none.
• Sign outbound mail with DKIM and keep keys current.
• Monitor DMARC reports to catch misconfigurations and abuse.

Email spoofing in bug bounty

Email spoofing has been a steady source of rewards for me — bounties, hall-of-fame acknowledgements, certificates, and swag across many programs. A few realities worth knowing if you report it:

• Severity varies a lot by program. Some rate it low, some medium, some high. The impact argument (phishing, impersonation, email-driven account actions) is what moves it up.
• Some programs exclude it from scope — either because they already know, or, honestly, because they underestimate its impact.
• Many organisations simply don’t realise they’re exposed. Plenty have SPF but no DMARC, or both but with a p=none policy or a misconfigured SPF — all of which still allow spoofing straight to the inbox.

I’ve reported Email Spoofing several times and I received a lot of Bounties, Certificates and Swags many times.

I received bounty on duplicate and informative report as well because I demonstrated the impact

More,

A huge swag from private site on h1

If you hunt it, make the impact concrete in your report (a spoofed email landing in the inbox, and a realistic abuse scenario for that organisation) rather than just flagging a missing record — that’s the difference between “informative” and a paid finding.

Read the scope carefully before you spend time on it. If a program flatly puts anything SPF/DMARC/DKIM-related out of scope, don’t bother. But read the wording — if they exclude only “email spoofing without a demonstrated impact” (or similar), that’s not a blanket exclusion: it means a spoof you can actually demonstrate with real impact is in scope. The exclusion is for low-effort “you’re missing DMARC” reports, not for a working proof-of-concept. Knowing the difference saves you from skipping a payable bug — or wasting time on an unpayable one.

Thanks for reading — go check your own domain’s records while you’re at it. Happy hacking!