Filter-Sensitive Delivery Routing
Detect when a destination sits behind protective filtering infrastructure and apply the most conservative delivery profile — treating its signals as authoritative rather than as an obstacle.
Runtime state: Destination grouping, per-group connection pooling and deferral-driven backoff all run in the delivery engine. The MX-group throttle hotlist is visible in the operational reports.
- Business objective
- Deliver acceptably to well-protected destinations by respecting their throttling signals immediately, instead of discovering the limit by crossing it.
- Trigger
- Routing resolution for a destination during campaign delivery.
- Inputs
- Resolved routing records for the destination domain
- Known protective filtering signatures in the routing chain
- Observed acceptance and deferral behavior for that destination
- The lane's configured concurrency ceilings
- Outputs
- A per-destination delivery profile — concurrency, pacing and retry shape
- Deferral signals treated as authoritative throttling instructions
- Updated smoothed metrics for that destination group
The framing that matters
This workflow is about being a well-behaved sender to destinations that filter carefully. It is not about circumventing anything.
Protective filtering infrastructure — appliances and services that sit in front of corporate mail — enforces conservative connection and rate expectations. Those expectations are legitimate. A sender that pushes past them gets throttled, then blocked, and the block applies to everything from that identity for a long time.
The correct response is to recognize the destination class early and start conservative, rather than to discover the limit by crossing it. Every signal a receiver sends is treated as an instruction, not as an obstacle to route around.
The workflow
Destination classification to delivery profile
Conservative by default. The receiver's signals are authoritative at every step.
- External service
Resolve the destination's routing chain
Pre-warmed during the start gate; served from cache during delivery.
- Automated software
Classify the destination
Decision point: Does the routing chain match a known protective filtering signature? Group the destination accordingly.
- Automated software
Select the delivery profile
Protected destinations start on the most conservative concurrency and pacing profile available, not on the lane default.
- Automated software
Partition the connection pool
Connections are pooled per destination group, so a conservative profile for one group does not constrain another.
- External service
Deliver within the profile
Decision point: Accepted, deferred or permanently failed.
- Monitoring / feedback
Treat deferrals as authoritative
Decision point: A deferral from a protected destination reduces concurrency immediately. It is read as an instruction, never as a transient to retry through.
- Monitoring / feedback
Update smoothed metrics
Per-destination-group acceptance and deferral behavior feeds the learning agent.
- Automated software
Recover slowly, if at all
Concurrency increases far more slowly than it decreases. Asymmetry is deliberate.
- Human action
Operator reviews persistent throttling
Decision point: Sustained deferral from a destination class is a content, list-quality or reputation question — not a tuning question.
- Human action
- Automated software
- External service
- Monitoring / feedback
Decision points
- Does this destination sit behind protective filtering? Signature match on the routing chain.
- Which profile applies? Conservative by default for this class.
- How to read a deferral? From a protected destination, as an instruction to slow down immediately.
- When to recover concurrency? Slowly, and only on sustained clean acceptance.
- When to escalate to a person? When throttling persists — because at that point the problem is upstream of delivery.
Responsibilities
AI / LLM
- Explaining a sustained deferral pattern to an operator during diagnosis, after the fact.
Deterministic
- Destination classification from the routing chain.
- Profile selection and concurrency ceilings.
- Connection pool partitioning.
- Deferral handling and backoff.
- Smoothed metric calculation.
- The asymmetric recovery curve.
Human approval points
- Configuring profiles and ceilings per destination class.
- Investigating persistent throttling, which is a content, list-quality or reputation question rather than a concurrency one.
- Any decision to change sending identity or content in response.
Failure handling
| Failure | Response |
|---|---|
| Destination classified conservatively when it need not be | Slower delivery to that group. Accepted — the asymmetry favors caution. |
| Deferrals rise on a protected group | Concurrency reduced immediately; the signal is authoritative. |
| Blocking response received | Delivery to that destination group stops. This is escalated to a person, not retried around. |
| Throttling persists after backing off | Escalated. The cause is upstream — content, list quality or reputation. |
| Routing chain unresolvable | Handled by the pre-warm gate before sending starts. |
Monitoring
Acceptance and deferral rate per destination group, concurrency level against ceiling, backoff frequency, time to recovery after backoff, and blocking responses. A blocking response is treated as an incident, not as a metric.
Business value
Protected destinations are frequently the highest-value recipients. Sustained access depends entirely on being a well-behaved sender, and a single aggressive run can cost weeks of reputation.
Related projects
Related workflows
- Closed-Loop Throughput Tuning
Adjust delivery concurrency from smoothed per-destination outcomes rather than from static configuration — with ceilings a loop can never exceed.
- Campaign Creation to Delivery
From an operator composing a campaign to messages accepted by receiving providers, through a single mandatory suppression gate and a fail-closed readiness barrier.