TL;DR: For a startup sending account-verification links to logistics users, the least expensive practical design is usually the one that keeps template source, suppression decisions, and delivery evidence in the application boundary while renting the mail-transfer plane. Do not optimize around a quoted per-message rate. Optimize for one durable rule: an address that has produced a terminal delivery signal must not receive another verification attempt until an explicit policy allows it. Keep domain verification and provider adaptation outside the signup request, and make every attempt traceable from template revision to final event.
This recommendation is deliberately narrower than “build or buy email.” The scenario is a dispatcher or driver creating an account, receiving a short-lived verification link, and perhaps retrying from a loading dock with uneven connectivity. The application owns whether that message should exist. A delivery service owns the mechanics of accepting and transferring it. Blurring those responsibilities makes a nominally cheap stack expensive in on-call time, because a template edit, a delayed bounce, and a user retry can interact without any component having the whole decision.
The invariant matters more than the brand: one logical verification challenge may create several attempts, but every attempt must pass the same local eligibility check immediately before submission.
What should a practical startup transactional email stack own?
I would bound the incident around one shipment-company tenant, one recipient, and one challenge ID. That is not a claim about a past outage; it is the smallest production-shaped case that exposes the ownership problem without inventing a benchmark. Assume the product target is that 99% of accepted verification requests receive a definitive submission result within 10 seconds, and that links expire after 15 minutes. Those are example objectives for capacity planning, not universal email standards.
At 09:00, signup creates challenge ch_8421 and renders template revision verify-v17. The delivery adapter accepts attempt one. At 09:01, the user taps resend. At 09:02, a terminal bounce event for attempt one reaches the event consumer. If the retry path consults only the delivery service, while a second path consults only application state, the system can submit attempt two in the gap. The visible symptom is “resend works sometimes.” The actual fault is that suppression ownership was never assigned.
Short gap. Large consequence.
Polling is acceptable when it is treated as ingestion rather than truth. Each poll needs a stable cursor, idempotent event storage, bounded retries, and lag telemetry. The consumer translates provider-shaped events into a small internal vocabulary, such as accepted, delivered, transient failure, terminal failure, and complaint. The local policy engine then decides what each state means for another verification attempt. A complaint and a temporary delivery failure should not collapse into the same retry behavior merely because both arrived through one endpoint.
This is also why the signup handler should not wait for domain-verification work. Domain readiness is deployment state: check it before enabling traffic, expose it to operations, and fail a rollout that lacks the required identity. A user request is the wrong moment to discover that the sending domain is not ready.
Put template authority beside product intent
Template ownership is the primary decision axis because the verification message is part of the authentication flow. The repository should contain the subject, plain-text body, HTML body, required variables, and a revision identifier. Reviewers can then inspect a change to link placement or expiry wording beside the code that creates the challenge. The delivery boundary receives rendered content and metadata; it does not silently select a mutable template by name.
That choice creates work. The team must preview both bodies, escape variables correctly, preserve a stable revision scheme, and test that every supported locale renders. I would still take that work for an authentication message. The alternative transfers a product-critical artifact into a separate control plane whose permissions, deployment history, and rollback semantics may not match the application.
A useful pre-deployment test matrix is small enough to run on every template change:
- Render with the longest supported organization name and locale values.
- Assert that exactly one active verification URL is present in both bodies.
- Reject missing variables rather than shipping empty strings.
- Record the template revision on the delivery attempt, without logging the secret token.
- Send to controlled test mailboxes only after static rendering tests pass.
None of this requires the application to operate mail servers. Ownership of content and policy is separable from ownership of transport.
The preventative path belongs before every submission
The critical code path is intentionally boring. It checks the challenge, evaluates local suppression state, renders an immutable revision, creates an attempt record, and only then calls a generic sender. The same function serves initial sends and resends, so a new endpoint cannot bypass policy by accident.
package verification
import (
"context"
"errors"
"time"
)
var ErrSuppressed = errors.New("recipient is not eligible for delivery")
type Attempt struct {
ID string
ChallengeID string
Recipient string
TemplateRevision string
CreatedAt time.Time
}
type Sender interface {
Submit(ctx context.Context, attempt Attempt, subject, textBody, htmlBody string) (string, error)
}
type Store interface {
IsSuppressed(ctx context.Context, recipient string, now time.Time) (bool, error)
CreateAttempt(ctx context.Context, attempt Attempt) error
MarkSubmitted(ctx context.Context, attemptID, externalID string) error
}
type Renderer interface {
Render(revision, recipient, challengeID string) (subject, textBody, htmlBody string, err error)
}
func Send(ctx context.Context, now time.Time, a Attempt, store Store, renderer Renderer, sender Sender) error {
blocked, err := store.IsSuppressed(ctx, a.Recipient, now)
if err != nil {
return err // Fail closed when eligibility cannot be established.
}
if blocked {
return ErrSuppressed
}
subject, textBody, htmlBody, err := renderer.Render(a.TemplateRevision, a.Recipient, a.ChallengeID)
if err != nil {
return err
}
if err := store.CreateAttempt(ctx, a); err != nil {
return err
}
externalID, err := sender.Submit(ctx, a, subject, textBody, htmlBody)
if err != nil {
return err
}
return store.MarkSubmitted(ctx, a.ID, externalID)
}
There is an unavoidable crash window between external acceptance and MarkSubmitted. Pretending otherwise produces duplicate sends. The adapter should pass an idempotency key when its transport contract supports one; regardless, reconciliation must search by the internal attempt ID and repair ambiguous records. The alert is not “API returned an error.” It is “attempts have remained ambiguous beyond the reconciliation objective,” because that maps to user impact and operator action.
The event side needs the same discipline. Store the raw event once, attach it to the external message ID, advance the normalized attempt state monotonically, and update suppression policy in the same durable transaction where practical. A late delivered event must not erase a complaint. An unfamiliar event should go to review rather than defaulting to success.
Buy-versus-build is an on-call decision
The useful comparison is not a feature checklist. It is which control plane the team is volunteering to operate.
| Boundary | Team owns | External system owns | Capacity and SLO question |
|---|---|---|---|
| Managed transfer | templates, policy, event normalization, evidence | submission and mail transfer | Can the event consumer absorb a retry burst without violating suppression freshness? |
| Managed templates and transfer | policy, event normalization, template coordination | template storage, submission, transfer | Can a template rollback be audited and completed inside the incident objective? |
| Self-operated transfer | templates, policy, queues, identity, transfer, reputation operations | recipient network behavior | Is there staffed expertise and error budget for the entire delivery plane? |
For a small platform team, self-operating transfer turns deliverability into a permanent service, complete with queue management, identity configuration, reputation monitoring, abuse response, and incident coverage. That can be rational when regulatory constraints or unusual routing requirements demand control. It is hard to justify merely to reduce a variable invoice line.
Managed templates can also be rational. A communications team may need independent publishing, approval, and localization workflows, while engineering supplies a typed variable contract and pins a published revision. In that organization, application-owned source could become the bottleneck. The deciding question is whether the template is authentication logic or independently governed content, followed by who can safely roll it back at 03:00.
The delivery service itself should be evaluated with a replay exercise, not a slide deck. Feed duplicate and out-of-order events into a staging consumer. Pause ingestion long enough to build a backlog. Rotate the domain-verification material in a non-production domain. Then estimate queue depth from peak signup attempts plus event retries, with enough headroom to meet the chosen lag objective during a dependency recovery. A system that is cheap at average volume and unbounded during replay is not capacity planned.
Limitations and trade-offs for this architecture
This architecture has limits. It is unsuitable without modification for marketing campaigns, where audience management, editorial scheduling, experimentation, and unsubscribe workflows shift the template boundary. It also does not justify treating SMS as an interchangeable emergency route. If the product adds SMS verification, that path needs its own consent, abuse, identity, and messaging-policy review; the CTIA material in the sources is a starting point for the US messaging context, not permission to copy email retry rules into another channel.
Nor should local suppression become an eternal, context-free deny list. Retention, appeal, address correction, and re-verification rules need documented owners and legal review for the regions in which the service operates. The engineering invariant is narrower: do not submit until the current policy has made an explicit decision, and keep enough evidence to explain that decision without retaining the secret verification token.
The practical stack is therefore an ownership map: versioned templates near the challenge logic, a single submission gate, a durable event inbox, a local suppression projection, reconciliation for ambiguous attempts, and operational checks for sending identity. Transport can change behind the adapter. The incident model and evidence trail should not.
Sources
References:
- Amazon Simple Email Service documentation: https://docs.aws.amazon.com/ses/latest/dg/Welcome.html
- CTIA Messaging Interoperability and SMS/MMS materials: https://www.ctia.org/the-wireless-industry/industry-commitments/messaging-interoperability-sms-mms
Top comments (0)