Sending
Email delivery and retries
A send that CommuniQueue accepts is queued and handed to a mail provider: your own, or our managed sending. This page explains how long a provider gets to accept each email, how often we try again, and what you can and cannot know about the email after that.
What a 202 means
POST /api/v1/notifications/send answers 202 Accepted once the send is valid and queued. Nothing has been delivered at that point. The send is processed within moments, and its progress shows on its send detail page.
Attempts and the 30-second rule
- Each attempt gives the provider 30 seconds to accept the email. If it has not accepted by then, the attempt is a provider timeout, whether the provider answered slowly or never answered.
- A send gets 3 attempts. After a failed attempt we wait 2 minutes before the second and 4 minutes before the third.
- When the third attempt fails, the send fails and nothing more is tried. Its detail page says why.
- A marketing send to a list is one email per recipient. While the provider keeps accepting, a long list carries on across as many runs as it needs; only a provider failure uses up an attempt.
- A provider can accept an email just as an attempt runs out of time. The retry then sends it again, so on rare occasions a recipient can get a duplicate.
What each attempt outcome means
- Accepted by provider. The provider took the email. What happens next is up to the provider (see below).
- Provider did not respond. No acceptance within the time an attempt gets. Check the provider's status page; a slow or overloaded provider is the usual cause.
- Could not reach provider. The connection itself failed: refused, timed out, or the host name did not resolve. Check the host and port in your SMTP settings.
- Provider rejected the message. The provider answered and said no, for example to the credentials or the from address. Owners and Admins see the provider's reply on the send detail page.
- We could not prepare this message. Something on our side stopped the attempt before a provider was involved.
With managed sending, the provider is our own sending service. A timeout or connection failure there is ours to fix, and you do not need to change anything.
Which providers report delivery
Delivered, Bounced and the delivery rate come from events a provider sends back to us after it accepts an email. Managed sending reports them, and so do SendGrid, Postmark, Mailgun and Amazon SES once their delivery webhook is set up. Custom SMTP never does: a relay accepts the email and tells us nothing more.
Sends that cannot report delivery show as Accepted by provider with a No delivery reporting tag, are counted on their own, and are left out of the delivery rate rather than counting as undelivered. To see what happened to them, use your provider's own dashboard.
Custom SMTP: ports, speed and limits
- Use port 587 (STARTTLS), 465 (TLS) or 2525. These are the ports providers give their customers for sending.
- Port 25 is not supported. AWS blocks outbound email on port 25, so a relay on it could only ever time out; saving a configuration on port 25 is refused, and so is a send through one.
- Pick a provider that accepts an email well within 30 seconds. A relay that takes many seconds per email turns into timeouts and retries.
- Your provider's own quotas apply after it accepts. A free plan with a daily cap, for example, may hold or drop email that we have already handed over.
Where to see it
In the app, open Insights, then Sends. The status column shows a send that is retrying (for example Retrying 1/3), one that needed retries, and one that failed and why. Open a send for its attempt timeline: each attempt with its time and outcome, and the next try when one is scheduled.