Thalion51

Posted on Nov 6

Marketplace Account Recovery Email: Domain Reputation and Attachment Delivery Boundaries

#email #deliverability #marketplace #backend

The least complex reliable design is a dedicated authenticated sender identity for password recovery, because email domain reputation directly impacts password reset delivery. Use a bounded retry queue and short-lived single-use tokens. Generated marketplace reports should use a separate sending identity and retention policy. A report retry storm must not compete with the one message a locked-out buyer needs.

That is the boundary.

No magic header fixes this.

The bill is mostly retention and transfer, not the few kilobytes of a reset link. A report attachment can be copied into object storage, queues, retry records, logs, and provider staging. Five copies of a 20 MB report are 100 MB before replication. I would retain the rendered report for a defined resend window, remove temporary copies afterward, and keep delivery metadata longer. The trade is plain: losing the original payload complicates a later dispute, while retaining it indefinitely expands privacy and incident-response scope.

This is a delivery-reliability problem. Sender reputation reflects sending behavior, authentication, complaints, bounces, and recipient engagement as judged by receiving systems; no application-level promise forces a reset email into an inbox.

What does sender reputation change for a password reset?

A reset message asks its recipient to trust a link immediately. The receiving system first asks whether the sending identity behaves like a legitimate, wanted sender. An uncertain answer can mean delay, spam placement, or rejection before the mailbox user sees anything.

The visible From domain, DKIM signing domain, envelope sender, sending IP, and message content are related but distinct signals. DMARC checks alignment between the visible From domain and authenticated SPF or DKIM identity. It does not guarantee inbox placement. Authentication is a prerequisite for a defensible sender identity, not a delivery guarantee.

The practical failure sequence is easy to miss. A report generator finishes, a worker copies the attachment into a retry payload, the remote system defers the message, and the queue retries without changing the underlying cause. Meanwhile, the password-reset worker shares the same concurrency pool and sender identity. The application sees two ordinary jobs, but the receiving ecosystem sees a burst from one identity, followed by more retries, followed by more unwanted mail signals. Separating queues prevents local contention; separating identities prevents the report stream from becoming the reset stream's reputation evidence. Neither separation removes the need to classify responses, authenticate domains, or stop retries. It only makes each decision observable.

For a marketplace, account mail should be boring and predictable. Report mail has a larger payload and a different resend pattern. Combining both classes makes unrelated behavior one reputation story. The reset path should also record an opaque message ID, queue time, authentication result, final response, and token outcome without logging the token or full URL.

Where does the money and operational risk accumulate?

The dominant storage term is the attachment lifecycle. A reset message has a small body; a report may exist as a rendered file, object, queue payload, retry copy, and diagnostic artifact. Pass a report reference through the queue and fetch it when the worker sends. Carry a report ID, authorization context, and idempotency key, not an unbounded binary blob. Enforce an attachment ceiling and timeout before delivery starts.

Retention must follow the failure being investigated. A 30-day report object can support a resend; 365 days creates a larger privacy surface. A reset token expires quickly, while its security event may need longer retention. The two mail classes should not inherit one shared table rule. Logs should contain IDs, classifications, response codes, and timestamps, never reset URLs or report contents.

from dataclasses import dataclass
from datetime import datetime, timedelta


@dataclass(frozen=True)
class MailRetention:
    object_days: int
    event_days: int
    max_attachment_bytes: int


RESET = MailRetention(1, 400, 256_000)
REPORT = MailRetention(30, 400, 20_000_000)


def expires_at(created_at: datetime, policy: MailRetention) -> datetime:
    if created_at.tzinfo is None:
        raise ValueError("created_at must include a timezone")
    return created_at + timedelta(days=policy.object_days)

These are policy examples, not universal limits. Replace them with the contractual resend window, privacy requirements, and attachment constraints. The useful property is explicit separation.

How should the sending path isolate failure?

Use separate queues and authenticated identities for account messages and reports. Shared worker libraries are fine; shared rate controls, retry budgets, and suppression handling are not. This is failure-domain isolation, not a claim that two domains automatically acquire good reputation.

For a reset, create the token transactionally with the request and enqueue a job with an idempotency key. Treat transient responses differently from permanent failures. A temporary refusal deserves bounded backoff and a dead-letter path; an invalid recipient should not retry forever. Repeated retries create traffic and can worsen the signal under examination.

Reports need the same discipline because schedulers replay jobs and workers can lose acknowledgements after remote acceptance. The idempotency key identifies the intended delivery; the message ID identifies an attempt. Those are different records. Emit queued, accepted, deferred, delivered, bounced, complained, expired, and suppressed states rather than collapsing everything into failed.

def next_action(event: dict) -> str:
    category = event["category"]
    attempts = event["attempts"]
    if category == "accepted":
        return "record_and_stop"
    if category == "temporary_failure" and attempts < 4:
        return "retry_with_backoff"
    if category in {"permanent_failure", "complaint"}:
        return "suppress_and_alert"
    return "dead_letter_for_review"

Four retries is a tunable example, not a protocol rule. Infinite patience is an unbounded sender.

Which signals should an operator trust?

Connect application intent to mail outcome. Measure request-to-queue latency, queue age, acceptance, deferrals, bounce classification, complaints, and token redemption. High acceptance with low redemption may indicate a user-interface or authentication problem. Rising queue age with normal acceptance may indicate worker capacity. Without both sides, the dashboard invites guesses.

Authentication has hard constraints. SPF has a DNS lookup processing limit of 10 mechanisms that require DNS queries; exceeding it produces a permanent error under RFC 7208. DKIM signatures must survive transformations in the sending path, and DMARC alignment must match the policy the organization intends to enforce. These are configuration constraints, not delivery badges.

There is no universal warm-up curve that guarantees reputation because recipient mix, complaints, authentication, content, and history differ. Start with a small observable stream to expected recipients and pause when deferrals or complaints change materially. Give reset traffic priority capacity from day one. Test controlled mailboxes, but treat a test as a timestamped observation: DNS caches and receiving policies change.

What decision rule survives a provider change?

Choose a transport by its controls and evidence. Can account and report traffic be isolated? Can transient and permanent outcomes be classified? Are stable message IDs available? Can complaints and hard bounces be suppressed? Can the intended domain sign the message? Can exported events reconcile with token and report state?

A managed relay can reduce the work of reputation monitoring and feedback processing, but it is a poor fit when the team needs full control of network-level queues or has a policy against external message processing. A self-operated path offers that control, while imposing responsibility for blocklists, feedback loops, DNS, and incident response. Either shape can fail when authentication is misaligned or retries are uncontrolled. The boundary is operational ownership, not branding.

Sending shape	Best fit	Main limitation
Managed relay	Small operations team that needs feedback and suppression handling	Less control over network-level behavior and provider-specific policy
Self-operated SMTP path	Team that can own DNS, reputation, queues, and incident response	More operational burden and more failure modes to monitor
Split account/report identities	Marketplace with high-value recovery mail and large reports	More configuration, separate dashboards, and separate retention rules

The table is a decision aid, not a ranking. The right choice depends on who will investigate a deferral at 02:00.

My acceptance test would request 100 reset messages across controlled recipients, inject temporary failures, replay acknowledgements, expire tokens, and send a report at the attachment ceiling. Verify account capacity, token redaction, one intended report delivery, and an explainable terminal state for every event. Repeat after changing the transport implementation.

Protect password reset delivery with an authenticated, low-volume identity and bounded queue; isolate generated report attachments with their own identity, retention rule, and retry budget. Reputation is earned by that behavior over time. No subject line or transport switch substitutes for it.

DEV Community