Documentation

When a message does not arrive

Documentation

Work down this list in order. It is arranged by how often each thing turns out to be the cause, not by how interesting it is.

1. Was there anything to send it?

Check that a rule exists. Editing the wording of a message does not make it send; an automation is what fires it. A template somebody carefully rewrote, with no rule behind it, is the single most common cause of "the client never got the email".

2. Did the system try?

Open the inspection and look at the delivery record — the Communication card, covered in Managing an inspection. Or look at the recent log on the automations page for a workspace-wide view.

Three outcomes, and they need different responses:

What you see	What it means	What to do
Nothing at all	No attempt was made	Back to step 1
Skipped	The system declined to send	Read on — this is a configuration answer
Failed	It was attempted and rejected	The error is on the row
Sent	It reached the provider	Jump to step 5

3. Skipped: why the system declined

Skipped is not a failure, and it is not an outage. The common reasons:

No consent on that channel. Texts require consent, and the check is not bypassable — not even by a test send. A test to a number that replied STOP is refused too, deliberately: honouring an opt-out does not depend on what the first message was sent under.
No address or number on the person the rule was aimed at.
A condition on the rule excluded this case.
A required template is missing.

4. The address is on the suppression list

If an address hard-bounced or someone marked one of your messages as spam, that address is suppressed for your workspace, and nothing is sent to it again.

It stays suppressed, and that is the design. The list is append-only — there is no auto-resubscribe, because a spam complaint is a person telling a provider they do not want your mail, and quietly resuming would put your whole domain's reputation at risk to serve one send.

Note the shape of it: a soft or transient bounce never suppresses anything. A full mailbox or a server having a bad afternoon leaves no row. Only a hard bounce or a complaint does.

What to do instead: reach the person another way, confirm the correct address, and record it against the contact. Where a client asks to be reinstated after a complaint, that is a conversation with your provider rather than a switch here.

5. Sent, but they say they did not receive it

At this point the message left the system and the question has changed. "We did not send it" and "they did not receive it" are different problems, and mixing them is what makes this take an afternoon.

For email:

Ask them to check spam and any quarantine their employer runs.
Confirm the address character by character. A typo is the single most common cause here.
If you send from your own domain, check that its records are verified. Mail that leaves your provider unauthenticated is delivered to spam by most large mailbox providers, and nothing in the product can see that happening.

For text:

Confirm the number, including the country code.
Ask whether they ever replied STOP — to any message from you, not just this one.
Carrier filtering exists and is not always reported back. A message accepted by the provider can still be dropped by the carrier.

6. Resending

Resend from the row that failed. Two rules are built in:

A resend follows the original channel — email as email, text as text. Consent and suppression are per-channel, and a "helpful" fallback is how somebody who opted out of texts receives one anyway.
Automation rows offer no resend. If a rule sent it, re-firing the rule is the automations page's job; repeating one delivery by hand hides that the rule itself is failing.