Bounces and Deliverability

Most email tools tell you that a send bounced. Leed can tell you which message to which person failed, and why, because every message goes out with a return address unique to that one recipient and that one send. When a receiving mail server rejects a message, its failure notice comes back to that address, and Leed knows exactly which row to write it on.

Bounce handling runs on every send on every plan. There is nothing to switch on.

How a bounce reaches Leed

The address a recipient sees is no-reply@ your public site domain. The address the mail system replies to is different: a per-recipient return path of the form bouncer+{batch}={contact}@b.leed.ai. A mail worker reads everything that arrives there, unpicks the batch and contact from the address, classifies the failure, and writes the result.

You never see that address and never need to configure it. It exists so a failure notice is attributable rather than anonymous — which is the difference between “12 bounces” and “these twelve people, and these three addresses are now dead”.

The three classes

Leed sorts every failure into one of three classes, and the class is what matters — the codes below are only how Leed arrives at it.

How a failure is classified

Leed reads the SMTP status code out of the bounce message — a three-digit basic code such as 550, optionally followed by an enhanced code such as 5.7.1 — and looks both up in the tables further down. If either is recognized, that decides the class.

If no recognized code is present, three fallbacks are applied in order:

1. The sender address contains complaints. Treated as a spam complaint.
2. The message body mentions a suppression list. Treated as a hard failure — the receiving system is refusing this address on purpose. Leed matches the token literally, and the token as shipped is misspelled, so this fallback fires on the misspelled form.
3. The message is an auto-responder. Out-of-office and vacation replies are identified from their headers (x-autorespond, auto-submitted, or a precedence of auto_reply) and ignored entirely — nothing is recorded, no flag is set, and the contact is unaffected. This is why a colleague’s holiday reply does not cost you a contact.

Anything still unclassified is recorded as code 000, an unknown soft failure. Nothing is silently discarded.

flowchart TD
    A[Bounce message arrives on the return path] --> B{Recognised SMTP code in the body?}
    B -- Yes --> C[Look up the basic and enhanced codes]
    C --> D{Class}
    B -- No --> E{Sender address mentions complaints?}
    E -- Yes --> S
    E -- No --> F{Body mentions a suppression list?}
    F -- Yes --> H
    F -- No --> G{Auto-responder headers?}
    G -- Yes --> I[Ignored — nothing recorded]
    G -- No --> J[Code 000, Unknown]
    J --> SOFT
    D -- hard --> H[Hard]
    D -- soft --> SOFT[Soft]
    D -- spam --> S[Spam]
    H --> H1[Flag the contact with the date and code]
    H --> H2[Mark the send bounced]
    H1 --> H3[Skipped by every future send]
    SOFT --> S1[Mark the send bounced]
    S1 --> S2[Address stays mailable]
    S --> P1[Mark the send unsubscribed]
    S --> P2[Write an opt-out, reason spam_complaint]
    P2 --> P3[Address permanently suppressed]

What each class does to the contact

Hard

The contact record is stamped with the bounce date and the code that caused it, and the send’s recipient row is marked bounced. From then on that contact is dropped twice over: once when a batch fans out, and again as the individual message is built. They stay in their contact groups and stay visible in Engage — they are simply never mailed again.

Soft

Only the send’s recipient row is marked bounced. Nothing is written to the contact. Your next blast tries the address again, which is the right behavior for a full mailbox or a busy server — but it also means a chronically failing address keeps consuming allotment and keeps depressing your rates without ever being suppressed.

Spam

The recipient row is marked unsubscribed, and an opt-out record is written against the contact carrying the reason spam_complaint. The suppression is permanent in practice: the newest opt record wins, and nothing in the CMS writes a newer one. The one thing that can — a later form fill on your own site — is covered in unsubscribes and opt-outs.

Reading the numbers

The Bounces column in Sent Emails counts recipients whose delivery failed for any reason other than a complaint — hard and soft together, undifferentiated. Complaints sit in the Unsubscribes column beside genuine unsubscribes, also undifferentiated. Neither column separates the two things inside it, so both numbers are directional rather than diagnostic.

They still tell you different things, and confusing them leads to the wrong fix:

• Bounces rising points at the list. Imported data going stale, addresses guessed rather than collected, a domain that has stopped accepting mail. The remedy is list hygiene.
• Unsubscribes rising on a list that used to be quiet points at the content or the cadence. The remedy is fewer, better-targeted sends — not a cleaner list.

A send with high bounces and low unsubscribes was mailed to the wrong addresses. A send with low bounces and high unsubscribes reached the right addresses with the wrong message.

SMTP codes Leed understands

The basic three-digit code carries the classification on its own; the enhanced code refines it. Either being recognized is enough, and a hard classification from either code flags the contact.

000 and 700 are Leed’s own: 000 is what an unclassifiable failure becomes, and 700 is what the complaint fallback assigns. Neither ever arrives from a mail server.

Every enhanced code Leed knows in the 5.x.x range is classified hard, so an enhanced code that is recognized at all is decisive. A code outside these tables is not treated as an error in itself — it simply fails to classify, and the message drops through to the fallback chain above.

Your side of deliverability

Leed sends as no-reply@ your public site domain. That is the whole point — mail from you looks like mail from you — and it means the records at your DNS provider, not anything inside the CMS, decide whether receiving servers trust it.

What Leed sets up for you. When your site’s domain is provisioned, Leed asks its sending provider to verify the domain and receives three DKIM records to publish. If you connect your domain through the guided flow, those records are published alongside your site’s own records automatically, together with the mail records the sending provider needs. If you manage DNS by hand, you publish them yourself. Domains and DNS covers both routes.

What is yours. SPF and DMARC are policies about your whole domain, not just about Leed, so they stay with you. If you already publish a DMARC policy, check that mail sent through Leed aligns with it before your first large send — a p=reject policy and an unaligned sender is the one configuration error that turns a good list into a wall of rejections.

What Leed does not offer. There is no sender-domain picker in the CMS: you send from your public site domain and nowhere else. There is no dedicated sending IP, no warm-up schedule, no per-send throttle, and no way to import a suppression list. If your program needs any of those, it needs a dedicated sending platform.

The hard-bounce flag itself is visible on each contact’s record in contacts, which is the fastest way to check why a specific person stopped receiving your email. There is no bounce-specific screen in the CMS; the numbers live on the send, and the flag lives on the contact.