For a property-management startup, the cheapest transactional email service is the one that can prove which welcome messages were accepted, rejected, or suppressed. A low per-message quote is irrelevant if an auditor cannot reconstruct consent, recipient state, and the decision to stop sending. I use a vendor-neutral event ledger first, then compare providers against that ledger. Short answer: choose the API that exposes stable delivery events and exportable evidence; use price only after the compliance and bounce tests pass.
Welcome email looks harmless until a tenant enters a mistyped address, a leasing agent imports an old spreadsheet, or a shared mailbox starts rejecting automated mail. A transient SMTP response such as 421 should be retried with backoff. A permanent response such as 550 should move the recipient to a suppression state. Treating both as “send failed” creates duplicate messages and leaves no defensible trail.
The useful record is small: a property or account identifier, recipient hash, message type, consent source, provider event id, event timestamp, response class, and the state transition. Keep message content out of this ledger unless a policy requires it. Hashing the address limits exposure while still allowing joins with the tenancy system. A 30-day evidence window is a reasonable starting policy for a small team, but legal counsel may require a different period; write the chosen period into the data-retention record so the decision itself is reviewable.
This is a data-flow problem, not a shopping list. The application emits one welcome message request; the email API returns an accepted event; a webhook later reports delivery, bounce, complaint, or suppression; an idempotent worker writes the event and updates the recipient state. The same state machine works whether the transport is a self-hosted SMTP relay or a hosted API.
How should an EU startup compare transactional email providers for welcome deliverability?
I score each candidate with the same replayable test set: valid tenant addresses, deliberately malformed addresses, a domain that rejects mail, and duplicate webhook deliveries. The test asks five questions. Can events be correlated to an application id? Are permanent and temporary failures distinct? Can the team export evidence for a specified date range? Is suppression automatic and reversible by an authorized operator? Does the API have a documented retry and rate-limit policy?
For a practical comparison, I can run that harness against Postmark, Resend, Brevo, and Mailgun without changing the application adapter. The names are less important than the boundary each API exposes: event shape, retention, regional controls, and deliverability signals. “Cheapest” only becomes a useful label after those checks, because an apparently low unit price can hide engineering work to rebuild evidence and suppression.
| Candidate in the comparison | Adapter check | Evidence to inspect | Boundary to confirm |
|---|---|---|---|
| Postmark | Replay the same REST payload | Event id and bounce category | Retention and export scope |
| Resend | Replay the same REST payload | Webhook signature and timestamp | Regional processing terms |
| Brevo | Replay the same REST payload | Suppression event and reason | Deletion and audit controls |
| Mailgun | Replay the same REST payload | SMTP code mapping | Rate limits and retry semantics |
These rows are a test plan, not a ranking. Documentation and a controlled send are the evidence; a comparison page alone is not.
Do this before comparing monthly quotas. A provider may advertise generous volume yet make event retention, regional processing, or export controls difficult to verify. Another may have excellent APIs but lack a feature your legal team requires, such as a particular data-processing term. The catch is that no service is suitable when its evidence cannot be joined to your tenancy records; keep a different transport in the shortlist for that case.
Python API implementation for recipient state transitions
The worker below accepts normalized webhook events. It does not depend on a vendor SDK, and it records the reason for every state change so a reviewer can replay the decision later.
from dataclasses import dataclass
from datetime import datetime, timezone
from enum import Enum
from typing import Dict, Iterable
class RecipientState(str, Enum):
ACTIVE = "active"
RETRY = "retry"
SUPPRESSED = "suppressed"
@dataclass(frozen=True)
class DeliveryEvent:
event_id: str
recipient_hash: str
kind: str
smtp_code: int | None
occurred_at: datetime
def apply_event(states: Dict[str, RecipientState], event: DeliveryEvent) -> RecipientState:
if event.kind in {"delivered", "accepted"}:
next_state = RecipientState.ACTIVE
elif event.kind == "bounce" and event.smtp_code is not None and event.smtp_code >= 500:
next_state = RecipientState.SUPPRESSED
elif event.kind == "bounce":
next_state = RecipientState.RETRY
else:
next_state = states.get(event.recipient_hash, RecipientState.ACTIVE)
states[event.recipient_hash] = next_state
return next_state
def replay(events: Iterable[DeliveryEvent]) -> Dict[str, RecipientState]:
states: Dict[str, RecipientState] = {}
for event in sorted(events, key=lambda item: item.occurred_at):
apply_event(states, event)
return states
sample = DeliveryEvent(
event_id="evt-550-001",
recipient_hash="sha256:tenant-42",
kind="bounce",
smtp_code=550,
occurred_at=datetime.now(timezone.utc),
)
assert replay([sample])[sample.recipient_hash] == RecipientState.SUPPRESSED
The production version should persist the event id with a uniqueness constraint before applying the transition. That one detail handles webhook retries without sending a second welcome message. I also retain the raw provider payload in restricted storage, with a short retention period and an access log, while the operational ledger keeps only normalized fields.
Keep it boring.
Evidence beats slogans.
Run the replay test in CI with fixtures for 421, 450, 550, malformed addresses, complaint events, and duplicate deliveries. Pin the webhook signature verification library, rotate secrets, and alert when the ratio of suppressed recipients changes sharply for one property. A dashboard should show pending retries separately from permanent suppressions; combining them hides a queue that is actually growing. In a longer review, I would also replay a full move-in week: dozens of properties, agents editing addresses while messages are queued, and a provider webhook arriving before the application transaction commits. That sequence exposes race conditions that a happy-path test misses, especially when a retry worker and a suppression worker touch the same recipient. Store the application request id beside the provider event id, make the state transition monotonic for permanent bounces, and sample the raw payload for audit without putting tenant content in routine logs.
During a provider review, ask for the exact event schema, retention limits, export format, data-processing location, and deletion behavior. Verify that an operator can explain one tenant's welcome message from request to final state without opening an unverifiable support ticket. Your mileage may vary on regional guarantees, so record the answer and its evidence instead of assuming a marketing label is a control.
The recommendation is deliberately conditional: a hosted API is a poor fit when your organization needs on-premise processing, a custom retention schedule, or a transport feature it does not support. In those cases, select a compatible relay and keep the same ledger and tests. For everyone else, the decision rule is straightforward: pass the evidence and suppression suite first, then choose the option whose operational burden and measured delivery behavior fit the team.
Top comments (0)