The domain is being spoofed: incident response, step by step

The first hours: collecting evidence, measuring the scale

The temptation of the first hours is to act on the DNS immediately. The right order is the reverse: freeze the evidence and take the measure first, then treat — a few hours of collection do not worsen the incident, but lost evidence cannot be recreated.

The evidence. What matters is complete copies of the fraudulent messages, headers included — not screenshots. The useful reflex: asking complaining recipients to send the message back as an attachment (.eml format), because a plain forward destroys the original headers. In each copy, three elements get extracted: the Received chain (the message's real path), the Authentication-Results field (the receiver's SPF, DKIM and DMARC verdicts), and the URLs or attachments in the body, which will feed the takedown and abuse reports. The aggregate reports covering the period get preserved as well, along with a timestamped incident log: who saw what, when, and what was decided.

The scale. Complaints tell anecdotes; aggregate reports give the only overall view. They answer the questions that structure the response: since when has the campaign been running? From which IP addresses, at what volume, toward which receiving providers? Does it target the main domain or a subdomain? A spike of ten failing messages does not call for the same response as a wave of a hundred thousand. That measurement calibrates everything that follows — including the communication.

The treatment: the incident is the argument for enforcement

For direct spoofing, the substantive treatment fits in one sentence: move the domain's DMARC policy to enforcement. A domain at p=none observes and blocks nothing; the fraudulent messages keep landing in inboxes. If the organization was living with a "someday, p=reject" project with no date attached, the incident has just supplied the date.

Acceleration does not excuse skipping the method. Before hardening, the aggregate reports must confirm that the legitimate sources — marketing platform, billing system, corporate mail — pass SPF or DKIM with alignment: hardening blindly would block legitimate mail in the middle of a crisis, the worst possible moment. But under incident conditions the calendar compresses: a quick move to p=quarantine sends the fraudulent flow to spam, then p=reject follows as soon as the reports confirm the real sources hold. The current standard (DMARCbis) provides the tools for that progression: the t=y test mode to flag a policy still being run in, the sp= tag to cover subdomains, and np= to shut down non-existent subdomains outright — a frequent target for attackers. The full method, outside emergency conditions, is walked through in getting to p=reject without breaking email.

One piece of honesty is required: DMARC only blocks direct spoofing, and only at receivers that evaluate it — nearly all the large consumer providers, only part of the corporate mail servers. And if the domain was already at p=reject when the campaign ran, the diagnosis changes: either the campaign goes through a cousin domain (back to qualification), or a fraudulent message that passes DKIM reveals a key compromise — the subject of secrets hygiene below.

Communicating: internally, to customers, to the bank, to law enforcement

A spoofing campaign attacks trust more than infrastructure; communication is therefore part of the treatment, graduated by severity.

Internally first. The support and front-desk teams need a briefing before the calls arrive: a standard, factual reply that acknowledges the ongoing campaign and explains how authentic messages can be recognized. Management gets informed early — especially if payments are at stake.

Customers and partners next, if the campaign targets them. The warning goes out through a channel distinct from the spoofed one where possible, without clickable links (a warning stuffed with links looks like phishing itself), and carries two simple messages: the company never requests this kind of action by email, and any doubtful message can be verified through a known channel.

The bank, without delay, if the campaign involves wire transfers or invoices — the classic scenario of CEO fraud and forged bank details. If a fraudulent payment has already left a deceived recipient's account, every hour matters for a recall attempt.

Law enforcement and authorities, by severity. A generic phishing wave gets reported through the national cybercrime reporting channel (IC3 in the United States, Action Fraud in the United Kingdom, and their equivalents elsewhere); financial damage or a serious attack on the brand justifies a formal complaint, which the evidence file assembled earlier makes actionable. A GDPR point that is often misunderstood: the spoofing of the domain, by itself, is not a personal-data breach of the spoofed organization — the 72-hour notification to the data-protection authority only applies if the incident reveals an internal compromise (a hijacked mailbox, an exfiltrated contact database).

Secrets hygiene after the incident

One technical question decides this step: did the fraudulent messages pass DKIM with a legitimate selector of the domain? If so, the matter goes beyond spoofing — a private key has leaked, or a system authorized to sign is compromised. Emergency rotation is mandatory: a new key under a new selector, the signing switched over, then the old selector revoked by publishing an empty p= record, which invalidates any signature that still claims it.

Even without proof of a leak, a serious incident justifies a review of the secrets that govern the sending identity: DKIM private keys, the DNS account credentials (which allow SPF, DKIM and DMARC to be published or sabotaged), the sending platforms' API tokens, SMTP passwords. A compromised DNS access is the gravest scenario — the attacker publishes records of their own and signs "legitimately". If an internal compromise is suspected, all of these secrets get rotated, starting with those the reports suggest may have been used.

DMARC.com is published by Hucency, a cybersecurity specialist; for centralizing this kind of secret — DKIM private keys, DNS credentials, API tokens — and orchestrating their rotation after an incident, there is Hucency Vault. An incident response without a vault too often ends with keys regenerated… and stored in the very place the old ones leaked from.

Closing the incident: monitoring, post-mortem, trajectory

An incident does not end when the complaints stop; it ends when three things are in place.

Reinforced monitoring. Campaigns come back — same infrastructure, new pretext. For several weeks, the aggregate reports get reviewed at a tighter cadence, with an alert on any new unknown source. The drop in DMARC-failing volume after the move to enforcement is also the success metric: it documents, with numbers, that the treatment worked.

The post-mortem. One page is enough: timeline, vector, measured scale, what worked, what was missing. In most cases the conclusion fits in one line — the domain sat at p=none for years, and the incident merely exploited a door that was known and left open. That finding, dated and shared, is what prevents a return to the status quo once the emotion subsides.

The trajectory. The policy hardened during the crisis becomes the permanent state: p=reject on the domain, subdomains covered, dormant domains locked down. What remains is verifying regularly that the protection holds — the approach described in testing whether a domain can be spoofed turns that check into a routine, alongside a periodic review of newly registered cousin domains around the brand.

In summary

A domain spoofing incident is recognized by the convergence of three signals — recipient complaints, exploding DMARC failures in the aggregate reports, mass NDR bounce-backs. Qualification decides everything: direct spoofing is treated with DMARC, the cousin domain with takedowns and a complaint. The first hours serve to freeze the evidence (complete .eml messages, headers, reports) and to measure the scale; the substantive treatment is accelerating toward enforcement — p=quarantine then p=reject — leaning on the reports so nothing legitimate breaks. Communication is graduated from internal briefing to formal complaint, rotation of DKIM keys and DNS credentials is mandatory at the slightest suspicion of compromise, and the close-out combines reinforced monitoring, a written post-mortem and a policy that stays hardened for good.

The first reflex, even before the first complaint, takes a few minutes: a free DMARC analysis shows whether the domain actually blocks direct spoofing or merely appears to. And to follow the aggregate reports, catch the next campaign early and steer the trajectory toward p=reject, opening an account puts in place the monitoring that was missing when the incident struck.