What is Domain Spoofing? How It Works and How to Stop It

Let me ask you a quick question — do you know who sent the last email "from" your domain?

If you're unsure, you're not alone. And that uncertainty is exactly what attackers bank on. Domain spoofing is one of those attacks that sounds technical but is devastatingly simple in practice. An attacker sends an email that looks like it came from your domain — your actual domain, not some misspelled version of it — and the recipient has no easy way to tell the difference.

I've been working in email security and PKI for over 20+ years now, and domain spoofing is one of those problems that I see businesses ignore until it's too late. By that point, a client has wired money to a fraudulent account, or a partner has lost trust in your communications. That's why I wanted to write this guide — to explain what domain spoofing actually is, how it works under the hood, and what you can practically do to stop it.

What Exactly is Domain Spoofing?

Domain spoofing is when someone forges the "From" address in an email to make it appear as though the message originated from a legitimate domain — usually yours. The email arrives in your client's or employee's inbox showing ceo@yourcompany.com in the sender field, but it was actually sent from an entirely different server that has nothing to do with your organization.

The reason this works is that the SMTP protocol — the foundation of how email is sent across the internet — was designed back in the 1980s. Authentication wasn't built into it. When you send an email, the "From" field is essentially self-declared. Think of it like writing any return address you want on a physical envelope. The post office doesn't verify it. Neither does SMTP, by default.

Domain Spoofing vs. Lookalike Domains — Know the Difference

People often confuse domain spoofing with lookalike (or cousin) domains. They're related but fundamentally different attacks.

Domain Spoofing is when an attacker uses your exact domain in the "From" header. The email says it's from accounts@yourdomain.com and the recipient sees exactly that. No typos, no tricks in the domain name itself.

Lookalike Domains involve registering a domain that looks similar — like yourd0main.com (with a zero) or yourdomain-support.com. These rely on the recipient not noticing the subtle difference.

Domain spoofing is arguably more dangerous because there's literally nothing visually "off" about the sender address. The protection against it has to be technical — which brings us to email authentication protocols.

Why Should You Care? The Numbers Tell the Story

The FBI's Internet Crime Complaint Center logged over 193,000 phishing and spoofing complaints in 2024 alone. And business email compromise — which almost always starts with a spoofed domain — caused around $2.9 billion in reported losses that same year.

These aren't theoretical risks. I've personally helped clients who discovered that someone was sending invoices to their customers using their exact domain name. The invoices looked completely legitimate because the sender address was real. The only thing that was fake was the person behind the email.

How Domain Spoofing Actually Works — A Technical Walkthrough

Let me walk you through how a domain spoofing attack actually plays out. It's simpler than most people think.

Step 1: The Attacker Sets Up a Mail Server

The attacker either sets up their own SMTP server or uses a compromised one. There are plenty of open-source tools available that let you configure an SMTP server in minutes. Some attackers even use legitimate email services with lax verification.

Step 2: They Craft the Spoofed Email

The attacker composes the email and manually sets the "From" header to your domain. The SMTP protocol allows this because, as I mentioned, the "From" field is just a text string — there's no built-in verification mechanism in plain SMTP.

Here's what the email headers might look like:

From: ceo@yourcompany.com
Reply-To: attacker@malicious-domain.com
To: finance@yourcompany.com
Subject: Urgent - Wire Transfer Authorization Required
MIME-Version: 1.0
Content-Type: text/html; charset=UTF-8

Notice the Reply-To is set to a different domain. But most email clients don't prominently display the Reply-To field — they show the "From" address. And that says yourcompany.com.

Step 3: The Email Reaches the Recipient

If the target domain (yours) doesn't have proper SPF, DKIM, and DMARC records — or if the DMARC policy is set to p=none — the receiving mail server has no instructions to reject or quarantine the spoofed message. It lands in the inbox looking completely legitimate.

Step 4: The Victim Acts on It

The recipient sees an email from their CEO asking for an urgent wire transfer. The domain checks out. There's no warning banner. They process the payment. By the time anyone realizes what happened, the money is gone.

The Different Flavours of Domain Spoofing

Domain spoofing isn't just one thing — attackers use it in several ways depending on their target and objective:

In this article, I'm focusing primarily on email-based domain spoofing because that's where the bulk of the damage happens — and where proper authentication can make an immediate difference.

How to Protect Your Domain from Spoofing

Now for the part that actually matters. There are three email authentication protocols that work together to prevent domain spoofing. If you've been following the email security space at all, you've heard of them: SPF, DKIM, and DMARC. Let me break down each one and explain how they fit together.

1. SPF (Sender Policy Framework)

SPF lets you publish a DNS record that specifies which IP addresses and mail servers are authorized to send email on behalf of your domain. When a receiving server gets an email claiming to be from your domain, it checks your SPF record. If the sending server's IP isn't listed, the SPF check fails.

Here's what a basic SPF record looks like:

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

That -all at the end is important — it tells receiving servers to reject emails from any server not listed in the record. A lot of domains still use ~all (soft fail), which only flags the email rather than blocking it. That's not enough.

2. DKIM (DomainKeys Identified Mail)

DKIM adds a digital signature to every outgoing email. The receiving server uses your public key (published in your DNS) to verify that the email hasn't been tampered with and that it was actually sent by an authorized server. If the signature doesn't match, DKIM fails.

DKIM doesn't prevent sending per se — it proves that the email content is authentic and unmodified. Think of it as a tamper-proof seal on a letter.

3. DMARC (Domain-based Message Authentication, Reporting, and Conformance)

This is where everything comes together. DMARC builds on top of SPF and DKIM by adding two critical things:

• Alignment: It checks that the domain in the "From" header matches the domain validated by SPF or DKIM. Without alignment, an attacker could pass SPF using their own domain while forging yours in the visible "From" field.

• Policy enforcement: It tells receiving servers what to do with emails that fail authentication — monitor them (p=none), send them to spam (p=quarantine), or block them entirely (p=reject).

Here's a DMARC record that actually protects your domain:

v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com; adkim=s; aspf=s; pct=100;

The key parameters here are p=reject (block failing emails), adkim=s and aspf=s (strict alignment), and rua (where aggregate reports are sent).

The DMARC Journey: From Vulnerable to

Protected

Here's how I typically guide clients through the DMARC implementation process:

1. Audit your current state — Run a DMARC record check on your domain. You can use our free DMARC Record Checker to see where you stand right now.

2. Publish a DMARC record with p=none — This starts the monitoring phase. You won't block anything yet, but you'll start receiving aggregate reports showing who's sending email as your domain.

3. Analyze your reports — This is where most people get stuck. Raw DMARC reports come in XML format and are nearly unreadable. A tool like SimpleDMARC parses these automatically and gives you a clear picture of your email traffic — legitimate senders, unauthorized sources, and authentication failures.

4. Fix SPF and DKIM for all legitimate senders — Make sure every service that sends email on your behalf (your email provider, marketing platform, CRM, ticketing system) is properly authenticated.

5. Move to p=quarantine — Once you're confident that all legitimate sources pass authentication, start quarantining failures. Monitor for any impact on delivery.

6. Enforce with p=reject — The final step. Emails that fail DMARC are now blocked before they reach anyone. Your domain is fully protected from spoofing.

Beyond DMARC: Additional Layers of Protection

DMARC is the foundation, but it's not the only thing you should do. Here are a few additional measures I always recommend:

MTA-STS (Mail Transfer Agent Strict Transport Security) — This ensures that emails sent to your domain are always encrypted with TLS during transit. Without MTA-STS, an attacker could perform a downgrade attack and intercept emails in plaintext.

TLS-RPT (TLS Reporting) — Works alongside MTA-STS by sending you reports when TLS negotiation failures occur. This gives you visibility into potential man-in-the-middle attacks.

BIMI (Brand Indicators for Message Identification) — Once you have DMARC enforced at p=reject or p=quarantine, you can implement BIMI to display your brand logo next to your emails in supported email clients. This is a strong visual trust indicator for your recipients and makes spoofed emails (that would fail DMARC and never display the logo) stand out even more.

Domain monitoring — Actively monitor for lookalike domains being registered that could be used for brand impersonation. Automated tools can alert you when someone registers a domain similar to yours.

Common Mistakes I See Organizations Make

After 20+ years in this space, I've seen the same patterns repeat across hundreds of organizations. Here are the most common mistakes:

Setting DMARC to p=none and forgetting about it. A p=none policy is a monitoring tool — it doesn't protect you from anything. I've seen domains sit on p=none for years while attackers freely spoofed them. The whole point of monitoring is to prepare for enforcement.

Not including an rua tag. Over 40% of domains with DMARC records don't include a reporting mechanism. Without reports, you're flying blind. You have no way to know if your emails are passing authentication or if someone is spoofing your domain.

Ignoring subdomains. Your DMARC policy for yourdomain.com doesn't automatically protect mail.yourdomain.com or app.yourdomain.com unless you use the sp= tag or publish separate DMARC records for subdomains. Attackers know this and specifically target unprotected subdomains.

SPF record with too many DNS lookups. SPF has a hard limit of 10 DNS lookups. Once you exceed that, your entire SPF record becomes invalid — which means SPF fails for all your emails. This is surprisingly common for organizations using multiple SaaS tools for email sending.

Not testing before enforcing. Moving to p=reject without thoroughly testing can break legitimate email flows. Your marketing emails, transactional emails, and third-party notifications could all get rejected if they're not properly authenticated.

Wrapping Up

Domain spoofing isn't a new attack — it's been around as long as email itself. But the scale and sophistication of these attacks in 2025 and 2026 is unlike anything we've seen before. Phishing-as-a-Service platforms have made it trivially easy for even low-skilled attackers to spoof any domain that isn't properly protected. AI-generated phishing content makes the emails more convincing than ever.

The good news? The solution is well-established and entirely within your control. SPF, DKIM, and DMARC are free to implement — they're DNS records. What you need is the process and visibility to implement them correctly without breaking your email delivery.

That's exactly what we built SimpleDMARC for. We help you go from zero visibility to full DMARC enforcement, with clear reporting and actionable insights at every step. No XML parsing, no guesswork.

If you've read this far and your domain still doesn't have DMARC enforced, today's a good day to fix that. Start with a free domain check and take it from there.

Stay safe out there.

— Gaurav Maniar