The first time you turn on DMARC reporting, the list of sending sources is usually longer and stranger than expected. Most of it is boring: a marketing tool, a support helpdesk, a transactional email provider someone signed up for two years ago and forgot about. But mixed in, occasionally, is something that's actually pretending to be you. Here's how to tell the difference.
1. It fails both SPF and DKIM alignment, not just one
A single failure is often a configuration mistake, not an attack. A legitimate vendor whose SPF record you forgot to add will fail SPF but might still pass DKIM if they sign their outgoing mail: that's a setup problem, not spoofing. What should get your attention is a source that fails both checks, with no plausible reason it should have been sending on your behalf in the first place. That combination is the strongest single signal in a DMARC report.
2. The volume doesn't match anything you recognize
Real vendors tend to show up with recognizable patterns: a few hundred messages a day from your email marketing platform, a steady trickle from your transactional provider. A spoofing attempt often looks different: a short, sharp burst (a single spam run) or a low, steady trickle from an IP block you've never dealt with, sitting there for weeks. Neither pattern matches "software you actually use," and that mismatch is worth investigating on its own.
3. The IP resolves to infrastructure with no connection to you
Look up the reverse DNS and ASN for the reporting IP. A source that resolves to a residential ISP, an unrelated hosting provider with no history of running a mail platform, or a country your organization has no footprint in is a much stronger signal than an IP sitting inside a known ESP's published ranges. This isn't conclusive by itself (plenty of infrastructure is shared or leased), but it's a fast way to triage a long report down to a short list worth checking further.
4. It's targeting a subdomain you don't actively send from
Attackers frequently spoof subdomains that look plausible but aren't actively used: mail.example.com, newsletter.example.com, billing.example.com. If your DMARC subdomain policy (the sp= tag, or np= for non-existent subdomains) is set to anything looser than your top-level policy, these are exactly the paths that get exploited, because recipients trust the parent domain's reputation. A burst of failing mail from a subdomain you've never configured for sending is a strong indicator, not a coincidence.
5. It shows up right after your domain gets more visible
A product launch, a viral post, a large customer signing on, a press mention: anything that puts your domain in front of more people also puts it in front of more people looking to abuse it. If a new failing source appears in your reports shortly after a visibility spike, that timing alone is worth treating with more suspicion than a source that's been quietly failing for months (which is more likely a configuration issue you just haven't gotten around to fixing).
What to actually do about it
None of these signs are proof on their own. Combine two or three and you have a source worth blocking rather than one worth ignoring. If you're confident a source is malicious and your policy is still at p=none, that's your signal to start moving toward quarantine: it costs you nothing for the sources you already trust (they're aligned, so they keep passing) and it starts actually stopping the ones that aren't.
This kind of triage is exactly what a report reader should surface without XML-wrangling. MyDMARC groups every sending source in your aggregate reports by hostname and pass/fail alignment, with volume trends over time, so the sources worth investigating stand out instead of getting lost in a sea of XML.