Anatomy of a Domain Spoofing Attack — and What It Looks Like in Your DMARC Reports

A spoofed email feels like a magic trick: a message that says it's from your CEO, your billing address, or your helpdesk, landing in someone's inbox — except your servers never sent it. There's no magic. Domain spoofing is just a forged From: header, and once you understand how the forgery works, you can see it happening in your own DMARC reports.

This post walks one attack end to end: how it's staged, what the target sees, and — the part most guides skip — exactly what it looks like in an aggregate report so you can recognize the real thing. If you want the protocol fundamentals first, our explainer on what DMARC is covers the groundwork.

How a spoofing attack is actually staged

Email has two "from" addresses, and that gap is the whole attack:

• The envelope sender (MAIL FROM, also called the Return-Path or 5321.From) — used for routing and checked by SPF. Recipients never see it.
• The header From (5322.From) — the friendly address shown in the mail client. This is what the human reads.

A spoofing attacker sends from their own server and simply writes From: ceo@yourdomain.com into the header. Nothing stops them from typing your address. What they can't do is authenticate as you:

• SPF checks whether the sending IP is authorized for the envelope domain. The attacker's IP isn't in your SPF record, so SPF fails to align with your domain.
• DKIM requires your private signing key to produce a valid signature. The attacker doesn't have it, so there's either no signature or one that doesn't verify against your domain.

DMARC ties these to the visible From:. For DMARC to pass, SPF or DKIM must not only pass but align — the authenticated domain has to match the domain the recipient sees. A spoofer can't make that happen, which is precisely why DMARC exists. (For how alignment works in detail, the reading DMARC aggregate reports post breaks it down field by field.)

What the recipient sees

If you have no DMARC policy — or p=none — the recipient sees a normal-looking message from ceo@yourdomain.com: real name, real domain, plausible signature. There's no warning, because authentication failures with no enforcing policy don't change delivery. That's the dangerous middle ground: you're being impersonated and the target has no idea.

With an enforcing policy in place, the same message is quarantined to spam or rejected before it reaches the inbox. The forgery still happens — the attacker still tries — but it no longer lands. The difference between those two outcomes is one tag in your DNS, which we'll come back to.

The same attack, in your aggregate report

Here's where it becomes concrete. Every receiver honoring your DMARC record sends back aggregate (rua) XML summarizing what it saw. A spoofing attempt shows up as a <record> like this:

<record>
  <row>
    <source_ip>203.0.113.45</source_ip>
    <count>418</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>fail</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>yourdomain.com</header_from>
  </identifiers>
  <auth_results>
    <spf><domain>yourdomain.com</domain><result>fail</result></spf>
  </auth_results>
</record>

Read it back in plain English: an IP you don't operate (203.0.113.45) sent 418 messages using yourdomain.com in the visible From:, and both DKIM and SPF failed. disposition: none means the policy was p=none, so those 418 forgeries were delivered anyway. That single record is an impersonation campaign against your domain, captured in the open.

Four signals mark it as spoofing rather than your own misconfigured mail:

• An unfamiliar source_ip — not your mail servers, your ESP, or any vendor you recognize.
• Both SPF and DKIM failing, with no valid DKIM signature on your domain at all.
• header_from is your domain — the attacker is forging you specifically.
• A burst in count from a single network, often from an unexpected geography, appearing suddenly.

Spoofing vs forwarding: don't cry wolf

Not every authentication failure is an attack, and treating them all as one is how teams scare themselves out of enforcing DMARC. Forwarding — a user auto-forwarding to another mailbox, or a mailing list relaying your message — also breaks SPF, because the forwarding server isn't in your SPF record. The difference:

• Forwarding usually keeps DKIM intact. If the body isn't modified, your DKIM signature still verifies, so DMARC can still pass on DKIM alignment. Spoofing has no valid DKIM at all.
• Forwarders are known systems. Google, Outlook, university relays, mailing-list servers — recognizable infrastructure with steady, recurring volume. Spoofing comes from IPs with no business sending as you, often in bursts.
• Intent shows in the pattern. A legitimate forwarder sends a trickle continuously; an attacker sends a spike and disappears.

When you see SPF fail but DKIM pass from a recognizable mail provider, that's almost always forwarding — safe to enforce through. Both failing from an unknown IP is the profile that deserves attention. Our domain checker helps you confirm which sources are legitimately yours.

What to do when you see it

1. Confirm it isn't you. Before calling it an attack, rule out a forgotten legitimate sender — an old marketing tool, a new SaaS app, a billing system — that's sending unauthenticated. Reports surface these too, and they're far more common than active attacks.
2. If it's genuinely spoofing, enforce. Detection without enforcement just means you have a good view of mail you're still letting through. Move from p=none toward p=reject so receivers refuse the forgeries. The staged, evidence-driven path is in our DMARC rollout playbook.
3. Keep watching. Attackers retry, and new legitimate senders appear constantly. The point of monitoring isn't a one-time audit — it's noticing the next spike before it does damage.

Frequently asked questions

How can I tell if my domain is being spoofed? Check your DMARC aggregate reports for mail using your domain in the From: address from IP addresses you don't operate, failing both SPF and DKIM alignment. A sudden spike of failing messages from an unfamiliar network is the clearest sign. Legitimate-but-misconfigured senders can look similar, so confirm the source isn't one of your own systems before treating it as an attack.

Does DMARC stop email spoofing? DMARC stops exact-domain spoofing once you set an enforcing policy. At p=none it only detects and reports spoofing; at p=quarantine or p=reject, receivers that honor DMARC send the forged mail to spam or refuse it outright. DMARC does not stop lookalike domains or display-name tricks — only mail that forges your actual domain.

---

A spoofing attack is loud, if you're reading your reports. The forged messages can't authenticate, so they announce themselves in every aggregate file as failing mail under your name. Check what's sending as your domain — and once you can see the forgeries, enforce so they stop landing.