Glossary
This page defines email and atproto terms used in the Comail docs. Each entry links to a specification or guide with more detail.
Use this page when you need to check a term or acronym.
atproto
Section titled “atproto”Atmosphere
Section titled “Atmosphere”The ecosystem of apps and services built on the AT Protocol. It includes Bluesky and many independently operated services. “Atmosphere” does not mean that those services share one operator or account system. Atmosphere Mail LLC is the company that operates Comail; it is one organization in the wider Atmosphere.
See Comail, Marque, and atproto.
Decentralized Identifier. A short string that uniquely names a person or service on atproto. Looks like did:plc:abc123… for accounts hosted on a community PDS or did:web:example.com for accounts that publish their identity from a domain you control.
A DID is the only identity comail uses to authenticate sends. The handle attached to it (e.g. you.bsky.social) is a human-readable alias that can change; the DID does not.
Spec: W3C DID Core 1.0. atproto-specific resolution: atproto.com/specs/did.
Handle
Section titled “Handle”The human-readable alias for a DID. Either a bsky.social subdomain (alice.bsky.social) or a custom domain (alice.com). Handles point to a DID via DNS TXT or HTTP /.well-known/atproto-did. comail accepts either form at signup and resolves it to the DID.
Personal Data Server. The atproto server that hosts an account and its public repository of records, such as posts, follows, and attestations. A DID document says which PDS currently hosts the account.
With your approval, Comail can publish an email.atmos.attestation record to your PDS during domain setup. The record describes the enrollment; it does not contain your mail or API keys.
Jetstream
Section titled “Jetstream”The Bluesky-operated atproto firehose with JSON output. comail’s labeler subscribes to Jetstream filtered to the email.atmos.attestation collection so it can react when you publish or update an attestation record.
Reference: github.com/bluesky-social/jetstream.
A signed assertion published by a labeler about a DID, account, or post. Comail can issue verified-mail-operator, relay-member, and, when configured reputation checks pass, clean-sender. Any atproto client can query public labels.
Spec: atproto.com/specs/label.
Email authentication
Section titled “Email authentication”Authoritative DNS
Section titled “Authoritative DNS”The DNS servers that publish the official records for a domain. Your registrar may also be your DNS provider, but those are separate jobs: the registrar records who controls the domain, while the authoritative DNS servers answer queries for records such as DKIM, SPF, DMARC, and MX.
DomainKeys Identified Mail. A cryptographic signature in the message headers that lets receivers confirm the sending domain authorized the message. The signer publishes the public half in DNS as a TXT record; the signing software uses the private half.
Comail signs outbound messages with a DKIM key for your domain and an operator key under atmos.email. Your domain’s signature can align with DMARC. Receiving providers decide how to use the operator signature. See DNS records for the records you publish.
Spec: RFC 6376.
Sender Policy Framework. A DNS TXT record at your domain’s apex that lists which IP addresses are authorized to send mail claiming to be from that domain. Receivers check it against the connecting IP.
You publish one SPF record per domain you enroll, including comail’s relay IP. The relay’s IP appears in the value the enrollment flow gives you.
Spec: RFC 7208.
Domain-based Message Authentication, Reporting, and Conformance. A policy you publish at _dmarc.your-domain.com telling receivers what to do with mail that fails DKIM and SPF alignment. Policies are none (just monitor), quarantine (deliver to spam), or reject (refuse the message).
Comail requires quarantine or reject on enrolled domains. Receiving providers apply their own policies to mail that fails authentication.
Spec: RFC 7489.
Alignment
Section titled “Alignment”A DMARC check that the DKIM d= domain (or the SPF Mail-From domain) matches the visible From: domain. Alignment is what stops a phisher from sending DKIM-signed mail from a domain they happen to control while spoofing yours in the visible From: header.
comail’s dual-DKIM scheme satisfies DMARC alignment via the d=your-domain.com signature.
Feedback and bounces
Section titled “Feedback and bounces”Mail Exchanger record. A DNS record that points a domain at the mail server that accepts inbound mail for it. Receivers look up the MX of your From: domain to find where to deliver bounces and where to send mail addressed to you.
comail does not require you to point your MX at the relay for sending. You only point an MX at us if you want reply forwarding.
Mail Transfer Agent. The software that moves email between servers using SMTP. comail’s relay is an MTA. So is Postfix, Sendmail, and the box on the other end of every MX record.
Delivery Status Notification. The bounce email a receiving server sends back when delivery fails. Format is RFC 3464 (three MIME parts: human-readable explanation, machine-readable status fields, original headers).
The relay receives DSNs on port 25, parses them, attributes the bounce to your member record via the VERP Return-Path (bounces+<member-hash>+<recipient-hash>@atmos.email), and forwards the original DSN to your domain’s reply-forwarding address if set. See Bounces.
Spec: RFC 3464.
Abuse Reporting Format. The standardized format a mailbox provider uses to send a complaint report when a recipient clicks “Report spam.” Contains the complained-about message headers plus a Feedback-Type field.
Comail can process ARF reports from providers such as Microsoft and Yahoo. Gmail’s feedback program provides aggregate signals rather than recipient-level ARF reports. See Feedback loops.
Spec: RFC 5965.
Feedback Loop. A provider program that sends complaint reports to a sender. Available programs and registration rules vary by provider. Examples include Microsoft JMRP and Yahoo CFL.
Comail’s operator manages provider registrations for the shared sending infrastructure. Available reports depend on the provider and registration status.
Variable Envelope Return Path. A technique where the envelope sender (MAIL FROM:) is rewritten to encode information about which message and which recipient a bounce relates to. comail uses VERP to attribute bounces back to specific members without needing a per-message database lookup.
The Return-Path: header on outbound mail looks like bounces+<encoded>@atmos.email. Recipients usually don’t see this; only their mail server does.
Suppression list
Section titled “Suppression list”The per-member record of addresses that the member must not send to. Entries can come from operator action, bounces, complaints, provider reports, or unsubscribe requests. Recognized user-initiated transactional mail can bypass unsubscribe-only entries; other suppression entries still block it. See Bounces and suppression.
comail-specific
Section titled “comail-specific”Marque
Section titled “Marque”An independent atproto-native domain registrar and DNS service operated by Padding Labs LLC. Marque can store DNS instructions in an at.marque.dns record on your PDS and synchronize them to your domain’s authoritative DNS servers. When a domain is managed there, Comail can add its required DNS records with your approval. Marque is optional; manual DNS setup works the same way.
See Comail, Marque, and atproto and marque.at.
Attestation
Section titled “Attestation”A public record of type email.atmos.attestation that you approve during domain setup. It connects your DID to an enrolled domain and lists the DKIM selectors Comail expects to find in DNS. The labeler reads it to know what to verify. It does not contain message contents, recipients, API keys, or private DKIM keys.
Address offering
Section titled “Address offering”A domain owner’s configuration for receiving-address requests. The owner can set who is eligible, whether requests need approval, and whether an address can receive, send, or both. Publishing an offering through the owner’s PDS is planned. It is separate from the domain’s sending warm-up.
Sending domain
Section titled “Sending domain”A domain you have enrolled with comail. Distinct from your atproto handle (though they can be the same string). You can have multiple sending domains per DID.
Member
Section titled “Member”A DID that has completed signup with comail. A member can hold zero or more sending domains.
Warming
Section titled “Warming”The period when Comail applies lower sending limits to a new domain. See Warming tiers.
Operator
Section titled “Operator”The person or organization that runs a Comail relay. Atmosphere Mail LLC is the current operator. Multi-operator federation is design work and is not available.
Adjacent concepts
Section titled “Adjacent concepts”These come up in mail circles often enough to be worth knowing, even though comail does not require you to act on them today.
Authenticated Received Chain. A mechanism for preserving authentication results across forwarding hops so a mailing list or relay can pass DMARC even when it modifies the message. Not yet used by comail. Spec: RFC 8617.
Brand Indicators for Message Identification. A scheme for publishing a logo through DNS. Display depends on the receiving provider and its requirements. BIMI can require DMARC enforcement and a Verified Mark Certificate. Comail does not configure BIMI. Reference: BIMI Group.
TLS-RPT and MTA-STS
Section titled “TLS-RPT and MTA-STS”Two opt-in standards for encrypted SMTP transport. TLS-RPT (RFC 8460) publishes a reporting endpoint; MTA-STS (RFC 8461) publishes a policy. Neither is required for sending through comail. Both are reasonable to add if you operate inbound mail and care about transport security.