DMARC reports show sources I do not recognise

26 May 2026 · 13 min read

You turned on DMARC reporting, the XML started arriving, and now you are staring at a list of sending sources that includes names and IP addresses you have never seen before. Some have a recognisable provider attached. Others are a bare IP in a country you do not operate in, sending mail with your domain in the From address and failing authentication. The instinct is to panic: someone is spoofing us. Sometimes that is exactly right. More often it is your own marketing team's new tool, a forwarding mailbox, or a security scanner. The whole job of this article is to give you a reliable way to tell which is which, because the correct response is completely different for each.

This is not a general "what is DMARC" piece. It assumes you already have a record publishing and reports flowing, and you are looking at sources you cannot immediately place. If you have not got that far, reading your first DMARC report covers the basics and DMARC RUA and RUF reports explains the two report types. Here we stay on the specific problem: an unknown source has appeared, and you need to identify it before you change anything.

Why unknown sources are normal, not alarming by default

The first thing to internalise is that a p=none DMARC record is a floodlight, not a filter. It does not block anything. It asks every receiving mail server in the world to send you a census of every IP that put your domain in a From header, whether the mail was legitimate, forwarded, forged, or random background noise. You asked for a complete picture, and a complete picture includes things you did not know were there.

So a fresh report almost always surfaces sources you do not recognise, and that is the system working. The categories you will see fall into four broad buckets:

• Legitimate senders you forgot about (shadow IT). A department signed up for a newsletter tool, a billing system sends receipts, a recruiter uses an applicant-tracking system. All sending as your domain, none of it on your radar.
• Forwarders and mailing lists. A real message you sent, relayed onward by an alias, a list, or a "forward everything to my Gmail" rule. The original was legitimate; the forwarded hop fails SPF and sometimes DKIM.
• Spoofers and abuse. Someone forging your domain in phishing, spam, or business-email-compromise attempts. This is the threat DMARC exists to stop.
• Noise. Spam traps, security scanners, backscatter, and reputation services that generate a row or two and never reappear.

Your task is triage: sort each unknown source into one of these buckets using the evidence already in the report, then act. Nothing in this process requires you to guess.

What an aggregate report actually tells you about a source

Before triaging, be precise about the data you have, because the temptation is to read more into a row than is there. Each record in an aggregate report gives you, per source IP:

• the source IP address and a count of messages,
• the From domain (header_from) the messages claimed,
• the SPF result and the domain SPF evaluated (the Return-Path / envelope domain),
• the DKIM result and the d= domain the signature used,
• the DMARC-level SPF and DKIM alignment (pass or fail for each),
• the disposition the receiver applied (none, quarantine, reject),
• the reporting receiver (Google, Yahoo, a corporate mail system, and so on).

What it does not tell you: the subject line, the recipient, the body, or any message content. Aggregate reports are statistical, by design, for privacy. So you identify a source from its IP, its claimed alignment domains, its pass/fail pattern, and its volume over time, never from message content. If you need content-level forensic detail on a single forged message, that is what failure (RUF) reports are for, and most receivers no longer send them. The aggregate data is your primary evidence. DMARC reports versus the inbox explains why the report view and what users actually receive can differ.

Raw XML is unreadable at any real volume, so do not try to triage by eye in a text editor. Paste reports into the DMARC report analyzer, which groups by source, resolves IPs to organisations, and shows the aligned-versus-unaligned breakdown per sender. Everything below assumes you are looking at a grouped, per-source view rather than a wall of XML.

The triage method: four questions per source

For each unknown source, work through these four questions in order. They will almost always land the source in the right bucket.

Question 1: who owns the IP?

Start with the single most informative fact: the IP's owner. Resolve the IP to its organisation. The analyzer does this for you, but you can confirm independently with a reverse-DNS lookup and a WHOIS on the IP. The PTR record (the reverse hostname) is often the giveaway.

• A PTR like mail-12-34.sendgrid.net, o1.email.someprovider.com, smtp.mailgun.com, or mail.zendesk.com immediately tells you it is a known email platform. That is almost certainly shadow IT: a legitimate provider somebody in your organisation is using.
• A PTR belonging to Google (mail-...google.com), Microsoft (outlook.com), or a hosting provider where you do run a server points you toward your own infrastructure or a forwarder.
• A PTR that is generic broadband or VPS hosting (pool-...comcast.net, a bare DigitalOcean or OVH droplet hostname), in a region you do not operate in, with mail failing both SPF and DKIM, leans towards spoofing or abuse, though a misconfigured legitimate sender can look the same, which is why you keep going.
• No PTR at all, low volume, never repeats: usually noise.

The PTR plus the WHOIS organisation answers "what is this?" for the large majority of sources in one step. The remaining questions disambiguate the rest.

Question 2: what domains did it authenticate for?

This is the question that separates a misconfigured friend from an actual enemy, and it is the one people skip. Look at the SPF domain and the DKIM d= domain the source used, not just the pass/fail.

A legitimate-but-unaligned sender authenticates as itself. Its mail passes SPF for the provider's bounce domain and passes DKIM for the provider's d=, but neither aligns with your From because nobody completed domain authentication. The pattern looks like this:

source IP:    198.51.100.7  (PTR: o1.emailprovider.net)
header_from:  yourdomain.com
SPF:          pass for bounce.emailprovider.net   -> not aligned
DKIM:         pass for d=emailprovider.net         -> not aligned
DMARC:        fail

Read that carefully. SPF and DKIM passed. The mail is cryptographically authenticated; it just authenticated the provider rather than you. A spoofer cannot do this. A spoofer has no relationship with a real email platform sending as your domain, so a forger's mail almost never shows a clean SPF pass and DKIM pass for a reputable provider's own domains. When you see both mechanisms passing for a recognisable platform, you are looking at shadow IT that needs domain authentication, not an attacker. The fix is to complete that provider's DKIM and Return-Path setup so it signs and bounces as your domain; our email authentication setup guides cover the common platforms one by one.

Contrast that with a true spoofer:

source IP:    203.0.113.99  (PTR: none, WHOIS: residential ISP, overseas)
header_from:  yourdomain.com
SPF:          fail (or pass for some unrelated throwaway domain)
DKIM:         none, or fail
DMARC:        fail

Nothing authenticated as you, and nothing authenticated as a recognisable provider either. The mail simply asserts your From with no valid, related credential behind it. That is the signature of forgery. Email spoofing and display-name spoofing explain the techniques; the report fingerprint is "claims your domain, holds no aligned or provider-owned credential".

The discriminator, stated plainly:

Shadow IT authenticates as some real provider and fails alignment. A spoofer authenticates as nobody (or as a throwaway) and fails outright. Read the d= and SPF domains, not just the verdict.

Question 3: what is the volume and shape over time?

A single source's behaviour across days is enormously revealing, and it is why a one-off snapshot misleads you.

• Steady, business-hours-weighted volume from a provider IP is a real internal sending stream. Your invoicing system sends a consistent few hundred a day on weekdays. That is shadow IT you should adopt and authenticate, not block.
• Volume that tracks your own sends, appearing shortly after a campaign and aimed through known receivers, is forwarding: recipients auto-forwarding your legitimate mail onward. The forwarded copies fail SPF (new connecting IP) but frequently still pass DKIM if the forwarder did not alter the message.
• Spiky, bursty volume from many scattered low-reputation IPs, often clustered in time, is the shape of a spoofing campaign. Attackers blast from botnets and disposable hosts, so you see lots of distinct IPs each sending small amounts, all failing, all at once, then vanishing.
• One or two messages, once, never again: noise. Do not spend time on it.

You can only see shape over time if you are retaining and trending reports, which is the strongest argument for continuous monitoring rather than opening XML by hand each week. A source that looks suspicious in one report often resolves obviously when you see it is the same steady weekday stream it has always been, and a genuinely new spoofing burst stands out precisely because it breaks an established pattern. That trend-break is also exactly what a change alert should fire on.

Question 4: does it pass anywhere, for anyone?

Last check. Does the source ever produce an aligned pass for your domain, even occasionally?

• If a source sometimes shows DKIM aligned with d=yourdomain.com, it is yours or a forwarder of your mail, full stop. Spoofers cannot produce a valid DKIM signature for your domain because they do not have your private key. An aligned DKIM pass is near-proof of legitimacy.
• If a source shows SPF pass aligned to your domain from an IP you recognise as your own infrastructure, it is yours.
• If a source never aligns and never carries a provider's own clean credential, it stays in the suspect column.

DMARC alignment explained is the underlying theory if any of the pass-versus-align distinction is fuzzy; for the very common "passes SPF and DKIM but still fails DMARC" case, DMARC fails but SPF and DKIM pass is the dedicated walk-through.

Telling forwarders apart specifically

Forwarders deserve their own note because they are the source people most often misclassify as spoofing, and acting on that mistake (rushing to enforcement) is how you junk legitimate forwarded mail.

The forwarding fingerprint in a report is distinctive:

header_from:  yourdomain.com
SPF:          fail   (forwarder's IP is not in your SPF)
DKIM:         pass for d=yourdomain.com   -> aligned
DMARC:        pass   (DKIM carried it)

SPF fails because the forwarding server connects from its own IP, which is not in your SPF record; forwarding rewrites the delivery path, not the SPF record. But DKIM signs message content, not the connection, so as long as the forwarder did not modify the body or signed headers, your d=yourdomain.com signature still verifies and still aligns, and DMARC passes overall. That is the system working, and no action is needed.

The dangerous variant is a forwarder that alters the message (appends a footer, rewrites links, changes the subject). That breaks the DKIM body hash, so now DKIM fails too, both mechanisms are gone, and a genuinely legitimate forwarded message fails DMARC. In a report this looks alarmingly like spoofing: your From, both mechanisms failing. The tell is the source IP, which resolves to a mailbox provider or mailing-list host (mail.google.com, a known list server) rather than a botnet, and the volume tracks real mail you sent. DKIM, alignment and forwarding and forwarding and DMARC go deeper. The practical defence is to ensure your direct mail has rock-solid DKIM alignment so the surviving signature carries DMARC through most forwarding hops.

A worked example: four unknown sources, four verdicts

Suppose your analyzer surfaces these four sources you do not recognise, all using header_from: yourdomain.com.

Source 1, a provider IP, both mechanisms passing for the provider:

PTR: o2.emailservice.net   |  volume: ~300/day, weekdays
SPF: pass for emailservice.net   -> not aligned
DKIM: pass for d=emailservice.net -> not aligned
DMARC: fail

Verdict: shadow IT. This is a real platform someone is using to send legitimate mail as you. Find out who owns the account internally, then complete the provider's domain authentication so it signs with d=yourdomain.com. After that, DMARC will pass for this source. Do not raise policy until it does.

Source 2, a Google IP, SPF fail but DKIM aligned:

PTR: mail-...google.com   |  volume: tracks your campaigns
SPF: fail
DKIM: pass for d=yourdomain.com   -> aligned
DMARC: pass

Verdict: forwarding. Recipients auto-forwarding your legitimate mail. It already passes via aligned DKIM. No action.

Source 3, scattered residential IPs, bursty, nothing authenticates:

PTR: mostly none, overseas residential/VPS   |  volume: 5,000 in one hour, then gone
SPF: fail
DKIM: none
DMARC: fail

Verdict: spoofing. No aligned credential, no provider credential, botnet shape. This is the attack DMARC blocks. The response is not to chase individual IPs (futile, they rotate) but to get to an enforcing policy so receivers reject this mail. Reach p=reject without breaking email sequences that safely once your legitimate sources are all aligned.

Source 4, one message, no repeat:

PTR: a security-scanner hostname   |  volume: 1, once
DMARC: fail

Verdict: noise. A scanner or trap. Ignore it.

Four unknown sources, four completely different correct actions, all distinguished from the same report fields: IP owner, authenticated domains, volume shape, and alignment.

What to actually do, by bucket

Once a source is classified, the action is well defined.

Shadow IT (legitimate, unaligned). Identify the internal owner, then authenticate the sender on your domain. The single highest-value step is completing the provider's DKIM domain authentication so it signs with d=yourdomain.com; a custom Return-Path for SPF alignment is a useful extra. Verify the selector with the DKIM checker and your SPF with the SPF checker. Then re-read reports and confirm the source flips to aligned. This is the bulk of pre-enforcement work for most organisations: discovering and authenticating senders you did not know about.

Forwarders. Usually no action if DKIM is aligned and surviving. If a forwarder is breaking your DKIM by modifying messages, the fix lives in the forwarding configuration, not your DNS. Keep your direct-mail DKIM strong so forwarding-induced SPF failures do not matter.

Spoofers. Do not try to block individual IPs; they rotate faster than you can react. The durable defence is policy enforcement: move to p=quarantine then p=reject once every legitimate source is aligned, so receivers themselves drop forged mail. If the spoofing is targeting a subdomain you never send from, an explicit reject policy on that subdomain (via the subdomain policy sp tag) shuts it down. For brand-impersonation context, invoice fraud and spoofed domains and the business email compromise entry explain the stakes.

Noise. Nothing. Recognise it and move on so it does not distract you from real sources.

Why this is a continuous job, not a one-off audit

The reason unknown sources keep appearing is that your sending estate keeps changing without telling you. Marketing trials a new tool. A new SaaS app starts emailing customers on your behalf. A partner sets up forwarding. An attacker picks your brand this week. A single audit identifies today's sources; it says nothing about the source that shows up next Tuesday.

That is the case for emailed monitoring with change alerts. The point is not just to parse reports more comfortably, although the DMARC report analyzer doing the IP resolution and grouping for you is a real time saver. The point is that a new unknown source, or an existing one suddenly spiking, is precisely the event you want to hear about the day it happens rather than the next time you remember to open the XML. A new aligned-and-passing source is probably a sanctioned tool that got set up correctly; a new failing burst from scattered IPs is probably an attack. Either way, you want to know now. Setting up alerts covers configuring that, and the enforcement journey puts source discovery in the wider sequence towards p=reject.

The practical takeaway

Unknown sources in your DMARC reports are expected, not an emergency, because p=none reporting shows you everything, including senders you forgot you had. Triage each one with four questions: who owns the IP (PTR and WHOIS), what domains did it authenticate for (the SPF and d= values, not just pass/fail), what is its volume and shape over time, and does it ever align for your domain. Shadow IT authenticates cleanly as a real provider and just needs domain authentication; forwarders fail SPF but usually carry aligned DKIM and need nothing; spoofers authenticate as nobody and are the reason to push policy to enforcement; noise is one-off and ignorable. The single most common mistake is reading a passing-but-unaligned provider as an attacker and a message-modifying forwarder as spoofing, both of which you avoid by reading the authenticated domains rather than the headline verdict.

Start by grouping your latest reports in the DMARC report analyzer and classifying every unknown source before you touch your policy. If you would rather not babysit the XML, point a domain at continuous monitoring: it resolves every source, separates aligned senders from forwarders and spoofers, and alerts you the moment a new one appears, while our done-for-you service identifies and authenticates each legitimate sender and takes you from p=none to p=reject without dropping a single real message.