Email blast platform: how to send a mass email without burning your domain

An email blast platform is software that sends one message to a large list of people at once: a sale, a product announcement, a monthly newsletter, a change to your opening hours. It holds the list, merges a name or two into each copy, sends the copies, and tells you afterwards who received, opened, clicked, bounced or unsubscribed. An email blast service is the same thing sold as a hosted product, and “mass email” is the plain-English name for what it sends.

The word “blast” is the problem. It suggests volume first and audience second: load every address you can find, press send, see what sticks. That is how mailbox providers see it too, and they have built their filters to stop exactly that. A message sent to many people who did not ask for it is spam, however good the offer, and the domain it came from is marked accordingly.

So this post treats a blast as what it has to be in order to work: a campaign. A campaign is one message to an audience that opted in, about something they opted in to, with an unsubscribe they can use in one click, from a domain that has been introduced to mailbox providers gradually. If you want to send bulk email and still have a working domain next month, every rule below follows from that definition. The glossary entry for a broadcast uses the same word for the same thing.

Mailbox providers decide where a message lands largely on the reputation of the domain it came from, and that reputation is built from how recipients treat its mail: whether they open it, delete it unread, or press “Report spam”. A blast is a large number of those judgements in a short time, so it moves a domain’s reputation faster than anything else you send. Four habits move it the wrong way.

Notice that none of the fixes is technical cleverness. Each one is about sending to fewer, more willing people, more slowly, and letting them leave. That is uncomfortable if the goal was reach, and it is the whole of deliverability for bulk mail. The same reputation also carries your receipts and password resets if they leave from the same domain, which is why a bad blast can cost more than the blast itself; the post on transactional and marketing email explains how to keep the two apart.

The largest mailbox providers have written their expectations down, and they agree on the substance. Gmail calls anyone who sends more than 5,000 messages a day to Gmail accounts a bulk sender. Bulk senders are asked to:

• Authenticate the domain. Set up SPF and DKIM, and publish a DMARC record. Yahoo asks for a DMARC policy of at least p=none that passes.
• Support one-click unsubscribe. Marketing and subscribed messages carry the headers RFC 8058 defines, plus a clearly visible unsubscribe link in the body. Yahoo asks for unsubscribes to be honoured within two days.
• Keep the spam rate low. Google’s sender guidelines ask for a spam rate reported in Postmaster Tools below 0.3% and recommend staying below 0.1%. Yahoo’s best practices also name 0.3%.
• Mail only people who asked. Google says not to send messages to people who did not sign up to get messages from you, and both providers say not to buy lists.

The law asks for some of the same things. In the United States, the FTC’s CAN-SPAM compliance guide points out that the Act covers all commercial messages, not only bulk ones, and lists among its requirements a valid physical postal address in every message, a clear way to opt out, and opt-outs honoured within 10 business days. Other countries set their own rules, often stricter about consent; this is not legal advice. The bulk sender requirements guide walks through every item on the providers’ lists.

Seven steps, in the order they matter. The first three happen before the first send and stay done; the last four are part of every send.

1. Clean the list — Start from people who opted in to hear from you, remove addresses that hard-bounced or complained, and sunset subscribers who have not opened or clicked in months. Never send to a bought or scraped list.
2. Warm up the sending domain — If the domain or address is new to bulk mail, start with a small send to your most engaged readers and raise the volume over several weeks, slowing down whenever deferrals or complaints rise.
3. Authenticate the domain — Publish SPF and DKIM for the sending domain and a DMARC record of at least p=none, so mailbox providers can tie the blast to a domain whose reputation they can score.
4. Add one-click unsubscribe — Send the List-Unsubscribe and List-Unsubscribe-Post headers defined by RFC 8058, put a visible unsubscribe link in the body, and honour every opt-out straight away.
5. Send in a topic — Scope the blast to a topic people subscribed to, so it reaches only the contacts opted in to that kind of mail and an opt-out from it leaves the rest of their choices alone.
6. Watch the complaint rate — Read the complaint rate per send and per domain. Google asks bulk senders to stay below 0.3% and recommends staying below 0.1%; a send that crosses that line is the signal to stop and find out why.
7. Handle bounces — Suppress hard bounces at once, retry soft bounces for a bounded window, and treat an address that soft-bounces on every send as dead, so the next blast goes only to mailboxes that exist.

List-Unsubscribe: <https://www.rasket.com/u/v1.1.eyJ0…>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

In Rasket a blast is a campaign, which is the broadcasts resource in the API. Most of the seven steps are built in, and the ones that cannot be skipped are enforced rather than recommended. There are two layers.

The send gate decides whether a campaign may be queued at all. It runs when you send, inside the same transaction that moves the campaign, and refuses with a 422 if any of these is missing:

• a from address on one of your domains that is verified for sending and enabled;
• a postal address on file for your team, which the footer prints;
• a segment that still exists, to send to;
• a body: non-empty HTML or text, written inline or copied from a published template.

A refused send creates nothing, and the answer names the first condition to fix. The unsubscribe link is not on the list because it cannot be missing: a body that contains neither {{{UNSUBSCRIBE_URL}}} nor {{{PREFERENCES_URL}}} gets a footer appended with an unsubscribe link and your postal address, and every campaign carries the one-click headers from step 4. A team whose sending has been restricted is refused with a 403 instead.

curl https://api.rasket.com/broadcasts \  -H "Authorization: Bearer $RASKET_API_KEY" \  -H "User-Agent: acme-news/1.0" \  -H "Content-Type: application/json" \  -d '{    "name": "Autumn sale",    "segment_id": "'"$SEGMENT_ID"'",    "topic_id": "'"$TOPIC_ID"'",    "from": "Acme <news@news.acme.example>",    "subject": "The autumn sale starts Monday",    "html": "<p>Hi {{{FIRST_NAME|there}}},</p><p>Everything in the shop is cheaper for a week.</p><p><a href=\"{{{UNSUBSCRIBE_URL}}}\">Unsubscribe</a></p>"  }'

# Every condition of the send gate, passed or notcurl https://api.rasket.com/broadcasts/$BROADCAST_ID/checklist \  -H "Authorization: Bearer $RASKET_API_KEY" \  -H "User-Agent: acme-news/1.0"
# Then queue itcurl https://api.rasket.com/broadcasts/$BROADCAST_ID/send \  -H "Authorization: Bearer $RASKET_API_KEY" \  -H "User-Agent: acme-news/1.0" \  -H "Idempotency-Key: autumn-sale-send" \  -H "Content-Type: application/json" \  -d '{}'

Eligibility decides who, of the segment, actually receives it. Each contact is checked when the campaign is planned and again just before their copy is sent, and skipped if they have unsubscribed from everything, opted out of the campaign’s topic (or never opted in to a topic whose default is out), are on your suppression list, or have been deleted. The report names the reason for each skipped contact. Every copy then goes through the same sending path as a single email, so hard bounces and complaints land on the suppression list automatically and the next blast skips them.

Consent is recorded where it is given. An opt-in written over the API, an opt-out from the one-click headers and a change on the hosted preference page all land in one ledger per contact and topic, with a source and a time. The Campaigns feature page shows the whole flow, and the newsletter API post walks through topics, contacts and segments call by call.

Whatever you choose, judge an email blast service by what it refuses to do as much as by what it does. The questions worth asking:

• Does it insist on consent? A platform that will import any list and send to it is a platform whose shared reputation includes everyone else’s bought lists.
• Is unsubscribe automatic? One-click headers on every message and an unsubscribe link that cannot be removed by accident.
• Can people choose what they hear about? Topics or a preference page, so leaving one kind of mail does not mean leaving all of it.
• Does it show complaints and bounces per send? A report that shows only opens and clicks is hiding the two numbers that decide the next send.
• Does it keep blasts apart from your transactional mail? Separate sending domains, ideally a subdomain for marketing, so a bad campaign cannot push your password resets into spam.

A platform that answers yes to all five will occasionally stop you from sending something. That is the point: every refusal is a complaint, a bounce or a burned domain that did not happen. Rasket’s marketing email is built to answer yes, from the same account and API you already use for transactional mail.