Domain Spoofing Incident Response: DMARC Anomaly and Active Spoofing Campaign
Response to an active spoofing campaign originating from your own domain; DMARC report anomaly detection, emergency policy escalation, affected user notification, and root cause analysis.
p=reject, strengthen it urgently; replace the ~all (softfail) value in the SPF record with -all (hardfail). Establish a regular WHOIS monitoring mechanism for similar domain registrations (typosquatting).Prepare
5 steps- Trigger definitions must be documented
Initiate the incident response process under any of the following conditions: DMARC aggregate report anomaly (high-volume fail from an unrecognized IP), user report ("we received a spoofed email from our own domain"), threat intelligence (domain reported as being used in a phishing campaign), or SIEM rule trigger (DMARC fail from own domain).
- Urgency classification must be ready
p=none + financial content + internal recipients → Critical P1; p=none + credential harvesting → High P2; p=quarantine + high volume → Medium P2; p=reject + unrecognized IP → Low P3 record; these thresholds must be agreed upon by the team before incident declaration.
- DMARC report processing tool must be active
parsedmarc, dmarcian, or equivalent tool is operational; `rua` and `ruf` mailboxes are accessible; SIEM integration has been tested.
- Authority and procedure definition
Responsibilities and authority for DNS changes (TTL, policy updates), SMTP gateway blocklist management, email recall via M365 Compliance Search/Purge or Google Vault, and user notification channel must be predefined.
- Escalation communication template ready
An incident notification template for CTO/CISO/email team (attacker IP, estimated volume, recipient list, actions taken, next steps) must be ready.