What is an email service provider? Hosting vs sending vs API

What an email service provider does for you#

You already have you@yourshop.com on a mailbox host, and it works. Then your shop needs to send order confirmations by itself, or you want a monthly newsletter, and someone says you need an ESP. You have email already, so what is the extra thing? It is the machinery for mail that no person types:

• Sending at volume, with retries when a receiving server says “try later”.
• Signing each message for your domain, so receivers can check it is really from you (DKIM, explained below).
• Remembering who not to mail: addresses that bounced (the mail came back undelivered), complained or unsubscribed, skipped automatically on the next send.
• An unsubscribe button in the inbox for marketing mail. Gmail requires it once you send close to 5,000 messages or more to personal Gmail accounts in 24 hours, and from then on for good.^[4] The rest of its rules are in the sender requirements guide.
• A record of every message: delivered or bounced, and reported as spam where the receiver tells the sender.

If you sell through a store or booking platform, it already sends its own order emails for you, through a sending service of its own. You need your own ESP when you want mail the platform does not send, such as a newsletter, or when your own software sends messages.

Email hosting vs email sending vs an email API#

Email hosting#

A mailbox provider, such as Google Workspace or Microsoft 365, runs the servers that receive and store your mail. Your domain’s MX records (mail exchange) point at those servers: in Google’s words, they “direct a domain’s email to the servers hosting the domain’s user accounts”.^[1] Our guide to free business email compares ways to get a mailbox on your own domain.

Email service providers#

Sending services split by the kind of mail. Transactional email is triggered by something the person did, such as an order or a password reset. Marketing email promotes something and must carry an unsubscribe link. Some services do one kind, some do both from one account; transactional vs marketing sorts out which kind a given message is.

Email APIs, and SMTP#

An API (application programming interface) is how a program asks a sending service to send a message: one web request, and an id back. This is what one looks like on Rasket:

curl https://api.rasket.com/emails \
  -H "Authorization: Bearer $RASKET_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: order-1042-confirmation" \
  -d '{
    "from": "Your Shop <orders@yourshop.com>",
    "to": ["ada@example.com"],
    "subject": "Order 1042 is confirmed",
    "text": "Thanks, Ada. Your order is confirmed and ships tomorrow.",
    "tags": [{ "name": "type", "value": "order_confirmation" }]
  }'

# The answer is an id. Keep it: it is how you look the message up later.
{"id": "…"}

The emails API reference lists every field and the errors a send can return.

The From address must be on a domain you have verified with the service. The Idempotency-Key header means a retry sends one email, not two, and the tag lets you count order confirmations apart from the rest of your mail. The other way in is SMTP (Simple Mail Transfer Protocol), the standard mail servers use to talk to each other. It suits software that already speaks it, such as a website plugin, a printer or an older app. Email API vs SMTP compares the two.

Why not send everything from your own mailbox?#

• Limits. Mailbox plans cap how much one person can send. Google Workspace, for example, allows 2,000 messages a day per user, and 500 on a trial account.^[2] A busy shop passes that in a sale.
• No list handling. A mailbox has no unsubscribe button, no record of who bounced, and no way to stop mailing someone who complained.
• Shared damage. Spam complaints about a newsletter hurt the reputation of the domain your staff write from. Their everyday replies can start landing in spam. Sending marketing from a subdomain such as news.yourshop.com keeps some of that apart, though receivers still link it to your main domain (the subdomain guide has the trade-off).

How to choose an email service provider#

A worked pricing example#

Say your shop has 1,000 newsletter contacts, sends four newsletters a month, and sends 500 order confirmations of its own. That is 4,500 emails a month to a list of 1,000. A tool that prices by contacts charges for all 1,000 every month, even in a month you send nothing. A service that prices by emails charges for the 4,500 you send.

On Rasket that month costs $20 on the cheapest paid plan. The list is past the Free plan’s 900 contacts, and one newsletter to it is past Free’s 100 emails a day. At the same size, our comparison of email marketing platforms finds $17 to $30 a month on five widely used marketing tools’ entry plans.

Once you are sending, check your spam-complaint rate after every campaign, not once a month. The spam complaint rate guide gives Gmail’s limits and how to measure yours.

The email setup a small business needs#

Which contact addresses to publish covers the role addresses. Each provider tells you the exact records to add. The next section is how.

DNS in five minutes#

DNS, the Domain Name System, is the internet’s directory: it turns a name such as yourshop.com into the addresses and settings other servers need. Your domain has a short list of DNS records, and each has three parts: a name (which part of your domain it is about), a type, and a value.

Google’s DNS basics page defines each record type.^[1]

What SPF, DKIM and DMARC actually check#

• SPF (Sender Policy Framework) is a published list of the servers allowed to send for a domain. Receivers check it against the hidden return address that bounces go to (the Return-Path), not the From address you see. Many sending services let you put that address on a subdomain of yours; some use their own domain until you do.
• DKIM (DomainKeys Identified Mail) is a seal on each message that only your domain can make and anyone can check. The sending service keeps the private key that makes the seal; you publish the matching public key in DNS, and receivers use it to check that the message was not changed and which domain sealed it.
• DMARC (Domain-based Message Authentication, Reporting and Conformance) ties the other two to the From address people see, and tells receivers what to do with mail that fails.

In plain words: DMARC passes when SPF or DKIM passes for your own domain, or a part of it such as bounce.yourshop.com, and not merely for the sending service’s domain.

To see which case your store or booking platform is in, open an order email it sent you in Gmail on a computer and click the down arrow below the sender’s name. “Mailed by” shows the return-path domain SPF checked, and “Signed by” the domain on the DKIM seal.^[5] If either is your domain, the platform sends as you. If both are the platform’s, look in its email settings for a way to add your domain. Each record in full is in DKIM, SPF and DMARC explained.

Start DMARC in report-only mode, with an address that collects the reports:

_dmarc.yourshop.com  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@yourshop.com"

p=none asks receivers to change nothing yet and send you reports. On its own it does not stop anyone faking your domain. The reports arrive as files for a reporting tool to read, not letters for you. Moving from p=none to p=reject covers the next steps.

Where to click#

You edit records at your DNS host. That is the company your domain’s nameservers point to: the servers that answer DNS questions for your domain. It is usually the registrar where you bought the domain, unless you moved the nameservers, for example to your website host. ICANN notes that registrants manage their domain’s settings through their registrar.^[6] The menus differ, but the steps are the same:

1. 1

   Find your DNS host

   Log in where you bought the domain and look at its nameservers. If they point to another company, such as your website host, edit the records there instead.

2. 2

   Open the DNS settings

   Choose the domain, then the page called DNS, Manage DNS, DNS records or Zone editor. Each company names it differently.

3. 3

   Add the record

   Select Add record, choose the type, type only the part of the name before your domain (or @ for the domain itself), and paste the value exactly as your provider gave it.

4. 4

   Save and wait

   Save, and leave the TTL at its default. Many changes show within minutes, but a changed record can take as long as its old TTL: a day if that was 86400 seconds.

5. 5

   Check that it worked

   Look the name up with a DNS lookup tool, or with your provider's own check, and confirm the value matches what you were given.

If a record will not verify, email domain verification, step by step goes through the usual causes for each type.

How to check it worked#

Changes are not instant. Each record has a TTL (time to live), in seconds, that tells other servers how long to remember it. Google’s example is that a change to a record with a TTL of 86400 “will take up to 24 hours to go into effect”.^[1] A brand-new record has its own wait: if a server looked the name up before you added it, it may remember that the name did not exist for a while.^[8] Check from a lookup tool that has not asked before, such as Google’s Admin Toolbox Dig in a browser.^[9] On a Mac or Linux terminal:

# Who receives mail for the domain? (MX records)
dig +short yourshop.com MX

# Is there an SPF record, and only one?
dig +short yourshop.com TXT

# The DMARC record lives on a name of its own
dig +short _dmarc.yourshop.com TXT

How hosting and sending share one domain#

• MX at the root belongs to the mailbox host. The root is the bare domain, yourshop.com itself, written @ in most DNS editors. Do not point its MX at a sending service unless you mean to move all incoming mail there.
• DKIM keys sit on names of their own, under _domainkey, so each service adds its own without touching the other’s.
• SPF at the root must stay one record. A name with two SPF records fails the check with an error.^[7] Many sending services put their SPF on a bounce subdomain of yours instead, which avoids the clash; in the default relaxed mode DMARC still aligns, since the subdomain is part of your domain. When two services both need the root, merge them into one record.
• DMARC is one record, at _dmarc on your domain, which also covers its subdomains unless one publishes its own.

Wrong: two SPF records on the same name. Receivers treat both as an error.
  yourshop.com  TXT  "v=spf1 include:mailhost.example ~all"
  yourshop.com  TXT  "v=spf1 include:sender.example ~all"

Right: one record that names both.
  yourshop.com  TXT  "v=spf1 include:mailhost.example include:sender.example ~all"

Each include: adds one service’s list of servers, and ~all at the end says mail from any other server is suspect. Copy the include: parts your two providers give you into one line, with one v=spf1 at the start and one ~all at the end. Each include: counts toward SPF’s limit of 10 DNS lookups, the lookups inside it included, and past 10 the whole check fails.^[7]

When mail goes missing anyway, tracing an email that was not delivered shows how to find out why.

Where Rasket fits#

Rasket is an email service provider for both kinds of mail: an email API and SMTP for the messages your product sends, and Campaigns for newsletters, which you can build in the dashboard without code. Its records stay off your mailbox host’s names: a DKIM key at rasket._domainkey and a bounce subdomain with its own records, as the domains docs list (rasket.yourshop.com for a domain added today, unless you pick another), so your root MX and SPF stay as they are. If your DNS is at Cloudflare, Rasket can add the records for you; otherwise the domain page lists each one and checks for it while you add it. The Free plan sends up to 3,000 emails a month; pricing shows every plan.

It also offers Rasket Inbox for team mailboxes. If all you need is a few mailboxes and nothing sends automatically, a mailbox host alone is enough for now.