"Email delivery service" is the phrase buyers use when they want email to simply arrive: receipts, password resets, alerts, invoices and product notifications that customers rely on. It is among the more valuable commercial phrases in this space because the people searching are usually responsible for a system that breaks visibly when mail does not arrive. This guide is for the engineer or technical lead who has been asked to choose or replace one. It defines what an email delivery service is and is not, sets out the engineering questions that separate providers from each other (reliability, latency, API behaviour, observability, security, support and exit), suggests how to run a proof of concept that tells you something real, and lists the failure modes to plan for regardless of vendor. We operate a delivery service ourselves, so use the framework to test us too, and read vendor claims as questions to verify. Related reading: the vendor scorecard and the transactional provider checklist.
What an email delivery service does
An email delivery service accepts messages from your applications and gets them to recipients' mailbox providers. Behind the interface it handles connection management, queueing, retry, pacing, authentication signing, reputation management and feedback processing, and it reports the outcome. It is usually offered as an SMTP relay, an HTTPS API or both. See how an SMTP relay works and email API vs SMTP relay.
What it does not do is guarantee inbox placement. Placement depends on your domain's authentication, your list quality, recipient engagement and content, as well as the sending infrastructure's reputation. A delivery service can make good practice easier and bad practice more visible; it cannot make poor mail welcome. See what a deliverability service includes for the related, but different, category of help.
Define your requirements first
| Question | Why it matters |
|---|---|
| What types of mail? | Transactional, notification, marketing and system mail have different needs and risks. See separating the streams |
| What volume, and how bursty? | Peaks (launches, billing runs, incidents) stress queues and limits |
| How time-sensitive? | One-time passcodes need seconds; digests can wait |
| Which regions are your recipients in? | Affects provider mix, latency and compliance |
| How do your systems send today? | SMTP from legacy tools, HTTPS from new services, or both |
| What data goes in messages? | Drives the security and privacy review |
| Who handles incidents? | Determines the support level you need |
Engineering questions that separate providers
Reliability and failure behaviour
- How is the service built for availability? Ask for architecture-level answers, not a headline number, and read the contract for what is actually committed.
- What happens to accepted messages during an incident? Are they durably queued?
- How do you communicate incidents, and is there a public status history you can read?
- What is the process for a regional or provider-wide problem?
A stated uptime figure is a legal commitment only to the extent the agreement says so, and credits are not the same as your lost revenue. Plan your own fallback regardless. See designing reliable email sending.
Latency and throughput
- How quickly is a message accepted, and how quickly does it leave the provider? Measure both in your proof of concept.
- What rate limits apply per second, per connection, per account and per request, and how are bursts handled?
- How are limits raised, and who approves?
API and protocol behaviour
- Are there idempotency keys to prevent duplicate sends on retry?
- What are the error semantics for validation errors, throttling and server errors? Are they documented and consistent?
- Does SMTP support modern TLS with STARTTLS or implicit TLS, and which ports are available? Our relay is
smtp.migosmtp.comon port 587 with STARTTLS; see which port to use. - Are there client libraries you would actually use, kept up to date?
Observability
- Can you search for one message by recipient or identifier and see its full lifecycle?
- Are delivery events available through webhooks with retries and signatures? See webhooks.
- How long are logs retained, and can you export them?
- Are bounces categorised in a way you can act on? See bounce codes explained.
Authentication and reputation controls
- Can you authenticate your own domain with SPF and DKIM and align with DMARC? See authenticating your sending domain.
- What IP options exist (shared pools, dedicated IPs, separate pools per stream), and what warm-up help is provided? See dedicated vs shared.
- How does the provider treat abusive customers in the same pool?
- Is there reputation monitoring? See reputation monitoring.
Security and compliance
- How are credentials scoped, rotated and audited? Are there separate keys per service?
- Where is data stored, how long, and how is it deleted?
- What agreements and attestations are available, and can you verify them? Ask for documents rather than relying on a badge on a web page.
The full question list is in the security and compliance questionnaire.
Support and operations
- What support channels exist, and what response targets apply to your plan?
- Who helps with deliverability problems, and what is included?
- How are account reviews and limit increases handled?
Exit
- Can you export suppression lists, templates and logs?
- Is your integration portable? SMTP generally is; APIs usually are not.
Run a proof of concept that tells you something
- Pick two or three candidates from your requirements, not from a ranking list.
- Authenticate a real subdomain for each and send test traffic from your actual application, not from a dashboard button.
- Send realistic mail: your real templates, sizes and headers, to seed mailboxes at the major providers. Read the authentication results. See reading email headers.
- Test bursts that match your peaks, and measure acceptance time and delivery time.
- Test failure paths: invalid recipients, expired credentials, rate limits and timeouts. See how errors surface.
- Test events: fire webhook events and check your handlers.
- Test support: ask a real technical question and note the response time and quality.
- Review the paperwork: terms, data processing agreements and acceptable use policy.
A seed-mailbox test is indicative, not a measure of what your whole audience will see. Treat results as evidence about the platform's behaviour, not a prediction of your inbox rate.
Failure modes to plan for with any provider
| Failure | Plan |
|---|---|
| Provider outage or degraded delivery | Queue on your side, retry with backoff, consider a standby route for critical mail |
| Credential leak | Scoped keys, rotation, alerts on unusual volume |
| Blocklisting or provider deferrals | Monitoring, a response runbook. See why emails get blocked |
| Webhook outage on your side | Provider retries plus a reconciliation job |
| Runaway job sending too much | Rate limiting and per-service quotas in your own wrapper |
| Account suspension | Know the policy, keep complaint and bounce rates low, hold a contact path |
Common mistakes in selection
- Choosing on headline price without modelling your real volume, features and support needs.
- Believing "best deliverability" claims. Deliverability depends mainly on your practices.
- Testing only with a dashboard send, not your application path.
- Ignoring exit, and building provider-specific code throughout the codebase.
- Forgetting that marketing and transactional streams have different risks.
Our SMTP relay and email API pages describe what we offer; test them with the same checklist as anyone else.
Put us through your proof of concept Create an account, authenticate a subdomain and send your real application traffic through the relay or API.
References and further reading
Frequently asked questions
What is an email delivery service?
A service that accepts messages from your applications and delivers them to recipients' mailbox providers, handling queueing, retries, authentication, reputation and reporting, usually through SMTP, an HTTPS API or both.
Does an email delivery service guarantee inbox placement?
No. Placement depends on your authentication, list quality, engagement and content as well as the sender infrastructure. A service can support good practice but cannot guarantee placement.
What should I test in a proof of concept?
Authenticate a real subdomain, send realistic traffic from your application, test bursts, failure paths, webhook events, support responses and review the contract terms.
How do I plan for a provider outage?
Queue messages on your side, retry with backoff, use idempotency to avoid duplicates and consider a standby route for critical transactional mail.
What matters beyond price?
Reliability behaviour, latency, API semantics, observability, authentication and IP options, security and compliance documents, support and ease of exit.