Once aggregate reports arrive, SendOps groups every sender it sees into a source table. This is the page you will spend the most time on, and the word that causes the most alarm on it is **unknown**.

**Where to find it:** **Reports → Authentication**, then select a domain and open the **Sources** tab. The same page carries the pass-rate trend and TLS reporting for that domain.

If a domain shows "Not receiving reports" instead, it has not finished setup — follow the link to Infrastructure → Domain Auth and see [Setting Up DMARC Reporting](/domain-auth/setting-up-dmarc-reporting).


"Unknown" is a question, not an accusation. It means SendOps has not been able to prove the source is yours and you have not yet told it either way. In practice, the large majority of unknown sources turn out to be a service somebody at your company signed up for and forgot about.


## The four classifications

Every source group carries one of four effective classes.

| Class | What it means |
|---|---|
| **Your SendOps sending** | Proven to be your own mail, sent through your SES identity. |
| **Your SendOps sending, not aligned** | Your mail, but misconfigured. Not an attacker. |
| **Known** | You looked at it and confirmed it. |
| **Unknown** | Undecided. This is where you start. |

### Your SendOps sending

The strongest signal is the **DKIM selector**. Amazon SES issues three DKIM signing keys per domain identity, and SendOps already holds those selector tokens from when you verified the domain. When a report shows a message that carried a *verified* signature using one of your selectors, that message provably originated from your identity.

Nothing inferred from an IP address alone ever reaches this level of certainty. SES is a shared service — being inside its IP ranges proves the mail is SES and says nothing whatever about *whose*.

### Your SendOps sending, not aligned

This class deserves attention because it is the one most likely to be misread.

It means: **your own SES, sending as your domain, failing DMARC alignment.** There is no attacker here. It is almost always one of two things — a custom MAIL FROM that was never configured, or a DKIM key rotated in SES without the matching CNAME records being republished.


Reporting misconfigured first-party sending as an unknown source would send you hunting an attacker who does not exist, while the actual fault — yours, and fixable in minutes — goes unaddressed. SendOps separates the two deliberately.


The diagnosis attached to the source names the exact fix. See the table below.

### Known and Unknown

**Known** means you pressed Confirm. **Unknown** means nobody has decided yet.

New sources always arrive as unreviewed, even when SendOps recognises the provider by fingerprint. Recognising "this is SendGrid" says nothing about whether *you* are the one renting it this week, so an automatic confirmation is exactly how a spoofer riding a shared email service goes unnoticed.

## Why sources are grouped, not listed per IP

Providers rotate IP addresses constantly. A table with one row per IP asks you the same question forever, and a prompt that never ends is one people learn to dismiss without reading.

SendOps therefore groups sources, keyed on the most specific thing it can identify:

1. **Provider fingerprint** — a recognised email service
2. **ASN** — the network operator, when no fingerprint matches
3. **Network prefix** — a `/24` for IPv4, `/48` for IPv6, as the fallback

A coarser group is a weaker key, never a wrong one — it may bundle a little more traffic together than ideal, but it will not tell you something untrue about what it contains.

One exception is worth knowing: shared-infrastructure networks like AWS are never used as a group key. AS16509 is every AWS tenant on earth, so grouping on it would put your own SES and an EC2-hosted spoofer in the same row. Those sources fall through to prefix grouping instead.

## Confirm and Reject — and what Reject does not do

Two buttons, and the second one does not do what most people assume.

**Confirm** records that the source is yours or is authorised. It stops asking.

**Reject** records that the source is **not** yours.


Rejecting a source records your judgement that it is not yours. It does **not** mute it. A rejected source that keeps sending is precisely the thing you want to keep hearing about — a Reject button that quietly stopped the alerts would be the most dangerous control on the page.


Rejecting also does not block any mail. SendOps does not sit in your mail flow and cannot stop a third party sending. What tightening actually stops that traffic is a DMARC policy change, which you make yourself in DNS — see [Moving to p=quarantine and p=reject](/domain-auth/moving-to-quarantine-and-reject).

Your decision takes effect immediately, not at the next overnight classification run. And the nightly pass never resets your review state — a source you confirmed stays confirmed.

## The diagnosis codes

When SendOps can name *why* a source is failing alignment, it attaches one of seven findings. Each one is withdrawn automatically once you fix it — publish the missing record and watch the finding disappear.

| Diagnosis | What it means | What to do |
|---|---|---|
| `dkim_missing_cname` | A DKIM CNAME record is not published. | Publish the named CNAME. SendOps tells you the exact record. |
| `dkim_relaxed_only` | Signatures verify but only align under relaxed policy. | A policy choice, not a broken record. Usually fine. |
| `spf_mailfrom_unset` | No custom MAIL FROM is configured on the SES identity. | Set it in the AWS SES console. |
| `spf_mailfrom_broken` | A custom MAIL FROM is set, but its DNS records do not resolve. | Republish the MX and TXT records SES issued. |
| `third_party_unauthenticated` | A source you confirmed authenticates as nothing. | Ask the vendor to set up DKIM signing for your domain. |
| `forwarding` | Mail is being forwarded. | **Nothing.** See below. |
| `spoofing_suspected` | Meaningful volume, no authentication, not yours. | The one finding with no configuration fix. |

A few of these carry detail worth knowing:

**`spf_mailfrom_unset` points you at the AWS console, not a SendOps button.** Configuring a custom MAIL FROM is a write to the SES identity, and SendOps deliberately performs no identity writes. It also cannot name the records to publish, because SES only issues them once the MAIL FROM domain is set.

**"This record does not resolve" is always checked against live DNS**, never inferred from the reports. Reports are up to 24 hours old and you may have already fixed the problem.

## Forwarding is not an attack

This deserves its own section, because a reader who does not understand it will confirm and reject sources at random.

**Mailing lists and forwarders break SPF by design.** When someone forwards your message, or when it passes through a mailing list, the forwarding server sends it onward from *its* IP address — which is not in your SPF record and never will be. SPF fails. This is not a bug in forwarding, it is what forwarding is.

For most domains, forwarders are the **majority of all unaligned traffic**. A tool that reported them as attacks would be wrong about most of what a normal domain sees, and its users would rightly stop reading it.

SendOps identifies forwarding by the signal that separates it from an actual spoofer: **a forwarder's DKIM signature still passes and still aligns.** The message really did come from you; it just took an extra hop. A spoofer has no valid signature to forward.

A source diagnosed as `forwarding` needs no action from you, and it does not block a policy change.


One safeguard: `forwarding` only suppresses alerting when it describes the *entire* group. If a legitimate mailing list happens to share a network prefix with an unknown sender, SendOps will not let the forwarder's benign explanation quiet the whole row. And a source you explicitly **rejected** is never silenced by a forwarding diagnosis — your judgement outranks an inferred explanation for a neighbour's traffic.


## Pass rate

The pass rate is the share of reported messages that passed DMARC alignment — a message counts as passing if *either* SPF or DKIM aligned.

An unaligned forwarder lowers this number without anything being wrong. If your pass rate sits at 96% and the gap is entirely forwarding, that is a healthy domain, not a broken one. What matters when you come to tighten your policy is not the raw number alone but what sits underneath it, which is why the [policy readiness card](/domain-auth/moving-to-quarantine-and-reject) states each criterion separately rather than reducing everything to one score.

The domain page shows a one-line readiness verdict — "Ready to move to quarantine" or "2 criteria blocking promotion" — linking to the full card under Infrastructure → Domain Auth. If the blocker is unreviewed sources, that card links straight back here.

## Related

- [Setting Up DMARC Reporting](/domain-auth/setting-up-dmarc-reporting)
- [Moving to p=quarantine and p=reject](/domain-auth/moving-to-quarantine-and-reject)
- [DNS Configuration](/domains/dns-configuration)