Short answer: choose the least complicated email service that lets a small SaaS authenticate its custom domain, export suppression state, distinguish bounces from complaints, and poll durable event records into its own audit store. Treat warmup as controlled traffic ramping, not as evidence that a compliance notice reached a person.
For a developer-tools business sending a policy-change notice, the hard question isn't whether an API returned an ID. It is whether the business can later reconstruct what it attempted, what the mail system reported, and why it stopped sending to an address. Keep that evidence in your database. A provider dashboard is an operations screen, not your system of record.
This changes the buying criterion. I care about revenue per engineering hour, so the simplest option is the one that removes undifferentiated mail operations without owning the compliance record. It should help the team ship weekly, while leaving a small and boring evidence pipeline under its control.
Can custom-domain email warmup and suppression records satisfy compliance governance?
Start with the evidence contract, then compare services. A custom domain and SPF support are table stakes for domain authorization: SPF defines a way for a receiving system to check whether a host is authorized to use a domain in the envelope identity. It does not prove that a person saw a message, and it should not be modeled as delivery evidence. That distinction matters during an audit. The concrete constraint is an auditable delivery record for a compliance notice, not maximum campaign throughput. A useful record needs lineage: notice revision, recipient, send attempt, external message ID, observed state changes, and suppression decision. Those fields have to survive a provider migration, so a dashboard-only workflow is out. Treat a successful submission as accepted, because that is exactly what the application knows. Later observations can add bounced or complained; neither should overwrite the history that came before it.
The service should expose enough state to answer four separate questions:
- What exact notice version did the application ask to send, to which normalized recipient, and when?
- What provider message identifier came back with the accepted submission?
- Which later event changed the message state, and what raw category accompanied it?
- Was the recipient suppressed before a later attempt, and which event or policy caused that decision?
Look for stable identifiers, timestamps, event categories, pagination, and a documented retention boundary. If any of those are unclear, I'm not sure a polling endpoint alone can satisfy the evidence requirement; a sample export and the provider's retention documentation would resolve that uncertainty. Your mileage may vary when counsel defines what must be retained, so turn that definition into an acceptance test before signing a contract.
Warmup belongs in the operational plan, but don't let it dominate selection. It is a controlled change in sending volume and recipient mix. The audit design should work on day one and after volume grows: every attempt gets a local record, every observed event is appended, and suppression is checked before another attempt. Keep the provider's raw event category beside your normalized state. Normalization makes application queries stable, while the raw value preserves context for later review. This is cheap insurance in engineering time — but it isn't magic proof of human receipt.
The catch is that a polling-only service is not suitable when the notice must appear in your system within seconds. Choose an option with signed event delivery when low latency is a real requirement. Stick with polling when delayed reconciliation is acceptable and one scheduled worker is easier to operate than a public callback endpoint. That is a workload choice, not a universal ranking.
SPF configuration needs the same precision. The RFC describes authorization checks using the domain in the SMTP MAIL FROM or HELO identity. Record the domain and configuration revision used for a launch, then validate the published policy as part of deployment. Don't write "SPF passed" into the audit trail unless the observed event actually supplies that result. The application cannot infer a receiver's evaluation from its own DNS lookup.
This is the part I would refuse to outsource: the meaning of the record. Sending, queueing, and bounce classification are undifferentiated work. The mapping from those signals to a compliance decision belongs close to the product.
Implement one adapter, one cursor, and two append-only records
The first version needs one send adapter, one event poller, and two append-oriented tables. The adapter prevents provider-shaped response objects from spreading through product code. The poller advances a cursor only after the page has been stored.
type NoticeAttempt = {
attemptId: string;
noticeRevision: string;
recipient: string;
requestedAt: string;
providerMessageId?: string;
state: "requested" | "accepted";
};
type DeliveryObservation = {
providerMessageId: string;
observedAt: string;
kind: "accepted" | "bounced" | "complained" | "suppressed";
rawKind: string;
};
type EventPage = {
observations: DeliveryObservation[];
nextCursor?: string;
};
interface MailEvidencePort {
submit(input: {
recipient: string;
noticeRevision: string;
idempotencyKey: string;
}): Promise<{ providerMessageId: string }>;
listEvents(cursor?: string): Promise<EventPage>;
}
The leading spaces before type are optional in a real file; the important boundary is the vocabulary. Product code knows accepted, bounced, complained, and suppressed. It does not know a vendor's route layout.
A small scheduled worker can reconcile pages without claiming more than it observes:
async function reconcile(
port: MailEvidencePort,
cursor: string | undefined,
appendOnce: (event: DeliveryObservation) => Promise<void>,
saveCursor: (cursor: string | undefined) => Promise<void>,
): Promise<void> {
const page = await port.listEvents(cursor);
for (const observation of page.observations) {
await appendOnce(observation);
}
await saveCursor(page.nextCursor);
}
appendOnce should use a deterministic uniqueness rule derived from the provider message ID, event kind, and observed timestamp. The exact rule depends on the event contract; verify it against replayed pages before deployment. Do not invent an event ID when the service already supplies one.
The failure case worth testing is mundane: the worker stores half a page and exits before saving the cursor. On its next run, it reads that page again. Duplicate observations must leave the audit history unchanged, and the cursor must remain behind until every observation is durable. Also test an empty page, an unchanged cursor, an address already on the suppression list, and two events for one message arriving out of order. These are deterministic tests. No production anecdote is needed to justify them.
Before sending, query the local suppression projection. If suppressed, record a blocked attempt with the governing reason rather than calling the send adapter. After polling, update that projection from appended bounce or complaint observations according to the written policy. The evidence log stays immutable; the projection can be rebuilt.
Evaluate the evidence claim before widening the cohort
Ship the pipeline behind a narrow release check. Validate the custom-domain identity, confirm the SPF policy is the intended revision, send only to the approved compliance cohort, and watch event reconciliation before widening the cohort. The SPF RFC is the authority for SPF semantics; a provider setup screen is only an interface to configuration.
Use a test matrix with accepted submission, suppression before submission, bounce observation, complaint observation, replayed page, and cursor recovery. Keep real recipient addresses out of fixtures. A synthetic identifier such as member-042@example.invalid makes the intent obvious without smuggling customer data into the repository.
Short version: deploy slowly.
Do not mix SMS one-time-code behavior into the email evidence model. The WebOTP API is specifically an API for obtaining one-time passwords from specially formatted SMS messages. That is a different channel and job. If SMS becomes a required fallback for the notice, give it its own delivery adapter, evidence vocabulary, and channel-specific review rather than pretending an email bounce category transfers cleanly.
Observability can stay lean. Alert on a poller that fails to advance within the expected schedule, a sustained rise in unclassified raw event kinds, and a mismatch between accepted attempts and reconciled message IDs. Set the actual thresholds from normal traffic after launch; fabricated universal percentages would create false confidence.
Migration at scale should preserve the product vocabulary
At higher volume, I would replace the single worker with partitioned reconciliation, retain the same port, and make cursor ownership explicit per partition. I would also separate immutable evidence storage from the query projection so support searches do not compete with ingestion. Those are scaling changes, not reasons to burden the first release.
There are real trade-offs. Polling spends requests on quiet periods and adds detection delay. Event delivery reduces that delay but creates an authenticated public ingestion surface, replay handling, and another availability boundary. A self-hosted mail stack offers deeper control, yet it also makes domain reputation operations, event classification, and retention your team's work. For a solo SaaS, that can consume the same hours that should ship customer-facing features.
Choose by evidence completeness and operating burden. Reject any service whose export cannot be mapped into the local attempt and observation model, whose suppression state cannot be inspected, or whose retention boundary cannot be established. Then choose the smallest operational shape that meets the latency requirement.
No provider can turn an SMTP-facing event into proof that a human read a legal notice. Preserve the claim you can support: what was requested, what was accepted, what later signal was observed, and what sending decision followed. That record is portable, testable, and appropriately modest.
