Last verified: August 5, 2026
Spoofed Emails Using Your Domain: What Is Actually Happening
TL;DR
When messages start reaching people that appear to come from a company's domain but were never sent by anyone at that company, the domain is being spoofed. This is not a rare stunt by sophisticated attackers; it is a routine consequence of how email was designed, and it quietly damages sender reputation, customer trust, and inbox placement long before anyone inside the organization notices.
What Does Domain Spoofing Actually Mean?
Domain spoofing refers to the forgery of the "From" address on an email so that the message appears to originate from a legitimate domain when it does not. The email protocol that carries most business mail, SMTP, was written in an era when trust between mail servers was assumed. Nothing in the base protocol prevents a sender from typing any address they want into the From field, in the same way nothing prevents a person from writing a false return address on a paper envelope.
Attackers exploit this in two common ways. In exact-domain spoofing, the visible From address matches the real domain character for character (billing@examplebrand.com). In display-name or lookalike spoofing, the visible name matches a real employee or brand while the underlying address uses a similar but different domain (examp1ebrand.com, examplebrand-support.com). Both trade on the recipient's assumption that the From line is verified. Neither is verified by default.
The response to this design gap is a stack of three authentication standards: SPF (Sender Policy Framework) declares which mail servers are allowed to send for a domain, DKIM (DomainKeys Identified Mail) attaches a cryptographic signature that proves a message was not altered in transit, and DMARC (Domain-based Message Authentication, Reporting and Conformance) tells receiving mail servers what to do when SPF and DKIM checks fail, and asks them to send back reports on who is sending under the domain. The problem is not that these standards do not exist. The problem is that most domains do not fully enforce them.
Photo by Why Do Legitimate Domains Stay Exposed?
Most exposed domains are not exposed because the owners are careless. They are exposed because responsibility for email is split across teams that rarely coordinate.
DNS records typically live with IT or engineering. Marketing owns the campaign platform. Sales owns the outbound sequencer. Support owns the help-desk mailer. Finance owns the invoicing tool. Each function adds a new sender when it needs to, and each assumes that whoever manages DNS will handle the authentication side. In practice, no one is watching the seam. A conversation with a marketing lead frequently reveals three or four sending sources on the domain that no single person can fully list from memory.
Even where authentication records exist, they are often partial. Four failure patterns recur:
- DMARC published at p=none indefinitely. The record exists, which creates a sense of protection, but the policy tells receiving servers to take no action on failures. Without an analysis platform for the aggregate XML reports, the domain owner is effectively blind to who is sending on their behalf.
- DMARC stuck at partial enforcement (pct=). Enforcement is set to apply to a fraction of mail, or to quarantine rather than reject, because escalating without visibility risks blocking legitimate senders. Without aggregate reporting, the escalation never happens.
- SPF alignment silently broken by marketing platforms. A message can pass SPF against the sending platform's own domain while failing SPF alignment with the brand's domain, because the envelope sender resolves to the platform. DKIM alone carries the DMARC pass. The moment a DKIM issue appears, DMARC fails entirely.
- New sending tools added without updating DNS. A team onboards a new tool and starts sending. SPF is not updated to include it, no DKIM key is published for it, and mailbox providers begin receiving unauthenticated mail from the domain. Reputation erodes before anyone connects the drop to the new tool.
How Do Attackers Actually Use the Domain?
Spoofed mail from a legitimate-looking domain is used for phishing (harvesting credentials), business email compromise (redirecting invoice payments or wire transfers), and malware delivery. The specific pretext matters less than the fact that the recipient's mental model, "this came from a domain I recognize", does the work of persuading them to click, reply, or pay.
The mechanism looks like this in practice. The attacker composes a message with the target domain in the From field and sends it through any mail server that will accept the traffic. If the target domain has no DMARC record, or a DMARC record at p=none, the receiving mail server has no instruction to reject the message. It may deliver it, or route it to spam, but nothing stops delivery outright. Employees of partner companies, customers, prospects, and internal staff all become potential victims of mail that carries the domain's name.
What Does Spoofing Quietly Cost Before Anyone Notices?
The visible cost of a spoofing incident, the phishing email a customer forwards to support, is a small fraction of the total damage. Most of the cost accrues silently.
Mailbox providers judge a domain by the aggregate behavior of everything sent under it. When unauthenticated mail from the domain hits spam filters, is flagged by recipients, or triggers abuse reports, the domain's reputation degrades. Legitimate marketing sends, sales outreach, and transactional messages (password resets, receipts, onboarding sequences) all pay the price through lower inbox placement. Opens drop. Replies dry up. Support gets tickets asking why confirmation emails never arrived. The team investigates the campaign, the copy, the list, and misses that the underlying reputation problem is being fed by mail no one at the company ever sent.
The table below maps the observable symptoms a team is likely to notice against the underlying mechanism driving them.
| Observable symptom | Likely underlying condition | Where the visibility gap sits |
|---|---|---|
| Customers forward suspicious mail "from" the company | Domain accepts spoofed From, no DMARC reject | No aggregate DMARC reporting in place |
| Gradual decline in marketing opens with no content change | Reputation erosion from unauthenticated third-party senders | New tools added to stack without DNS updates |
| Transactional mail hitting spam despite clean list | SPF/DKIM misalignment on one sending source dragging the domain | No audit across all sending sources |
| Sales replies fall off across a whole outbound domain | Domain flagged by receiving providers | Cold, marketing, and transactional traffic sharing one reputation |
Which Signals Show a Domain Is Already Being Spoofed?
Several signals typically appear before an organization understands what is happening. Customers or partners report emails they did not send. Bounce notifications arrive for messages the company never composed, the artifact of a spoofing campaign whose forged mail is being rejected by receiving servers and returned to the domain. Abuse complaints spike from mailbox providers. Domain reputation scores in public reputation databases drop without a corresponding change in legitimate sending behavior. Aggregate DMARC reports, if they are being collected and read, show sending IP addresses the company does not recognize.
Any one of these signals in isolation is easy to dismiss. Together they describe a domain that is being used by parties it never authorized.
What Does a Protected Domain Look Like in Principle?
A protected domain is one where the owner can answer, at any moment, three questions: who is authorized to send mail as this domain, what happens to mail that is not authorized, and how would the owner know if that changed.
Answering the first question requires a current inventory of every sending source: the marketing platform, the sales sequencer, the help-desk mailer, the billing system, the internal notification service, the analytics tool that sends alerts, and any legacy sender still configured somewhere. Each source has SPF authorization, a DKIM key published under the domain, and alignment configured so that DMARC checks pass against the brand's domain rather than the sending platform's.
Answering the second question requires a DMARC policy at p=reject, reached through a deliberate escalation from p=none through p=quarantine, guided by aggregate report data so that legitimate senders are corrected before enforcement blocks them.
Answering the third question requires ongoing aggregate report analysis. Raw DMARC reports arrive as machine-readable XML, impractical to read by hand. Without a mechanism to parse and monitor them continuously, a new unauthorized sender can begin operating under the domain and remain undetected until reputation damage shows up in other metrics.
The domains that stay clean are not the ones whose owners set the records once and forgot them. They are the ones whose owners treat authentication as an operational discipline: every new sending tool triggers a DNS update, every DMARC report is reviewed, and enforcement is held at reject rather than allowed to drift back to none when a false alarm makes someone nervous.
Spoofing is not a problem that arrives with a dramatic breach announcement. It is a problem that arrives quietly, through a protocol that trusts the sender by default, and it persists because the work of closing the gap sits between teams that rarely talk to each other. Recognizing that is the first step toward closing it.