What is email spoofing, exactly

The three layers spoofing can target

An email has several distinct "sender addresses," and spoofing can target each differently:

• The SMTP envelope (MAIL FROM) — the technical address used for routing, generally invisible to the end user.
• The From: header — the address shown in the mail client, the one the victim sees and bases their trust on.
• The display name — the plain-text name ("Executive Office," "IT Support") associated with the address, sometimes manipulated independently of the address itself to deceive visually, even when the real address would look suspicious to anyone bothering to read it.

A sophisticated attacker can play all three layers at once — a consistent technical envelope, a forged From:, and a reassuring display name — to maximize the message's credibility.

What spoofing makes possible

The practical consequences of spoofing go far beyond one annoying isolated email. It's the underlying technical mechanism behind most social-engineering attacks that travel by email:

• Generic phishing — an email claiming to come from a bank, a government service, or a well-known vendor, pushing the recipient to click a malicious link.
• CEO fraud (BEC) — an email seemingly from an executive, requesting an urgent, confidential wire transfer.
• Brand impersonation — mass campaigns sent in a company's name, damaging its reputation and exposing its customers to fraud.

Each of these scenarios rests on the same basic vulnerability: historically, nothing prevented lying about the sender, and every downstream defense — training, filters, awareness campaigns — has had to compensate for that missing foundation.

How DMARC closes this gap

DMARC, paired with SPF and DKIM, tackles this problem head-on. SPF verifies the sending server is authorized for the domain; DKIM verifies the content hasn't been altered in transit via a cryptographic signature; DMARC ties the two to the visible From: domain and lets the legitimate domain tell receivers what to do with mail that fails this check — ignore it, send it to spam, or refuse it outright.

Where the fit between these three pieces isn't yet clear, SPF, DKIM and DMARC explained together covers the mechanics from the ground up. The key point to remember here: a domain without DMARC at an enforcing policy (p=quarantine or p=reject) remains technically spoofable, exactly as it was before the protocol existed.

Spoofing continues even with DMARC: what it doesn't cover

Honesty about the limits matters. DMARC at p=reject prevents direct spoofing of one exact domain — nobody can send a forged From: contact@example.com that reaches the inbox anymore. But it doesn't cover:

• Lookalike domains (typosquatting) — examp1e.com, example-secure.com — which are different domains, each with its own DMARC configuration, potentially absent.
• Display-name manipulation — an attacker can show "Example Company" on some random Gmail address; DMARC only applies to the address's real domain, not the visible text next to it.
• Compromised legitimate accounts — if an attacker obtains the credentials of a real mailbox, DMARC has nothing to object to: the message goes out genuinely authenticated.

That's why complete protection combines DMARC (against direct domain spoofing) with human vigilance, training for teams exposed to wire transfers and payments, and lookalike-domain detection tools (against the rest). The topic is developed in preventing email spoofing, which covers the full range of attack angles beyond DMARC alone.

How to know whether a domain is spoofable today

The question checks out directly: a domain with no DMARC record, or one at p=none, is spoofable — anyone can send an email claiming to come from it, and most recipients will see no warning. It's a binary, quick test to run, requiring no particular technical skill — and it's the first question to settle, before even deciding which DMARC policy to aim for, since there's no point debating quarantine versus reject on a domain that isn't even publishing a record yet.

Publishing a record at p=none has a second, less obvious benefit: it turns the invisible into the measurable. Within days, the aggregate reports that receivers send back show whether anyone is actually attempting to spoof the domain, from where, and at what volume. Many organizations assume they're not interesting enough to be targeted — until the first week of reports proves otherwise. That evidence usually does more to unlock internal priorities and budget than any abstract warning about risk ever could, and it sets the baseline needed later, when the question becomes whether the legitimate sources are aligned enough to harden the policy.

A concrete example, step by step

To make the mechanics tangible, here's what happens technically when an attacker spoofs an email, broken down:

1. The attacker picks a target — say accounting@target-company.com, an address they spotted on the company website or in an email signature intercepted elsewhere.
2. They configure their own sending server (or use a poorly secured bulk-sending service) to write that address into the From: field of the message they're about to send. No authorization is requested at this step — it's a free-text field.
3. They write a credible message — often mimicking the tone and format of real internal communication, sometimes after studying the company's org chart via LinkedIn or other public sources.
4. The message goes out to its real target, say an accountant or an executive assistant.
5. The receiving server gets the message. Without DMARC enforced, it has no reliable way to verify the sending domain matches the authorized one — the message is delivered normally, looking like a legitimate internal email.
6. The victim, seeing an address that looks correct, acts — clicks a link, opens an attachment, or worse, initiates a wire transfer following instructions that appear to come from leadership.

Every step of this chain is trivial to execute with free, public tools, none of which require any prior compromise of the target's systems. It's precisely this absence of a technical barrier that explains why spoofing remains, decades after email's invention, one of the most-used attack vectors — far more so than hacking that requires exploiting a software flaw, rare and expensive to discover.

Why attackers prefer spoofing to hacking

A point often underestimated: from a purely economic standpoint, spoofing is almost always more profitable for an attacker than actually compromising a system. Hacking a mail server takes skill, time, and exposes the attacker to a much higher risk of detection. Spoofing an email takes a basic SMTP server and a list of target addresses gathered publicly. That return on investment explains the phenomenon's prevalence — and, implicitly, why the most effective defense isn't chasing every individual attacker, but closing the structural flaw that makes the attack possible at scale, which is precisely what DMARC does. Awareness training helps individual employees recognize a suspicious message; DMARC removes the attack surface for an entire domain at once, which is why the two are complementary rather than substitutes for each other.

In summary

Email spoofing isn't a recent security flaw or a sophisticated exploit — it's a direct consequence of a decades-old protocol's design, one that never built in native identity verification. DMARC, resting on SPF and DKIM, closes that gap for direct domain spoofing — the most credible and most damaging form, since it uses the exact identity rather than an approximate imitation the victim might spot at a glance if they looked closely.

Finding out whether a domain is spoofable today takes one pass through the free DMARC analyzer — a direct, unambiguous test that settles in seconds whether the door is open or closed, and if it's open, what the first concrete step to close it looks like — usually publishing a monitoring-only record and reading what comes back.