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 ten 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. |
| `suite_signing_as_itself` | Google Workspace or Microsoft 365 is signing with **its** domain, not yours. | Turn on DKIM at the provider. See below — this mail is passing today. |
| `forwarding` | Mail is being forwarded. | **Nothing.** See below. |
| `relay_breaking_alignment` | A named forwarder is re-sending your mail and breaking the signature. | **Nothing you can publish.** See below. |
| `spoofing_suspected` | Meaningful volume, no authentication, not yours. | One of two findings with no configuration fix. |
| `distributed_spoofing` | Hundreds of separate addresses sending as you, each too quiet to flag alone. | Nothing per-source. The remedy is enforcement. |

A few of these carry detail worth knowing:

**`suite_signing_as_itself` is the only finding here about mail that is passing today.** Your Google Workspace or Microsoft 365 mail is signed with the provider's own domain rather than yours, because DKIM was never set up for your domain. The signature is valid — and DMARC only counts a signature that carries *your* name, so this mail is passing on SPF alone.

That holds exactly until somebody forwards it. Forwarding breaks SPF, and with no DKIM signature of yours there is nothing left to pass on, so it fails at the moment you cannot see it. This is why nothing else ever caught it.

The fix is one setting and one DNS record in your provider's console — Google's *Authenticate email*, or Microsoft's DKIM page under email authentication settings. SendOps links the vendor's own page rather than writing its own version, and gives you the menu path for whichever provider you are on.


On Microsoft 365, no DKIM signing happens for custom domains until you turn it on. Finding this on your domain does not mean somebody misconfigured something — it means nobody has done the step yet.


**`relay_breaking_alignment` has no fix on your side, and that is the point of naming it.** A forwarder SendOps can name is re-sending your own mail and breaking the signature in transit. Your recipients chose to forward; you cannot publish anything that changes that, and hunting for a record to fix is time wasted.

What it does change is what publishing costs you. This mail is yours, it will stop arriving under a stricter policy, and because you cannot reach it SendOps leaves it out of the readiness verdict — and then asks you to [acknowledge it](/domain-auth/moving-to-quarantine-and-reject#accepting-a-cost-before-you-publish) before handing you the record, so the cost is not discounted silently.

**`distributed_spoofing` is a fact about your domain, not about one source.** Somebody is sending as you from **50 or more separate addresses**, each too quiet to raise a finding on its own — which is exactly how a campaign evades a per-source floor. It is stated once, for the domain, and there is **nothing to confirm or reject**: this mail is not yours, no per-source decision is available, and the remedy is enforcement rather than triage.

Its volume is subtracted from your pass rate, because it is mail you never sent and a number that moves when a stranger spoofs you is a number you cannot act on. It stays visible in the campaign card on the Overview.

**`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.


## What SendOps tells you about a source

Beyond the classification and the diagnosis, a row can carry short **annotations** — sentences describing what a source *is*, rather than findings about it. They come in four kinds:

| Kind | Shown as | What it does |
|---|---|---|
| Identity | *What this is* | Names the service. "This is Zendesk" is often the whole answer to an unknown row. |
| Infrastructure | *How it travelled* | The path the mail took to get there. |
| Caution | *Worth knowing* | Stops you over-reading an identification. Asks nothing of you. |
| Gap | *Missing setup* | Something incomplete, with the fix named. |

Each carries how far SendOps stands behind it — **Confirmed** (the vendor's own documentation says so, or we checked live DNS ourselves) or **Strong** (several credible sources agree, but no vendor document states it outright). Nothing weaker than that is shown at all.


An annotation naming a service is **not** a reason to confirm the row. Recognition tells you what the mail is; confirming tells SendOps the mail is *yours*. A caution exists precisely to stop that jump, which is why it is never dressed up as a task to clear — the only way to "complete" one would be to confirm the source, which is the mistake it is warning you about.


### When a source is a shared sending pool

Some senders — large ESPs and transactional providers — send everybody's mail from the same addresses. When you go to confirm one of these, SendOps asks a question instead of accepting the answer, because knowing the mail came through a given vendor tells you **which service it left through, not who sent it**. Anyone can open an account there.

The dialog gives you both branches:

- **If it is you** — complete that vendor's domain authentication so it signs as your domain. Until that is done, your mail through that pool genuinely cannot be told apart from anyone else's. SendOps links the vendor's own setup guide.
- **If you do not use them** — somebody else is sending as you through a service anyone can rent. Reject the source, and treat it as a reason to keep tightening your policy: enforcement is what stops it arriving.

## 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.

### The rate is measured over mail you could have authenticated

Three populations are subtracted before the rate is computed, each for a stated reason and each still counted somewhere you can read it:

- **A distributed spoofing campaign** — mail you never sent.
- **Sources you have rejected** — mail you have said in as many words is not yours. It stays visible in the impact preview.
- **Your own mail broken on a forwarder's relay path** — this one *is* yours, and it stays in the impact preview at **full weight**. It leaves the rate only because you cannot reach it, which is why publishing past it needs an [acknowledgement](/domain-auth/moving-to-quarantine-and-reject#accepting-a-cost-before-you-publish).

None of this is leniency, and the same figure is used everywhere: the Overview and the readiness card quote **one** pass rate for a domain, over the same window.

### Alignment breadth: how much survives a forward

Beside the pass rate, the Overview states how much of your **passing** mail passes on **both** SPF and DKIM rather than on one.

This matters more than the rate itself for a domain about to tighten. A domain at 99% whose passes are almost all SPF-only is one forward away from failing — SPF is the leg forwarding destroys, and a recipient setting up a forward is not something you can prevent or even see. A domain at 99% on both mechanisms is solid. **The pass rate is identical for both.**


Alignment breadth is a fragility warning, never a criterion. It does not block a policy move: the remedy is a DKIM key at a third party on their timetable, and a domain forwarded to by strangers cannot make forwarding stop.


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 — and why the criterion that actually decides is counted in **messages a day**, not as a percentage.

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)
- [Change History](/domain-auth/change-history) — what changed on this domain, and whether it worked
- [DNS Configuration](/domains/dns-configuration)