A spoofing campaign

Customers are receiving convincing invoices from your domain. The first useful question is not who is doing it — it is whether the mail is actually using your domain at all, because the answer determines whether you have any lever.

Establish what is being spoofed

Get a sample. A forwarded copy WITH FULL HEADERS.
A screenshot is not evidence and cannot be worked from.

Then read the From header:

  From: billing@example.com        your domain
  -> your DMARC policy applies. You have a lever.

  From: billing@example-invoices.com   a lookalike
  -> your policy is irrelevant. Different response entirely.

  From: "Example Billing" <x@gmail.com>   display name only
  -> your policy is irrelevant. Different response entirely.

The majority of reported “spoofing” is one of the second two, and the response to those is takedown and customer communication rather than anything in DNS. Establishing which case you are in takes one look at a header and saves days.

If it is genuinely your domain

Check your own policy first. If you are at p=none, the campaign is working because you asked receivers to let it. Moving to quarantine is the single most effective action available, and the usual objection — that you have not finished the sender inventory — has to be weighed against an active campaign.
Confirm the mail is actually failing. If it is passing DMARC, it is not spoofed: something of yours sent it, or an account is compromised. That is a different incident.
Read the reports for the source. Aggregate reports give you sending IPs and volumes by receiver. Not recipients, not content.
Tell customers directly. The reports cannot identify who was targeted, so proactive communication through a channel you control is the only reach you have.

What you cannot do

Identify the recipients          reports contain none
Read the messages                aggregate reports carry no content
Stop it at the source            the sending infrastructure is not yours
Get it stopped quickly           abuse reports to a bulletproof host
                                 go nowhere
Undo delivery                    mail already accepted is delivered

Enforcement is not retroactive

Moving to reject mid-campaign stops the next wave. It does nothing about messages already in inboxes, and it does not stop an attacker switching to a lookalike domain that afternoon — which is what a competent one does. Enforcement is necessary and it is not the end of the incident.

Knowledge check

A customer forwards a convincing fake invoice. The headers show it passed SPF and DKIM, both aligned with your domain. What is this?

Not spoofing — something of yours sent it. A compromised platform account or a compromised mailbox.
Spoofing that defeated DMARC, so the policy needs tightening to reject.
A forwarded message, where the original authentication was preserved.
A receiver reporting authentication results incorrectly.

Correct — Not spoofing — something of yours sent it. A compromised platform account or a compromised mailbox. An aligned pass means the message came from infrastructure authorised to send as you. No DMARC change addresses this, and the response is account containment rather than policy.

Not this — Spoofing that defeated DMARC, so the policy needs tightening to reject. The message passed. Tightening the policy changes the treatment of failing mail and has no effect on mail that passes.

Not this — A forwarded message, where the original authentication was preserved. Forwarding preserves DKIM and breaks SPF. Both passing points at direct delivery from authorised infrastructure.

Not this — A receiver reporting authentication results incorrectly. Possible in principle and vanishingly rare. Assume the results are accurate and follow where they lead.

Establish what is being spoofed

If it is genuinely your domain

What you cannot do

Try it on a real domain