Prerequisites
- A message you can point to, or the recipient and roughly when you sent it.
- Access to your email provider’s dashboard, for everything past the handoff.
Read the status first
The status tells you which half of the trip failed. covers the full lifecycle. Two of them cause most of the confusion:SENTmeans the provider accepted the message. It isn’t a delivery confirmation.DELIVEREDmeans the recipient’s mail server accepted it. It isn’t proof the message reached the inbox.
A corporate mail gateway (Proofpoint, Mimecast, Barracuda) can quarantine a message after the server accepts it.
DELIVERED with an empty inbox usually means the message is held on the recipient’s side.Find where it stopped
1
Open the message
Filter by recipient, template, or time range, then open the message.
2
Read the timeline
The timeline lists every step the message passed, from the request through routing, rendering, and the provider handoff. The last step that succeeded tells you who owns the problem.
3
Open the provider response
Select the send event to see what the provider returned, including its status code and its own message id. Use that id to find the same message in the provider’s dashboard.
See exactly what was rendered
The timeline tells you where a message stopped. It doesn’t tell you what the recipient actually got, which is the question behind most “the notification looked wrong” reports. returns the rendered content Courier delivered, broken out per channel:channel it was rendered for and a content object holding whichever fields that channel uses, such as subject and html for email or text for SMS:
For the ordered list of status transitions and their timestamps, use .
Work the scenario
Stuck at SENT
Stuck at SENT
Usually not a failure. Delivery confirmation is off until you configure it, per provider, so a healthy send stops at
SENT. Check and set up its webhook or polling toggle.If tracking is already configured, the provider may be retrying a deferral, or Courier may not have polled yet. Confirm the outcome in the provider’s dashboard.UNDELIVERABLE
UNDELIVERABLE
The provider rejected the message, and Courier doesn’t retry. Open the event for the provider’s error, then match it to a cause:
- Hard bounce. The address doesn’t exist, or the domain doesn’t resolve.
- Soft bounce. The mailbox is full or temporarily unavailable. Some providers retry before reporting failure.
- Block. The receiving server refused the message on reputation, content, or policy.
- Suppression. The address sits on the provider’s suppression list from an earlier bounce or complaint. Remove it there before you can send to that address again.
DELIVERED, but not in the inbox
DELIVERED, but not in the inbox
The message reached the mail server. Three things commonly take it from there:
- Spam or junk. Ask the recipient to check both folders.
- A security gateway. When every affected recipient shares one domain, their IT team has to check the quarantine and allowlist your sending domain.
- An inbox rule. A filter the recipient set may have moved or deleted the message.
FILTERED or UNROUTABLE
FILTERED or UNROUTABLE
The cause is inside Courier: the message stopped before it reached a provider.
FILTERED means preferences, a send condition, or a channel condition removed it. UNROUTABLE means no channel could be addressed, usually a missing email address on the profile. lists each reason and its fix.Check sender authentication
Weak authentication causes failures that look random and hit many recipients at once. Confirm all three records for your sending domain:
Each provider’s setup page walks through its own records. See the .
Ask the provider
Courier’s logs end where the provider takes over, so the delivery event itself lives there:- SendGrid: the Activity Feed, per-message delivery events.
- Postmark: Activity, with bounce and complaint detail.
- AWS SES: the Reputation Dashboard, for bounce and complaint rates.
- Mailgun: Logs, for a message’s full event history.
- Mandrill: Outbound Activity.
Debug from an AI agent
exposes the same message data as the console, so you can ask instead of click:MCP
Verify
Send the template to a test recipient and watch the status passSENT in Logs. After a suppression or authentication fix, confirm the provider’s own dashboard shows the new message as delivered.