Sending sources, grouped by provider

Updated 2026-10-29 · Product Guide

DMARC reports identify senders by IP address, and IP addresses are a terrible way to think about your email. What you actually want to know is "does Microsoft 365 pass?" and "what is this thing calling itself my domain from a datacentre I've never heard of?". The Sending sources table answers in those terms: every source in the reporting window, grouped by the provider that actually sent it.

What the table shows

The table is organised by outcome first, provider second. Three sections, in this order — a section with nothing in it is left out:

Each section's header gives its message and source counts, followed by small chips that split its messages by reason — for example fully aligned, no DKIM signature counted, Return-Path is not yours, forwarded — nothing to do, your SPF record could not be read, your signature did not verify or no identity of yours at all. The chips are the quickest summary of what, if anything, needs fixing.

Inside each section, sources are grouped by the provider that sent them — Microsoft 365, Postmark, Google and so on, with anything unrecognised under Unknown. Each provider row shows how many sources (IP addresses) it spans and its message total; providers are sorted by volume. A source that sent both verified and unverified mail appears in both sections, each time with only that section's share — so five failing messages are never buried among ten thousand passing ones.

Expanding a provider

Click a provider row (or focus it and press Enter) to open its sources. Each source row shows:

• the From domain, the reason for its outcome and last seen — the most recent day this result was reported for it;
• the sending IP and the country it resolves to;
• the message count;
• the SPF and DKIM cells, and the DMARC verdict.

One source can have more than one row. Every row is true for every message in it: if the same IP sent some mail with a DKIM signature and some without — typically before and after you switched signing on — it gets one row for each, each with its own last seen. After fixing a sender you see the fixed row with a recent date next to the old row with an older one; the old row disappears once its days leave the reporting window. The provider's source count still counts IP addresses, not rows.

Reading the SPF and DKIM cells

Each cell shows two things. First, whether the check succeeded — ✓ it did, ✕ it did not. Second, whose domain the check was for — = yours, ≠ someone else's, ○ none was present — followed by that domain (or no signature when a message carried no DKIM signature). DMARC only counts a check when it both passes and is for your domain, which is why ✓ ≠ sendgrid.net is a real pass that DMARC still cannot use; DMARC alignment explained covers why.

Colour follows what matters: aqua is a check that passed and counted for your domain; amber on a passing row is information — DMARC still verified those messages and nothing is being rejected (a pass on a subdomain of yours is amber too: it counts, and it is worth knowing); red appears only where mail is actually at risk, in Not verified. There, the fail · p=none and would quarantine verdicts are amber and would reject is red. Hover any cell for the specific reason in plain words.

The DMARC verdict

Rows in Verified and Carried by DKIM alone say pass. Rows in Not verified say what your published policy does with that mail: would reject under p=reject, would quarantine under p=quarantine, and fail · p=none under a monitoring policy (or no policy), where the mail is still delivered. The dot at the start of each row repeats the section in colour — aqua, amber or red.

Two small behaviours make the table pleasant to live in: if the whole table holds a single section with a single provider, it opens already expanded; and the providers you have expanded stay open when you switch reporting windows or the data refreshes. The account owner, and admins of the domain's workspace, can also name a source we could not identify — Add source next to its IP — and that name then groups it like a detected provider, wherever that IP appears in the account.

How provider detection works

Naming a provider from a DMARC report is an inference, and we make it in three tiers, most trustworthy first:

1. Authentication fingerprints. The report itself carries the DKIM signing domains and selectors and the SPF domain that were evaluated. Many providers leave an unmistakable signature there — Postmark's bounce domains and selectors, amazonses.com for Amazon SES, sendgrid.net for SendGrid. Because the report already authenticated these domains, this is the strongest evidence.
2. Known IP ranges. When a source's authentication is fully aligned to your domain (so there's no provider tell in tier 1), we match its IP against a curated table of provider ranges — Google, Microsoft 365, Postmark, SendGrid, Amazon SES and others.
3. Reverse DNS. As a last resort we look up the IP's PTR hostname and match it against known provider hostnames.

Providers recognised today include Microsoft 365, Google, Postmark, Amazon SES, SendGrid, Mailgun, Mailchimp, SparkPost, Kinsta, Zoho, Mimecast and Salesforce — and the list grows as we see more traffic. Anything that matches no tier lands in Unknown. That is honesty, not failure: an Unknown group that passes DMARC is usually just a smaller or self-hosted sender we haven't fingerprinted yet, while an Unknown group flagged would reject is exactly the thing DMARC exists to catch.

Reading it in practice

The layout turns the table into a to-do list, top to bottom. Verified with only fully aligned needs nothing. Verified with Return-Path is not yours is a provider sending with its own bounce domain — passing, and worth a custom Return-Path if you want SPF to count too. Carried by DKIM alone tells you which streams would fail the day their signature breaks. Not verified is where the work is: expand it and each row names the From domain, IP and country. A provider you use there (say, a newly connected marketing tool) is unfinished setup; an Unknown source from a country you do not operate in is spoofing, and your DMARC policy — not that sender — is the fix.

The count above the table ("9 sources · 3 providers") gives you the scale at a glance, and the whole view is scoped to the reporting window like everything else — see Understanding your dashboard for the full tour, including where the country data comes from.