Deliverability CRM Fields: Data Model for Outbound

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 your data model.

TL;DR: A deliverability data model is the set of CRM fields + event logs that let you measure sender identity health (domain, mailbox, auth), recipient feedback (bounces, spam complaints, unsubscribes), and inbox placement proxies, then turn those signals into automation (stop rules, throttles, suppressions, and scoring inputs). If your CRM does not store these signals at the right granularity (message, mailbox, domain, lead), you will keep “fixing deliverability” with opinions instead of evidence.

Definition: what a “deliverability data model” means (and why it matters)

A deliverability data model is a structured schema that connects:

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 complained, unsubscribed, replied)
How inboxes reacted over time (reputation trends, complaint thresholds, block/deferral patterns)
What your system should do next (pause, throttle, route to a different sender, suppress a lead, or change sequencing logic)

Why it matters now:

Google and Yahoo’s bulk sender requirements made authentication, one-click unsubscribe, and complaint-rate control table stakes. Many senders track these in scattered tools, not in the CRM where outbound decisions are actually made. Mailchimp’s summary of these requirements is a good baseline reference. Mailchimp newsroom post
Microsoft followed with similar requirements for high-volume senders to Outlook consumer domains. Microsoft Tech Community
“One-click unsubscribe” is a real technical standard (RFC 8058). RFC 8058
Industry benchmark reporting continues to show inbox placement is not guaranteed, even when “delivery” looks fine. Validity reports a 2024 global inbox placement rate of 75.6%. Validity: 6 email marketing trends for 2025

If you only track opens and replies, you are missing the upstream signals that decide whether you even get seen.

The problem: outbound teams track deliverability in the wrong place

Most teams keep deliverability data in:

ESP dashboards
Postmaster portals
DMARC report viewers
Warmup tools
CSV exports in Slack threads

That creates three predictable failures:

No per-mailbox accountability
One mailbox burns reputation and the whole domain gets blamed.
No causal timeline
You see “replies dropped,” but you cannot tie it to “spam complaints spiked on Tuesday from mailbox A into Gmail.”
No automation hooks
Even if someone spots the issue, the sequencer keeps sending until you manually intervene.

A deliverability data model fixes this by making deliverability a first-class object in your CRM, alongside leads, accounts, and deals.

Core concepts: the entities you need (objects) and why

You want four primary entity layers, plus an event log.

1) Sender Domain (and Subdomain)

Represents your sending identity at the domain level, for example mail.yourcompany.com versus yourcompany.com.

Why: reputation and authentication are evaluated at domain and subdomain levels by mailbox providers, and problems often cluster there.

2) Mailbox (sender identity)

Represents an actual sending mailbox like anna@mail.yourcompany.com.

Why: throttling, warmup state, and negative feedback are usually mailbox-specific first, then roll up.

3) Lead (recipient identity)

Represents the person you email.

Why: suppression and “per-lead deliverability risk” prevents you from repeatedly touching bad addresses, spam traps, or chronically complaining segments.

4) Message (the atomic unit)

Represents a single email attempt.

Why: deliverability is ultimately a per-message outcome. Your rollups should come from message-level facts.

5) Deliverability Event Log (the source of truth)

Append-only events: bounce, deferral, complaint, unsubscribe, reply, etc.

Why: you need an auditable timeline that survives tool changes and allows backtesting.

The deliverability CRM fields schema (copyable)

Below is a practical schema you can copy into your CRM or data warehouse. It is designed to support stop rules, throttles, and scoring.

Sender domain fields (table: `sender_domain`)

Minimum viable “deliverability CRM fields” at the domain layer:

sender_domain_id (PK)
domain (example: mail.yourcompany.com)
root_domain (example: yourcompany.com)
domain_purpose (enum: outbound, newsletter, transactional, mixed)
provider (enum: google_workspace, microsoft_365, ses, sendgrid, other)
dns_spf_present (bool)
dns_dkim_present (bool)
dns_dmarc_present (bool)
dmarc_policy (enum: none, quarantine, reject)
dmarc_rua_configured (bool)
bimi_configured (bool, optional)
tls_required (bool, optional)
one_click_unsubscribe_supported (bool, based on header validation and unsubscribe endpoint health; see RFC 8058)
domain_health_score (0-100, computed)
domain_health_status (enum: green, yellow, red)
last_auth_audit_at (datetime)
notes

Why these matter: SPF, DKIM, and DMARC are now baseline requirements for bulk senders across major providers, and one-click unsubscribe is a defined standard via RFC 8058. Mailchimp newsroom post, RFC 8058

Mailbox fields (table: `sender_mailbox`)

Track the mailbox as an operational unit.

sender_mailbox_id (PK)
sender_domain_id (FK)
email_address
display_name
mailbox_provider (enum: google_workspace, microsoft_365, other)
mailbox_status (enum: active, paused, warming, disabled)
warmup_state (enum: not_started, warming, stable, cooldown)
warmup_started_at (datetime)
warmup_target_daily_volume (int)
daily_send_cap (int, enforced cap)
hourly_send_cap (int)
min_seconds_between_sends (int)
timezone
last_sent_at (datetime)
rolling_7d_sent (int, computed)
rolling_7d_hard_bounce_rate (decimal)
rolling_7d_spam_complaint_rate (decimal)
rolling_7d_unsubscribe_rate (decimal)
mailbox_health_score (0-100, computed)
mailbox_health_status (enum: green, yellow, red)

Why these matter: the automation you actually need (pause, throttle, rotate) operates at the mailbox layer.

Lead deliverability risk fields (table: `lead`)

Add a deliverability slice to your lead record so outbound can avoid known hazards.

lead_id (PK)
email
email_domain (computed)
email_type (enum: business, consumer, unknown)
catch_all_detected (bool)
role_address_detected (bool, like info@, sales@)
verification_status (enum: unknown, valid, risky, invalid)
last_verified_at (datetime)
suppression_status (enum: not_suppressed, suppressed)
suppression_reason (enum: hard_bounce, spam_complaint, unsubscribed, manual, policy_block, do_not_contact)
suppressed_at (datetime)
deliverability_risk_score (0-100)
deliverability_risk_factors (json array, example: ["catch_all","consumer_domain","prior_soft_bounce"])
last_bounce_type (enum: see bounce taxonomy below)
last_bounce_at (datetime)
last_complaint_at (datetime)
last_unsubscribe_at (datetime)

Why these matter: these fields power per-lead stop rules and help your AI avoid targeting segments that reliably degrade reputation.

Message fields (table: `outbound_message`)

This object ties your CRM campaign logic to deliverability outcomes.

message_id (PK)
lead_id (FK)
sender_mailbox_id (FK)
sequence_id / campaign_id
step_id
provider_message_id (from ESP or SMTP relay)
subject
template_id
sent_at (datetime)
recipient_mx_provider (enum: google, microsoft, yahoo, other, unknown)
authentication_spf_result (enum: pass, fail, none, unknown)
authentication_dkim_result (enum: pass, fail, none, unknown)
authentication_dmarc_result (enum: pass, fail, none, unknown)
dmarc_alignment (enum: aligned, not_aligned, unknown)
tls_used (bool, if available)
list_unsubscribe_header_present (bool)
list_unsubscribe_post_present (bool, RFC 8058 indicator)
delivery_status (enum: accepted, delivered, bounced, deferred, unknown)
first_outcome_at (datetime)
final_outcome_at (datetime)

Important: Many teams cannot reliably store “inbox vs spam.” You still want the proxies above, plus event outcomes.

Deliverability event log (table: `deliverability_event`)

Make this append-only. Do not overwrite history.

event_id (PK)
message_id (FK, nullable if event is domain-level like postmaster)
sender_domain_id (FK)
sender_mailbox_id (FK)
lead_id (FK, nullable for domain-level)
event_time (datetime)
event_source (enum: smtp, esp_webhook, postmaster, dmarc_rua, manual)
event_type (enum: see below)
event_subtype (string)
smtp_code (string, nullable)
smtp_enhanced_code (string, nullable)
raw_reason (string)
bounce_class (enum)
severity (enum: info, warn, critical)
metadata (json)

Event type taxonomy (recommended)

SENT
DELIVERED (if your provider gives it; SMTP acceptance is not always “delivered”)
DEFERRED (temporary failure)
BOUNCE_HARD
BOUNCE_SOFT
SPAM_COMPLAINT
UNSUBSCRIBE
REPLY
OOTO (out-of-office, optional but useful)
BLOCKED (policy or reputation)
AUTH_FAILURE (SPF/DKIM/DMARC issues detected)
WARMUP_STATE_CHANGED
SUPPRESSION_APPLIED

Bounce types, suppression reasons, and “what counts” (make it unambiguous)

You need a consistent classification so automation does not argue with humans.

Bounce classification (field: `bounce_class`)

Use a small set that maps from SMTP enhanced status codes and provider webhooks:

invalid_mailbox (user does not exist)
invalid_domain (NXDOMAIN, no MX)
mailbox_full (soft)
spam_block (reputation/policy, includes 550 5.7.x variants)
rate_limited (421 deferrals, throttles)
content_rejected (policy/content flags)
auth_failed (SPF/DKIM/DMARC failures)
unknown

Suppression reasons (field: `suppression_reason`)

Keep these strict:

hard_bounce
spam_complaint
unsubscribed
do_not_contact
policy_block (optional, if you want to stop retrying)
manual

One-click unsubscribe compliance (why it belongs in your CRM)

One-click unsubscribe is signaled via headers: List-Unsubscribe and List-Unsubscribe-Post. That is standardized in RFC 8058. RFC 8058

In practice, your CRM should store:

Whether your templates include the header
Whether your unsubscribe endpoint returned success (you can log an internal event when a recipient clicks)

This matters because the fastest way to generate spam complaints is to make opt-out difficult.

Inbox placement proxies: what to track when you cannot measure “inbox”

Most outbound teams do not have seed list infrastructure or consistent inbox placement testing. That is OK, but you still need proxies.

Track these rollups by mailbox, domain, and recipient provider (Gmail vs Microsoft vs Yahoo):

Deferral rate (DEFERRED / SENT) over 24h and 7d
Spam complaint rate (SPAM_COMPLAINT / DELIVERED) where available
Hard bounce rate
“Suspicious due to low reputation” blocks (parse SMTP reasons into spam_block)
Reply rate and positive reply rate (as a sanity check, not a deliverability metric)

Also keep one external benchmark in mind for executive reporting: Validity cites a 75.6% global inbox placement rate in 2024, which is a reminder that “delivered” is not “seen.” Validity: 6 email marketing trends for 2025

Domain health and mailbox health: a practical scoring model

You do not need a fancy ML model to start. You need a score that is:

explainable
computed nightly
directly tied to automation thresholds

Suggested `mailbox_health_score` components (0-100)

Example weighting (adjust by your reality):

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

Then store:

mailbox_health_status:
- green = score >= 80
- yellow = 60-79
- red = < 60

Practical threshold reference

Multiple sources reference a 0.3% spam complaint rate as a critical threshold for major providers, often tracked via Postmaster tooling and compliance guidance. For a conservative outbound posture, many teams aim significantly below that. HubSpot deliverability webinar PDF, Validity benchmark report PDF

How to connect deliverability CRM fields to automation (stop rules, throttling, and scoring)

This is the payoff: your schema becomes an engine.

1) Stop rules (lead-level and mailbox-level)

Implement deterministic rules that trigger instantly from events.

Lead-level stop rules

If event_type = SPAM_COMPLAINT then:
1. set lead.suppression_status = suppressed
2. set lead.suppression_reason = spam_complaint
3. stop all active sequences for that lead immediately
If event_type = UNSUBSCRIBE then:
- suppress lead and stop sequences (and log SUPPRESSION_APPLIED)
If event_type = BOUNCE_HARD with bounce_class in (invalid_mailbox, invalid_domain) then:
- suppress lead as hard_bounce

Mailbox-level stop rules

If sender_mailbox.rolling_7d_spam_complaint_rate >= threshold then:
- set mailbox_status = paused
- create a task for RevOps to investigate, including the top campaigns, templates, and segments

2) Throttling rules (delivery-aware pacing)

Use your fields to dynamically adjust volume.

Example throttling logic:

Start with daily_send_cap per mailbox based on warmup state.
Apply multipliers by health status:
- green: 1.0x
- yellow: 0.6x
- red: 0.0x (pause)
Apply provider-specific adjustments:
- if recipient_mx_provider = google and deferrals spike, slow the send rate (increase min_seconds_between_sends)

Throttling is where most teams “feel” deliverability improvement within days because it reduces provider-side suspicion signals (rapid bursts, repeated deferrals, and retries).

3) Scoring inputs (tie deliverability risk into AI lead scoring)

Do not let AI lead scoring optimize for “reply likelihood” while ignoring “deliverability damage.”

Add these as negative features in your scoring model:

lead.deliverability_risk_score (direct feature)
lead.verification_status (risky/invalid downgrade)
lead.email_type = consumer (optional downgrade depending on your ICP)
Prior soft_bounce count in last 30 days
Account-level complaint history for that domain segment (if you model accounts)

If you are using Chronic Digital’s scoring, treat deliverability as a first-class signal alongside intent and fit. This is the difference between “leads that might buy” and “leads you can safely contact at scale.” (Related: Proof-based lead scoring model with evidence fields and AI lead scoring feature)

Concrete implementation blueprint in Chronic Digital (fields + workflows)

If you are implementing this in Chronic Digital, the clean pattern is:

Create sender objects: Sender Domain and Sender Mailbox as custom objects (or equivalent).
Log deliverability events from:
- your ESP webhooks
- SMTP relay responses
- unsubscribe clicks
Compute rollups nightly into mailbox and domain health scores.
Wire automations:
- pause sequences
- throttle sending
- suppress leads
- reroute to a healthier mailbox when appropriate

Where Chronic Digital helps:

Use Lead enrichment to populate email domain, company context, and segmentation fields that correlate with deliverability risk (for example, consumer vs business domains).
Use the Sales pipeline to separate “deliverability holds” from “active outreach” so reps do not keep retrying leads that should be suppressed.
Use the AI email writer for controlled template variants, but only after your stop rules and throttles exist, otherwise you will generate more volume without control.

Related reads that pair well with this schema (without duplicating a checklist):

Common trade-offs and limitations (so you design this sanely)

You will not always know true inbox placement. Many systems can only confirm SMTP acceptance, not inbox vs spam. That is why you track deferrals, blocks, complaints, and replies as proxies.
Open rates are unreliable. Privacy changes and proxy opens make opens a weak deliverability indicator for outbound. Store them if you have them, but do not use them as a primary deliverability control.
Postmaster data is aggregated and delayed. Treat it as a trend signal at the domain level, not a per-message truth source.
Over-automation can hurt. If you rotate mailboxes too aggressively, you can create inconsistent sending patterns. Health-based throttling is usually safer than constant switching.

FAQ

What are “deliverability CRM fields” in plain English?

They are the specific CRM fields that record sender identity health (domain, mailbox, authentication), recipient feedback (bounces, complaints, unsubscribes), and inbox placement proxies (deferrals, blocks). Once those fields exist, you can automate suppression, throttling, and routing instead of guessing.

What is the minimum deliverability data model I can start with this week?

Start with:

Sender mailbox table (status, warmup state, daily cap)
Message table (sender mailbox, lead, sent time)
Event log (hard bounce, soft bounce, complaint, unsubscribe, reply)
Lead suppression fields (status, reason, date) That is enough to implement stop rules and basic throttling.

How do I track one-click unsubscribe correctly?

Store two things:

whether you include List-Unsubscribe and List-Unsubscribe-Post headers (RFC 8058) in outbound mail, and
the unsubscribe event itself (who, when, which campaign).
RFC 8058 defines the header mechanism. RFC 8058

Should deliverability signals affect AI lead scoring?

Yes. If scoring ignores deliverability risk, it will select leads that might be a fit but damage your sender reputation (invalid addresses, high complaint likelihood). Use deliverability risk as a negative input so the model optimizes for pipeline you can actually reach.

What should I do when a mailbox health score turns red?

Automatically pause that mailbox, stop sequences tied to it, and investigate in this order:

authentication regressions (SPF/DKIM/DMARC alignment)
segment quality (verification, role accounts, consumer domains)
sudden volume spikes (warmup breach)
templates and offers that caused complaint spikes
Then restart with a lower cap and stricter targeting.

How is this different from a generic deliverability checklist?

A checklist tells you what to set up. A deliverability data model tells your CRM 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.

Implement the schema, then turn on the guardrails

If you want outbound to stop flying blind, do it in this order:

Implement the schema above (domain, mailbox, lead risk, message, event log).
Define suppression and bounce taxonomy so every event maps to a rule.
Ship three automations on day one:
- suppress on complaint, unsubscribe, hard bounce
- pause mailbox on threshold breach
- throttle based on mailbox health score
Only then scale volume and experiment with templates, sequencing, and AI personalization.

Once these deliverability CRM fields are in place, outbound becomes measurable engineering: you can see what is breaking, where it is breaking, and you can stop it automatically before it burns your domain.

The CRM Deliverability Data Model: Fields and Events to Track So Outbound Stops Flying Blind