Postmark or SendGrid: transactional email is a deliverability problem

Postmark and SendGrid are bought for one reason: a password reset, an invoice or an order confirmation has to reach an inbox, not a spam folder. What separates them is not the feature list but the division of labour — how much of the sending the provider takes, and how much stays with you as DNS records, suppression decisions and someone reading a bounce log. The answer flips the moment one account must carry both a receipt and a newsletter.

What is each product actually organised around?

Postmark is organised around transactional mail and treats broadcast as a separate stream with its own statistics, its own suppression behaviour and often its own sending IP. SendGrid grew from marketing email and carries both under one account, with subusers, separate IP pools and a suppression system that spans it all.

Both deliver a receipt. The useful question is which one makes it harder to damage the password-reset channel by accident.

Why does mixing the two streams break both?

Marketing mail goes to addresses that did not ask for it, in bursts, with links and images, and a small share of recipients press "report spam". That complaint rate attaches to the domain and the IP.

Send a campaign from the domain that sends password resets and the two share a reputation. A bad batch of addresses drags the domain down and the next reset lands in spam, which the customer experiences as "the site is broken". The reverse also happens: an unsubscribe processed on a shared suppression list quietly stops a receipt somebody is waiting for.

Splitting the streams fixes this at the level of the sending identity — mail.example.com for receipts, news.example.com for campaigns, each accumulating its own history. Both providers allow it; only one makes it the default shape of the product.

What does a provider give you that your mail server does not?

A server moves a message. A provider decides what to do with the answer.

• Bounce classification. A hard bounce is a dead address and must be suppressed; a soft bounce is a full mailbox or a greylist and must be retried.
• Complaint feedback, an enforced suppression list, and retries with a queue that survives your application restarting mid-send: a spam report or a dead address is not repeated on every send.
• Per-stream reporting, so you can see the receipt stream is healthy while the campaign stream is not.

None of this is exotic. It is work you would otherwise build, and the cost teams underestimate is operating it: a bounce log nobody reads is no bounce handling at all.

What do you still have to configure yourself?

Authentication, and it is not optional. The provider signs your mail with a DKIM key it generates, but the key counts only once you publish it in DNS, and the domain must say which hosts may send for it.

Three records, on a sending subdomain rather than the apex:

1. SPF — a TXT record listing the provider's hosts for the envelope domain.
2. DKIM — the public key the provider gives you, at the selector it names.
3. DMARC — a policy at _dmarc saying what to do with a message that fails alignment, and where to send reports. RFC 7489 is the specification; read it once instead of trusting a wizard.

Two details cause most failures. DMARC checks alignment, not just a pass: the domain in the visible From header must match the one SPF or DKIM authenticated. And a subdomain inherits the apex policy unless you publish a subdomain policy, so a strict apex rule can quarantine your receipts by default.

What do you look at the day the mail stops arriving?

Not the vendor's page, and not one recipient's spam folder.

1. The activity log. Accepted, suppressed before sending, or bounced? Three problems, and the log names yours.
2. The headers of a real message. Authentication-Results shows SPF, DKIM and DMARC separately; one fail explains a week of guessing.
3. The suppression list. A soft bounce that hardened, or a complaint from a shared address, removes an address silently.
4. What changed. A new sending domain, a link shortener, a jump in volume. Reputation is built slowly, lost in an afternoon.
5. The receiving side. Blocklists, and the recipient's own filter: only their administrator can say why.

The comparison that decides it

Dimension	Postmark	SendGrid
What the product assumes	a receipt matters more than a campaign	a platform for both, marketing first
Stream separation	the default shape, per stream	possible with subusers and IP pools
Bounce and complaint handling	built in, reported per stream	built in, reported per account
What you still publish	SPF, DKIM, DMARC on a sending subdomain	the same records, per domain used
What to verify on the vendor's page	how streams isolate reputation	which features need a higher plan

How to choose, in order

1. List every message the business sends and mark who triggered it: a customer action, or a calendar.
2. Give the two lists different sending subdomains before comparing providers at all.
3. Publish SPF, DKIM and DMARC with a permissive policy first, and read the aggregate reports for two weeks.
4. Send a test to a Gmail address, an Outlook address and a local provider, then read the headers yourself.
5. Name the person who reads the bounce log weekly; a team is not an owner.
6. Compare plans last: what is metered, and what the provider does when a stream is suspended.

Where this goes wrong

• One domain for everything. The campaign damages the receipt, and the receipt is the message the customer cannot work around.
• A no-reply address nobody reads. Replies are a signal, and answering them catches a broken template before a customer does.
• Auth done once, never monitored. Keys rotate, a DNS migration drops a TXT record, and nobody notices until a launch.
• Switching providers to fix reputation. Reputation follows the domain, so the new vendor inherits the old problem and adds a migration.

When neither fits

If the business sends a handful of messages a day, an authenticated mailbox on its own domain is enough. The provider earns its place when bounces must be handled systematically, and when someone has to prove a message was accepted.

What this advice leaves out

No prices appear here, and no percentages. Deliverability depends on the domain, the list, the content and the recipient's filters; any figure printed in an article gets quoted long after it stopped being true. Which messages a mailbox accepts is the provider's rule to state; what you must keep is your accountant's.

We build the sending subdomain, the authentication records and the bounce handling around whichever provider you pick. We resell neither product and take no commission on the choice.

We start from the two streams, because a receipt and a campaign sharing a domain are one reputation waiting to be spent.