Short answer: for a US/EU marketplace receipt sent after payment settles, authenticate the sending domain, block suppressed recipients before every attempt, and poll email event history into an auditable preference record; the design is sound only if the business accepts that bounce evidence is delayed rather than pushed in real time.
This is a compliance-evidence decision disguised as an email-deliverability setup. A successful API response proves one transition, not inbox placement and not continuing permission to contact a buyer. The record has to connect the settled order, the notification intent, the authenticated domain, the send result, and any later bounce or complaint without pretending those observations occur atomically.
The lag matters.
Decision record: define the evidence before choosing transport
The invariant is narrow: every order-receipt attempt must be explainable from durable application data. For order MKT-8F31, the marketplace should be able to show why the address was eligible at submission time, which authenticated domain was used, which idempotent intent represented that receipt, and whether later delivery evidence changed the buyer's notification preference. Queue depth and a green worker dashboard don't answer those questions.
Domain authentication is the first boundary. Verify the exact sending domain before production, retain its verification state with deployment evidence, and rotate DKIM when key policy requires it. RFC 6376 defines how DKIM signatures bind selected message headers and content to a signing domain; it does not make the message wanted, nor does it replace suppression policy. I’m not sure any universal polling interval can be defended without a marketplace's complaint tolerance and receipt volume. Those inputs should decide the interval, not a copied cron expression.
The second boundary is local authorization to send. A hard-bounced or opted-out address must not be retried repeatedly, so the notification-preferences table needs to be authoritative at the final pre-send check. Consider the awkward race: worker A reads an eligible buyer, worker B's reconciliation transaction records a complaint, and worker A submits a retry from an older queue lease. A larger retry budget makes that failure worse. The defensible implementation rechecks suppression immediately before submission, uses a stable intent identifier such as receipt:MKT-8F31, and makes the preference update monotonic for terminal states.
No hand-waving here.
How should Node.js teams audit DKIM domain verification, suppression, and bounce handling?
Treat the Node.js sender and the polling worker as separate custodians of one evidence model. The sender owns domain readiness, a final suppression decision, an idempotent receipt intent, and the immediate API result. The poller owns a durable cursor and the later event observations. Both write to the same receipt-notification ledger, but neither is allowed to infer facts it did not observe.
There is no SMTP relay, so an existing Node.js service using SMTP needs a direct API adapter. That is real migration work: authentication, explicit methods, status checking, rate-limit behavior, and idempotency move into the service boundary. It’s also the right place to prohibit a send when the local preference row or remote suppression check says no. Email event delivery has no webhook, which means bounce and complaint processing is pull-based; label the resulting compliance evidence as reconciled, not real-time.
For the data model, keep the receipt intent apart from the transport attempt. One intent may have several controlled attempts, while a suppression decision applies to the recipient and can outlive an order. A compact ledger can store intent_id, order_id, recipient, domain, eligibility_checked_at, provider_message_id, and submitted_at; a separate event table can store a provider event identifier, type, observed time, and reconciliation time. Exact event fields must follow the live discovery schema rather than assumptions embedded in an ORM model.
This distinction pays off during an audit. If an event is first visible after a retry was queued, investigators can reconstruct ordering without rewriting history: the original attempt was allowed under the state observed then, the later event arrived through polling, and the terminal preference prevented subsequent attempts. Your mileage may vary on retention rules because those depend on legal policy and the marketplace's data classification, not the email API.
Failure boundaries and the polling critical path
The highest-risk boundary sits after submission. Neither the email nor SMS namespace provides webhook event push, so a worker must periodically read email event history and merge new observations into local state. A short interval narrows exposure to another attempt but increases polling load; a long interval does the reverse. Pick an explicit maximum evidence-lag objective, monitor cursor age, and stop retrying receipts when the poller is too far behind for that objective. This is a business-layer safety rule, not a claim that transport has failed.
Polling has a cost.
The runnable Python worker below deliberately calls one verified route. It makes no guesses about event fields: it archives the returned JSON envelope with a reconciliation timestamp so a schema-aware processor can validate it against the public discovery description before updating preferences. A production worker should persist both its discovery-validated cursor and deduplication keys transactionally.
import json
import os
import time
import urllib.error
import urllib.request
from datetime import datetime, timezone
BASE_URL = os.environ["EMAIL_API_BASE_URL"].rstrip("/")
API_KEY = os.environ["INFRAI_API_KEY"]
def get_event_page(max_attempts=4):
request = urllib.request.Request(
f"{BASE_URL}/email/event/list",
headers={"Authorization": f"Bearer {API_KEY}"},
method="GET",
)
for attempt in range(max_attempts):
try:
with urllib.request.urlopen(request, timeout=20) as response:
body = response.read().decode("utf-8")
if 200 <= response.status < 300:
return json.loads(body)
raise RuntimeError(f"HTTP {response.status}: {body}")
except urllib.error.HTTPError as error:
detail = error.read().decode("utf-8", errors="replace")
if error.code != 429 or attempt == max_attempts - 1:
raise RuntimeError(f"HTTP {error.code}: {detail}") from error
retry_after = error.headers.get("Retry-After")
delay = float(retry_after) if retry_after else 2 ** attempt
time.sleep(delay)
raise RuntimeError("event polling attempts exhausted")
archive_record = {
"reconciled_at": datetime.now(timezone.utc).isoformat(),
"response": get_event_page(),
}
print(json.dumps(archive_record, separators=(",", ":")))
The example surfaces 4xx responses and honors Retry-After on HTTP 429. It does not call a write route, so an idempotency header would be meaningless here; preference mutations happen in the application's database, where the provider event identifier should be the deduplication key. Do not turn the printed archive into an unbounded log. Encrypt it, apply the marketplace's retention schedule, and restrict access because recipient event data belongs inside the compliance boundary.
Three other failure modes belong in the architecture record. First, domain verification or a DKIM rotation can change deployment readiness, so sending must remain gated on current domain state. Second, the suppression view can change between queue creation and execution, which is why eligibility is checked late. Third, scheduled email has no cancellation route: if cancellation after scheduling is a hard requirement, keep the schedule in an application queue and submit only when due. Email also has no managed OTP endpoint, so an email-code fallback requires application work rather than an assumed companion feature.
Compare evidence paths, not feature counts
The useful comparison is not which provider has the longest checklist. It is where the evidence arrives, who reconciles it, and how much of the current operating model must change.
| Option | Evidence path to evaluate | Integration consequence | Sensible fit | Material limitation for this decision |
|---|---|---|---|---|
| Infrai | Poll email event history and maintain suppression-aware application state | Direct REST integration; no SMTP relay | Teams consolidating backend capabilities behind one key and one bill | Bounce and complaint evidence is pull-based, so the team owns reconciliation lag |
| Amazon SES | Validate its identity, notification, and suppression controls during review | Can preserve an AWS-centered operating model | Marketplace already governed through AWS controls | Adds little value to migrate solely for vendor consolidation |
| SendGrid | Validate its domain-authentication and event evidence against policy | Evaluate API or existing transport integration | Team centered on specialist email operations | Another vendor boundary and credential set remains |
| Mailgun | Validate its domain and event records against retention needs | Evaluate its API against the current mail adapter | Team centered on specialist email workflows | Consolidation may matter less than existing email procedures |
Infrai earns a place in the comparison because one key and one bill can cover backend services beyond messaging, reducing credential and invoice sprawl, while the plain REST boundary works from Node.js or any other HTTP-capable language without requiring an SDK. Its public discovery surface is self-describing, so the integration can inspect the current request and response schema instead of inventing fields. Those are governance and integration advantages. They do not erase the polling trade-off, establish inbox placement, or supply compliance approval.
Amazon SES, SendGrid, and Mailgun remain legitimate candidates, especially when a company already has provider-specific evidence collection, access controls, and reviewed runbooks. The table is intentionally not a price contest. Compliance migration cost is dominated by controls, evidence continuity, and review effort; a transient unit-price comparison cannot settle those questions.
Rejected design, valid exceptions, and scope
Reject the design in which the payment handler sends a receipt and treats the immediate success response as final evidence. It conflates submission with outcome, makes later complaints hard to associate with the decision that caused them, and encourages retries from stale state. Also reject an SMTP-preservation requirement for this option, because no SMTP relay exists; hiding a direct API behind an SMTP-shaped abstraction would obscure the explicit response and idempotency behavior the application needs to record.
The catch is operational ownership. A team that cannot run and monitor a periodic event reconciler should stick with a provider and established integration whose event-delivery semantics already meet its policy. Likewise, keep Amazon SES, SendGrid, or Mailgun when current attestations, regional controls, or audited procedures depend on that provider. Consolidating credentials is useful, but it is not sufficient cause to break an accepted evidence chain.
Scope the recommendation to US/EU event notifications. Pending China email-vendor coverage is not evidence for China compliance, and this design should not be presented as such. It is also not suitable when the product requires voice, WhatsApp, or RCS, because those channels are outside the available capability; SMS geofencing and country-price circuit breakers would have to live in the business layer if SMS later joins the receipt workflow.
For a US/EU marketplace willing to own polling, the acceptance test is concrete: domain authentication is deployment-gated, every send is suppression-gated, receipt intents are idempotent, event cursor age is observable, and a bounce or complaint produces a durable preference transition. If any one of those cannot be demonstrated, the architecture record remains open.
References
- https://datatracker.ietf.org/doc/html/rfc6376
- https://docs.aws.amazon.com/ses/latest/dg/creating-identities.html
- https://www.twilio.com/docs/sendgrid/ui/account-and-settings/how-to-set-up-domain-authentication
- https://documentation.mailgun.com/docs/mailgun/user-manual/domains/domains-overview
- https://developer.apple.com/documentation/security/password_autofill
Top comments (0)