What to do when DMARCdrift detects an unknown sender

An unknown sender in DMARCdrift means traffic appeared in aggregate reports claiming to come from your domain, from a source you haven't identified or authorized. This isn't automatically a security incident: it could be a legitimate service you forgot to configure, a new tool someone on your team started using, or — less commonly — actual spoofing.

What the report shows

Each aggregate report record includes:

• Source IP address: the IP that sent the message
• Message count: how many messages came from that IP in the reporting period
• DMARC disposition: what the receiver did with the mail (none, quarantine, reject)
• Authentication results: whether SPF and DKIM passed and whether they produced alignment

An unknown sender shows up as an IP range you don't recognize with failing or absent alignment.

Step 1: identify the sending service

Look up the source IP to find what service or organization owns it. Most IP ranges are registered to cloud providers, ESPs, or infrastructure services. Search the IP against your own knowledge of what services you use, or check the IP's PTR record and ASN.

Common patterns:

• Amazon AWS IPs: SES, Resend, or any service built on AWS infrastructure
• Google IPs: Google Workspace or third-party tools that use Google's outbound relays
• Microsoft IPs: Microsoft 365 or Azure-hosted applications
• ESP-named PTR records: Mailchimp, SendGrid, Postmark, Klaviyo, and others use named PTR hostnames you can recognize

If the DKIM signature includes a d= domain, that domain often points to the sending service.

Step 2: match it to something you're using

Ask yourself: does any service your team uses send mail claiming to be from your domain?

Check recently connected tools. Marketing automation, CRM notifications, transactional email triggers, error alerting, scheduled reports — any service that sends email on your behalf.

Ask your team. Someone may have connected a new tool to a shared account and not realized it would send as your domain.

Check billing and sign-up records. If the IP resolves to a known ESP, look for accounts with that service that use your domain.

Step 3: decide what it is

Known service, not yet configured: You recognize the service, it's legitimate, but DKIM or SPF hasn't been set up for it. Follow the appropriate setup guide to get it aligned. Until then, it will continue appearing as a failing source.

Known service, unexpectedly sending: You recognize the service but didn't intend for it to send as your domain. Review the service's settings and disable email sending from your domain if it's not needed.

Unknown service with low volume from shared IPs: A few messages from Amazon or Google IPs without DKIM alignment could be from a free-tier tool, a developer testing something, or a low-priority integration. Investigate if it persists or the volume grows.

Unknown service, persistent, high volume, failing alignment: This is a stronger signal of either a misconfigured legitimate sender or an active spoofing campaign. If you can't identify the source after checking your tools and team, treat it as potential spoofing.

Step 4: what to do about spoofing

If you believe a source is spoofing your domain:

• If you're on p=none: the mail is being delivered. Moving to p=quarantine or p=reject will instruct receivers to block or filter it. Before doing that, confirm all your legitimate senders are passing alignment — see the enforcement readiness checklist.
• If you're already on p=quarantine or p=reject: the policy is already working to block spoofed mail. Continue monitoring for the pattern.

You can't directly block a specific sender through DMARC — the policy applies to all failing traffic. The goal is to reach a state where all legitimate mail passes alignment, then enforce, which blocks spoofing as a side effect.

---

See also: DMARC alignment failures: when legitimate senders fail alignment. Enforcement readiness: the checklist before moving to quarantine or reject.