Which senders in your DMARC reports are yours? Source verdicts in DMARCTrust

You open a week of DMARC aggregate reports for one domain and count 40 IP addresses. Some carry hostnames you recognise, like mail-yw1-f10.google.com. Some you half recognise, like mail132-9.atl131.mcsv.net. A few have no hostname at all. Next to each one: SPF pass or fail, DKIM pass or fail, and a message count.

The report does not tell you which of these servers send mail for you, which of yours are misconfigured, and which belong to someone else using your domain. You need those three answers before you move from p=none to p=reject, and the XML leaves all three to you.

Source Insights, on the Starter and Pro plans, now does that sorting. It groups the IPs into senders, gives each sender a verdict computed from your reports, and asks you one question per failing sender: is it yours?

From 40 IPs to a dozen senders

A DMARC aggregate report is keyed by source IP. People think in vendors: “our Google Workspace”, “the Mailchimp account marketing uses”. Source Insights groups the IPs in three steps.

1. First by provider. We maintain a catalogue that maps reverse DNS suffixes to providers. An IP whose PTR hostname ends in google.com or 1e100.net belongs to Google, protection.outlook.com to Microsoft 365, mcsv.net or mcdlv.net to Mailchimp. The catalogue also records what kind of sender each provider is: mailbox provider, email marketing, transactional email, security gateway, forwarding, or web hosting.
2. Then by PTR domain. When the hostname matches no catalogue entry, the sender is the registrable domain of its reverse DNS name, for example newsletter.example.net.
3. Every IP with no reverse DNS hostname goes into one group, Unresolved sources.

On our production data (30 days of reports across paid domains, measured on 19 September 2026), the median domain came out at 13 senders after grouping.

Six verdicts

A message counts as failing when it passed neither aligned SPF nor aligned DKIM, which is a DMARC fail. A sender needs attention when it has at least 10 failing messages in the selected window and those are at least 1% of its own volume. Below that, a few failures from a large sender are noise, and a handful from a small one are not worth a decision.

Each sender gets one of six verdicts:

Verdict	What it means	What to do
Cleared	Below the attention threshold, and not muted, marked Not ours or an unanswered forwarder	Nothing
Answer needed	Above the threshold, and nobody on your team has said whether it is yours	Answer Ours or Not ours
Fix needed	Above the threshold, and your team marked it Ours	Follow the fix hint on the card
Not yours	Your team marked it Not ours	Nothing to fix; under p=reject, receivers refuse its mail that fails DMARC
Forwarded	A forwarding service from our catalogue that you have not answered about	Nothing; forwarding fails SPF by design
Muted	Your team muted it	Nothing until someone unmutes it

On the same production data, 96% of sender groups, carrying 93% of the mail, needed no input from anyone. The median domain had one sender waiting for an answer.

One question, asked once

An Answer needed card reads “N messages failed DMARC. Do you send through X?” and offers two buttons.

Ours records that you send through this sender. Since it is failing, its verdict becomes Fix needed and the card shows a fix hint for its kind, a field for a one-line note (up to 200 characters), a Change button that switches the answer to Not ours (keeping your note), a Remove answer button that deletes it so the question comes back, and a button to mute the sender if you will not fix it now, for example a legacy system due to be switched off.

Not ours records that you do not send through it. The verdict becomes Not yours and the card folds away.

The answer is stored per domain and shared with everyone in the account, so a teammate who opens the page tomorrow sees your answer, your email address, and when you gave it. Answers are per domain: if the same Mailchimp account sends for two of your domains, answer on each.

An answer changes the verdict, never the traffic. Message totals, SPF and DKIM alignment, and dispositions stay exactly as the reports state them. In the Unresolved sources group, IPs you mark Not ours or mute no longer count toward the group’s verdict, so one answered IP cannot keep the whole group asking; the group’s failure count and pass rate still include them, as the reports state.

The reality check: failing does not mean hostile

A sender that fails DMARC is not automatically an attacker. Two cases produce failures from mail that is legitimate or may be yours.

Forwarding and mailing lists

When a mailbox forwards your message, the forwarder’s server delivers it from its own IP, which your SPF record does not list. SPF fails, and DKIM survives only if the forwarder leaves the message intact. Mailing lists that add a footer or rewrite the subject break DKIM too. None of this is fixable from your DNS; the forwarding and mailing lists post explains why. Forwarding services in our catalogue (Cloudflare, Apple, web.de and T-Online today) get the Forwarded verdict without any answer from you. A mailing list server outside the catalogue shows up as its own PTR domain and asks the question; answer Not ours. It is not a server you send through, even if the mail on it started as yours.

Servers with no hostname

The Unresolved sources group holds every IP without a reverse DNS name. Some of them can be yours: an office server, a scanner that emails PDFs, an app on a cloud VM that nobody gave a PTR record. The rest are someone else’s. Each IP in that group has its own Ours and Not ours buttons, because one group-wide answer would be wrong for most of them.

Senders that move between groups

Reverse DNS lookups run in the background after each report arrives. A new IP sits under Unresolved sources until its lookup completes. It then moves to its provider, or to its PTR domain when the catalogue does not cover that domain yet, and to the provider once it does. Answers follow the sender: a group with no answer of its own inherits the most recent answer given on one of its PTR domains, then on one of its IPs.

Working through the Answer needed list

The page puts senders that need an answer first, then senders that need a fix, then the rest by volume. Work from the top.

1. Read the card. It lists each IP with its hostname, message count, SPF and DKIM alignment, and dispositions. Every IP links to the reports that contain it, so you can see which receivers saw the traffic and on which days.
2. Find the owner. A provider name usually points to a team: Mailchimp to marketing, a helpdesk platform to support, a hosting company to whoever runs the website. The sender inventory post has a checklist of the usual suspects.
3. Answer Ours if you send through it, Not ours if you do not. If you cannot tell yet, leave it: it stays at the top of the page until someone answers.
4. Fix what is yours. Every Fix needed card carries a hint chosen by the sender’s kind.

What each fix hint means

Mailbox provider (Google, Microsoft 365, and similar)

The hint reads: “These failures usually come from a mailing group, a forwarding rule or an internal relay server.” Mail sent from your users’ mailboxes passes when your provider signs it with DKIM for your domain. Failing mail from the same provider’s IPs points to something else going out through it: a group or list that resends messages, a forwarding rule that sends mail back out, or an internal server that relays through the provider.

Email marketing and transactional email (Mailchimp, SendGrid, Amazon SES, and similar)

“In the provider’s settings, authenticate your domain (often called domain or sender authentication). This sets up DKIM and a custom Return-Path.” Without that step, the provider signs with its own domain and bounces to its own Return-Path, so SPF and DKIM pass for the provider and neither aligns with yours. The Mailchimp, SendGrid and Klaviyo post walks through each provider.

Security gateway

“Add the gateway to your SPF record, or have the gateway sign your mail with DKIM.” An outbound gateway relays your mail from its own IPs, so it has to be authorised in SPF or sign with a key published under your domain.

Web hosting

“Add the host to your SPF record, or send this mail through your mailbox provider instead.” Contact forms and CMS notifications often go out from the web server itself. Sending them through your mailbox provider over authenticated SMTP puts them on infrastructure your SPF record and DKIM keys already cover.

No hostname

“If this is your own server, add its IP to your SPF record and sign its mail with DKIM.”

Any other sender

“Add this source to your SPF record, or set it up to sign your mail with DKIM.”

When no sender is left at Answer needed or Fix needed, every sender still failing above the threshold is a forwarder, one you disowned, or one you muted. Check the muted ones before raising the policy: under p=reject, their failing mail is refused too. The enforcement rollout playbook covers moving the policy up in steps.

Your approved-sender list, in one tab

The All sources tab lists every sender seen within your retention window (90 days on Starter, 180 on Pro) in one table: kind, answer, verdict, messages and pass rate over the last 30 days, last seen, and who answered. Filters narrow it to Yours, Not yours, Cleared, Answer needed, or Muted.

A sender you answered about keeps its row after it stops sending, greyed out with no traffic. When the old newsletter tool comes back six months later, the answer is already there. The Yours filter is the list auditors and security questionnaires ask for: the services allowed to send as your domain, with who confirmed each one and when.

Take the verdicts out: CSV and API

Export CSV writes one row per IP. The original ten columns keep their order, and five columns follow: Kind, Verdict, Answer, Muted, and Note. The All sources tab exports the same columns.

The REST API returns the same data from GET /api/v1/domains/:id/sources. Each source carries verdict, kind, provider, grain and key, failing_messages, its IPs, and label, the answer your team gave (relationship, muted, note, updated_at), or null when nobody has answered. To list the senders waiting for an answer on one domain:

curl -s -H "Authorization: Bearer $DMARCTRUST_API_KEY" \
  "https://www.dmarctrust.com/api/v1/domains/ud_19/sources?range=30d" \
  | jq '.data.sources[] | select(.verdict == "answer_needed") | {key, failing_messages}'

Swap the filter for select(.label.relationship == "ours") and you have the approved-sender list for your CMDB. Loop over GET /api/v1/domains to repeat it for each of your domains. Answers are written in the dashboard; the API reads them. The API reference documents every field and each verdict value.

Which plans include it

Source Insights, its CSV export, and the API are part of Starter ($19/month, 2 domains, 90-day retention) and Pro ($49/month, 5 domains, 180-day retention). On the Free plan, the Source Insights page shows the domain’s message count and number of distinct sending IPs over the last 7 days, without the per-sender breakdown. The dashboard modules guide describes the page screen by screen, and pricing lists the plans. Start for free with aggregate reports for one domain.

FAQ

How do I know which DMARC sources are mine?

Group the IPs in your aggregate reports by provider, then check each provider against the tools your teams pay for or log into. Mailbox providers, marketing and transactional email services, helpdesks, and web hosts cover most legitimate senders. DMARCTrust does the grouping for you on the Starter and Pro plans and asks you to confirm each failing sender once, with an Ours or Not ours answer that the whole team then sees.

What does “Answer needed” mean in DMARCTrust?

It means a sender failed DMARC on at least 10 messages, amounting to at least 1% of its own volume, in the selected window, and nobody on your team has said whether you send through it. Answer Ours and it becomes Fix needed with a fix hint for its kind. Answer Not ours and it becomes Not yours.

Does marking a source “Not ours” block its mail?

No. The answer is a record in DMARCTrust; it changes the verdict and nothing else. Receiving mail servers decide what happens to failing mail based on your published DMARC policy. With p=reject, receivers that enforce DMARC refuse it.

Why does a sender I use fail DMARC?

Usually because it authenticates with its own domain instead of yours. SPF and DKIM pass for the provider’s domain, but DMARC requires one of them to align with the domain in your From address. Setting up domain authentication in the provider fixes that for email marketing and transactional services. For your own servers, add the IP to SPF and sign with DKIM.