Read delivery statistics

Smailor summarizes sending activity, bounces, and spam complaints for each of
your active domains. Use these signals to catch address-quality, authentication,
or reputation problems before they become a sustained delivery failure.

Where to find the data

Only domains used by active addresses on your account are included. A missing
domain may mean that no active address is currently attached to it.

What each metric means

Sent

A send is counted when Smailor accepts the outbound message into its delivery
pipeline for usage and reputation tracking. It does not prove that the recipient
placed the message in the inbox or read it.

Bounce

A bounce is delivery feedback indicating that a provider could not deliver a
message. Common classes include:

• Hard bounce: a permanent problem, such as an address that does not exist.
• Soft bounce: a temporary problem, such as a full mailbox or transient
  provider failure.

The event reason is more useful than the aggregate count. Repeated soft bounces
can become a reputation problem and should not be retried forever.

Complaint

A complaint is feedback that a recipient marked a message as spam. Complaints
are high-signal events: they indicate that the recipient did not expect or want
the message, regardless of whether the address was technically valid.

Not every mailbox provider sends feedback, and events can arrive after the
original send. A zero count means that Smailor received no events in that window;
it is not proof that every provider delivered every message.

How rates are calculated

For a domain and period with at least one tracked send:

bounce rate    = bounces    / sent messages × 100
complaint rate = complaints / sent messages × 100

Example:

Rates become volatile at low volume. One complaint in 20 sends is 5%, but it is
not statistically comparable to 100 complaints in 2,000 sends. Read the count,
rate, volume, and trend together.

How to interpret the trend

Smailor may classify a domain as healthy, watch, or blocked. The product's
current status and recommendation are authoritative because safety thresholds
can change.

As practical investigation triggers:

• a complaint rate near or above 0.3% is a serious warning;
• a bounce rate near or above 5% requires immediate list and address review;
• a sudden increase matters even when the absolute rate is still below a guide
  value;
• a clean aggregate can hide a failing campaign or recipient provider, so inspect
  recent event reasons.

These are diagnostic signals, not guarantees that a provider will accept or
reject mail at a specific value.

Investigation workflow

Rate changes
     |
     v
Confirm volume and time window
     |
     v
Group events by domain, campaign, and reason
     |
     +--> Invalid recipients? Remove and validate addresses
     +--> Authentication? Check SPF, DKIM, and DMARC
     +--> Complaints? Stop the source and review consent
     `--> Temporary provider failure? Pause and retry conservatively

1. Select the affected domain and the shortest period that shows the change.
2. Compare the current period with the previous normal period.
3. Read individual bounce or complaint reasons.
4. Identify the traffic source, audience, template, and sending address.
5. Pause the responsible workflow if continuing would create more harmful
   events.
6. Correct the source problem, then resume with a small controlled batch.

Respond to a high bounce rate

• Stop sending to addresses that hard bounced.
• Check form validation, imports, and data-entry sources.
• Remove stale lists and addresses that have never engaged.
• Use confirmed or double opt-in for new subscriptions.
• Verify that SPF, DKIM, DMARC, and the From address are correct.
• Separate transactional traffic from prospecting or marketing traffic.

Never keep retrying a permanent recipient error. It wastes capacity and signals
poor list management to receiving providers.

Respond to complaints

• Stop the campaign or automation that produced the complaints.
• Confirm how and when recipients consented.
• Make the sender identity and purpose recognizable.
• Make opt-out controls visible and honor them promptly.
• Check whether frequency increased or content changed before the spike.
• Suppress complainants from future mail.

Changing wording without fixing consent or targeting does not address the root
cause.

One-click unsubscribe for high-volume mail

Gmail treats a sender as a bulk sender when its primary domain sends close to
5,000 or more messages to personal Gmail accounts in a 24-hour period. Traffic
from subdomains counts together, and Gmail keeps the bulk-sender classification
after the first qualifying day. For bulk senders, marketing and subscribed
messages need both List-Unsubscribe: <https://...> and
List-Unsubscribe-Post: List-Unsubscribe=One-Click, plus a visible unsubscribe
link in the message body. The HTTPS endpoint must accept the one-click POST
without a login or confirmation step. Ordinary correspondence and transactional
mail should not acquire an invented unsubscribe action merely because the domain
has high volume.

Smailor's own outreach messages and follow-ups include the two headers and a
working opt-out link on every message. Applying this to the message category
from the start is safer than switching it on at message 5,000: Gmail counts by
primary domain across senders and keeps bulk status. The outreach sender also
caps each address at 120 messages per day. Smailor forwards the outreach headers
through its sender-node SMTP and provider routes. The relay rejects an outreach
job if either one-click header is missing or the unsubscribe URL is not HTTPS.
The normal composer is designed for correspondence. The public send API can
forward a customer-supplied one-click header pair, but the customer must host
the HTTPS POST endpoint, keep a suppression list, and include a visible opt-out
link in the body. See the send API reference.

See Gmail's sender guidelines
and bulk-sender FAQ.

Why counts may not match a provider dashboard

Smailor and an external provider may use different event times, deduplication,
retries, time zones, or definitions of accepted and delivered. When investigating
a difference:

1. compare the same domain and UTC/calendar window;
2. distinguish queued, provider-accepted, delivered, deferred, and bounced;
3. check whether the provider delayed or retried an event;
4. compare message identifiers where available.

API availability

GET /api/v1/domains returns a 30-day reputation summary for domains available
to the authenticated account. Smailor does not currently expose the full daily
Monitoring event stream as a separate public statistics endpoint.

See the REST API reference for authentication and response
behavior.

Ongoing health checklist

• Review domain trends at a consistent cadence.
• Assign an owner for bounce and complaint alerts.
• Suppress permanent failures and complaints.
• Keep consent evidence and unsubscribe handling current.
• Recheck authentication after DNS or provider changes.
• Warm new domains and traffic streams gradually.
• Investigate sudden changes by source, not only by domain total.

Related guides

• Email authentication
• Add a custom domain
• REST API reference