Anatomy of a Domain Spoofing Attack

A spoofed email feels like a magic trick: a message that says it is from your CEO, your billing address, or your helpdesk, landing in someone's inbox — except your servers never sent it. There is 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 is 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 cannot do is authenticate as you:

• SPF checks whether the sending IP is authorized for the envelope domain. The attacker's IP is not 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 does not have it, so there is either no signature or one that does not 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 cannot 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 is no warning, because authentication failures with no enforcing policy do not change delivery. That is the dangerous middle ground: you are 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, covered further below.

The same attack, in your aggregate report

Here is 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 do not 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 separate spoofing from 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: avoid false alarms

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 is not in your SPF record. The difference:

• Forwarding usually keeps DKIM intact. If the body is not 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 is 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 is not you. Before calling it an attack, rule out a forgotten legitimate sender — an old marketing tool, a new SaaS app, a billing system — that is sending unauthenticated. Reports surface these too, and they are far more common than active attacks.
2. If it is genuinely spoofing, enforce. Detection without enforcement just means you have a good view of mail you are 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 is not a one-time audit — it is noticing the next spike before it does damage.

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