The deliverability model an autonomous operator runs on: what it tracks and how it acts

Outbound used to be "send, wait, hope." In 2026 it is deliverability engineering, and the difference between pipeline and silence is usually not your copy. It is whether anyone is tracking the right signals and acting on them in time.

Most teams treat that tracking as a project: build fields in a CRM, wire webhooks, write stop rules, then hope someone watches the dashboards. An autonomous revenue operator flips it around. The model below is the one Chronic runs on internally. The agent already records sender-identity health, recipient feedback, and inbox-placement proxies at the message, mailbox, and domain level, and it acts on them: pausing, throttling, and suppressing on its own. You set the goal and the approval bar; you do not build the schema.

This post explains what that model looks like, so you can judge any tool (or your own setup) against it, and so you know exactly what an operator is watching on your behalf.

What a deliverability model actually has to do

A deliverability model is the structured set of facts and events that connect five questions:

• Who sent the email (domain, subdomain, mailbox, provider, IP or sending service)
• Whether it was authenticated (SPF, DKIM, DMARC alignment, TLS)
• What happened to the message (delivered, bounced, deferred, spam complaint, unsubscribe, reply)
• How inboxes reacted over time (reputation trends, complaint thresholds, block and deferral patterns)
• What to do next (pause, throttle, route to a different sender, suppress a lead, or change sequencing)

The last line is the one that matters. A model that only records signals is a report. A model an operator runs on closes the loop: every signal maps to an action, automatically.

Why this is non-negotiable now:

• Google and Yahoo's bulk-sender requirements made authentication, one-click unsubscribe, and complaint-rate control table stakes. Mailchimp's summary is a good baseline. (mailchimp.com)
• Microsoft added similar requirements for high-volume senders to Outlook consumer domains. (techcommunity.microsoft.com)
• One-click unsubscribe is a real technical standard, RFC 8058. (datatracker.ietf.org)
• Inbox placement is never guaranteed, even when "delivery" looks fine. Validity reported a 2024 global inbox placement rate of 83.5%. (validity.com)

If you only watch opens and replies, you are missing every upstream signal that decides whether you get seen at all.

Why hand-built tracking fails

When teams try to track deliverability themselves, the data ends up scattered across ESP dashboards, postmaster portals, DMARC report viewers, warmup tools, and CSV exports in Slack threads. That produces three predictable failures:

1. No per-mailbox accountability. One mailbox burns reputation and the whole domain takes the blame.
2. No causal timeline. You see "replies dropped" but cannot tie it to "spam complaints spiked Tuesday from mailbox A into Gmail."
3. No action. Even when someone spots the problem, the sequencer keeps sending until a human intervenes by hand.

An autonomous operator removes all three, because the model is not a side project. It is the substrate the agent sends from. Deliverability becomes a first-class object next to leads, accounts, and deals, wired to behavior and not just to a chart.

The entities the model tracks

There are four primary layers plus an event log.

Sender domain (and subdomain)

The sending identity at the domain level, for example mail.yourcompany.com versus yourcompany.com. Reputation and authentication are evaluated at the domain and subdomain level by mailbox providers, and problems cluster there.

Mailbox (sender identity)

An actual sending mailbox like anna@mail.yourcompany.com. Throttling, warmup state, and negative feedback are usually mailbox-specific first, then roll up.

Lead (recipient identity)

The person being emailed. Per-lead deliverability risk and suppression keep the agent from repeatedly touching bad addresses, spam traps, or chronically complaining segments.

Message (the atomic unit)

A single email attempt. Deliverability is ultimately a per-message outcome, so every rollup is built from message-level facts.

Deliverability event log (the source of truth)

Append-only events: bounce, deferral, complaint, unsubscribe, reply, and more. This is the auditable timeline that survives tool changes and lets the operator backtest its own decisions.

The fields, layer by layer

These are the fields that separate an operator that can act from one that is guessing. Whether Chronic maintains them for you or you are auditing your own stack, this is the bar.

Sender domain

• domain, root_domain, domain_purpose (outbound, newsletter, transactional, mixed)
• provider (google_workspace, microsoft_365, ses, sendgrid, other)
• dns_spf_present, dns_dkim_present, dns_dmarc_present
• dmarc_policy (none, quarantine, reject), dmarc_rua_configured
• bimi_configured, tls_required (optional)
• one_click_unsubscribe_supported (header validation plus endpoint health, see RFC 8058)
• domain_health_score (0-100, computed), domain_health_status (green, yellow, red)
• last_auth_audit_at

Why: SPF, DKIM, and DMARC are now baseline requirements for bulk senders across the major providers, and one-click unsubscribe is a defined standard. (mailchimp.com, datatracker.ietf.org)

Mailbox

• email_address, display_name, mailbox_provider
• mailbox_status (active, paused, warming, disabled)
• warmup_state (not_started, warming, stable, cooldown), warmup_started_at, warmup_target_daily_volume
• daily_send_cap, hourly_send_cap, min_seconds_between_sends, timezone, last_sent_at
• rolling_7d_sent, rolling_7d_hard_bounce_rate, rolling_7d_spam_complaint_rate, rolling_7d_unsubscribe_rate
• mailbox_health_score (0-100), mailbox_health_status (green, yellow, red)

Why: the actions that protect a sending program (pause, throttle, rotate) all operate at the mailbox layer.

Lead deliverability risk

• email, email_domain, email_type (business, consumer, unknown)
• catch_all_detected, role_address_detected (like info@, sales@)
• verification_status (unknown, valid, risky, invalid), last_verified_at
• suppression_status, suppression_reason (hard_bounce, spam_complaint, unsubscribed, manual, policy_block, do_not_contact), suppressed_at
• deliverability_risk_score (0-100), deliverability_risk_factors (for example ["catch_all","consumer_domain","prior_soft_bounce"])
• last_bounce_type, last_bounce_at, last_complaint_at, last_unsubscribe_at

Why: these power per-lead stop rules and keep the agent from targeting segments that reliably degrade reputation.

Message

• lead_id, sender_mailbox_id, sequence_id / campaign_id, step_id
• provider_message_id, subject, template_id, sent_at
• recipient_mx_provider (google, microsoft, yahoo, other, unknown)
• authentication_spf_result, authentication_dkim_result, authentication_dmarc_result (pass, fail, none, unknown)
• dmarc_alignment (aligned, not_aligned, unknown), tls_used
• list_unsubscribe_header_present, list_unsubscribe_post_present (RFC 8058 indicator)
• delivery_status (accepted, delivered, bounced, deferred, unknown), first_outcome_at, final_outcome_at

Most systems cannot reliably store "inbox vs spam," so the proxies above plus event outcomes carry the load.

Deliverability event log (append-only, never overwritten)

• message_id (nullable for domain-level events), sender_domain_id, sender_mailbox_id, lead_id (nullable)
• event_time, event_source (smtp, esp_webhook, postmaster, dmarc_rua, manual)
• event_type (see below), event_subtype, smtp_code, smtp_enhanced_code, raw_reason
• bounce_class, severity (info, warn, critical), metadata

Event types worth recording: SENT, DELIVERED (when the provider gives it, since SMTP acceptance is not always delivery), DEFERRED, BOUNCE_HARD, BOUNCE_SOFT, SPAM_COMPLAINT, UNSUBSCRIBE, REPLY, OOTO, BLOCKED, AUTH_FAILURE, WARMUP_STATE_CHANGED, SUPPRESSION_APPLIED.

Classify everything the same way

Automation cannot argue with humans about edge cases, so the classifications have to be unambiguous.

Bounce classes, mapped from SMTP enhanced status codes and provider webhooks: invalid_mailbox, invalid_domain (NXDOMAIN, no MX), mailbox_full (soft), spam_block (reputation or policy, includes 550 5.7.x variants), rate_limited (421 deferrals, throttles), content_rejected, auth_failed, unknown.

Suppression reasons, kept strict: hard_bounce, spam_complaint, unsubscribed, do_not_contact, policy_block, manual.

One-click unsubscribe. It is signaled by the List-Unsubscribe and List-Unsubscribe-Post headers, standardized in RFC 8058. (datatracker.ietf.org) The model records whether outbound mail carries the headers and whether the unsubscribe endpoint succeeded. The fastest way to generate spam complaints is to make opting out hard, so this is a reputation control, not a compliance footnote.

Inbox-placement proxies (what to watch when you cannot measure "inbox")

Few outbound programs have seed-list infrastructure or consistent inbox-placement testing. That is fine. The proxies, rolled up by mailbox, domain, and recipient provider (Gmail vs Microsoft vs Yahoo), tell most of the story:

• Deferral rate (DEFERRED / SENT) over 24h and 7d
• Spam complaint rate (SPAM_COMPLAINT / DELIVERED) where available
• Hard bounce rate
• Low-reputation blocks (SMTP reasons parsed into spam_block)
• Reply rate and positive reply rate as a sanity check, not a deliverability metric

Keep one external benchmark for context: Validity cites an 83.5% global inbox placement rate in 2024, a reminder that "delivered" is not "seen." (validity.com)

Scoring health so the agent knows when to slow down

You do not need a machine-learning model to start. You need a score that is explainable, recomputed nightly, and tied directly to action thresholds.

A workable mailbox_health_score (0-100), adjustable to your reality:

• 40%: rolling 7d spam complaint rate (critical)
• 25%: rolling 7d hard bounce rate
• 20%: rolling 7d deferral plus block rate
• 15%: auth compliance rate (SPF, DKIM, DMARC pass plus alignment)

Then a status band: green at 80 or above, yellow at 60 to 79, red below 60.

For thresholds, multiple sources reference a 0.3% spam complaint rate as a critical line for the major providers, usually tracked via postmaster tooling. A conservative outbound posture aims well below that. (hubspot.com, validity.com)

From signal to action

This is the payoff, and it is the part hand-built setups almost never finish. The signals only matter because they trigger behavior.

Stop rules

Deterministic, instant, no human in the loop for the obvious cases.

• On SPAM_COMPLAINT: suppress the lead (suppression_reason = spam_complaint) and stop every active sequence for that lead immediately.
• On UNSUBSCRIBE: suppress and stop sequences, log SUPPRESSION_APPLIED.
• On BOUNCE_HARD with bounce_class in (invalid_mailbox, invalid_domain): suppress as hard_bounce.
• When a mailbox's rolling_7d_spam_complaint_rate crosses threshold: set mailbox_status = paused and escalate for review, with the top campaigns, templates, and segments attached.

That last one is where the operator surfaces an approval. Chronic pauses first, then asks, because protecting the domain is not a decision worth waiting on.

Throttling

Volume that adapts to health rather than a fixed daily number.

1. Start from daily_send_cap per mailbox, set by warmup state.
2. Apply a health multiplier: green 1.0x, yellow 0.6x, red 0.0x (paused).
3. Adjust per provider: if Gmail deferrals spike, slow the send rate (raise min_seconds_between_sends).

Throttling is where most programs feel deliverability improve within days, because it removes the provider-side suspicion signals (rapid bursts, repeated deferrals, retries) that cause blocks in the first place.

Scoring inputs

Lead scoring should never optimize for "reply likelihood" while ignoring "deliverability damage." Deliverability risk belongs in the model as a negative feature: deliverability_risk_score, a risky/invalid verification downgrade, an optional consumer-domain downgrade by ICP, recent soft-bounce counts, and account-level complaint history. That is the difference between "leads that might buy" and "leads you can safely contact at scale."

What this looks like in Chronic

You do not build any of the above. You give Chronic a revenue goal and an approval bar, and the agent runs this model as part of how it operates:

• It sends from managed, warmed mailboxes it provisions and maintains, so warmup state and send caps are its responsibility, not a spreadsheet.
• It logs deliverability events from the sending path and recomputes mailbox and domain health continuously.
• It suppresses, throttles, pauses, and reroutes to a healthier mailbox on its own, and surfaces an approval only when a decision is worth your attention (a mailbox going red, a segment that needs your call).
• It feeds deliverability risk into how it picks and scores leads, so it does not chase prospects that would burn your reputation.

The job to be done is qualified meetings without your managing domains, mailboxes, or sequences. This model is how the agent keeps that promise while protecting your sender identity. Related reading: Cold email in 2026: 9 deliverability mistakes and the fix for each, CRM data hygiene checklist for outbound teams (2026), and Composable outbound stack in 2026.

Trade-offs worth knowing

• True inbox placement is often unknowable. Many systems can only confirm SMTP acceptance, which is why deferrals, blocks, complaints, and replies stand in as proxies.
• Open rates are unreliable. Privacy changes and proxy opens make them a weak deliverability indicator. Store them if you have them; never use them as a primary control.
• Postmaster data is aggregated and delayed. Treat it as a domain-level trend, not a per-message truth source.
• Over-rotation hurts. Switching mailboxes too aggressively creates inconsistent sending patterns. Health-based throttling is usually safer than constant switching, and it is what Chronic prefers.

FAQ

What is a deliverability model in plain English?

It is the set of facts and events that record sender-identity health (domain, mailbox, authentication), recipient feedback (bounces, complaints, unsubscribes), and inbox-placement proxies (deferrals, blocks). Once those exist, suppression, throttling, and routing can run automatically instead of by guesswork.

Do I have to build this myself?

No. With an autonomous operator like Chronic, the agent maintains this model and acts on it. You set the revenue goal and the approval bar; you do not wire fields, webhooks, or stop rules. The model above is what the agent is doing on your behalf.

How is an operator different from a deliverability checklist?

A checklist tells you what to set up once. This model tells the operator what to remember and what to do next, automatically: stop rules, throttling, and scoring. It turns deliverability from a periodic audit into an always-on control system.

How do I track one-click unsubscribe correctly?

Record two things: whether outbound mail carries the List-Unsubscribe and List-Unsubscribe-Post headers (RFC 8058), and the unsubscribe event itself (who, when, which campaign). RFC 8058 defines the header mechanism. (datatracker.ietf.org)

What happens when a mailbox health score turns red?

The mailbox is paused and its sequences stop. Then the investigation order is: authentication regressions (SPF/DKIM/DMARC alignment), segment quality (verification, role accounts, consumer domains), volume spikes (warmup breach), and templates or offers that caused complaint spikes. It restarts with a lower cap and stricter targeting. In Chronic this happens automatically, with an approval surfaced for the call that needs you.