Revenue

Deliverability

Your sending domain is an asset you can destroy in an afternoon and spend months rebuilding. This page is the short list of what protects it in Genosyn — the suppression list, unsubscribe links, bounce handling and send caps — and what to do if you have already done the damage. Read it before you turn on autoSend.

The suppression list

A Suppression is an address this company must never email. The list lives at Revenue → Suppressions, searchable and filterable by reason.

unsubscribe
They asked to stop. Only a human may remove it, and the UI warns first.
bounce
The address is dead. Mailing it again is what tells a provider you do not clean your list.
complaint
Somebody marked your mail as spam. The most expensive signal there is.
manual
Somebody added it deliberately.
imported
Carried in from another system's opt-out list.

All five block equally; the reason exists for the human reading the audit trail. The list is scoped to the company, not to a mailbox: a person who unsubscribed from one of your addresses has not consented to hear from another one, and the reputational damage of getting that wrong lands on the whole domain either way.

Adding an address is idempotent — suppressing one that is already suppressed changes nothing and keeps the original reason, so a bounce report arriving twice is harmless. If you are moving from another outbound tool, export its opt-out list and import it here before you send anything. That is the single highest-value five minutes in this page.

Do not contact vs. suppression

They are different objects and both are checked on every send. A Suppression says never mail this address. Do not contact, the flag on a Contact, says never contact this person — and blocks every address you hold for them, including ones that were never suppressed individually. Use the contact flag when somebody asks you to stop by phone or in a meeting.

Sending refuses suppressed recipients

The check sits at the single outbound choke-point, so it covers every path equally and there is deliberately no way to send that skips it:

  • a Member pressing Send or Reply in the inbox;
  • a bulk send from the Drafts review queue;
  • a Sequence step, whether or not autoSend is on;
  • an AI employee calling its mail tools, at any grant level, including the gmail_* tools from the Google connector.

For a single message the refusal is all or nothing: if any recipient in To, Cc or Bcc is blocked, the send fails and names the addresses. Quietly delivering to three of four recipients is a bug the sender discovers weeks later, if ever. For a sequence the behaviour is the tolerant one — a blocked contact is skipped with the reason recorded on the enrolment, and the other ninety-nine go out.

Unsubscribe links and one-click

Outbound mail carries an unsubscribe link in its footer and the RFC 8058 header pair that makes Gmail and Outlook render their own native Unsubscribe button next to your sender name, with a mailto: fallback for older clients. Gmail and Yahoo expect at least one of those on bulk mail; without them, the only way a recipient can stop you is the spam button.

Four properties of that link, because each one exists to stop a specific failure:

  1. It never expires. A dead unsubscribe link is a compliance failure and, practically, a spam complaint. Links keep working years later.
  2. It needs no login and no JavaScript. Gmail's servers POST the URL themselves the moment somebody presses the native button — no cookie, no browser, no human present.
  3. It is idempotent. The mail client's POST and the recipient's later click on the footer link both succeed, and the timeline records the opt-out once.
  4. A bad or unknown token reveals nothing. Tampered, truncated and simply unrecognised links all render the same neutral page, so the endpoint cannot be used to test whether an address is in your system.

One click writes three things: a suppression with reason unsubscribe, an unsubscribe activity on the contact's timeline, and a stop on every live sequence enrolment for that person. There is nothing to process afterwards.

Bounces

Mail sync reads the delivery reports that come back to the mailbox. A report from a mail daemon — mailer-daemon@, postmaster@ and the other addresses reserved for exactly this — carrying a permanent failure (a 5xx reply or a 5.x.x status) is treated as a hard bounce: the failed address is suppressed with reason bounce, the contact is stamped as bounced, a bounce activity lands on the timeline, and any live sequence enrolment stops.

Soft failures — a full mailbox, a temporary defer — are not suppressed, because the address is fine and will accept mail tomorrow. Vendor envelope senders like bounces@ are deliberately not treated as daemons either; they are also used for ordinary bulk mail, and treating one as a bounce report would let a newsletter suppress your contacts.

Send caps and windows

Volume and timing are per-sequence, set in the sequence builder and described in full under Sequences:

  • Daily cap — the maximum touches a sequence may produce in a day, default 50. Both sent and drafted touches count. 0 means uncapped; it is not a setting for a sequence you have not watched run.
  • Send window — weekdays 08:00 to 17:00 in the timezone you choose, by default. Mail that lands at 3am reads as automated however good the copy is.
  • Per-sweep budget — the scheduler dispatches a bounded number of touches per pass across the whole installation, so a backlog trails rather than bursting.

If you are sending from a domain with little history, start far below these defaults. A new domain that emits two hundred cold emails on its first day is indistinguishable from a compromised account. Ramp over weeks, keep replies high and complaints near zero, and let volume follow engagement rather than ambition.

If the domain is already burned

The symptoms: replies stop, open rates collapse, customers say your mail lands in spam, or your own transactional mail — invoices, password resets — starts going missing. What to do, in order:

  1. Stop sending outbound entirely. Pause every Sequence, disable every Signal whose action enrols or hands off, and turn off autoSend. Every additional message makes the hole deeper.
  2. Find out what you sent. The per-step run history on each enrolment records exactly what went to whom and when, and what was skipped. Read it before you theorize.
  3. Clean the list. Suppress every bounced and unresponsive address, import any opt-out list you had elsewhere, and delete the source of the addresses if you cannot say where they came from.
  4. Protect the transactional path. Move invoice, receipt and password-reset mail to a subdomain or a separate sending identity that has never carried cold outbound, so the business keeps working while the reputation recovers.
  5. Fix authentication and monitor it. Confirm SPF, DKIM and DMARC pass, and watch the DMARC aggregate reports rather than guessing.
  6. Rebuild slowly, to people who reply. Weeks of low-volume mail to engaged recipients is what restores a reputation. There is no faster route, and buying a fresh domain to escape the problem simply moves it, because the behaviour that burned the first one is still in your process.

Then change the thing that caused it. In practice it is almost always one of three: a list you did not earn, autoSend enabled before anybody read the drafts, or a Signal with no dedupe column re-firing the same people every tick.

Advanced

The unsubscribe endpoint must be publicly reachable

Unsubscribe links are served from /u/<token> at the root of your install, outside every auth, session and origin check — because the caller is a stranger's mail client. If your Genosyn instance is only reachable on a VPN or an internal hostname, those links do not work for recipients, and one-click unsubscribe fails silently at Gmail. Set the instance's public URL to something the internet can resolve before you send outbound mail. A reverse proxy must pass POST /u/* through unmodified; it carries no Origin header and needs no body.

Rotating the encryption secret invalidates outstanding links

Unsubscribe tokens are signed with a key derived from security.encryptionSecret in config.ts. Changing that secret makes every link already sitting in somebody's inbox stop verifying, and a dead unsubscribe link is the thing this whole page exists to avoid. If you must rotate it, expect complaints from anyone who tries to opt out of older mail, and be ready to suppress those addresses by hand.