Member labels, deep

Comail publishes some member status as signed atproto labels. Anyone on the network can read them.

The labels overview explains verification, relay membership, and the optional clean-sender label. This page describes the public labels and internal safety signals, and explains how they affect sending.

What a label is

A label is a small signed record asserting one thing about one subject. The subject is a DID. The assertion is a short string (verified-mail-operator, relay-member, burst_warming). The signer is the comail labeler at labeler.atmos.email. Every record includes a creation timestamp and a neg boolean that flips the assertion off when the underlying fact stops holding.

The labeler stores signed records in its own database and serves them over the atproto XRPC endpoint com.atproto.label.queryLabels. There is no comail-specific API to query labels. Any client that already knows how to read Bluesky labels reads ours unchanged.

The attestation chain

A label exists because something proved itself worth labeling. For comail members that proof lives in a record on the member’s own PDS, in the email.atmos.attestation collection. The labeler subscribes to the atproto firehose (Jetstream) filtered to that collection, and reacts to writes.

The attestation declares the sending domain and its DKIM selectors. When the labeler sees a new or updated attestation, it checks that the DID controls the domain and verifies its SPF, DKIM, and DMARC records. MX is checked for diagnostics but is not required for a sending-only domain. A failed check leaves that attestation unverified. Another verified domain owned by the same DID can still support its labels.

When both checks pass, the labeler issues verified-mail-operator for the DID. If the attestation also opts the DID into relay membership, it issues relay-member. The clean-sender label is issued only when the labeler has a reputation service configured and the DID meets its checks. The labeler signs each record before it stores it.

The loop is incremental. Adding a domain runs the same path for the new attestation. Removing a domain (or letting DNS lapse) flips verified=false, and ReconcileLabels recomputes the desired set across every attestation the DID still owns. A label stays active as long as at least one verified attestation supports it.

The two label sources

There are two distinct sources of labels, and they behave differently.

The first source is the labeler itself, described above. It produces labels rooted in proof by checking whether a DID published the records it claims to have published. These labels are queryable through the public XRPC endpoint.

The second source is the relay’s trust and safety service, Osprey. It evaluates relay activity and returns private signals, such as burst or suspension status. The relay uses those signals when it decides whether to accept a message. They are not available through the public label endpoint.

Both end up as strings attached to a DID, but only the first set is queryable publicly.

The full label vocabulary

These are the labels you might see attached to a DID, where each one comes from, and what the send pipeline does about it.

verified-mail-operator

Source: labeler. Issued when: domain control is proven and the attestation’s SPF, DKIM, and DMARC checks pass. Effect on sending: the API key is minted at enrollment regardless, but the SMTP AUTH path (and the HTTP send path) refuse submissions from a member whose DNS gate hasn’t passed. In practice the label tracks whether DNS is live and is the signal the send path uses to accept versus reject. A member who lost DKIM (record removed, key compromised) will have the label negated and submissions will fail.

relay-member

Source: labeler. Issued when: the attestation is verified and the record sets the relay-membership opt-in. Effect on sending: required alongside verified-mail-operator. The relay refuses authorization when either label is missing. A member-store entry alone does not satisfy this check.

The relay caches the combined label decision for five minutes for members with fewer than 100 sends, or one hour for established members. An unexpired cached decision remains usable during a labeler outage. Once it expires, a failed lookup rejects authorization rather than extending the old decision.

clean-sender

Source: labeler. Issued when the DID has verified relay membership, is not suspended, and meets all of these conditions:

• At least 50 messages in the last 30 days, with a hard-bounce rate below 5% and a complaint rate below 0.1%.
• A fresh green evaluation from Sentinel, the relay’s behavior monitor.

The labeler issues clean-sender only when its reputation service is configured. If that service or Sentinel data is unavailable, it does not issue the label. It can issue the label later if the checks pass.

Effect on sending: none directly. The label is a signal to outside readers, not an input to the relay’s own policy. The relay already knows the underlying metrics.

highly_trusted

Source: Osprey rule output. Issued when: a relay-internal rule flags a member as well-established (manual operator add, long clean history, etc). Effect on sending: skips warming and uses the member’s configured hourly and daily limits.

burst_warming

Source: Osprey rule output. Issued when: a warming-tier member exceeds the expected curve (rule-defined threshold). Effect on sending: hourly limit multiplier of 0.5. The member’s effective hourly cap is halved until the label clears. Composes with highly_trusted: an operator override that skips warming can still be throttled if behavior looks bursty.

auto_suspended

Source: Osprey rule output. Issued when: a rule trips that warrants immediate suspension (extreme velocity, critical bounce rate, complaint spike). Effect on sending: hard reject at submission time. The SMTP layer returns 535 5.7.1 at AUTH time, with a message directing you to GET https://smtp.atmos.email/member/status?did=... (with an Authorization: Bearer header) to check status. (The auto_suspended by T&S rules string is the policy reason recorded in the log, not the SMTP response wording.) The label clears manually after operator review.

shadow:<name>

Source: Osprey rule output, observation mode. Issued when: a rule is running in shadow mode to evaluate its impact before promotion. Effect on sending: none. Comail keeps these signals private for operator review.

Querying labels yourself

Labels signed by the labeler live behind the standard atproto endpoint. Any DID is queryable by anyone:

curl "https://labeler.atmos.email/xrpc/com.atproto.label.queryLabels?uriPatterns=did:plc:your-did"

The response contains a page of label history for the subject, including positive and negated records in issuance order. Follow the returned cursor to read subsequent pages before deciding current state. A label is active if the latest record for that (subject, value) pair has neg=false or omits neg. Each label identifies its signer in src so consumers can verify the signature against the right key.

Osprey-sourced labels (highly_trusted, burst_warming, auto_suspended, shadow variants) are not in this public response. The authenticated GET https://smtp.atmos.email/member/status endpoint keeps its labels field limited to the labeler-issued view, but its safety object reports the effective Osprey gate used by SMTP: whether sending is allowed, the stable reason code, whether a block is temporary, and any warming or hourly-limit modifier. The underlying private label set is not exposed wholesale.

Negation, in practice

The labeler does not delete records. When a fact stops being true, it writes a fresh record with the same subject and value plus neg=true. A consumer evaluating a label’s current state looks at the latest record. This matches atproto’s general approach: history is append-only, current state is a fold over time.

The labeler can negate a label after a domain check fails, an attestation is removed, or an operator revokes it. The timing depends on the check or action that triggers the change.

Why the public labels are available

Public labels let members and other atproto services read the labeler’s current statements. A member can inspect the attestation and DNS state when they dispute a label. Another relay can read these records without access to Comail’s internal database.

Comail serves public labels through the standard atproto XRPC endpoint. Internal trust and safety signals remain private.

Related

• Atproto labels overview: verification, membership, and optional sender reputation
• Warming tiers: how the tier system interacts with label-driven policy
• Bounces and suppression: the underlying signals that feed clean-sender and auto_suspended

Back to docs