Inside a Deliverability Engagement: What the First 90 Days Actually Look Like

Do not index

This article offers a transparent look at the email deliverability audit process inside a real engagement.

A typical deliverability engagement begins with access and discovery, moves into a structured audit, and then progresses through remediation, monitoring, and iteration during the first 90 days. That initial period rarely produces instant recovery. It should, however, produce a clear sending map, validated authentication, reduced operational risk, and a more controlled email program.

Key takeaways

An email deliverability audit process starts with access to DNS, ESP reporting, postmaster tools, and recent sending history.

Week 1 and week 2 typically focus on infrastructure, authentication, reputation, volume behavior, list quality, and message construction.

Week 2 through week 4 usually focus on remediation in a deliberate sequence so mailbox-provider responses can be interpreted accurately.

Week 4 through week 12 usually focus on monitoring, alerting, and controlled change management.

A strong deliverability engagement improves visibility and reduces risk, but it cannot correct weak consent practices or harmful sending habits on its own.

If you have ever wondered what a deliverability consultant actually does once an engagement begins, the answer is usually less mysterious than the market suggests. The work is methodical. It combines technical review, risk assessment, operational cleanup, and ongoing monitoring. It also depends heavily on access, sending history, and the quality of the underlying program.

Table of Contents

Key takeaways What happens in week 1 of a deliverability engagement?What is typically requested What is usually not requested What gets audited in week 1 and week 2?1. Infrastructure Mapping 2. Authentication and DNS Validation 3. Reputation and Provider Signals 4. Sending Patterns and Volume Behavior 5. List Acquisition, Hygiene, and Engagement 6. Message Construction and Operational Risk What gets fixed in week 2 through week 4?What the client does versus what MailAdept does What happens in week 4 through week 12?What is watched daily What triggers an alert What the weekly review covers What does good look like at 30, 60, and 90 days?At 30 days At 60 days At 90 days What does a deliverability engagement not fix?Frequently Asked Questions What data does a consultant need at the start?How long does a deliverability engagement timeline usually take?Can MailAdept fix everything without the client?What is included in a deliverability audit checklist?

What happens in week 1 of a deliverability engagement?

Week 1 is primarily about visibility. Gmail, Outlook, and Yahoo placement issues cannot be diagnosed reliably until the sending setup, domain structure, access model, and recent sending history are fully understood.

An email deliverability audit process should begin with read access, not broad administrative control. Read access allows a consultant to inspect DNS, ESP reporting, and postmaster data without introducing uncontrolled production changes.

At this stage, the standard request is read access, not broad administrative control.

What is typically requested

DNS read access provides visibility into SPF, DKIM, DMARC, return-path alignment, and sending subdomains. That access may come through direct read-only permissions, screenshots, or exports from tools such as Cloudflare, Route 53, or GoDaddy.

1. DNS read access, or screenshots or exports of DNS recordsThis is needed to verify SPF, DKIM, DMARC, return-path alignment, and sending subdomain configuration. In some environments, consultants receive direct read-only DNS access. In others, the client shares exports or screenshots from Cloudflare, Route 53, GoDaddy, or another provider.

Why it matters: DNS is where trust signals are declared. If the sending setup is fragmented, outdated, or misaligned, mailbox providers will detect those issues long before they evaluate creative or campaign timing.

ESP reporting access provides read access to campaign, automation, bounce, complaint, suppression, and segment reporting within the sending platform. It helps determine whether a problem is isolated to a single stream, segment, or operational change.

2. ESP reporting accessRead access to the email service provider is usually required, whether that platform is Klaviyo, HubSpot, Mailchimp, Iterable, Braze, Customer.io, Salesforce Marketing Cloud, or another provider. The goal is not to edit automations on day one. The goal is to inspect bounce categories, complaint trends, segment logic, suppression behavior, recent volume shifts, and differences between campaigns and triggered mail.

Why it matters: the sending platform contains the operational record. It often shows whether performance decline is gradual, isolated to one stream, or tied to a recent change in volume, segmentation, or domain usage.

Postmaster tools are mailbox-provider dashboards that expose domain or IP reputation, complaint patterns, and delivery anomalies. Google Postmaster Tools and Microsoft SNDS are the two most commonly used in deliverability work when available.

3. Postmaster tool accessWhere available, access is requested to Google Postmaster Tools and any equivalent reputation dashboards the sender has configured. Microsoft SNDS may also be relevant for senders with meaningful Outlook and Microsoft mailbox volume.

Why it matters: postmaster tools provide provider-level signals that the ESP cannot. They can reveal domain or IP reputation shifts, complaint patterns, authentication issues, and delivery anomalies.

4. A recent sending calendar or campaign logThis can be simple. A spreadsheet of major sends, promotional spikes, seasonal pushes, list imports, migration dates, or segmentation changes is often sufficient.

Why it matters: reputation issues frequently follow operational events. If performance changed after a list upload, a new warm-up, a platform migration, or a sudden increase in frequency, the timeline is important.

5. Current list acquisition sourcesThe consultant will usually ask where subscribers originate, such as checkout opt-in, lead forms, content downloads, co-registration, events, sales imports, support flows, or legacy uploads.

Why it matters: acquisition source influences complaint risk, engagement quality, and the likelihood of invalid or low-intent addresses entering the program.

What is usually not requested

Inbox contents are not typically requested in a standard deliverability review. Seed testing or controlled test accounts may be used to observe placement, but that is not the same as reviewing a person’s real inbox history.

Password access to unrelated systems is not typically requested unless a system directly controls email sending and the scope is clearly defined. CRM admin access, billing access, and unrelated internal records are usually outside the initial review.

Customer message bodies at scale are not the focus of week 1. A few representative samples may be reviewed, but the initial focus is infrastructure and sending behavior, not private correspondence.

That distinction matters. A professional engagement is designed to obtain enough access to diagnose sending risk, not unnecessary exposure to customer data.

What gets audited in week 1 and week 2?

A deliverability audit checklist usually follows a defined sequence because some findings only make sense after earlier findings are confirmed. A structured process makes it easier to distinguish root causes from symptoms.

1. Infrastructure Mapping

Infrastructure mapping is the process of identifying every domain, subdomain, ESP, IP, and sending stream involved in a mail program. It also identifies who owns DNS, who controls the ESP, and who can implement changes.

The first task is to map the full sending environment.

That includes identifying:

all sending domains and subdomains

all ESPs or outbound systems in use

which streams are marketing, lifecycle, transactional, and support

whether dedicated IPs, shared pools, or both are in use

who controls DNS, who controls the ESP, and who can implement fixes

What a finding looks like: a company may be sending campaigns from the root domain, transactional mail from the same domain through another provider, and support mail through a third system with no documented ownership. That is not unusual, but it creates confusion around reputation, alignment, and accountability.

2. Authentication and DNS Validation

SPF, DKIM, and DMARC are the core authentication controls used to show that mail is authorized and aligned with the visible sender identity. They do not guarantee inbox placement, but they are foundational trust signals for Gmail, Outlook, and Yahoo.

Once the sending map is clear, the authentication review becomes meaningful.

This stage checks:

SPF structure and lookup-count issues

DKIM presence and selector validity

DMARC policy and alignment

custom return-path configuration

bounce domain setup

tracking domain alignment

whether old or unused senders still have active DNS records

What a finding looks like: SPF may technically pass for one stream while DKIM is missing for another. DMARC may exist but fail alignment with the visible From domain. A tracking domain may still point to an old vendor. These are not abstract issues. They affect trust and make later analysis more difficult if they are not resolved first.

3. Reputation and Provider Signals

Sender reputation is the aggregate trust mailbox providers assign to a domain, IP, or stream based on historical behavior and recipient response. Reputation can vary by provider, which means Gmail, Outlook, and Yahoo may react differently to the same sender.

With infrastructure validated, the next question is how mailbox providers currently view the sender.

This includes reviewing:

Google Postmaster reputation trends

Microsoft network data where relevant

blocklist status

bounce classifications by provider

complaint rates by stream

signs of bulk-folder placement, temporary deferrals, or outright blocking

What a finding looks like: Gmail may show a decline from medium to low domain reputation during the same period that complaint rates rose on promotional sends. Outlook may show elevated deferrals while Gmail remains stable. That pattern suggests the issue is not universal, and the recovery plan should not assume identical provider behavior.

4. Sending Patterns and Volume Behavior

Volume behavior refers to how much mail is sent, how often it is sent, and which recipients receive repeated sends over time. It matters because abrupt spikes, unstable cadence, and aggressive ramp-ups can create trust problems even when authentication is correct.

Once reputation is understood, volume behavior can be analyzed in context.

The audit reviews:

daily and weekly send-volume trends

sudden spikes or drops

launch events, seasonal pushes, or migrations

the ratio of promotional to triggered mail

cadence changes by segment

frequency concentration among the same subscribers

What a finding looks like: a sender may have doubled campaign frequency within a month, or migrated to a new domain and sent at mature volume immediately. Another common finding is over-mailing a small active segment while still batch-sending to large inactive groups.

5. List Acquisition, Hygiene, and Engagement

List quality is the combined effect of consent, source quality, hygiene, and ongoing recipient engagement. It is one of the strongest drivers of complaint risk, bounce risk, and long-term sender reputation.

At this stage, the consultant can connect infrastructure and volume behavior to audience quality.

This review covers:

opt-in method and proof of consent

source quality by list segment

bounce-rate trends

complaint sources

unengaged population size

suppression rules

sunset logic, or the lack of it

any historical purchased, scraped, or appended data

What a finding looks like: the highest-complaint cohort may come from a giveaway source, a co-registration path, or an old sales import. Another common finding is that the program has no working definition of inactivity, so people who have not opened or clicked in a year still receive every campaign.

6. Message Construction and Operational Risk

Message construction refers to the combination of From identity, template structure, link behavior, unsubscribe handling, and the operational logic that determines when an email is sent. It matters because confusing identity, broken unsubscribe flows, and automation overlap can increase complaints even when infrastructure is sound.

Content is usually examined last, not because it is unimportant, but because content issues are often overstated when the real problem lies in reputation, authentication, or targeting.

The review typically checks:

consistency of From name and From address

subject-line behavior

link domains and redirect chains

image-to-text balance in context

footer clarity and unsubscribe behavior

template rendering issues

transactional versus promotional boundary issues

whether automations continue sending after negative signals

What a finding looks like: a password-reset template may share branding but route through the same domain and infrastructure as high-volume promotions. An unsubscribe flow may technically exist but still be difficult to complete, increasing complaint risk.

By the end of week 2, the output is not a vague theory. It is a prioritized list of risks, dependencies, and recommended actions.

What gets fixed in week 2 through week 4?

Remediation is where sequencing matters most. If a team changes domains, authentication, segmentation, volume, and templates in the same week, provider responses become much harder to interpret.

A typical remediation order looks like this:

First, stabilize trust signals.Authentication issues, broken DNS alignment, incorrect return-path configuration, or shared-domain confusion are usually addressed first.

Second, isolate critical streams.If marketing and transactional mail are mixed on the same domain or setup, separation is often prioritized. This reduces the chance that one stream will harm another and makes monitoring clearer.

Third, stop avoidable harm.This can include pausing risky segments, suppressing long-term inactive users, halting questionable acquisition sources, or slowing volume on a newly introduced domain.

Fourth, repair operational logic.Examples include adjusting segment rules, correcting automation overlap, tightening unsubscribe handling, or implementing reasonable send-frequency controls.

Fifth, tune templates and message construction where needed.Template work is usually not the first fix unless a specific template is generating obvious complaints, broken links, or rendering failures.

What the client does versus what MailAdept does

The division of responsibility is usually straightforward.

MailAdept typically does:

audit and documentation

prioritization of fixes

technical recommendations

validation of DNS and authentication changes

monitoring setup

interpretation of provider-level signals

weekly status reviews and next-step recommendations

The client typically does:

approve changes

make DNS updates if internal policy requires it

grant platform access

implement segmentation or lifecycle adjustments inside the ESP

confirm business constraints, such as legal retention rules or campaign commitments

align internal teams, especially if engineering, CRM, and support all affect email

In some engagements, MailAdept can implement much of the work directly. In others, especially within larger organizations, MailAdept functions more as a technical operator and reviewer while internal teams make production changes.

Infrastructure fixes can happen quickly. Reputation recovery usually cannot. A clean DNS setup does not erase months of poor list practices overnight.

Teams that want a more hands-on operating model often choose to work with a deliverability team rather than treat the audit as a one-time document.

What happens in week 4 through week 12?

Monitoring and iteration is the phase in which a deliverability engagement shifts from diagnosis to pattern detection. This matters because mailbox-provider responses are gradual, uneven, and easier to understand when changes are controlled.

This phase defines the practical deliverability engagement timeline for most programs because the goal is to understand provider response over time, not just immediately after fixes.

What is watched daily

Daily monitoring usually includes:

bounce rates, especially hard bounces and provider-specific deferrals

complaint rates by campaign and segment

unusual open-rate declines when measurement remains directionally useful

sudden changes in click activity

domain and IP reputation indicators where available

blocklist events

authentication failures

send-volume spikes by stream

anomalies in transactional delivery

The objective is not to overreact to every fluctuation. It is to identify patterns early enough to investigate them before they expand.

What triggers an alert

An alert is usually triggered by a change, not by a single metric in isolation.

Common examples include:

a complaint spike tied to one acquisition source or campaign

a bounce pattern isolated to a mailbox provider

a sudden volume increase from a previously quiet stream

DKIM or SPF failures after a DNS change

transactional mail showing unusual delay or spam placement

a measurable drop in engagement on segments that were previously stable

A useful alert includes context. It should explain what changed, when it began, which stream is affected, and whether the issue appears technical, reputational, or audience-related.

What the weekly review covers

Weekly reviews are where true signal is separated from normal noise.

A productive review usually covers:

what changed this week in DNS, segmentation, templates, or sending behavior

whether provider signals moved in the expected direction

campaign cohorts with outlier complaints or bounces

inactive-suppression results

any warm-up progress on domains or IPs

issues that remain unresolved because they depend on internal approvals

what to change next week, and what not to change yet

Most of the value comes from consistency. Watch the right signals, make one meaningful change at a time, and document the response.

What does good look like at 30, 60, and 90 days?

No credible deliverability provider should promise identical results across all senders. Useful milestones still exist, and they help teams measure progress without creating unrealistic expectations.

At 30 days

Good progress at 30 days usually means the environment is cleaner and easier to interpret.

That often includes:

complete visibility into all sending streams

corrected or validated SPF, DKIM, and DMARC setup

separation of risky and critical mail where possible

suppression of clearly problematic audiences

baseline monitoring in place

fewer unknowns in bounce and complaint reporting

Inbox placement may still be inconsistent at 30 days, especially if the sender has a weak history with Gmail, Outlook, or Yahoo.

At 60 days

Good progress at 60 days often looks more operational than cosmetic.

That may include:

more stable complaint behavior

better consistency between campaigns rather than sharp swings

early reputation recovery on some providers

a more disciplined volume pattern

clearer rules for who should stop receiving campaigns

fewer emergency fixes caused by preventable setup issues

Provider-specific outcomes may still vary. Gmail, Outlook, Yahoo, and smaller regional providers do not always recover at the same pace.

At 90 days

Good progress at 90 days usually means the program is no longer being managed on assumptions.

That often includes:

a documented sending architecture

established ownership of DNS, ESP, and postmaster tools

working alerting and review cadence

known risky sources and segments under control

a repeatable process for launching changes without damaging reputation

enough historical monitoring to judge whether the program is improving, flat, or constrained by deeper issues

An honest 90-day outcome is not a percentage promise. It is a maturity shift. Some programs see faster placement improvement. Others mainly achieve clarity, risk reduction, and a stable foundation for slower recovery.

What does a deliverability engagement not fix?

Deliverability work has limits. It can reduce risk and improve clarity, but it cannot manufacture recipient demand or override harmful business decisions.

1. The audience never wanted the mail in the first placeIf the program depends on purchased data, low-intent acquisition, or systematically weak consent, technical cleanup will not create genuine recipient demand.

2. The business will not stop harmful sending behaviorIf leadership insists on mailing inactive users indefinitely, ignoring complaints, or forcing volume spikes regardless of reputation signals, the process becomes damage control.

3. The sending setup cannot be changedSometimes the root issue is known, but DNS ownership is unclear, ESP limitations are fixed, or internal governance delays remediation for months.

4. Measurement is too poor to diagnose cause and effectIf multiple teams change targeting, templates, domains, and frequency at once without documentation, it becomes difficult to isolate what is driving performance.

5. The problem is not primarily deliverabilitySome programs have normal placement but weak engagement because the offer, timing, creative, or audience fit is poor. A deliverability review can identify that possibility, but it cannot solve a messaging-strategy problem on its own.

Frequently Asked Questions

What data does a consultant need at the start?

A deliverability consultant usually needs read access to DNS records, ESP reporting, and postmaster tools, along with a recent sending timeline and basic acquisition-source context. That combination allows the consultant to evaluate authentication, reputation, bounce patterns, complaint sources, and operational changes without needing access to private inbox contents.

How long does a deliverability engagement timeline usually take?

A useful initial diagnosis often takes place within the first one to two weeks because access and audit work can begin quickly. Meaningful monitoring usually extends through the full first 90 days because Gmail, Outlook, and Yahoo often respond gradually, and not always at the same pace.

Can MailAdept fix everything without the client?

MailAdept usually cannot fix everything independently because the client often controls DNS, approvals, segmentation rules, compliance constraints, and business decisions about what can be paused or changed. The strongest deliverability outcomes usually come from shared ownership between MailAdept and the internal teams that control production systems.

What is included in a deliverability audit checklist?

A strong deliverability audit checklist covers six areas: infrastructure, authentication and DNS, reputation signals, sending patterns, list quality, and message construction. The order matters because later findings are easier to interpret after the sending map, trust signals, and provider-level reputation are already understood.

A clear process matters more than a promise. If you want a team that can review the same issues inside your own program, work with a deliverability team.