Deliverability tooling
Deliverability is three separate things that get talked about as one: authentication, which has a correct answer; reputation, which is behaviour over time; and content, which is judgement. This product can settle the first, measure the second, and warn you about the third. Nobody can guarantee an inbox, and anybody who says otherwise is selling something.
Authentication is checked live, and told to you in your DNS provider's words
Adding a domain produces the exact rows to paste: DKIM CNAMEs, an ownership TXT, SPF, a DMARC record starting at p=none, and an MX record if you want to receive. Re-checking resolves each one and marks it found or not. The SPF check is lenient about a record you already have, so a domain that already includes amazonses.com passes rather than being told to replace something that works. We look up who runs your DNS and name them, because "add a CNAME at GoDaddy" is a different instruction from "add a CNAME".
DMARC reports, parsed and filed rather than left in an inbox
Publish rua pointing at the address we give you for the domain, and the aggregate reports that arrive are parsed and stored as rows: who reported, the window, how many messages, how many passed, how many failed, the policy in force, and a summary per sending IP. Alignment is evaluated the way the specification actually defines it, which is that SPF or DKIM passes and aligns, not that both do. The parser is ours and handles gzip and zip, because those reports arrive compressed.
Reputation against the numbers that actually get you suspended
Per domain, over a window: sent, bounced, complained, the two rates, a level, a trend, and any warnings. The thresholds are not invented. A complaint rate warns at 0.10% and is critical at 0.30%, which are Google's bulk sender requirements. A bounce rate warns at 5% and is critical at 10%, which is where an AWS account review starts and where suspension follows. Nothing warns below 100 messages, because a rate over eleven sends is noise, and the trend line only speaks when a rate has moved by half again or more.
You are told when a rate crosses the line, once
Crossing 0.30% complaints or 10% bounces on a domain notifies the workspace. It notifies once per crossing rather than every day the rate stays high, because an alert that arrives every morning is an alert people filter. The state is kept on the domain, so coming back under the threshold and crossing it again is a second alert and a bad fortnight is not forty emails.
Suppression is a list you can read, export, and correct
Hard bounces and complaints suppress automatically and a send to a suppressed address is refused before it reaches the provider. The list is a REST resource: filter by reason, page through it, add an address, remove one. Every row carries a reason and a sentence of detail explaining how it got there, so removing an entry is a decision rather than a guess. There are export and provenance views in the dashboard for when somebody asks why a particular customer stopped receiving mail.
Blocklist checks, on request
Spamhaus ZEN, Spamhaus DBL, SpamCop, Barracuda, and SURBL, checked when you ask rather than on every page load. Spamhaus refusing to answer a public mirror is read as no answer rather than as a listing, which is the mistake that makes most free blocklist checkers report a listing that does not exist.
The API
Every one of these exists today and answers to the key you already have. Nothing on this list is planned.
- POST /v1/domains/:id/verify
- Re-resolve every record and return each with whether it was found.
- GET /v1/analytics
- Bounce and complaint rates over any window, filtered by domain.
- GET /v1/suppressions
- Filter by reason and address, paged, each row with a prose reason.
- POST /v1/suppressions
- Add an address yourself.
- DELETE /v1/suppressions?email=
- Remove one, by id or by address.
Why did this address stop receiving mail
The reason_detail field is a sentence, so the answer does not need a second lookup.
curl -sS -G https://emails.sh/v1/suppressions \
-H "Authorization: Bearer $EMAILSSH_API_KEY" \
--data-urlencode "email=customer@example.com"
# Rows carry id, email, reason (bounce, complaint, unsub, or manual),
# reason_detail, is_global, and created_at.
#
# If it was a mistake, take it off the list:
curl -sS -X DELETE \
"https://emails.sh/v1/suppressions?email=customer@example.com" \
-H "Authorization: Bearer $EMAILSSH_API_KEY"What this does not do
Named here rather than left for a trial to discover. If something on this list is how your team works, that is a real reason to pick another product, and we would rather you knew now.
There is no deliverability guarantee
We will not promise an inbox placement rate and we do not have one to promise. Authentication is the part with a correct answer and we get that right; the rest is your list, your content, and your sending history, and those move with you between providers.
DMARC reports and reputation are dashboard only
Both are real and both are in the product. Neither has a REST endpoint yet, so you cannot pull last month's DMARC rows into your own reporting.
No seed testing or inbox placement panel
Nothing here mails a set of test accounts across providers and reports where each one landed. The mail tester in the free tools sends to one address and shows you the authentication result.
No SOC 2
We are not SOC 2 certified. If your procurement requires a report, that is a real reason to pick a larger vendor, and we would rather you found out on this page than four weeks in.
Regions are about where mail is sent from, not full data residency
You can pick us or eu per workspace or per domain, and the AWS leg genuinely runs in that region: Ireland for eu, Northern Virginia for us. Storage is in the EU for both. The compute that assembles a message runs at the Cloudflare location nearest whoever called the API, so it is not pinned to the EU. Your mail is stored in the EU and sent through AWS in Ireland, and we will not describe that as data never leaving the EU, because it is not.
Questions
What DNS records do I actually need?
DKIM as CNAMEs, an ownership TXT record, SPF including amazonses.com, and a DMARC record. Add an MX record only if you want to receive mail on that domain, and be aware it competes with any mailbox provider already receiving there.
Should I send product mail from my main domain?
Usually from a subdomain. mail.acme.com gets its own SPF lookup budget and its own reputation, so a bad week for your application mail does not follow your invoices and your staff email around.
What complaint rate is too high?
Google's bulk sender requirements put the line at 0.30% and ask you to stay under 0.10%. The reputation view here uses exactly those numbers, so a warning means you are approaching the threshold an inbox provider will act on rather than one we invented.
Do you keep the reason an address was suppressed?
Yes, as a reason code and a sentence of detail, and the dashboard has a provenance view for tracing one back. Suppression survives deleting a contact, because forgetting that somebody complained is not something you want to be able to do by accident.
Can you help if my mail is going to spam?
Email support is on every plan including the free one, answered by the people who wrote the API. We can tell you what your authentication says, what your bounce and complaint rates are, and what the receiving servers actually answered. We cannot make a decision for Gmail.
Send your first email today.
3,000 emails a month on the transactional side and 1,000 contacts on the marketing side, both free, no card. Enough to run real traffic through it before you decide.
Related