Why sources show as Unknown
An Unknown group in your Sending sources table looks alarming — a block of mail from senders the product can't name. But Unknown is a statement about identification, not about trust: it means we couldn't determine which provider operates the source, and nothing more. Some of the most legitimate traffic a domain sends lands under Unknown, and so does most spoofing. This article shows you how to tell them apart.
What Unknown actually means
DMARCmetric names providers by inference, in three tiers, strongest evidence first:
- Authentication fingerprints — the DKIM signing domains, DKIM selectors and SPF domain carried inside the report itself. Many providers leave an unmistakable signature there (Postmark's bounce domains and selectors,
amazonses.com,sendgrid.net). - Known IP ranges — a curated table of provider address space, used when the source's authentication is fully aligned to your domain and so carries no provider tell.
- Reverse DNS — the IP's PTR hostname, matched against known provider hostnames as a last resort.
Unknown means none of the three matched. That's the honest label, not a failure state — and crucially, it is not a verdict. The verdict pill next to the group (pass, mixed, would reject) is computed from authentication results exactly as for every other group, and that pill, not the name, is what tells you whether to worry. Sending sources, grouped by provider covers the detection tiers in more detail.
Diagnose: expand the group
Click the Unknown group row to open its individual sources. Each per-IP row gives you everything you need for a judgement:
- From domain — what the mail claimed in its visible From header,
- the sending IP and the country it resolves to,
- message count over the window,
- SPF and DKIM alignment tags, and an overall DMARC verdict.
Work the rows one at a time, asking one question of each: is this plausibly something my organisation operates or pays for? The columns usually answer it quickly.
Look up who owns the IP
When the columns leave you undecided, the next question is usually who owns this IP address? — and there is a public answer. Every routable address is allocated by a regional internet registry to an organisation, and that allocation is queryable by anyone. RDAP is the modern replacement for WHOIS for IP addresses: the same registry data, served as structured JSON over HTTPS, behind one entry point that redirects to whichever registry holds the block, so you don't need to know the region first.
Take the address from the row you're investigating, drop it into this pattern, and open it in a browser tab:
https://rdap.org/ip/<address>Three fields in the response carry the answer:
| Field | What it tells you |
|---|---|
| Network handle | The registry's identifier for the allocation — the same handle on two rows means one block, and one owner. |
| Allocated organisation | The company the address space was assigned to: a hosting company, an ISP, or an email provider. |
| Netblock range | The first and last address in the block, so you can see which of your other Unknown rows fall inside it. |
Read the owner next to the verdict columns, never on its own. Two patterns cover most rows:
- A bulk hosting or VPS provider you have no relationship with, with
✕ failon both SPF and DKIM. That is the spoofer archetype described under The malicious fingerprint below: rented address space, sending as you. - Your own ISP, your office connection, your hosting company or an ESP you already pay. That is the benign archetype — a block you can account for, and the row usually passes. Where a provider is recognisable from the report itself we name it for you, which is why the senders that reach Unknown tend to be the smaller and self-hosted ones; Sending sources, grouped by provider explains the three detection tiers.
One distinction is worth keeping straight, because the two are easily read as the same fact: RDAP reports registry ownership, not geolocation. It tells you which organisation an address block was allocated to, and a multinational can route its blocks anywhere. The country shown against a source in DMARCmetric doesn't come from RDAP at all — it comes from a MaxMind GeoLite2 lookup applied at ingest, and Where your mail comes from covers what that can and cannot tell you. When the registry names one country and the flag shows another, neither is wrong; they answer different questions.
The legitimate Unknowns
These show up in almost every domain's reports, and none of them match a provider fingerprint:
- Your own mail server. A self-hosted Postfix or Exchange box signs as your domain, sends from your own IP, and has your own (or your host's generic) reverse DNS — nothing there says "provider" because there isn't one. This is the classic Unknown.
- A smaller ESP or regional provider we haven't fingerprinted yet. The detection list grows continuously, but the long tail of the email world is long.
- A corporate relay or gateway appliance — a firewall, an on-premises smarthost, a copier that emails scans through your server.
The tell is consistency: the mail passes DMARC (at least one check shows ✓ aligned), the From domain is yours and used the way you'd expect, the country is one you operate in, and the volume is steady rather than bursty. An Unknown row with a pass verdict needs no fixing — at most, note the IP somewhere so future-you recognises it.
One variant deserves action: an Unknown source that is yours but failing — right country, recognisable From, but ✕ fail on both columns. That's typically a legitimate system nobody finished setting up, like an appliance relaying without a DKIM signature. Complete its authentication the same way you would any third-party sender.
The malicious fingerprint
Spoofed mail has a recognisable shape, and it is close to the mirror image of the list above:
| Signal | What you'll see |
|---|---|
| Authentication | ✕ fail on both SPF and DKIM — verdict would reject |
| Geography | Countries where you have no operations or customers |
| Volume | Probing single digits, or sudden bursts — not a steady hum |
| From domain | Yours, exactly — that's the point of spoofing |
The verdict is the anchor: a source failing both checks is flagged as a threat, and the whole group shows would reject. DMARC pass and fail, explained decodes each verdict label precisely.
And here is the part that surprises people: there is nothing to fix on that sender. You cannot make a spoofer stop sending; you can only make their mail undeliverable. That is your DMARC policy's job — a domain at p=none merely observes these sources, while advancing to quarantine and reject is what actually shuts them down. In that sense, a would reject Unknown group is your DMARC deployment working: it found exactly the thing the whole system exists to catch.
A short decision rule
- Unknown +
pass→ legitimate, unfingerprinted. Leave it alone. - Unknown + failing, but plausibly yours (right country, sensible pattern) → investigate internally, complete its SPF/DKIM setup.
- Unknown +
would reject, not plausibly yours → spoofing. Fix nothing; let your policy ladder do its work, and watch the group shrink into irrelevance as you enforce.
If you're ever unsure which bucket a row belongs in, volume over time is the tiebreaker — your own systems send on business rhythms; spoofers don't.