Why your domain can be spoofed, and how to stop it

12 June 2026 · 14 min read

If you own a domain and have never published a DMARC record, anyone on the internet can send email that appears to come from you. Not a clever lookalike, not a slightly-off variation, but your exact address: accounts@yourcompany.com, ceo@yourcompany.com, invoices@yourcompany.com. They do not need your password. They do not need to break into your mail server. They do not need anything from you at all. The design of email permits this by default, and the only thing that stops it is a small set of DNS records that you, the domain owner, have to publish.

This article explains, in plain terms, exactly how that spoofing works at the level where email actually moves between servers, why a domain with no DMARC is wide open, and which records close the gap. You do not need to be a mail administrator to follow it. By the end you will understand what an attacker actually does, why your inbox provider cannot save you on its own, and what you need to publish to make exact-domain spoofing fail.

What "spoofing" really means

When people say their domain was "spoofed", they usually mean one specific thing: someone sent an email where the visible From address showed their domain, even though the email did not come from them or from any system they authorised.

It helps to be precise about which "from" we are talking about, because email has more than one.

The envelope sender (also called the Return-Path or MAIL FROM) is the address the sending server announces during the SMTP conversation. Bounces go here. Recipients almost never see it.
The header From is the address your mail client displays as the sender. This is the one a human reads and trusts.

These two can be completely different, and nothing in the basic email protocol requires them to match. An attacker can put their own throwaway address in the envelope sender and put your domain in the header From. The recipient sees only the header From, so to them the message looks like it came from you.

That gap, between the address the machine negotiates and the address the human sees, is the entire foundation of exact-domain spoofing.

How email actually moves: the SMTP conversation

To understand why spoofing is so easy, you have to see how plain a normal email handover is. SMTP, the protocol that carries mail between servers, is a short text conversation. A sending server connects to a receiving server and they exchange a handful of commands. Stripped down, it looks like this:

HELO mail.attacker-host.example
MAIL FROM:<bounces@attacker-host.example>
RCPT TO:<victim@theircompany.com>
DATA
From: "Your Company Billing" <billing@yourcompany.com>
To: victim@theircompany.com
Subject: Updated bank details for your next invoice

Please send all future payments to the account below...
.

Look closely at what happened. The MAIL FROM line, the envelope sender, points at the attacker's own host. But inside the message body, after DATA, the From: header claims to be billing@yourcompany.com. The receiving server is being told one thing by the envelope and shown another thing in the header.

Crucially, nothing in this exchange proves the sender is allowed to use yourcompany.com. SMTP was designed in the early 1980s for a small, trusting network. It has no built-in identity check. Any server on the internet can type any address it likes into that From: header. The protocol will not stop it. The receiving server will accept the bytes exactly as typed.

This is not a bug in any one product. It is how the base protocol works. The header From is, by default, an unverified claim, like the return address you scribble on the back of an envelope. The postal service does not check it, and neither does raw SMTP.

So the honest answer to "why can my domain be spoofed?" is: because the protocol lets the sender write your name on the envelope, and unless you have published records that tell receivers how to check that claim, they have nothing to check it against.

Why your email provider does not stop this for you

A reasonable reaction is: surely Gmail, Microsoft 365, or whoever runs the recipient's mailbox should catch this? They do try, but there are hard limits on what they can do without your help.

When a message claiming to be from yourcompany.com arrives at a receiving server, that server wants to ask a simple question: "Is the system that sent this actually authorised to send for yourcompany.com?" The only authoritative place to look up the answer is your DNS, because DNS for your domain is something only you control. If you have not published any policy there, the receiving server has nowhere to look. It is left guessing based on spam heuristics: reputation of the sending IP, content patterns, whether the message looks like previous junk.

Heuristics are probabilistic. A careful attacker who sends a small volume of clean-looking, well-written mail from a fresh, unblocked IP can sail straight past them. There is no signal in the message itself that says "this is forged", because as far as the receiving server can tell, the From address is just text and there is no published rule saying that text must be backed by anything.

This is the key insight for non-experts: the protection has to come from the domain owner, published in the domain owner's DNS. The recipient's provider can only enforce a rule that you have actually stated. No rule, nothing to enforce.

You can see exactly what your domain currently tells the world by running it through the free DMARC checker. If it reports no record, that is precisely the open door this article is about.

The three records that close the door

Three standards work together to turn the From address from an unverified claim into something a receiver can check and act on: SPF, DKIM, and DMARC. They are all published as DNS records on your domain. Think of them as three layers:

SPF says which servers are allowed to send mail for your domain.
DKIM lets receivers verify a message genuinely came from your domain and was not tampered with, using a cryptographic signature.
DMARC ties the first two to the visible From address and tells receivers what to do when a message fails: monitor it, quarantine it, or reject it outright.

SPF and DKIM on their own are necessary but not sufficient, for a reason we will come to. DMARC is the piece that actually shuts down exact-domain spoofing. Let us take them in turn.

SPF: a list of who may send

SPF, the Sender Policy Framework, is a TXT record in your DNS that lists the servers permitted to send email using your domain. A simple one looks like this:

v=spf1 include:_spf.google.com include:sendgrid.net -all

In plain English: "Mail for this domain should come from Google's servers or SendGrid's servers. Anything else, reject (-all)."

When a receiving server gets a message, it looks at the envelope sender domain, fetches that domain's SPF record, and checks whether the connecting server's IP address is on the approved list. If it is, SPF passes. If not, SPF fails.

SPF is genuinely useful, but notice its blind spot. SPF checks the envelope sender, not the header From that the human reads. Remember the attacker's SMTP conversation: they put their own host in MAIL FROM and your domain only in the header From:. SPF, checking the envelope, sees the attacker's own domain, which may well have its own valid SPF record. SPF passes, for the attacker's domain, while your domain sits forged in the header where the recipient actually looks.

That is why SPF alone does not stop header-From spoofing. It guards the wrong "from". You can inspect any domain's SPF setup, including the lookup limits SPF imposes, with the SPF checker. SPF is still worth getting right, and our SPF product keeps the record valid and within limits automatically, but on its own it is half the wall.

DKIM: a tamper-proof signature

DKIM, DomainKeys Identified Mail, takes a different approach. Instead of listing IP addresses, it attaches a cryptographic signature to each outgoing message. Your sending system holds a private key; a matching public key is published in your DNS. The receiving server fetches the public key and verifies the signature.

A valid DKIM signature proves two things: the message really was signed by something holding your domain's private key, and specific parts of the message (typically including the From header and body) were not altered in transit. The signature names a domain, called the DKIM d= domain, and that is the identity DKIM authenticates.

DKIM is strong, but it has its own gap when used alone. An attacker can simply not sign the message at all, or sign it with their own domain's DKIM key. A message can carry a perfectly valid DKIM signature for attacker-domain.example while the header From still says yourcompany.com. DKIM, by itself, does not insist that the signing domain has anything to do with the domain in the From address. You can verify a domain's published DKIM keys with the DKIM checker, and let our DKIM product handle key publishing and rotation.

So both SPF and DKIM can pass for a message that is still forging your visible From address, because each one authenticates a different identity (the envelope sender for SPF, the signing domain for DKIM) and neither is required to match the header From. This is the crucial weakness that DMARC was created to fix.

DMARC: tying it all to the visible From

DMARC, Domain-based Message Authentication, Reporting and Conformance, is the record that finally connects SPF and DKIM to the address the human actually sees. It adds two things the others lack: alignment and a published policy.

A DMARC record is a TXT record at _dmarc.yourcompany.com and looks like this:

v=DMARC1; p=reject; rua=mailto:reports@yourcompany.com

Here is what DMARC does that the others cannot.

Alignment. DMARC tells the receiver: do not just check that SPF or DKIM passed for some domain; check that the domain they passed for matches the domain in the header From. A message passes DMARC only if at least one of these is true:

SPF passed and the envelope sender domain aligns with the header From domain, or
DKIM passed and the signing (d=) domain aligns with the header From domain.

Now reconsider the attacker. Their envelope sender is attacker-host.example, so even though SPF passes for that domain, it does not align with yourcompany.com in the header From: SPF alignment fails. They have no access to your private key, so they cannot produce a DKIM signature whose d= is yourcompany.com: DKIM alignment fails. Both legs fail. The message fails DMARC.

Policy. The p= tag tells receivers what to do with a message that fails:

p=none: take no special action, just observe and report. This is monitoring only.
p=quarantine: treat failing mail as suspicious, typically deliver to spam.
p=reject: refuse the message outright; it never reaches the inbox.

With p=reject published and aligned authentication in place, the attacker's forged message is rejected by every major receiver that honours DMARC, which today includes Gmail, Yahoo, Microsoft and the rest of the large mailbox providers. That, finally, is how exact-domain spoofing of your domain is stopped: not by hoping a spam filter notices, but by you publishing a rule that says "if it claims to be us and cannot prove it, throw it away", and the world's mailbox providers enforcing it.

You can check whether a domain currently publishes DMARC, and at what policy, with the DMARC checker. For a deeper look at every tag and what it means, see understanding your DMARC record.

Why so many domains are still wide open at p=none

If DMARC at p=reject is the answer, why are so many domains spoofable? Because most domains either have no DMARC record at all, or they have one stuck at p=none, which monitors but does not block. A policy of p=none is reporting only: it tells you about forgeries after the fact but does nothing to stop them. To an attacker, p=none is functionally the same as no policy.

Domains get stuck at p=none for an understandable reason: fear of breaking legitimate mail. Moving straight to p=reject without first checking your own sending sources can cause your real email (newsletters, invoicing systems, helpdesk tools, that one marketing platform a colleague set up years ago) to fail authentication and get rejected along with the forgeries. The cautious thing is to start at p=none, watch the reports, fix your legitimate senders so they align, and only then tighten the policy. The mistake is stopping at the cautious first step and never finishing the journey.

This is exactly the problem DMARC Engine exists to solve. The hard part is not publishing a record; it is getting safely from p=none to p=reject without an email outage. We do that by analysing your real traffic, identifying every legitimate sender, getting them aligned, and stepping the policy up only when the data shows it is safe. The detailed walkthrough is in how to reach p=reject without breaking email.

Reading the evidence: DMARC reports

One of the quietly brilliant parts of DMARC is the rua tag, which asks receivers to send you aggregate reports. Every day, mailbox providers send back XML summaries of the mail they saw claiming to be from your domain: which IPs sent it, whether SPF and DKIM passed, and whether the results aligned.

These reports are how you discover two things at once: every legitimate system that sends as you (some of which you have probably forgotten about), and every source forging your domain. They are the map you use to move safely toward enforcement, because they show you what would be blocked before you turn blocking on.

Raw DMARC XML is not pleasant to read by hand. The free DMARC report analyzer turns those files into a readable picture of who is sending as you. If your reports look empty when you expected data, the usual causes are covered in why my DMARC reports are empty.

Two more records worth knowing

DMARC, SPF and DKIM are the core defence against From-address spoofing. Two further standards harden the surrounding area.

MTA-STS protects the transport rather than the sender identity. It tells sending servers to require an encrypted, properly authenticated TLS connection when delivering mail to your domain, which closes off a class of attacks where a network attacker downgrades or intercepts mail in transit. You can test a domain's policy with the MTA-STS checker, and our MTA-STS product hosts the policy and certificate for you.

BIMI is the visible reward for getting authentication right. Once you reach an enforced DMARC policy, BIMI lets your verified logo appear next to your messages in supporting inboxes, which both reinforces your brand and gives recipients a genuine, authentication-backed visual cue. Check a domain's setup with the BIMI checker or read about the BIMI product. BIMI deliberately requires DMARC enforcement first, which is a neat illustration of the whole point: the visible trust signal is only granted to domains that have actually closed the spoofing door.

What this looks like as a checklist

If you take nothing else away, here is the concrete sequence that turns an open, spoofable domain into a protected one.

Find out where you stand. Run your domain through the DMARC checker. No record, or p=none, means you are currently spoofable at the exact-domain level.
Publish SPF correctly. List every legitimate sending service and end with a firm -all. Watch the ten-lookup limit; verify with the SPF checker.
Enable DKIM on every sender. Each platform that sends as you should sign with a key published in your DNS. Confirm with the DKIM checker.
Publish DMARC at p=none with rua reporting. This breaks nothing and starts the flow of evidence.
Read the reports. Use the DMARC report analyzer to find every legitimate sender and confirm each one aligns.
Fix alignment, then raise the policy. Move to p=quarantine, then p=reject, only when the data shows your real mail is safe.
Harden transport and unlock branding. Add MTA-STS, and once enforced, BIMI.

The order matters. Steps 4 to 6 are where domains stall, and they are also where a single mistake can drop legitimate mail. This is precisely the work DMARC Engine automates so you do not have to interpret XML by hand or guess when it is safe to tighten the screw. You can see the major mailbox-provider rules that make this urgent in Gmail, Yahoo and Microsoft now require DMARC, and a practical starting path in getting started. When you are ready, adding a domain takes a few minutes.

The short version

Your domain can be spoofed because the email protocol lets any server on the internet type your address into the visible From header, and unless you have published rules saying that claim must be backed by proof, receiving servers have nothing to check it against. SPF and DKIM each verify a different identity and can both pass while your From address is still forged. DMARC is the record that ties authentication to the visible From through alignment, and at p=reject it instructs the world's mailbox providers to throw forged mail away.

The open door is closed not by your mailbox provider and not by luck, but by records you publish in your own DNS. The free DMARC checker will tell you in seconds whether that door is currently open. For the underlying products that keep DMARC, SPF and DKIM correct and move you safely to enforcement, and for the exact email-provider deadlines driving all of this, see the requirements and the glossary if any term here is new.