Short answer: A transactional email API is useful for startup welcome emails when you need structured events, but template ownership still matters more; for a property-management compliance notice, keep approved words versioned and treat an API or SMTP relay as transport only.
The decision is about who owns the words. Keep the approved template under a versioned change process, render it in your service, and record the exact revision with the delivery evidence. An API or SMTP relay can transport that message; neither should be the system of record for legal wording.
That sounds obvious until an auditor asks which notice a tenant actually received. A successful SMTP 250 only proves that a server accepted a message. It does not prove the final body, the later delivery event, or that an editor did not change a shared template between the send and the review. I have seen teams optimize the transport first and discover that their evidence trail was assembled from screenshots. The dashboard looked green; the record was not defensible.
Limitation: this pattern cannot prove that a tenant read a message or that an inbox was secure; it proves what your system rendered, submitted, and observed.
Keep it boring.
What must an auditable notice prove?
Start with an immutable attempt record. Store the notice ID, property and lease IDs, recipient, template revision, rendered-content hash, creation and attempt timestamps, and the transport message ID. Keep the body in an access-controlled evidence store rather than ordinary logs; the hash lets an investigator verify sameness without spreading tenant data through every log sink.
Model delivery as an append-only state machine: queued, accepted, delivered, bounced, or complained. “Accepted” is deliberately not “delivered.” Google’s sender guidance makes authentication, spam-rate monitoring, and clear handling of unwanted mail operational requirements, so the state machine needs a place for provider feedback, not just the initial response. For account creation or identity recovery notices, NIST SP 800-63B also makes the surrounding authenticator workflow relevant; email is a transport, not proof that a person controls a device.
The outbox row belongs in the same database transaction as the compliance decision. A worker claims it, loads a revision in an approved state, renders deterministic content, computes the hash, and submits with the notice ID as an idempotency key. If the network times out after submission, a retry must reconcile by that key instead of creating a second notice.
type Attempt struct {
NoticeID string
TemplateRev string
RenderedSHA256 string
Recipient string
TransportID string
State string
AttemptedAt time.Time
}
func Dispatch(ctx context.Context, n Notice, mail Mailer, audit AuditStore) error {
body, rev, err := RenderApproved(n.TemplateRev, n.Data)
if err != nil {
return err
}
digest := sha256.Sum256([]byte(body))
transportID, err := mail.Send(ctx, Message{To: n.Recipient, Body: body}, n.ID)
if err != nil {
return Retryable(err)
}
return audit.Append(ctx, Attempt{
NoticeID: n.ID, TemplateRev: rev,
RenderedSHA256: hex.EncodeToString(digest[:]),
Recipient: n.Recipient, TransportID: transportID,
State: "accepted", AttemptedAt: time.Now().UTC(),
})
}
The example omits encryption and authorization checks on purpose: those belong in the evidence store boundary, where retention and access policy can be tested. The invariant is smaller and sharper: a send cannot be marked accepted without a revision and a content hash.
Who should own the template at 2 a.m.?
There are three reasonable ownership models, and each moves work somewhere else.
| Ownership boundary | Useful property | Cost paid elsewhere |
|---|---|---|
| Application repository | Reviewable diffs and reproducible builds | Wording changes require a deploy |
| Versioned content service | Authorized editors can approve without a binary release | You must audit approvals and cache invalidation |
| Hosted visual editor | Fast copy changes for non-engineers | Every render needs a durable revision snapshot |
For a statutory notice, I favor the first two. The sender should refuse a draft or an unapproved revision, even if a human insists that the text is harmless. This is a policy check that can be unit-tested and exercised in deployment review. A marketing welcome email has a different risk profile; there, a hosted editor may be a sensible trade if the snapshot and rollback contract are explicit.
Should a startup use a transactional email API for welcome emails?
Compare interfaces, not logos. A direct API typically returns structured identifiers and exposes webhooks; an SMTP relay works with mature libraries but leaves you responsible for mapping later events to the original notice. SendGrid documents both API and SMTP paths, Amazon SES exposes both interfaces, and Postmark separates transactional streams. Those are factual boundary differences, not a ranking. The right choice depends on whether your evidence adapter can preserve stable IDs and event timestamps.
An API is the wrong boundary for a tiny startup that already has a tested SMTP client, modest volume, and no requirement to correlate downstream events. It adds another credential lifecycle and failure domain; the relay plus a small evidence adapter may be easier to operate.
The reverse limitation matters too. A relay is a poor fit when the compliance team must export a complete event timeline, attach metadata to each attempt, and replay an investigation without a provider dashboard. In that case, the extra API contract and webhook consumer are operational work worth owning, provided the team budgets for queue backlogs, signature verification, and schema changes instead of treating JSON as a reliability feature.
Run one acceptance test against every candidate: submit a deterministic token, force a simulated bounce, rotate a credential, and verify that the notice ID remains attached through the terminal event. Include the adapter in your disaster-recovery exercise. If exporting events requires a dashboard click, record that as operational debt rather than pretending the data is portable.
My buy-versus-build review uses this table before feature checklists:
| Path | On-call surface | Lock-in question | Evidence test |
|---|---|---|---|
| Managed API | Queue and webhook operations | Are event fields and IDs exportable? | Can a replay rebuild the timeline? |
| Managed SMTP relay | Fewer code changes, more event translation | Can feedback be correlated without parsing prose? | Does a delayed bounce retain the notice ID? |
| Self-hosted SMTP | Maximum control, deliverability is yours | Who runs reputation and blocklist response? | Can the team retain and query feedback safely? |
Set an SLO for the workflow: for example, 99.9% of accepted notices reach a terminal evidence state within 15 minutes. Alert on queue age and missing event windows, not on every transient 4xx. Bound retries with exponential backoff, then quarantine the attempt for a human review that is itself recorded.
Capacity planning is unglamorous and useful. If 2,000 leases can trigger a notice in a ten-minute legal window, the baseline is 3.34 sends per second before retries, webhook work, and a safety margin. Load-test that burst against the outbox index and evidence-store retention volume. A quiet staging test says almost nothing about the write amplification when every lease produces multiple state transitions.
When does SMTP remain the better boundary?
Keep SMTP when the team already has a tested client, the volume is modest, and downstream events are not part of the compliance proof. Put an evidence adapter beside it, pin the template revision, and test delayed bounces. Moving to an API only to obtain a fashionable JSON request can add a new credential lifecycle and another failure domain without improving the audit record.
Choose an API when structured event correlation, explicit idempotency, or per-message metadata materially reduces your operational risk. Either way, template ownership stays in your system. The transport can change; the approved words and their hashes must not.