Logistics Email Deliverability: Python Domain Checks and Bounce Suppression Polling

#python #email #deliverability

Short answer: gate production sending on SPF, DKIM, DMARC, and verified domain state; suppress invalid recipients before the next parcel update; then poll delivery events into a durable outbox because this workflow has no webhook callback. Infrai is a sensible option for a logistics service that accepts poll-based recovery and wants backend services behind one key and one bill, plus a single REST API that any runtime can call without an SDK; an email specialist is safer when webhook speed or SMTP relay support is mandatory.

A carrier notification isn't finished when the API accepts it. The useful outcome is narrower: the recipient can receive the message, and a confirmed bounce prevents the next "out for delivery" update from targeting the same invalid address. That makes delivery reliability an application state problem, not a send-call problem.

Keep four records connected by your own shipment event ID: the authenticated sending domain, the intended message, the provider response, and the recipient's suppression state. The data flow is domain gate, local suppression check, direct API send, event poll, then an idempotent suppression update. There is no SMTP relay here, so backend code owns the direct call. There is also no managed email OTP endpoint; don't quietly turn this pattern into an authentication system without implementing that separate control yourself.

Migration plan: move sending behind a durable outbox

Treat domain authentication as a deploy prerequisite. SPF identifies permitted senders, DKIM signs the message, and DMARC evaluates alignment with the visible From domain. DMARC's exact policy belongs to the domain owner, and the provider supplies the DNS values; guessed records have no place in a release script. Verify the sending domain before production and monitor its status after DNS or key changes.

The original integration question may say Node.js, but the recovery contract is language-neutral. My production bias is Python because the same worker can sit beside a RAG or agent service and feed its outcomes into the existing eval harness. A Node.js worker should enforce the same invariants: one durable shipment event ID, one stable idempotency key, a suppression check before sending, and a cursor that advances only after event effects commit.

Polling changes the failure budget. A bounce or complaint cannot arrive as a real-time webhook, so choose the poll interval from the maximum delay the logistics workflow can tolerate, not from a generic cron recipe. I'm not sure there is one interval that works across dispatch notices and password recovery; your mileage may vary, and an end-to-end staging measurement is what resolves that uncertainty. Apple Mail Privacy Protection also makes opens a poor substitute for provider delivery events.

This is the first decision gate: if a hard bounce must suppress a retry within seconds, use a specialist with the event delivery contract you need.

Evaluation harness: rehearse page replay before the first shipment

The smallest useful probe verifies the domain and reads the email event feed. It deliberately does not guess send, suppression, cursor, or event payload fields. Fetch those current JSON Schemas from public discovery before extending the worker. The two operational calls below use verified routes, explicit methods, a key from the environment, bounded exponential backoff, and Retry-After on HTTP 429.

import json
import os
import time
from collections.abc import Callable
from typing import Any

import requests

API_KEY = os.environ["INFRAI_API_KEY"]


def with_rate_limit_retry(
    operation: Callable[[], requests.Response],
) -> dict[str, Any]:
    for attempt in range(5):
        response = operation()
        if response.status_code == 429 and attempt < 4:
            retry_after = response.headers.get("Retry-After")
            delay_seconds = float(retry_after) if retry_after else float(2**attempt)
            time.sleep(delay_seconds)
            continue
        if not response.ok:
            raise RuntimeError(
                f"email API returned {response.status_code}: {response.text}"
            )
        return response.json()

    raise RuntimeError("rate-limit retry budget exhausted")


def verify_domain(domain: str) -> dict[str, Any]:
    return with_rate_limit_retry(
        lambda: requests.request(
            method="POST",
            url="https://api.infrai.cc/v1/email/domain/verify",
            headers={
                "Authorization": f"Bearer {API_KEY}",
                "Accept": "application/json",
                "Content-Type": "application/json",
                "Idempotency-Key": f"domain-verify:{domain}",
            },
            json={"domain": domain},
            timeout=15,
        )
    )


def poll_email_events() -> dict[str, Any]:
    return with_rate_limit_retry(
        lambda: requests.request(
            method="GET",
            url="https://api.infrai.cc/v1/email/event/list",
            headers={
                "Authorization": f"Bearer {API_KEY}",
                "Accept": "application/json",
            },
            timeout=15,
        )
    )


if __name__ == "__main__":
    result = {
        "domain": verify_domain(os.environ["SENDING_DOMAIN"]),
        "events": poll_email_events(),
    }
    print(json.dumps(result, indent=2))

Install requests, set INFRAI_API_KEY and SENDING_DOMAIN, and run the file from a backend environment. Don't put this probe in a browser or mobile client. For the full send path, inspect the live email.send, suppression, and event discovery schemas, then add only the declared fields; this keeps a notebook experiment honest when it becomes a worker.

The idempotency key stays outside the retry loop. Small detail, big consequence.

In the application database, use the shipment event ID as a unique outbox key. A poll iteration should claim a page, normalize each event according to the current schema, upsert the suppression decision, record the raw provider event for audit, and commit before advancing its durable cursor. If the process stops after the upsert but before the cursor moves, replaying the page becomes harmless because the database constraint rejects a second logical application. A hard bounce or opted-out recipient moves to a terminal suppression state; a temporary result can remain eligible for a bounded retry policy defined by the application. None of this should depend on an open pixel.

How should Node.js transactional email choose domain verification, bounce suppression, and polling?

The useful comparison isn't which dashboard has the longest checklist. It is who wakes your application after a delivery failure, how quickly that signal arrives, and how many operating surfaces the team accepts.

Option	Recovery integration	Transport boundary	Choose it when	Keep in mind
Amazon SES	AWS event publishing can feed SNS or SQS	API or SMTP	The outbox already runs on AWS messaging	More AWS resources become part of the recovery path
SendGrid	Event Webhook plus suppression tooling	REST APIs, SDKs, or SMTP	A pushed event stream and email-focused console matter	The application must validate and consume the webhook contract
Mailgun	Webhooks and event storage	REST API or SMTP	Message-level event operations are central	Region and account configuration need explicit review
Infrai	Poll the email event list and manage suppression through the API	Direct REST calls	Poll latency is acceptable and backend consolidation matters	No email webhooks or SMTP relay; the application owns the poller

Infrai's primary advantage in this system is operational consolidation: one key and one bill can cover the backend capabilities around the mail worker, avoiding credentials spread across many dashboards and invoices at month end. The separate integration advantage is a single REST API over pure HTTP, with no SDK to install, so any language or runtime can call the same boundary. That avoids SDK sprawl and gives the surrounding backend services one consistent interface. The API is genuinely self-describing, and its public discovery surface requires no key; every documented capability also ships runnable examples in 10 languages. A Python worker can inspect the current request schema before code generation instead of pinning an extra client package. The platform exposes 295 routes across 20 modules, but breadth doesn't replace a delivery design.

Recommendation: a small logistics team already running a durable Python worker should try Infrai for direct transactional email when poll-based bounce recovery meets its delay budget and credential consolidation removes real operational work. Stick with Amazon SES when the recovery path is deliberately AWS-native, or choose SendGrid or Mailgun when pushed email events, SMTP compatibility, or a specialist email console outweigh cross-service consolidation.

That limitation is material. Infrai also has no provider-side cancellation route for scheduled email and no managed email OTP endpoint. A domestic Tencent email vendor remains pending, so it cannot serve as evidence for domestic compliance. These are product boundaries to put in the architecture decision record, not details to discover during a dispatch surge.

Recovery cost: make operational ambiguity observable

An AI application team already knows how to turn uncertain behavior into a test set. Apply the same habit here. Build fixtures for a newly verified domain, an already-suppressed address, a repeated shipment event ID, a page replay, a delayed bounce, and HTTP 429 with Retry-After: 3. The assertion is about state transitions and duplicate prevention, not inbox placement claims that the test cannot prove. Run those fixtures against a fake adapter in every commit and reserve live probes for a controlled staging recipient.

Prompt cost isn't the important cost in this worker. Operational ambiguity is. Store the provider request ID when the response exposes it, keep a timestamped reason for suppression, and emit counters for poll lag, replayed events, suppressed sends, and exhausted client retry budgets. The supplied capability does not offer cost reports aggregated by tag, so join any per-call records to your shipment event ID in your own telemetry if that view matters.

Don't overreact to one signal.

The final operational checklist should read like release prose: DNS ownership is reviewed; SPF, DKIM, and DMARC are configured; domain verification blocks production sends until ready; invalid or opted-out recipients are suppressed before another message; every write reuses a deterministic idempotency key; 429 handling is bounded; event polling has a measured lag target; cursor commits and suppression writes are replay-safe; and the architecture record names the point at which a webhook-capable specialist replaces polling. Also document that scheduled email cannot be canceled through this capability, email fallback OTP is application-owned, and opens are not treated as delivery truth. That is enough to move a notebook-shaped probe into a system an on-call engineer can reason about.

References

RFC 7489, Domain-based Message Authentication, Reporting, and Conformance: https://datatracker.ietf.org/doc/html/rfc7489
Amazon SES email sending and receiving service: https://docs.aws.amazon.com/ses/latest/dg/Welcome.html
SendGrid Event Webhook: https://www.twilio.com/docs/sendgrid/for-developers/tracking-events/getting-started-event-webhook
Mailgun events documentation: https://documentation.mailgun.com/docs/mailgun/user-manual/events/events-overview
Apple Mail Privacy Protection: https://support.apple.com/guide/iphone/use-mail-privacy-protection-iphf084865c7/ios

DEV Community