Email Deliverability Plan: A Practical Framework for Inbox Placement

An email deliverability plan is the operating system behind reliable email sending: it defines who you mail, what you send, how your domain is authenticated, which signals you monitor, and what you do when inbox placement declines. It is not a one-time DNS project or a prettier template; it is an ongoing process for earning recipient and mailbox-provider trust.

What an email deliverability plan is — and what it is not

Deliverability is the likelihood that a message reaches the inbox rather than the spam folder, another filtered location, or a block. It is different from delivery: a delivery event usually means the receiving server accepted the message, while inbox placement is a filtering outcome that an SMTP acceptance response alone cannot prove.

A useful plan treats deliverability as a system with four connected inputs:

1. Identity: Can receivers verify who is sending the message?
2. Permission and list quality: Did the recipient expect the message, and can you stop sending when they opt out or become unreachable?
3. Message relevance and behavior: Is the volume, frequency, content, and targeting consistent with what recipients signed up to receive?
4. Measurement and response: Can you see authentication failures, complaints, bounces, and provider-specific problems early enough to act?

Mailbox providers evaluate more than message copy. Google lists authentication, valid forward and reverse DNS, TLS, message formatting, and low spam rates among its sending requirements. Microsoft likewise identifies sending IP and domain reputation, authentication, list accuracy, complaints, and content as filtering factors. (support.google.com)

The goal is not to find a trick that bypasses spam filters. The durable goal is simpler: make each stream recognizable, technically valid, expected, useful, and easy to stop.

Start with an audit before changing DNS or sending volume

Do not begin by adding a DMARC record or launching a re-engagement campaign. First map every system that can send as your domain. An overlooked help desk, invoicing platform, CRM workflow, recruiting tool, or old agency account can cause authentication failures or confuse your reporting.

Build a sender inventory

Create a spreadsheet with one row per sending system and include:

This inventory answers a critical question: can every sender be authenticated and controlled? If the answer is no, do not move DMARC to an enforcement policy yet. DMARC reports are particularly useful here because they reveal services sending mail that claims to be from your domain. (dmarc.org)

Separate email by recipient expectation

At minimum, separate these categories in your sending logic and reporting:

• Transactional: Password resets, receipts, verification emails, security notices, and product actions initiated by the user.
• Lifecycle: Onboarding, trial education, renewal reminders, and behavior-triggered product education.
• Marketing: Newsletters, launches, promotions, webinars, and announcements.
• Operational support: Cases, responses, service notices, and account communications.

Do not use a marketing blast to repair a weak product-email reputation, and do not hide promotions inside password-reset or receipt streams. Separate streams make it easier to tune frequency, unsubscribe behavior, templates, routing, and incident response. They also reduce the chance that an aggressive campaign damages email recipients genuinely need.

Establish a baseline

For each stream, capture at least four weeks of available data before major changes: attempted sends, accepted deliveries, hard bounces, soft bounces or deferrals, unsubscribes, spam complaints, and conversions. Break the numbers down by mailbox domain where volume permits, such as Gmail, Yahoo, and Microsoft-hosted domains.

Do not rely on a single overall delivery percentage. A high acceptance rate can coexist with poor inbox placement, and aggregate numbers can conceal a serious decline at the provider where most of your customers receive mail. Gmail Postmaster Tools exposes domain-level views of spam rate, reputation, authentication, and delivery errors for qualifying traffic. (support.google.com)

Build the technical foundation: SPF, DKIM, DMARC, DNS, and TLS

Authentication proves that a sending system is authorized to use your domain and that the visible sender identity aligns with that authorization. It does not guarantee inbox placement, but missing or broken authentication is an avoidable obstacle.

Google requires all senders to personal Gmail accounts to use SPF or DKIM, and requires senders above its stated bulk threshold of more than 5,000 messages per day to Gmail accounts to use SPF, DKIM, and DMARC. Yahoo’s bulk-sender requirements similarly call for SPF, DKIM, a valid DMARC policy, and alignment between the From domain and SPF or DKIM. (support.google.com)

SPF: authorize the envelope sender

SPF is a DNS-based authorization check for the SMTP MAIL FROM identity or, in some cases, the sending host identity. In plain language, it tells receivers which mail servers may send using a domain in the envelope sender. (datatracker.ietf.org)

A simplified illustrative record looks like this:

example.com.  TXT  "v=spf1 ip4:192.0.2.10 include:spf.vendor.example -all"

Do not copy that record literally. 192.0.2.10 and spf.vendor.example are documentation placeholders. Your sending provider will publish the exact include mechanism or IP range it requires.

Important SPF rules:

• Publish one SPF TXT record for each domain. Multiple SPF records can create a permanent error.
• Include every authorized sender for that envelope domain, including a product-email provider or transactional relay.
• Use -all only after you are certain your inventory is complete. It indicates mail from other sources should fail SPF.
• Count DNS lookups caused by include, a, mx, exists, redirect, and related mechanisms. SPF evaluation has a limit of 10 DNS lookups; exceeding it can produce a permerror. (datatracker.ietf.org)

SPF alone is fragile for forwarded mail and does not necessarily align with the address recipients see in the From field. That is why a mature plan uses it alongside DKIM and DMARC.

DKIM: sign the mail your platform sends

DKIM adds a cryptographic signature to selected message headers and body content. The public key is published in DNS; receivers use it to validate that the signed content has not been altered and that the signing domain authorized the signature. DKIM is an Internet Standard specified in RFC 6376. (datatracker.ietf.org)

A DKIM DNS record has this general shape:

s1._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=BASE64_PUBLIC_KEY_FROM_YOUR_PROVIDER"

Use the selector and public key supplied by each platform. Many ESPs provide CNAME records rather than a raw TXT key, while others provide a TXT record; follow the provider’s exact setup instructions. Rotate selectors when your provider supports it, and keep old selectors published until mail signed with them has aged out of recipient systems.

Test DKIM by sending to a mailbox you control and inspecting the full headers. Look for a DKIM-Signature header and an authentication result showing dkim=pass. A signature can exist but still fail if a gateway modifies a signed part of the message after signing, such as by appending a footer.

DMARC: connect authentication to the visible From domain

DMARC lets a domain owner publish a policy for mail that fails authentication and alignment, while also requesting aggregate reports. Its practical value is that it evaluates whether SPF or DKIM passes and aligns with the domain recipients see in the From field. (dmarc.org)

Start with a monitoring record:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r"

Here is what the important tags mean:

• v=DMARC1 identifies the record.
• p=none asks receivers to monitor rather than quarantine or reject failed mail.
• rua=mailto: requests aggregate reports. Use an inbox or reporting service that can accept and parse XML attachments.
• adkim=r and aspf=r use relaxed alignment. A subdomain can align with its organizational domain, which is often appropriate during initial deployment.

After you have examined reports and verified every legitimate sender, you can consider p=quarantine and then p=reject. Do not treat enforcement as a checkbox. Moving too fast can block legitimate password resets, invoices, support replies, or messages from a SaaS platform your team forgot to inventory.

DNS, PTR, and encrypted transport

If you operate your own mail transfer infrastructure or use dedicated IPs, make sure the sending IP has valid forward and reverse DNS. Google and Yahoo explicitly require valid forward and reverse DNS records, while Microsoft notes that it may not accept mail from senders that fail reverse-DNS lookup. Use TLS for SMTP transmission as required by Google’s sender guidelines. (support.google.com)

For most teams using a reputable ESP, the provider handles IP-level TLS and reverse DNS. Your responsibility is to authenticate your own domain correctly, use the provider’s approved custom return-path or tracking-domain setup where applicable, and avoid sending bulk campaigns from a personal mailbox or a general-purpose corporate SMTP account.

Make consent and list hygiene operational, not aspirational

The fastest way to undermine a well-authenticated domain is to mail people who did not ask for the email, no longer recognize the sender, or cannot easily leave. Permission quality affects complaints, engagement, bounces, and long-term reputation.

Define acceptable acquisition sources

For every contact source, record the action that created consent, the date, the form or product surface, the language shown at signup, and the email category promised. This makes it possible to distinguish a product user who agreed to account communications from a newsletter subscriber who opted in to promotional email.

A conservative policy should prohibit purchased, scraped, harvested, or appended lists. It should also prohibit silently adding a person to ongoing marketing merely because they downloaded a document, attended a meeting, exchanged business cards, or received a sales email. These sources tend to generate low recognition and higher complaint risk.

Where appropriate for your audience and jurisdiction, use confirmed opt-in: after a person submits a form, send a confirmation link before enabling promotional mail. It adds friction, but it produces a cleaner evidence trail and confirms that the address can receive email.

Process bounces, complaints, and unsubscribes immediately

Your ESP should automatically suppress hard bounces and known complaints. In addition, maintain a centralized suppression list that every marketing sender checks before sending. Suppression should win over a newly imported list, a CRM sync, or an enthusiastic sales request.

For US commercial email, the FTC says messages must use accurate header information and non-deceptive subject lines, include a valid physical postal address, and provide a clear, conspicuous way to opt out. The FTC also states that recipients must be able to stop all marketing messages, even if you offer category-level preferences. (ftc.gov)

Treat the legal deadline as a maximum, not an operational target. Yahoo says bulk senders should honor unsubscribes within two days; in a well-designed system, the unsubscribe event should reach suppression tables nearly immediately. (senders.yahooinc.com)

Use an engagement policy rather than endless re-sends

Set a documented inactivity rule. For example, define an audience segment that has not opened, clicked, logged in, purchased, or otherwise meaningfully engaged during a period appropriate to your product’s buying cycle. Do not assume one universal number works for every business: weekly retail mail and annual B2B software renewals have different natural cadences.

When a subscriber reaches the inactivity threshold, remove them from routine promotional sends. You may run a limited, clearly labeled re-permission sequence, but stop mailing people who do not reconfirm interest. Continuing to send to an unresponsive audience can make your campaign-level engagement look acceptable while weakening provider trust over time.

Before an import, remove obvious syntax errors, duplicates, role addresses where they are not relevant to your use case, previously unsubscribed contacts, and addresses previously marked as hard bounces. An email-verification service can be a useful pre-send control, but it is not proof of consent or a substitute for an opt-in record; use a free address verification tool as one layer in the process, not as permission to mail a cold list.

Design messages people recognize and want to receive

Content does not operate independently from reputation. The same template can perform differently depending on sender recognition, list quality, recipient behavior, and frequency. Focus on reducing surprise and giving recipients a clear choice.

Make identity obvious

Use a stable From name and address that match the brand or product recipients signed up for. If your marketing program is Northstar Weekly, do not suddenly send from a founder’s unfamiliar personal name with a different reply-to address. Keep your visible From domain aligned with your DKIM or SPF identity so DMARC can pass.

Write subject lines that accurately describe the content. Do not use fake replies, misleading urgency, or “Re:” and “Fwd:” prefixes when the message is not part of a real conversation. Accurate headers and non-deceptive subject lines are also part of CAN-SPAM compliance. (ftc.gov)

Give marketing mail a real unsubscribe path

Every promotional email needs a prominent body unsubscribe link and a functioning preference center if you offer categories or frequency controls. A preference center can save a subscriber who wants product updates but not weekly promotions, but it must never make full opt-out difficult to find.

For bulk or subscribed marketing email, implement header-based one-click unsubscribe in addition to the footer link. RFC 8058 defines the mechanism, and Yahoo recommends the POST method. The RFC requires the List-Unsubscribe-Post field to contain List-Unsubscribe=One-Click and requires a valid DKIM signature covering the relevant unsubscribe headers. (rfc-editor.org)

A typical implementation looks like this:

List-Unsubscribe: <https://email.example.com/unsubscribe/9f8a7b6c>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

The URL should accept the RFC 8058 one-click POST request and unsubscribe the recipient without asking them to log in, fill out a survey, or confirm through another email. Use an opaque, recipient-specific token rather than exposing an email address in the URL. Test that the headers survive your sending provider and that the unsubscribe event updates your central suppression list.

Control frequency and campaign overlap

Set a frequency policy by segment. A new subscriber may receive an onboarding sequence, a trial user may receive product education, and a customer may receive occasional release notes. The important principle is that contacts should not receive every campaign simply because they exist in the database.

Use a campaign calendar that shows all scheduled sends across teams. Exclude people already in a high-frequency lifecycle sequence from broad promotions when appropriate, cap messages per recipient over a defined period, and give internal teams one shared view of planned sends. These controls prevent the classic deliverability failure where three legitimate teams each mail once, but the recipient experiences a barrage.

Use a cautious ramp-up plan for new domains, subdomains, and IPs

A new sending identity has little or no reputation. Microsoft notes that new IP addresses have no established reputation and can experience delivery issues; its guidance says ramp-up may take a couple of weeks or less depending on volume, list accuracy, and junk-mail complaints. (learn.microsoft.com)

There is no universal daily-volume schedule because the appropriate pace depends on audience size, recipient engagement, provider mix, shared versus dedicated IPs, and your historical domain reputation. Avoid generic charts that promise a fixed number of messages on each day.

A safer ramp-up sequence

1. Authenticate first. Confirm SPF, DKIM, DMARC monitoring, TLS, and visible From-domain alignment before sending meaningful volume.
2. Start with the most engaged recipients. Use customers and subscribers with recent, positive interactions rather than old or imported contacts.
3. Increase gradually only when signals stay healthy. Expand volume in measured steps; do not double volume just because a calendar says it is time.
4. Keep content and cadence consistent. Do not combine a new sender identity with an unfamiliar template, a sudden promotional push, and a cold audience.
5. Pause on adverse signals. If complaints rise, deferrals increase, authentication fails, or a mailbox provider’s reputation falls, hold volume steady or reduce it while investigating.

A separate marketing subdomain such as news.example.com can make stream management clearer, but it does not erase the reputation or trust implications of the parent brand. Use it when you can consistently maintain the identity, authentication, list policy, and content strategy—not as a way to evade the consequences of poor sending.

Monitor the right signals every day, week, and month

Monitoring turns deliverability from an after-the-fact mystery into a managed process. Your dashboard should show operational health by stream and by mailbox provider, not only total sends.

Daily checks

Review the following after significant sends:

• SPF, DKIM, and DMARC pass rates.
• Hard bounces, soft bounces, deferrals, and SMTP rejection codes.
• Spam complaints and unsubscribe events.
• Send volume changes by domain and campaign.
• One-click unsubscribe and footer-unsubscribe processing failures.

Google says to keep spam rates in Postmaster Tools below 0.3%. Yahoo also specifies a spam complaint rate below 0.3%. Treat that number as a ceiling, not a target: the practical response to a rising complaint trend should begin before you approach a provider’s stated limit. (support.google.com)

Weekly checks

Once a week, compare each major mailbox provider and stream. Look for changes in accepted delivery, bounces, deferrals, complaints, and unsubscribes. Review the top campaigns by complaints and the acquisition sources behind the contacts who complained.

For Gmail traffic, use Postmaster Tools to review spam rate, domain and IP reputation, authentication, and delivery errors. For Yahoo traffic, monitor feedback-loop data if available to your sending setup and review Sender Hub guidance and SMTP error codes when messages defer or reject. (support.google.com)

Monthly checks

Monthly governance should include a sender-inventory review, DMARC-report review, suppression-list audit, provider-configuration review, and a campaign-frequency review. Confirm that departed employees, retired tools, and old domains cannot still send as your brand.

Also review whether your reporting produces a false sense of success. A campaign that drives short-term clicks but causes elevated complaints, opt-outs, or long-term inactivity may be expensive reputation debt rather than a win.

A 30-day email deliverability plan you can actually run

The following plan is intentionally vendor-neutral. The precise screens differ across ESPs and email APIs, but the work products remain the same.

Days 1–5: Discover and stabilize

• Complete the sender inventory.
• Freeze questionable imports and pause any campaign aimed at unverified or stale contacts.
• Identify the owner of DNS, the ESP account, product-email code, CRM, and suppression list.
• Export current delivery, bounce, complaint, unsubscribe, and conversion data by stream.
• Send seed messages to controlled inboxes at Gmail, Yahoo, and Microsoft-hosted addresses; inspect headers rather than judging results only from where one test email lands.

Days 6–10: Authenticate and verify

• Publish or correct SPF for every envelope-sender domain.
• Enable DKIM for every sender and verify dkim=pass in received-message headers.
• Publish DMARC with p=none and an rua destination you will actually review.
• Confirm From-domain alignment with either SPF or DKIM.
• Verify TLS, forward DNS, and reverse DNS where you control sending infrastructure or dedicated IPs.

Days 11–15: Fix recipient controls

• Create a single global suppression process for unsubscribes, hard bounces, and complaints.
• Add visible footer unsubscribes to marketing templates.
• Implement and test List-Unsubscribe plus List-Unsubscribe-Post for qualifying promotional streams.
• Add the required sender identity details, including a valid postal address for US commercial messages.
• Document acquisition sources and remove contacts that lack a defensible permission record.

Days 16–23: Improve targeting and ramp safely

• Segment engaged contacts from inactive contacts.
• Establish campaign-frequency caps and exclusions for overlapping journeys.
• Start or restart promotional sending with recent, engaged recipients.
• Monitor provider-level results after each meaningful increase in volume.
• Hold or reduce sends when signals worsen; do not send a large “win-back” blast to solve an engagement problem.

Days 24–30: Operationalize

• Build a weekly deliverability dashboard.
• Set alert thresholds for authentication failure, bounce spikes, complaint spikes, and abnormal volume increases.
• Assign one accountable owner for each sender, DNS record, and response playbook.
• Review DMARC aggregate reports for unknown senders before considering a stricter policy.
• Schedule a recurring monthly deliverability review with marketing, engineering, support, and operations.

If your sending platform exposes an email API and event webhooks, connect delivery, bounce, complaint, and unsubscribe events to your customer-data and suppression workflows. Use the platform’s email API setup guides to implement event handling before scaling automated email; a beautiful campaign cannot compensate for a suppression list that updates too late.

Worked example: repairing a SaaS newsletter program

Assume a SaaS company, Acme Metrics, has 20,000 contacts in its marketing database. It sends a weekly product newsletter from hello@acmemetrics.com, product notifications from notifications@acmemetrics.com, and receipts through a billing tool. The marketing team sees a strong server-accepted delivery rate, but support tickets say Gmail users cannot find newsletters.

Step 1: Find the actual sender identities

The audit reveals three systems:

• The newsletter ESP sends with a custom From address but has DKIM disabled.
• The product-email provider signs with its own domain, not acmemetrics.com.
• The billing platform has been sending from the company domain without appearing in the SPF record.

The company publishes a DMARC monitoring record, enables the ESP’s custom DKIM domain, configures the product provider to sign with mail.acmemetrics.com, and adds the billing platform’s approved SPF mechanism. It then sends tests to controlled inboxes and verifies a passing aligned DKIM result for each system.

Step 2: Stop treating all 20,000 contacts as one audience

The company splits the list into three segments:

• Recently engaged: Users with a recent product login, click, or purchase-related interaction.
• Active customers but email-inactive: Customers who use the product but have not interacted with marketing mail.
• Dormant prospects: Contacts without a recent product or email interaction.

For the next few newsletter sends, Acme mails the recently engaged segment first. Active customers receive a less frequent, product-focused digest. Dormant prospects are excluded from regular newsletters and receive one limited re-permission campaign with a direct choice to stay subscribed or unsubscribe.

Step 3: Correct unsubscribe behavior

The old footer link sends recipients to an account-login page, which is inappropriate for trial users and prospects. Acme replaces it with a tokenized direct-unsubscribe endpoint, adds the RFC 8058 headers, and tests both the header action and footer action against the suppression database.

The newsletter now includes:

List-Unsubscribe: <https://email.acmemetrics.com/unsubscribe/recipient-token>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

The endpoint accepts the one-click POST and immediately suppresses future marketing email. Product-security and receipt streams remain operationally separate and are not used to send newsletter promotions.

Step 4: Decide whether it worked

Acme does not declare victory because one test message lands in one inbox. It watches four things over multiple sends: Gmail Postmaster authentication and reputation data, complaint trends, deferral or rejection patterns, and the relative performance of the engaged segment versus the old all-contacts blast.

Success looks like consistent authentication passes, no unknown sources in DMARC reports, low and stable complaints, normal unsubscribe processing, and fewer provider-specific delivery errors. It also looks like fewer messages sent to recipients with no demonstrated interest—not merely more messages accepted by receiving servers.

What commonly goes wrong — and how to fix it

“We set up DMARC, but mail still goes to spam”

DMARC is authentication and policy, not an inbox-placement guarantee. Check complaint trends, audience source, campaign frequency, domain alignment, message relevance, and provider-specific delivery errors. Gmail and Microsoft both make clear that reputation and recipient response matter in addition to authentication. (support.google.com)

“Our ESP says the domain is verified”

Vendor verification may not mean DKIM is enabled, SPF aligns, DMARC passes, or every other platform is authenticated. Verify actual received-message headers for each sending system and examine DMARC aggregate reports.

“We need to warm up by emailing our entire database”

That approach sends your least-engaged recipients a large, unexpected campaign at the moment your identity has the least established reputation. Begin with people likely to recognize and value the mail, then expand based on observed results.

“We have a preference center, so one-click unsubscribe is unnecessary”

A preference center and one-click unsubscribe solve different problems. The preference center allows recipients to tune categories; one-click unsubscribe lets mailbox interfaces offer a fast stop mechanism. For relevant bulk marketing mail, implement both.

“Our bounce rate is low, so the list is healthy”

A low bounce rate says relatively little about consent or interest. A contact can have a valid mailbox, receive every message, and still mark your mail as spam because they never requested it or no longer recognize the sender.

How to tell your email deliverability plan is working

A healthy program has evidence at three levels.

Technical evidence: SPF and DKIM pass for authorized senders, DMARC alignment passes, DMARC reports do not show unexplained systems, and unsubscribe headers work as intended.

Provider evidence: Major mailbox providers show stable or improving reputation and do not produce unusual deferrals, blocks, or spam-rate warnings. Google’s Postmaster Tools is particularly valuable for monitoring Gmail-specific spam rate, reputation, authentication, and delivery errors. (support.google.com)

Recipient evidence: Complaint and unsubscribe patterns remain controlled, engaged segments continue to interact or convert, and you are deliberately sending less mail to dormant recipients. This is the strongest sign that the program is aligned with what people expect.

FAQ

What is the first step in an email deliverability plan?

Inventory every platform that sends mail as your domain. You cannot safely authenticate or enforce DMARC until you know which systems send product, marketing, support, billing, and internal messages.

Does DMARC improve email deliverability?

DMARC helps receivers validate the relationship between your visible From domain and SPF or DKIM authentication. It reduces spoofing risk and satisfies requirements for many bulk-sender programs, but it does not override complaint rates, poor list quality, irrelevant content, or sudden volume spikes. (support.google.com)

What spam complaint rate should we aim for?

Google and Yahoo state that senders should keep spam rates below 0.3%. Treat that as a maximum boundary rather than a goal; investigate a sustained rise well before that level. (support.google.com)

Should transactional and marketing email use different domains?

They should at least be logically separated in sending systems, templates, reporting, suppression rules, and campaign governance. Separate subdomains can help make those distinctions operationally clear, but they do not replace authentication, recipient consent, or responsible sending behavior.

How long does it take to improve deliverability?

Authentication errors and unsubscribe defects can be fixed quickly, while reputation recovery depends on future sending behavior and recipient response. New IP reputation may ramp over a period influenced by volume, list accuracy, and complaint rates; Microsoft describes this as potentially a couple of weeks or less for a new IP, but there is no universal recovery timetable. (learn.microsoft.com)