Failed Sends and Retries
Sends fail. The useful skill is telling apart the failure that will succeed on a retry from the one that never will.
Where to find it
Architect Panel → Activity:
- E-mail Log — the result and the detail behind it
Architect Panel → Integration & Connections:
- E-mail Accounts — the sending account and its credentials
- E-mail Relay Clients — relay configuration
Read the log detail, not just the result
The result says it failed. The detail recorded alongside says why, and that determines everything about what to do next. Retrying without reading it is how an afternoon disappears.
Transient failures
A timeout, a temporary rejection, a provider having a bad ten minutes. These succeed on a retry, and the right response is to retry — once, and then look properly if it fails again.
Permanent failures
An address that does not exist, a rejected credential, a message refused for its content or size. Retrying achieves nothing and can make things worse: repeated sends to a dead address damage your sending reputation, which affects every other message you send.
These need the underlying cause fixed — the address corrected, the credential renewed, the attachment reduced.
Authentication failures are urgent
A rejected credential usually means every message is failing, not just the one you are looking at. Check whether other recent sends failed the same way before treating it as an isolated incident — an expired sending credential can silence a system's entire outbound communication without anybody noticing for a day.
Look at the pattern
Before fixing one message, ask what else failed nearby:
- Many failures to one domain — that recipient is blocking or greylisting you.
- Many failures across all domains in one window — the account, relay or provider.
- Scattered individual failures — bad addresses, which is a data quality problem.
The third is the one most often treated as a series of unrelated incidents when it is really one problem with data capture.
Resending is a decision
Check whether the recipient has since received the information another way, and whether the content is still accurate — resending a three-day-old appointment reminder for an appointment that has passed is worse than not resending it.
Tell somebody when it matters
If a failed message carried something the recipient needed — an invoice, an appointment, a decision — the failure needs a person to act, not just a fix. The log tells you what did not arrive; only somebody contacting them closes it.
Worked example
A morning check shows fourteen failures. Twelve are to one domain with a temporary rejection — that recipient is greylisting, and they succeed on retry. One is a non-existent address, corrected at source. One is an attachment over the provider's size limit, and the document is sent as a link instead. Three causes, three different responses, and none of them was "retry everything".
Recommendations
- Read the failure detail before retrying.
- Never repeatedly retry a permanent failure.
- Check the pattern before treating a failure as isolated.
- Treat authentication failures as urgent and systemic.