The Seven-Step Delivery Model

If you need a way to organize deliverability work, think of every email program as a cycle of seven steps, where each step feeds the next. Steps 1–2 and 6–7 are mainly the responsibility of the sender (the marketer). Steps 3–5 depend more on the sending platform.

The whole cycle rests on one golden rule: send interesting and valuable content to people who have agreed to receive it. This is the principle of wanted and expected mail described in Foundations of Email Deliverability.

        ┌─────────────────────────────────────────────┐
        ▼                                             │
1 Assemble → 2 Create → 3 Transmit → 4 Recipient → 5 Track
  the list     content     cleanly      issues       results
        ▲                                  │            │
        └────────── 6 Manage hygiene ◄─────┘   7 Fine-tune content ──► (2)

The value of the model is in its feedback loops. Recipient issues (4) must update the list (6, and then 1), and results (5) must update the content (7, and then 2). A program that runs steps 1–3 but never closes the loops builds up stale addresses and content nobody engages with, which is exactly the profile that mailbox providers score down.

Division of responsibility

The white paper's division of responsibility is still a useful way to structure conversations between a sender and its platform. The marketer controls these reputation inputs: complaints, hard bounces, spam-trap hits and content. The platform controls these: compliance with the RFCs and other technical standards, the mechanics of authentication, management of the sending rate, and processing of bounces and feedback loop (FBL) reports.

Neither side can make up for the other's failures. A platform is also not a list-cleaning service. It automates ongoing maintenance, but starting with a properly consented list is the sender's job.

Recipient-issues taxonomy (step 4)

Once a message is handed off, seven kinds of problem can occur. They are listed roughly from the greatest effect on reputation to the smallest:

When delivery gets worse, the first diagnostic habit is to work out which of these is happening: a transmission issue, a problem with the list or content, or accumulated reputation damage. The remedies are completely different. See Reputation Monitoring for the monitoring stack and the recovery workflow.

The noreply@ problem

The From address is part of the content (step 2), and also one of the places where recipient issues arise (step 4). Sending from noreply@, an address that nobody reads or that does not exist, tells subscribers "please don't talk to us", and it has concrete costs for the sender:

1. Mail from noreply@ is more likely to be ignored, deleted or marked as spam, because modern mail clients show the address and not only the display name.
2. Replies are customer feedback that gets lost, including attempts to unsubscribe by replying. A "remove me" reply that nobody reads often turns into a spam complaint.
3. Replies are a positive signal. When a recipient replies, the sender is often added automatically to their contacts or safe senders, which improves placement of all future mail for that user.
4. The effects observed are lower open rates and higher unsubscribe and complaint rates.

Two authorities support this. CAN-SPAM requires the From and Reply-To addresses and the routing information to be accurate and to identify the business that initiated the message (see CAN-SPAM). The M3AAWG Senders BCP says senders should be able to process unsubscribe requests sent to the From and Reply-To addresses. Use a real address that someone reads (hello@, news@, info@), and keep working abuse@ and postmaster@ mailboxes on the sending domain. The same BCP asks for those two mailboxes, and an MX record, on the domain that the sending server uses in its HELO and reverse DNS.

Aged claims in the source, corrected

The 2018 white paper predates several changes. Where its advice has aged, this is the current situation:

• Authentication: the white paper listed "SPF/Sender ID, DomainKeys and DKIM", with none of them dominant. Sender ID and DomainKeys have long been obsolete, and Version 4.0 of the M3AAWG Sender Best Common Practices (August 2026) formally deprecates both. The current baseline is SPF and DKIM with DMARC on top, and the major providers require authentication for bulk senders. See Gmail, Yahoo and Microsoft.
• Third-party accreditation and whitelisting (Goodmail, Habeas, Return Path certification): these programs are defunct or marginal, and providers now rely on their own reputation systems. Trust at the level of the recipient (contacts and safe-sender lists) still matters. The industry now calls lists of approved senders "allowlists".
• Spam scores based on keywords ("avoid words like free, casino"): modern filters look at the whole message and are driven by reputation. Lists of trigger words are largely a myth. See Content & Design for what actually matters in content.
• Open tracking: since Apple Mail Privacy Protection (2021), open counts are inflated and unreliable as a signal for individual recipients. See the limits of measurement described in Metrics & Benchmarks.

Related articles

• Foundations of Email Deliverability
• Two Worlds of Email Deliverability, the strategic frame for steps 5–7
• Consent Methods and the List-Quality Spectrum, on step 1
• Metrics and Benchmarks, the numbers behind steps 4–6
• What Mailbox Providers Measure, and Who on Your Team Owns Each Part, on how the sender's share of the responsibility divides across marketing, the DNS owner and the platform