# Deliverability

Connect sends through your own mailbox with your own provider, so the reputation being judged is your domain's, not a shared pool's. What Connect controls is discipline: one send boundary, evidence before a message is reported as sent, one compliance check before outreach, and no invented recipients. Whether a particular message reaches an inbox is never promised, here or anywhere.

- **Status:** Available
- **Audience:** both
- **Channels:** email
- **In the app:** #/inbox, #/settings
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/email/deliverability/

## Nobody can promise placement

Delivery is decided by the receiving side, using signals about your domain that were accumulating before Connect existed and rules that are not published. A product that promises inbox placement is promising something it does not control, and the promise is worth exactly as much as the control behind it.

The useful question is narrower and answerable: which of the things that influence delivery are inside this software, which are inside your own infrastructure, and which belong to nobody you can reach? The three lists below are that split.

## Inside Connect

- **One send boundary.** Every message — the engine's and a person's — leaves through the same place, so there is no second route that skips a check.
- **Evidence for sent.** A message is reported as sent only when the provider has acknowledged it, with a third state, *uncertain*, shown as uncertain rather than guessed, because re-sending on a maybe is how somebody receives the same message twice.
- **One compliance check.** Suppression, unsubscribes, complaints and do-not-contact instructions are asked together, before outreach, at the boundary rather than in each screen that could compose a message.
- **No invented recipients.** Connect does not guess a prospect's email; a contact has to be evidenced. This is the single largest lever on bounce rate, because assembled recipients are what produce runs of rejections.
- **A bounded rate.** The daily allowance bounds how much mail is processed, and when it is spent the work is held rather than dropped — the read cursor deliberately does not advance, because advancing it on a refusal is how a mail agent loses messages permanently.
- **Health that is not just 'connected'.** A mailbox that authenticates and returns nothing is recorded as quiet, which is a health verdict rather than an error.

## Yours, not Connect's

Mail goes out through the mailbox you connected — a Google account, a Microsoft one, or your own server over IMAP and SMTP. The sending identity is therefore yours, which is the good news and the whole of the obligation: nothing here is sent from a shared pool whose reputation you inherit, and equally nothing here can repair a reputation you already have.

| Thing | Where it is set | Why Connect cannot do it |
|---|---|---|
| SPF, DKIM and DMARC | DNS records for your sending domain | They are published by the domain owner; a mail client cannot assert them on your behalf |
| Domain and sending history | Accumulated by everything that has ever sent as you | Reputation is held by the receiving systems, not by any sender |
| Your provider's own limits | Your mailbox provider's account policy | Rate and volume caps belong to the account, and are enforced there |
| List quality you brought with you | Wherever the contacts came from | Connect will not guess an address, but it cannot verify one it was handed |

## Nobody's

Recipient-side filtering, corporate gateways, and the difference between a main inbox and a promotions tab are decisions taken by systems that publish neither their rules nor their reasons, and that change them without notice. Treat any advice that claims to guarantee a folder as guesswork with confidence attached.

> **Note** One thing Connect deliberately does *not* do is fetch remote images into a reader's browser: incoming mail is rendered with images proxied and the HTML sanitised, so opening a message does not tell its sender that you opened it. That is a privacy choice on the reading side, and it is worth knowing that other people's tracking of your opens works the same way in reverse.

## The order worth fixing things in

1. Authenticate the sending domain. Until SPF, DKIM and DMARC line up, everything below this is noise, because a receiving system that cannot verify you has already decided.
2. Send only to recipients you can evidence. A run of permanent bounces is read as a statement about the sender, and it is the fastest way to damage a domain that was fine yesterday.
3. Honour opt-outs the moment they arrive, and record them with their origin so the next run knows.
4. Watch complaints rather than volume. A complaint is a recipient saying your mail was unwanted, which is more informative than any count of sends.
5. Keep the rate steady. The daily allowance is a bound, not a target, and a sudden burst from a quiet domain is itself a signal.
6. Write mail somebody would answer. Relevance is not a deliverability trick, but it is the only durable input to every signal above.

The first two account for most real problems. The rest are worth doing and will not rescue a domain that fails either of them.

## Questions

### Does Connect improve our deliverability?

It improves the discipline that feeds it: one path out, provider evidence before anything is called sent, one compliance gate, and no invented recipients. It does not change your domain's history, it does not publish your DNS records, and it cannot promise placement.

### Do you send from your own servers or from ours?

Through the mailbox you connected — Gmail, Microsoft Graph, or your own IMAP and SMTP server. The sending identity and its reputation are yours, which is why the authentication records for your domain matter more than anything in this product.

### A message says uncertain rather than sent. Is that a delivery problem?

It is an evidence problem, which is different. The provider has not acknowledged the message, so claiming it was sent would be a guess. It is shown as uncertain deliberately, and it is not resolved by sending again automatically.

## Related

- [Sending email](https://connectbyjbrh.com/docs/email/sending/)
- [Proof that a message was sent](https://connectbyjbrh.com/docs/email/send-evidence/)
- [Bounces](https://connectbyjbrh.com/docs/email/bounces/)
- [The suppression list](https://connectbyjbrh.com/docs/email/suppression-list/)
- [Connect does not guess email addresses](https://connectbyjbrh.com/docs/prospects/no-guessed-email/)
- [Why 'sent' must require provider evidence](https://connectbyjbrh.com/research/provider-evidence-for-sent/)

## What this page is based on

- `docs-source/sources/CHANNELS.md` §1 — mailboxes, sending, compliance and rendering
- Connect capability registry (docs-source/facts.py) — CHANNELS['email'], send_evidence, no_guessed_email
- `docs-source/sources/CHANNELS.md` §1 — the daily allowance and the read cursor