Judge transactional email on retries and DKIM alignment, not open rates

A dev.to write-up on custom-domain mail for US and EU SaaS makes a procurement argument rather than a product one: choose a transactional email service by proving that a Node.js signup verification link survives retries, preserves custom-domain DKIM and SPF alignment, and produces durable delivery events in both deployments, with setup simplicity ranked after those invariants ^[1]. The same test covers password reset, according to the author, because both messages carry a short-lived credential and both fail the user the moment delivery becomes ambiguous ^[2]. The proposed unit of evaluation is one attempted signup, followed from token creation to accepted message, rather than a provider dashboard's aggregate open rate ^[3]. The reason is mechanical rather than philosophical: Apple's Mail Privacy Protection can prevent a sender from learning whether a recipient opened a message, so an open pixel cannot define delivery success ^[4]. Acceptance, bounce, complaint and the application's eventual token redemption are offered as more defensible signals, and the piece is explicit that they should be kept separate ^[5]. Invariant one is one logical message per security event, enforced with an application-generated idempotency key on every reset or verification attempt ^[6]. The failure mode is specific: a timeout at the API boundary leaves an unknown outcome, because the provider may have accepted the message even though the application never saw the response, and retrying without the key can produce two valid-looking messages and teach the recipient to distrust both ^[7]. Invariant two is authentication that stays verifiable after setup. DKIM supplies a signature associated with a domain, SPF authorizes sending infrastructure, and DMARC evaluates identifier alignment and publishes a handling policy ^[8]. The operational question is not whether a setup screen showed three green checks once, but whether the From domain, signing domain and envelope path still satisfy the policy after a region change, a subdomain migration or a DNS rotation ^[9]. DMARC aggregate reports are recommended for that review because they expose authentication results by source without turning individual recipient addresses into log labels ^[10]. Invariant three is a documented state machine. Queued, accepted, delivered, bounced and complained are given as examples, with the transitions mattering more than the vocabulary: a delayed webhook must not move a terminal bounce back to delivered, a duplicated event must not increment the failure count twice, and the raw provider event id should be persisted, mapped once to an internal state, and replayable ^[11]. The clock is where most latency budgets leak. The article floats an internal objective of 99% of verification attempts reaching accepted within 30 seconds, with a user able to request another link after 60 seconds, and labels these proposed product targets rather than email guarantees ^[12]. It also insists on measuring from the application's enqueue timestamp, because timing from the moment a worker calls the mail service deletes queue congestion from the number ^[13]. That fits the five ownership boundaries it identifies, from token creation through queue, worker submission, the receiving mail system's decision, and redemption: reliability spans all five while the vendor API controls only submission ^[14]. The telemetry advice is the part with a bill attached. The recommended record is a small fixed set of fields, with no email address, raw token, subject line, full webhook body or per-customer label ^[15]. On the article's illustrative arithmetic, 40,000 attempts at four lifecycle events each ^[18] costs roughly 80 MB at 500 bytes per record and roughly 960 MB at 6 KB of raw payload, a 12x ratio ^[16]. Raw payloads are for a short, access-controlled diagnostic window; normalized transitions live longer; counters aggregate by purpose, region and template version ^[17]. Watch what happens at the next DNS rotation or region migration, since that is where the alignment claim gets tested rather than the setup wizard ^[9].