Defaults.Exposed

Defaults.Exposed › Reports

Email Spoofing Explained: Why 90.7% of Domains Can Be Forged

Published

Email spoofing is the forging of the sender address on an email so a message appears to come from a domain it did not come from. It works because the internet’s core mail protocol, SMTP, never required senders to prove who they are — and because most domains still publish no record instructing receiving servers to reject forgeries. The August 2026 census of 376,928,750 graded domains finds that 341,945,132 of them — 90.7% — have no enforcing DMARC policy, which is the definition of a domain that can be spoofed. 214,276,774 (56.8%) publish neither SPF nor DMARC at all.

Email spoofing is not a sophisticated attack. It requires no compromise of your mail server, no stolen password, no malware. An attacker with a sending service and your domain name can put your domain in the From field of a message and send it to your customers, your staff, or a government agency. Whether that message is delivered is decided almost entirely by three DNS records — SPF, DKIM, and DMARC — that most of the internet has never fully published.

This report explains how email spoofing works at the protocol level, how to detect a spoofed message from its email headers, and which anti-spoofing controls actually close the gap. Throughout, it measures the real scale of the exposure using the defaults.exposed August 2026 census: a scan of 432,127,908 domains, 376,928,750 of which were graded, measured as of 2026-08-16.

What Is Email Spoofing?

Email spoofing is any technique that forges the apparent origin of an email. The recipient sees a message that looks like it came from a trusted domain or person. It did not.

Spoofing is the delivery mechanism; phishing is usually the goal. Phishing is the attempt to trick a recipient into revealing credentials, approving a payment, or opening a malicious attachment. A phishing email is far more persuasive when it appears to come from a domain the target already trusts — their bank, their employer, a supplier. Email spoofing is what supplies that appearance. Not every phishing email is spoofed, and not every spoofed email is phishing, but the two travel together: spoofing removes the recipient’s first and strongest defence, which is recognising an unfamiliar sender.

It helps to separate the main techniques, because they are stopped by different controls.

Exact-domain spoofing. The attacker puts your real domain — yourcompany.com — in the From header. This is the purest form of spoofing and the one email authentication was designed to stop. If your domain publishes an enforcing DMARC policy, this attack fails at the receiving server. If it does not, the forged message is indistinguishable from a genuine one.

Display-name spoofing. The attacker sends from an address they control — [email protected] or a throwaway domain — but sets the human-readable display name to “Your Company Finance” or the name of your CEO. Most mail clients show the display name prominently and hide the actual address, especially on mobile. Display-name spoofing does not forge your domain at all, so SPF, DKIM, and DMARC cannot catch it — which is exactly why attackers fall back to it once a target’s domain is properly locked down. It is defeated by user training and by mail-gateway rules that flag external senders impersonating internal names, not by DNS records.

Domain impersonation (lookalike and typosquat domains). The attacker registers a domain that reads like yours at a glance — yourcompany-invoices.com, yourc0mpany.com, yourcompany.co instead of .com — and authenticates it perfectly. Every check passes, because the attacker owns the lookalike domain. This is domain impersonation rather than true spoofing, and it is a growing share of real-world attacks precisely because it sidesteps email authentication. Defences here are brand monitoring, lookalike-domain registration, and recipient vigilance.

The distinction matters because a domain owner who deploys DMARC has closed the first category completely and forced attackers into the second and third, which are noisier, costlier, and easier for a trained recipient to spot. Authentication does not make you unspoofable in every sense. It makes exact-domain spoofing — the most convincing kind — impossible.

How Email Spoofing Works: SMTP, Envelopes, and Forged Headers

To understand why spoofing is so easy by default, you have to look at how a message is actually sent.

Email is delivered over SMTP, the Simple Mail Transfer Protocol. SMTP was standardised in 1982, in an era when every host on the network was known and trusted. It has two separate notions of “who sent this,” and an attacker exploits the gap between them.

The first is the envelope sender, transmitted in the SMTP MAIL FROM command during the delivery conversation between servers. This is the address that bounce messages return to. The receiving server sees it, but the recipient almost never does.

The second is the From header inside the message body — the address the recipient’s mail client displays. This is a completely separate field, written by the sender, and SMTP does nothing to require that it match the envelope sender or that the sender is authorised to use it. An attacker simply writes From: [email protected] into the message. There is no protocol-level check, at the point of sending, that stops them.

A third field, Reply-To, compounds the problem. An attacker can spoof your domain in the visible From header to earn trust, then set Reply-To to an address they control, so that when the victim hits reply, the conversation quietly moves to the attacker. Reply-To abuse is a hallmark of business email compromise.

So the forgery itself is trivial. What determines whether the forged message reaches the inbox is what happens at the receiving server — and that is entirely governed by the DNS records the spoofed domain has (or has not) published. This is the crucial point: you do not defend against spoofing by securing your own outbound mail. You defend against it by publishing DNS records that let every receiving server in the world reject mail that forges your domain. If those records are absent, the receiver has nothing to check against, and the open door stays open.

The Scale of the Exposure: What the Census Measures

Because email authentication lives in public DNS records, its adoption is directly measurable at internet scale. The August 2026 census graded 376,928,750 domains. Here is the anti-spoofing posture of the web, laid out on a single denominator.

CohortDomainsShare of gradedMeaning for spoofing
Neither SPF nor DMARC214,276,77456.8%Trivially spoofable — no signal at all
Publish SPF146,413,29738.8%Declares senders, but does not stop forgery alone
Publish any DMARC75,571,24820.0%Policy exists; may not be enforcing
DMARC at p=none only40,541,89610.8%Monitoring only — spoofed mail still delivered
No enforcing DMARC (spoofable)341,945,13290.7%Receivers have no instruction to reject forgeries
Enforcing DMARC (p=quarantine or p=reject)34,983,6189.3%Forged mail is quarantined or rejected

The headline is the 90.7%. On this site, “spoofable” has a precise meaning: a domain lacking an enforcing DMARC policy, because without one there is no published instruction telling a receiving server to reject mail that fails authentication. By that definition, more than nine in ten graded domains can be spoofed.

The 56.8% figure is the sharper subset — 214 million domains that publish nothing, neither SPF nor DMARC. Many of them are parked, dormant, or web-only domains whose owners assume that not sending email means not needing email security. That assumption is the single most exploited gap in the dataset. A domain that has never sent legitimate mail has, by definition, never been hardened, and it carries the full trust of its brand when an attacker forges it. (We examine that cohort in detail in The Silent Domain.)

Even the SPF majority is thinner than it looks. Of the 146,413,297 domains that publish SPF, 82,539,695 — 56.4% — end their record in a soft fail (~all), which asks receivers to accept suspicious mail and merely mark it. In most real deployments soft fail behaves like a pass. Only 56,268,491 SPF publishers use hard fail (-all), the setting that actually instructs rejection. SPF was never designed to stop spoofing on its own; it lists authorised senders, but says nothing about the visible From header the recipient reads. That is DMARC’s job, and DMARC is where the funnel collapses.

How to Detect a Spoofed Email

Detection happens at two levels: automatically, at the receiving mail server, and manually, by a suspicious human reading the message.

Automatic detection is exactly what SPF, DKIM, and DMARC provide. When a message arrives, a compliant receiver checks whether it passes SPF (did it come from an authorised server?) and DKIM (is its cryptographic signature valid and unbroken?), and then applies DMARC alignment: does the domain that passed SPF or DKIM match the domain in the visible From header? If neither aligns and the domain publishes an enforcing DMARC policy, the message is quarantined or rejected. This is why authentication is the primary anti-spoofing control — it moves detection off the end user and onto every receiving server automatically.

Manual detection is what remains when a message slips through — because it exploited display-name spoofing, a lookalike domain, or a target domain with no enforcing policy. The signals a trained recipient can check:

The email headers are the ground truth. Everything a mail client shows in its tidy summary view is a rendering of fields any sender can write; the Authentication-Results header records what the receiving server actually verified. Teaching staff to read that one line is one of the cheapest anti-spoofing controls available.

Anti-Spoofing Controls: SPF, DKIM, and DMARC

Three published standards, deployed together, close the exact-domain spoofing gap. Each does one job, and the protection comes from the combination.

SPF (Sender Policy Framework, RFC 7208) is a DNS TXT record listing the servers authorised to send mail for your domain. It ends in a qualifier: -all (hard fail — reject anything from an unlisted server) or ~all (soft fail — accept but flag). SPF alone does not stop spoofing, because it validates the envelope sender, not the From header the recipient sees, and because most records use the weaker soft fail. It is a necessary input to DMARC, not a defence by itself.

DKIM (DomainKeys Identified Mail, RFC 6376) attaches a cryptographic signature to each outbound message, using a private key held by your mail infrastructure and a public key published in your DNS records. The receiver verifies the signature; if the message was altered in transit or did not originate from a holder of your key, verification fails. DKIM proves message integrity and authorised origin, but on its own it gives receivers no policy instruction about what to do with a failure.

DMARC (RFC 7489) is the record that ties the other two together and makes them enforceable. Published as a TXT record at _dmarc.yourdomain, it does three things: it requires alignment, so that the domain passing SPF or DKIM must match the domain in the visible From header — which is what finally protects the field the recipient actually reads; it publishes a policy — p=none (monitor), p=quarantine (send to spam), or p=reject (refuse) — telling every receiver what to do with unaligned mail; and it provides a reporting address (rua=) so you receive aggregate feedback on who is sending as your domain.

Only p=quarantine and p=reject are enforcing. This is where the internet stalls. Of the 75.6 million domains that publish DMARC, 40,541,896 — more than half — sit at p=none: a monitoring posture that generates reports but tells receivers to take no action. A domain at p=none is not protected against spoofing. It has bought the alarm and left it switched off. Moving from p=none to p=quarantine is a single DNS edit, and it is the single highest-leverage anti-spoofing action available to the ~40 million domains already in that cohort. (We trace that specific gap in DMARC Gap: 87 Million Domains One Record From Safety.)

The complete anti-spoofing posture, then, is: SPF with -all, DKIM signing on every legitimate sending service, and DMARC advanced to p=reject. For a domain that sends no mail at all, the same protection is even simpler — publish v=spf1 -all, a null MX record, and v=DMARC1; p=reject; sp=reject, and every forged message fails alignment and is rejected. Only 10,902,284 domains (2.9%) currently meet the census’s full-protection bar of SPF, enforcing DMARC, DNSSEC, HTTPS, and HSTS together — the cohort that has closed the common attack surfaces at once.

From Spoofing to Business Email Compromise

The reason email spoofing matters commercially is BEC — business email compromise. BEC is the class of attack in which a forged or impersonated email induces an organisation to send money or sensitive data to an attacker. The FBI’s Internet Crime Complaint Center has for years ranked BEC among the highest-loss categories of cybercrime, consistently ahead of ransomware in reported dollar losses, precisely because it needs no malware — only a convincing email.

The mechanics run straight through the gaps described above. An attacker spoofs a supplier’s domain (or impersonates it with a lookalike), sends an invoice with altered banking details, adds urgency and a Reply-To they control, and waits for the payment to route to their account. If the supplier’s domain has no enforcing DMARC — and at 90.7% of graded domains, the odds are that it does not — the receiving mail server has no basis to reject the forgery, and the message lands in the accounts-payable inbox looking exactly like every genuine invoice before it.

That is why email authentication is not only an IT hygiene task but a financial control. A domain with p=reject cannot be exactly-spoofed, which eliminates the most convincing version of the invoice-fraud attack against everyone who receives mail from it — your customers and suppliers included. We examine the accounts-payable side of this in Invoice Fraud Prevention: Closing the Domain-Spoofing Gap Behind BEC.

What this means

For business owners, the practical takeaway is that email spoofing is a solved problem you may simply not have applied. The forgery is trivial and free for the attacker; the defence is three DNS records and free for you. If your domain publishes an enforcing DMARC policy, nobody can send exact-domain spoofed mail as you — full stop. If it does not, you are in the 90.7% majority whose domain can be forged at will, and the first you will hear of it is a customer or supplier asking about an email you never sent. Every domain you own, including the ones you don’t send mail from, should be checked and closed.

For IT and security teams, the enforcement gap is the actionable number. The distance between the 20.0% of domains that publish any DMARC and the 9.3% that enforce it is roughly 40 million domains that have done the hard part and stopped one edit short. If that describes your domain — DMARC published, sitting at p=none, reports arriving — the reporting data already tells you whether your legitimate senders are aligned. If they are, move to p=quarantine, then p=reject. Separately, audit your SPF records for the soft-fail trap: a ~all terminator behind an enforcing DMARC policy delivers less protection than the policy implies, because most receivers treat soft fail as a pass.

For compliance and risk teams, email authentication is now a measurable control that external frameworks expect. The Google and Yahoo bulk-sender requirements have mandated SPF, DKIM, and DMARC for high-volume senders since 2024; CISA’s guidance sets p=reject as the federal target; and the EU NIS2 directive’s baseline expectations, as elaborated by ENISA, include SPF, DKIM, and DMARC at enforcement. “The domain can be spoofed and we have no published policy” is not a defensible posture in any of them. The absence of an enforcing DMARC record is a documented gap, and it is one an assessor can verify from outside your network in seconds — the same way this census did, 376 million times.

FAQ

What is email spoofing in simple terms? Email spoofing is forging the sender address on an email so it appears to come from a person or domain it did not come from. The internet’s mail protocol, SMTP, lets any sender write any address into the visible From field without proving they own it. Whether a forged message is delivered depends on whether the spoofed domain has published an enforcing DMARC policy — and in the August 2026 census, 90.7% of graded domains had not.

How is email spoofing different from phishing? Phishing is the goal — tricking someone into revealing a password, approving a payment, or opening a malicious file. Spoofing is a technique that makes phishing more convincing by forging a trusted sender. Not all phishing uses spoofing and not all spoofing is phishing, but they frequently combine: a spoofed sender removes the recipient’s first defence, which is recognising an unfamiliar address.

Can email spoofing be stopped completely? Exact-domain spoofing — forging your real domain in the From field — can be stopped completely by publishing an enforcing DMARC policy (p=quarantine or p=reject) alongside SPF and DKIM. That forces attackers onto weaker techniques: display-name spoofing (using their own address with your name as the label) and lookalike domains, both of which are noisier and easier for a trained recipient to catch. Authentication makes the most convincing form of spoofing impossible.

How do I check whether an email is spoofed? Open the full email headers (“Show original” in Gmail) and read the Authentication-Results line, which records the receiving server’s spf=, dkim=, and dmarc= verdicts. A message claiming to be from a major brand but showing fail or none is suspect. Also read the actual sender address rather than the display name, and watch for a Reply-To that differs from the From.

Does SPF alone stop email spoofing? No. SPF lists which servers may send for your domain, but it validates the hidden envelope sender, not the visible From header the recipient reads, and 56.4% of SPF records use the weaker soft-fail setting that most receivers treat as a pass. SPF is a necessary input to DMARC, which is the record that actually protects the From header and instructs receivers to reject forgeries.

Why do so many domains remain spoofable? Cost is not the reason — the records are free and the domains in question have already proven they can edit DNS. The census points to three causes: mail-provider setup wizards prompt for SPF but rarely for DMARC, so the checklist ends early; domains that publish DMARC at p=none to monitor first often never schedule the move to enforcement; and most owners have simply never been told their domain can be spoofed. The barrier is awareness, not difficulty.

Data to cite

See where your own domain stands

Email spoofing is one of the few internet-scale threats with a free, permanent, do-it-this-afternoon fix — and 90.7% of domains have not applied it, mostly because no one told their owners it was open. You can check any domain you own privately and see exactly which anti-spoofing records it publishes, which it is missing, and whether its DMARC policy is actually enforcing.

Check your domain free at defaults.exposed — see instantly whether your domain can be spoofed, what its SPF, DKIM, and DMARC records say, and every check that is failing. Takes 30 seconds. No account needed. If you would rather have the gaps closed for you, see how the fix works.

Read the flagship census report: The State of Domain Security 2026 →

Related from this series: The Silent Domain · DMARC Gap: 87 Million Domains One Record From Safety · The Google-and-Yahoo Deadline, Two Years On

Aggregate data only. Data stored and processed in the EU.

Data source: defaults.exposed August 2026 census, methodology v9, as of 2026-08-16. 376,928,750 domains graded from 432,127,908 scanned. All figures are counts of graded domains unless otherwise noted. References: RFC 7208 (SPF), RFC 6376 (DKIM), RFC 7489 (DMARC), RFC 7505 (null MX), CISA Binding Operational Directive 18-01, EU NIS2 Directive 2022/2555, Google/Yahoo bulk sender requirements (February 2024).

How to cite this report

Press / blog: defaults.exposed (2026). Email Spoofing Explained: Why 90.7% of Domains Can Be Forged. defaults.exposed August 2026 Domain Security Census (432,127,908 domains scanned, asOf 2026-08-16). Retrieved from https://defaults.exposed/v9/articles/email-spoofing-explained-why-90-7-of-domains-can-be-forged

Academic: defaults.exposed. (2026, August 21). Email Spoofing Explained: Why 90.7% of Domains Can Be Forged. In defaults.exposed Domain Security Census: August 2026. https://defaults.exposed/v9/articles/email-spoofing-explained-why-90-7-of-domains-can-be-forged

In-line citation: (defaults.exposed, August 2026 Domain Security Census, n=376,928,750 graded domains)

About the defaults.exposed August 2026 Census

The defaults.exposed Domain Security Census is a recurring independent measurement of the public domain namespace. The August 2026 edition scanned 432,127,908 domains between 1–16 August 2026 and graded 376,928,750 of them using methodology v9. Scans are conducted from EU infrastructure. No individual domain, registrant, or business is named in any report. All figures are aggregate distributions. Data is stored and processed within the EU.

Methodology: defaults.exposed/v9/methodology Full census report: defaults.exposed/en/articles/the-state-of-domain-security-2026

Data sourced from the August 2026 grading methodology (v9) — 34 checks, 376 million domains. Browse the census statistics or the Census Explorer, or see all August 2026 research →