Choosing an email sending service looks like a procurement task and behaves like an architecture decision. The provider you pick becomes part of how your product communicates with customers, so the choice affects reliability, security reviews, costs, incident response and, if you ever need to leave, an engineering project. People searching for an "email sending service" are often a technical lead who has been asked for a recommendation by Friday. This guide gives that person a scorecard: a weighted set of criteria, what evidence to collect for each, how to score without being led by marketing pages and how to present a recommendation to a CTO or VP. It is deliberately provider-neutral; apply it to us as well. We do not name or rank competitors, we do not quote prices and we do not state any provider's limits, because those change and should be verified from current documentation and contracts. Use this alongside how engineering teams evaluate delivery services.
Step 1: write requirements and set weights
Before you open a vendor site, write a one-page requirements note: the mail types you send, expected volume and peaks, latency needs, regions, integration style (SMTP, API or both), data sensitivity, who will operate the integration and what an outage costs. Then assign weights to the categories below, totalling 100. A fintech that sends one-time passcodes will weight reliability and security heavily. A product that sends weekly digests will weight cost and templates more. Fixing the weights first protects you from choosing the vendor with the best demo.
The scorecard
| Category | Example weight | Evidence to collect |
|---|---|---|
| Reliability and failure behaviour | 20 | Architecture explanation, status history, contract commitments, behaviour in your load test |
| Deliverability controls | 15 | Authentication options, IP options, reputation tooling, support for stream separation |
| API and SMTP quality | 15 | Documentation, error semantics, idempotency, libraries, TLS support |
| Observability | 10 | Message search, events, logs retention, exports |
| Security and compliance | 15 | Questionnaire answers, data processing terms, access controls, documents on request |
| Support and operations | 10 | Channels, response targets, escalation, quality of answers in your trial |
| Cost model | 10 | Modelled at your volume, with add-ons and support included |
| Portability and exit | 5 | Export options, standard protocols, contract terms |
The weights above are examples only. Change them to reflect your situation. Score each category from 1 to 5 using the rubric in the next section, multiply by the weight and add up.
Scoring rubric
| Score | Meaning |
|---|---|
| 1 | Does not meet the need, or no evidence |
| 2 | Partly meets; significant gaps or only vendor claims |
| 3 | Meets the need; evidence from documentation |
| 4 | Meets the need well; evidence from documentation and our tests |
| 5 | Exceeds the need; verified in tests, contract and references |
A claim without evidence cannot score above 2. This simple rule removes much of the bias that comes from polished marketing.
What to look for in each category
Reliability and failure behaviour
Ask how accepted messages are protected during an incident, how incidents are communicated and what the agreement actually commits to. Read the status history if one is public. In your test, observe acceptance time and delivery time under bursts that match your peaks. Whatever the answers, plan your own protection with queues and retries; see designing reliable email sending.
Deliverability controls
Confirm that you can authenticate your own domain with SPF and DKIM and align with DMARC. See authenticating your sending domain. Ask about shared and dedicated IP options, warm-up support, separate pools for transactional and marketing mail, suppression handling and what monitoring is included. No vendor can promise inbox placement; be wary of those who do. See dedicated vs shared IPs.
API and SMTP quality
Read the documentation as a new engineer would. Are errors specific and consistent? Is there an idempotency mechanism? Is TLS modern and well documented? Which ports are supported? Our relay is smtp.migosmtp.com on port 587 with STARTTLS. Is there a sandbox or test mode? See testing email in staging. Check that the libraries you would use are maintained.
Observability
You will debug delivery problems at inconvenient times. You need to find one message, see each attempt and read the receiving server's response. You also need delivery events pushed to your systems with retries and signatures. See webhooks and email analytics. Ask about log retention and export.
Security and compliance
Send your security team's questionnaire early, since it often takes the longest. Our list of questions is in the vendor security review guide. Ask for documents, not badges, and verify that anything cited covers the service you will use.
Support and operations
Test support during the trial with a real technical question. Note how long the answer took and whether it was correct. Ask what is included in your plan for deliverability help and how limit increases and account reviews are handled.
Cost model
Model cost at your current volume and at ten times that volume, including dedicated IPs, extra features and support tiers. Ask what happens at the limit: do messages queue, fail or trigger automatic upgrades? Compare using the vendors' current published terms and written quotes. Do not compare headline rates alone; include engineering time. See build vs buy for a fuller cost list.
Portability and exit
Ask how you would leave. Can you export suppression lists, templates and logs? Does the integration use a standard protocol such as SMTP, or provider-specific API calls? Keep provider code behind your own interface. See the migration checklist.
Present the recommendation
A CTO or VP reading your recommendation needs five things on one page.
- The decision and the runner-up. What you recommend and what you would choose if it falls through.
- The scorecard, with weights and scores, so the reasoning is visible.
- The risks, including what you could not verify and how you will mitigate it.
- The cost, modelled at current and expected volume, with the assumptions listed.
- The rollout plan: pilot, ramp-up, monitoring and rollback. See the warm-up guide for new sending infrastructure.
Red flags during evaluation
- Guaranteed inbox placement or a promise to remove blocklistings.
- Unwillingness to answer security questions in writing.
- Documentation that is thin, outdated or contradicts the product.
- A trial that cannot send from your own domain.
- Pricing that is clear only after a sales call, with no written quote.
- No clear path to export your data.
Common objections, and how to answer them
Scorecards attract objections, and it is better to anticipate them. Someone will say the weights are arbitrary. They are choices, which is the point: write them down, explain them and let stakeholders challenge them before the scoring, not after. Someone will say the cheapest option should win. Ask for the cost model, including engineering time and the cost of an incident, and show the scorecard with cost weighted higher to see whether the result changes. Someone will say a vendor's size makes it safe. Size is not evidence of fit; ask the same questions of every candidate. And someone will say the decision can be reversed later. It can, but at a cost, so check the portability score honestly and keep your integration behind an interface of your own.
After you choose
Start with a small stream, authenticate a subdomain and watch bounces and complaints before increasing volume. Set up monitoring and alerting from day one; see email delivery monitoring and SLOs. Record the decision, the weights and the evidence, and revisit it yearly or when your needs change. Our SMTP relay, email API and comparison page are where to start if you want to include us in your scorecard.
Include us in your scorecard Create an account, authenticate a subdomain and score us with the same criteria as every other vendor.
References and further reading
Frequently asked questions
How do I choose an email sending service?
Write requirements, set weights for reliability, deliverability controls, API quality, observability, security, support, cost and portability, then score each candidate from documents and tests.
Why set weights before looking at vendors?
It prevents the best demo or marketing page from steering the choice. Weights come from your own needs, such as whether reliability or cost matters more.
What score can an unverified vendor claim receive?
No more than 2 in the example rubric. Evidence from documentation, tests, contracts or references is needed for higher scores.
How do I present the decision to a CTO or VP?
On one page: the decision and runner-up, the scorecard, the risks and unknowns, the modelled cost and the rollout plan.
What are red flags when evaluating vendors?
Guaranteed inbox placement, unwillingness to answer security questions in writing, thin documentation, trials that cannot send from your domain and no data export path.