09 Oct 20266 minutes read
SendmarcSpoofed Emails from Your Domain: An Incident Response Playbook
Spoofed emails overview:
- Assign incident owners before an email impersonation incident occurs.
- Review DMARC aggregate reports as an early signal.
- Triage with header analysis and aggregate data.
- Coordinate customer messaging with security and legal.
- Move to p=reject in stages and keep monitoring.
When a customer forwards a suspicious message that appears to come from your domain, the cause isn't always an attacker. It could be spoofed emails sent by a threat actor, or legitimate email from one of your own senders that's failing authentication. Your team needs to identify the cause, fix it or plan the right response, and keep customers informed.
Spoofed emails from an attacker reach customers when your DMARC policy is set to p=none. Enforcement often stalls because teams can't see every service sending email on their behalf. This playbook sets out spoofing incident response, with clear responsibilities for security, email administration, compliance, and brand teams.
Explore how DMARC Management shows your team every source sending email from your domain, so you can trace spoofed emails to their origin.
Spoofing Incident Response Playbook
Assign Ownership
Reports of spoofed emails arrive through several channels. A customer forwards a suspicious message, support sees a rise in tickets asking whether a message is genuine, or a partner’s security team gets in touch directly.
The first failure at this stage is usually organizational. Email security spans infrastructure, brand, legal, and customer communications. Without a defined escalation path, the report moves between teams while more customers receive the message.
Set ownership before an email impersonation incident occurs:
- Primary owner: Security operations or infrastructure, responsible for triage and remediation
- Compliance lead: Legal or compliance, responsible for regulatory exposure and documentation
- Communications lead: Brand or corporate communications, responsible for customer and partner messaging
Two types of signals should route to the primary owner:
- Inbound reports: Forwarded messages, support tickets that reference suspicious email, and abuse mailbox submissions
- DMARC aggregate reports: Unrecognized sending sources, and SPF or DKIM failures on messages your infrastructure didn’t send
Aggregate reports are often the earliest internal signal of spoofed emails. Receivers typically send them daily, so unauthorized sending surfaces within about a day, but only if someone reviews the data. If your reporting mailbox is unmonitored, a customer may alert you before your own reports do.
Triage the Email Impersonation Incident
Each report points to one of two root causes, and each needs a different response:
- External spoofing: An attacker sends spoofed emails that use your domain in the “From” address, from infrastructure you don’t control. At p=none, receivers take no action on these messages.
- Misconfigured legitimate sender: A marketing platform, CRM, or new vendor sends on your behalf without aligned SPF or DKIM. The sender is legitimate, but its messages fail authentication and look suspicious to recipients. Typical causes include acquisitions and tools adopted without IT involvement.
To classify the report:
- Copy the full header from the reported message and paste or upload it into Sendmarc's email header analyzer.
- Review the authentication results. The analyzer shows whether the message passed or failed SPF, DKIM, and DMARC.
- Review the delivery route and sender reputation. The analyzer lists every server the message passed through and checks each hop's IP against reputation data, including abuse scores and spam infrastructure.
- Compare the originating server against your known sending services, including ESPs, CRMs, HR platforms, and transactional email providers.
- Check your DMARC aggregate reports for the same period. The analyzer checks one message at a time, while aggregate data shows whether the same source is sending at volume.
If the source is unknown and DMARC fails, treat the report as external spoofing. If the source is a known service that wasn’t set up correctly, treat it as a configuration fix.
For CISOs, external spoofing at p=none is a material risk. Your domain is being used against customers, partners, or employees, and receivers have no instructions to block the messages.
Manage Communications During an Email Impersonation Incident
Communication runs in parallel with triage and remediation.
Documentation: Log the email impersonation incident timeline, including the time of the first report, the triage steps, the stakeholders notified, and the actions taken. If spoofed emails target regulated communications, keep the reported samples and their headers as evidence. These records support internal reviews, audits, and regulator inquiries.
External messaging: Brand teams often want to publish a public advisory as soon as spoofed emails are reported. Coordinate with security and legal first, so the message reflects what triage has confirmed. An advisory issued before triage is complete can’t tell customers whether they’re still at risk.
When customer notification is needed, keep it direct:
- Confirm that fraudulent emails are using your domain
- State what your company legitimately sends by email
- Give recipients a way to verify whether a message is genuine
Don’t describe the incident as a breach unless investigation confirms one. Spoofing exploits unenforced authentication and doesn’t require access to your systems.
Harden Your Domain Against Future Spoofed Emails
Hardening is the final stage of spoofing incident response and removes the conditions that allowed it.
- Sender inventory: Map every service that sends email using your domains, including marketing platforms, payroll and HR systems, transactional providers, and regional subsidiaries. Confirm each one passes SPF or DKIM in alignment with your “From” domain, and keep SPF records within the 10 DNS lookup limit.
- Staged enforcement: Move from p=none to p=quarantine to p=reject as aggregate report data confirms each legitimate sender passes.
- Subdomains: Subdomains used for product, regional, or transactional email are also spoofing targets. Use the
sp=tag to set a different policy for subdomains. Without it, subdomains inherit your root domain's policy. - Continuous monitoring: New tools, DNS changes, and acquisitions introduce new senders and misconfigurations. Monitor for new sources and authentication failures continuously.
For boards and risk committees, the useful question isn’t whether DMARC exists. It’s whether your domains are at enforcement and whether anyone is monitoring for changes.
How Sendmarc Can Help
Customer reports of spoofed emails often reveal the same underlying problems: limited visibility into who sends on your behalf, too few people to investigate, and no clear way to prove control to auditors and boards.
Sendmarc supports spoofing incident response by helping you:
- Identify every sender using your domains: The Email Senders view shows each source’s volume and DMARC results, so your team can separate unauthorized senders from misconfigured legitimate ones during triage.
- Reach enforcement without disrupting critical email: Sendmarc’s implementation team takes a staged approach from p=none to p=reject.
- Reduce manual investigation: Continuous monitoring and administrator alerts keep your team informed as new senders appear, without adding to internal workload.
- Provide credible evidence to auditors and boards: Audit-ready reporting and the DMARC compliance certificate give verifiable proof of enforcement status and support alignment with mandates such as PCI DSS, GDPR, and POPIA.
- Cover threats outside your own domain: Lookalike Domain Defense detects domains registered to impersonate your brand, and Breach Detection identifies exposed employee credentials.
Explore how Sendmarc’s DMARC solution keeps spoofed emails out of your customers’ inboxes.
