The one rule
A change that makes the API nicer but risks inbox placement is a bad change. That is written into the repository’s own guidelines, and it is why several things below are enforced in code rather than documented as best practice and hoped for.
We sign as you, and we only ask for one record
Every message is signed with a DKIM key belonging to your domain, so a receiver can prove it genuinely came from you. DMARC passes when either SPF or DKIM aligns, which means DKIM alignment on its own is enough — so we ask you to publish one TXT record and nothing else.
We deliberately do not ask you to change your SPF record. A domain may publish only one, and pasting ours over yours would break every other system that sends as you. Providers that ask for this are trading your other mail for their convenience.
Volume ramps whether you want it to or not
A new sending IP has no reputation, and volume that appears out of nothing looks exactly like a compromised host. So every account starts at 200 messages a day and climbs one rung at a time: 200, 500, 1,000, 2,500, 5,000, 10,000, 25,000, 50,000, 100,000, 250,000.
You move up after a day where you used at least 80% of your cap with a complaint rate at or under 0.1% and bounces at or under 5%. You move down after a day where complaints passed 0.3% or bounces passed 10%. Never more than one rung a day, and an idle day moves nothing — capacity is earned with real volume, not with time. The full mechanics are in the docs.
The 0.3% figure is Gmail’s, not ours. We stop growing and start shrinking well before a receiver would act on it.
Every message ends somewhere definite
The receiving server accepted it and said so. We keep what it said, verbatim.
A permanent refusal. The address is suppressed immediately, because continuing to send to an address a receiver has permanently refused is the fastest way to lose reputation.
A temporary refusal. We retry on a backoff and we do not suppress — suppressing on a transient error would make a perfectly good address unreachable forever.
Refused before anything went out, because the address has already bounced or complained. You are told at the API call, not an hour later.
Why we refuse marketing mail
Bulk campaigns carry a fundamentally different complaint profile from transactional mail. On shared sending infrastructure, one customer’s bad list damages placement for everyone else on the same IP. Refusing that category outright is worth more to your password resets and receipts than the revenue would be.
If you need campaign sending, use a provider built for it. We would rather lose the sale than the IP.
What we cannot promise
We are not better at deliverability than Postmark today, and anyone telling you otherwise on day one is guessing. Placement is built on a sending IP over months of consistent, well-behaved volume, and ours is new.
What we can promise now is that you will see exactly what happened to every message, including the receiving server’s own words when it went wrong. That is more than the established providers give you, and it is the thing that lets you fix your own sending rather than filing a ticket and waiting.
What we ask of you
- Send to addresses that asked to hear from you. Purchased lists are grounds for suspension, and they are obvious from the bounce pattern within a day.
- Fix hard bounces at the source. We suppress them, but a list that keeps producing them is a list with a problem upstream.
- Put a real reply-to on transactional mail. Mail nobody can reply to gets marked as spam more often.
- Watch your complaint rate in the delivery records, not at the end of the month.