Email deliverability policy is the set of rules your company follows to make legitimate messages easy to recognize, wanted by recipients, and technically safe for mailbox providers to accept. It is not a promise that every message reaches the inbox; it is the operating policy that reduces preventable spam placement, throttling, and rejection.

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

An email deliverability policy is an internal standard for everyone who collects addresses, writes campaigns, sends product notifications, configures DNS, and handles unsubscribes. It should state what mail you send, who may receive it, which domains and vendors may send it, how you authenticate it, which metrics trigger intervention, and who has authority to pause a campaign.

The policy’s job is to join technical controls and marketing behavior. SPF, DKIM, and DMARC help a recipient server evaluate whether mail is legitimately associated with your domain. But authentication alone does not make a message wanted. Mailbox providers also consider complaint signals, sending patterns, list quality, content, and their own reputation systems when deciding whether to accept, junk, or inbox mail. (datatracker.ietf.org)

Do not confuse this with an external privacy policy or a terms-of-service page. Those documents explain your practices to users. An email deliverability policy is an operational playbook: it tells your team exactly what to do before, during, and after sending.

A useful policy applies to at least four streams:

  • Marketing email: newsletters, promotions, lifecycle campaigns, webinar invites, and product announcements.
  • Transactional email: receipts, password resets, security notices, account confirmations, and delivery updates.
  • Operational email: incident alerts, administrator notifications, and internal workflow messages.
  • Sales or outreach email: messages sent by individual users or sales systems, which must not be exempted simply because they are lower volume.

In the United States, CAN-SPAM applies to commercial email generally, not just large campaigns or consumer marketing. It requires truthful routing information and subject lines, a valid postal address, a clear opt-out method, and honoring opt-outs within the statutory timeframe. Transactional or relationship messages are treated differently under the law, but that is not a reason to mix promotional content into them casually. (ftc.gov)

Why deliverability policy has become an operational requirement

Mailbox providers publish baseline sender requirements because unauthenticated and unwanted mail creates phishing, spam, and recipient harm. Gmail requires all senders to personal Gmail accounts to meet core requirements, including SPF or DKIM, valid forward and reverse DNS, TLS, RFC-compliant message formatting, and a spam rate below 0.3% in Postmaster Tools. Its higher-volume rules apply when a sender delivers 5,000 or more messages per day to personal Gmail accounts. (support.google.com)

For those Gmail bulk senders, SPF, DKIM, and DMARC are required; the visible From domain must align with the SPF or DKIM domain for direct mail; and marketing or subscribed messages need one-click unsubscribe plus a conspicuous body link. Google’s stated DMARC minimum may use p=none, but stronger enforcement should be adopted only after you understand every authorized sending source. (support.google.com)

Yahoo’s sender guidance likewise calls for authenticated mail, easy unsubscribe mechanisms, valid forward and reverse DNS, RFC-compliant messages, and spam rates below 0.3%. Yahoo says a functioning List-Unsubscribe header is needed for marketing and subscribed messages, recommends the RFC 8058 POST method, and says unsubscribes should be honored within two days. (senders.yahooinc.com)

Microsoft has also announced SPF, DKIM, and DMARC requirements for domains sending more than 5,000 messages per day to Outlook.com consumer mailboxes, with non-compliant mail initially routed to Junk under its announced enforcement approach. Requirements and enforcement behavior can change by provider, so an owner should review each provider’s current sender documentation during policy reviews rather than treating a one-time setup as permanent. (techcommunity.microsoft.com)

The practical takeaway is simple: deliverability is now a cross-functional control. Marketing cannot buy or import a list without affecting engineering’s domain reputation. Engineering cannot add a new email vendor without affecting legal compliance and unsubscribe handling. A policy assigns those responsibilities before an urgent launch turns them into an incident.

The six pillars of an email deliverability policy

A durable policy has six connected controls. Leaving out one produces a familiar failure mode: technically perfect mail that recipients never requested, a clean opt-in program sending from an unaligned domain, or a good campaign that keeps mailing people who opted out.

1. Permission and source documentation

The policy should define allowed acquisition sources. A strong default is: send marketing email only to people who actively requested it through a form, checkout flow, event registration, account setting, or another documented permission flow. Preserve the evidence: email address, collection timestamp, source URL or form name, consent language version, and relevant preference selections.

Do not buy lists, scrape addresses, or use a pre-checked marketing box as a substitute for meaningful permission. Yahoo specifically advises senders not to purchase lists and not to subscribe users through automatically checked opt-in boxes. (senders.yahooinc.com)

For product-led businesses, double opt-in is a sensible risk control for newsletters and high-risk acquisition sources. It is not universally mandated by mailbox providers, but it creates stronger proof that the address owner wanted mail and catches typos before they become hard bounces or complaints.

2. Clear purpose and stream separation

Define each stream by purpose and sender identity. For example, updates@example.com can send product newsletters, while notify@example.com sends receipts and security alerts. The recipient should be able to predict what each address means.

The policy should prohibit using a transactional trigger as a hidden promotional channel. A password-reset email with a small, relevant product footer is different from a reset email dominated by a sale. If the primary purpose becomes commercial, compliance and unsubscribe obligations may change; have counsel review borderline templates. (ftc.gov)

Separate streams also make diagnosis easier. If a promotional campaign produces complaints, you can pause that stream without interrupting password resets or invoices.

3. Authentication and sending infrastructure

Every domain and subdomain used in a visible From address should have a documented sending inventory: the owner, use case, sending vendor, return-path domain, DKIM selector, SPF mechanism, DMARC status, and volume profile. Do not let teams configure these records independently without a shared inventory.

SPF authorizes hosts to send using the envelope sender domain. DKIM attaches a domain-associated cryptographic signature to a message. DMARC lets the author-domain owner publish handling preferences for failed authentication and request reports; it also relies on alignment between the visible From domain and an authenticated identifier. (datatracker.ietf.org)

4. Recipient control and suppression

An unsubscribe must stop future marketing mail across every system that can send it. Your policy needs a centralized suppression list or a reliable real-time sync among the CRM, marketing platform, customer-data platform, and email API.

Under CAN-SPAM, a commercial email opt-out mechanism must be able to process requests for at least 30 days after the message is sent, and the sender has up to 10 business days to honor the request. Mailbox-provider expectations can be stricter operationally: Yahoo says to honor unsubscribes within two days. Use the shorter internal service level—immediate suppression where technically possible, and no later than two days—for promotional streams. (govinfo.gov)

5. List quality and volume discipline

Your policy should require removal or suppression of permanent failures and should define how to treat temporary failures. A hard bounce or SMTP 5xx response is not an invitation to retry forever. Yahoo advises list managers to remove addresses producing 5xx errors and not retry mail that returns a 5xx error. (senders.yahooinc.com)

Avoid sudden, unexplained volume spikes. A gradual ramp is not a magic formula, but it gives you time to observe complaint, bounce, and deferral signals before scaling. The most important rule is consistency: do not send a monthly list daily because the calendar changed, and do not reactivate long-inactive subscribers with your full normal cadence on day one.

6. Measurement, escalation, and accountability

Set a reporting cadence and name the people who can act. At minimum, a deliverability owner should review domain authentication, delivery errors, complaint indicators, bounce categories, unsubscribe rates, and campaign-level engagement before major sends.

Google Postmaster Tools provides data for outgoing mail to personal Gmail accounts, including spam rate, reputation, authentication, and delivery errors. It is valuable diagnostic data, but it is not a full inbox-placement measurement system and should be paired with your sending platform’s event data and SMTP response logs. (support.google.com)

The technical baseline: SPF, DKIM, DMARC, TLS, and DNS

Your policy should specify principles, not copy-and-paste vendor records. DNS values vary by email provider, and using an invented include domain or DKIM key will break authentication. The examples below show the shape of real records; replace the placeholders with values supplied by your sending provider.

SPF: authorize every legitimate envelope sender

Publish one SPF TXT record at the domain used for the envelope sender, commonly called the Return-Path or MAIL FROM domain. SPF uses mechanisms such as ip4, ip6, a, mx, and include to identify authorized senders. The SPF specification also limits SPF evaluation to ten DNS-query-causing mechanisms and modifiers, a constraint that commonly causes failures when companies stack too many vendors. (datatracker.ietf.org)

Example shape:

example.com.  TXT  "v=spf1 include:spf.email-provider.example ip4:198.51.100.25 -all"

Use -all only when the inventory is complete. If you are still discovering senders, a temporary soft-fail or neutral posture may be used during investigation, but it should not become a permanent excuse for unmanaged infrastructure. Most importantly, publish one SPF record per domain. Multiple independent v=spf1 records can create an SPF PermError.

DKIM: sign every stream with a controlled domain

DKIM signs mail with a private key and publishes the matching public key in DNS at selector._domainkey.example.com. The signature identifies both a signing domain (d=) and selector (s=). Use separate selectors for distinct providers or key rotations so you can retire a vendor without disrupting another sender. (datatracker.ietf.org)

Example shape:

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

The p= value must be the actual public key generated or supplied by your provider. Do not truncate it, add extra quotation marks in a DNS UI that already handles wrapping, or reuse an old selector after a vendor rotation without testing.

DMARC: start with visibility, then enforce deliberately

DMARC records live at _dmarc.example.com. The core policy choices are p=none, p=quarantine, and p=reject. A monitoring policy asks receivers to send reports without requesting enforcement; quarantine and reject request progressively stronger handling for mail that fails DMARC evaluation. DMARC permits reports so the domain owner can identify authorized and unauthorized sources. (datatracker.ietf.org)

A conservative monitoring record looks like this:

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

For a brand with a complete sending inventory and reviewed aggregate reports, a later enforcement record might look like this:

_dmarc.example.com. TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com; adkim=s; aspf=s; pct=100"

The policy should require an approval step before moving from p=none to p=quarantine or p=reject. Strict alignment (adkim=s and aspf=s) can be useful, but it can also break valid mail if a provider signs with or uses an unaligned domain. Review actual DMARC reports first.

TLS, PTR, and standards-compliant messages

Require TLS for SMTP connections where supported, plus valid forward and reverse DNS for sending IP addresses. Gmail and Yahoo list TLS and forward/reverse DNS among sender requirements or recommendations. Messages should also conform to Internet Message Format requirements, including properly structured headers. (support.google.com)

If your application sends through a managed email API, the provider may operate the IP-level PTR and TLS configuration. Your policy should still require the engineering owner to confirm that responsibility in writing and to configure the domain-level authentication records correctly. For implementation details, keep the sending service’s email API setup guides alongside the policy so configuration changes are reproducible.

Make unsubscribe genuinely easy

A footer link is necessary but not sufficient for modern bulk marketing mail. Use both a visible unsubscribe link in the message body and machine-readable unsubscribe headers. This makes opting out accessible in the email client and directly on your own preference page.

A typical header pattern is:

List-Unsubscribe: <https://email.example.com/unsubscribe/u/abc123>, <mailto:unsubscribe@example.com?subject=unsubscribe>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

RFC 8058 defines the POST-based signal for one-click List-Unsubscribe functionality. The endpoint should accept the relevant POST request without requiring the recipient to log in, solve a CAPTCHA, or navigate a multi-step confirmation journey. You can show a confirmation page after processing the request, but the action itself should not depend on that extra click. (datatracker.ietf.org)

Your policy should also specify these rules:

  1. The body link must be prominent, readable, and available in both HTML and plain-text parts.
  2. A global unsubscribe stops all non-essential marketing mail, even if a recipient remains subscribed to one preference category in an older system.
  3. Preference-center choices must update the same suppression source used by campaigns and automated journeys.
  4. Transactional email should not be blocked by a marketing unsubscribe when it is necessary to complete a requested service or secure an account.
  5. Unsubscribing must never require a password or more personal data than necessary to process the request.

List hygiene: the policy rules that prevent reputation damage

Most list-quality failures begin before sending: a form accepts malformed addresses, a lead import has no consent evidence, a campaign targets recipients who have been inactive for years, or a temporary error is retried until it becomes a provider complaint.

Require address validation at the point of collection. At a minimum, validate syntax and domain structure in the form, send a confirmation or verification email where appropriate, and capture delivery events after the first send. A verifier can help identify obviously invalid addresses before a campaign, but it cannot prove that a mailbox owner wants marketing email. Permission records remain essential.

Use segmentation based on evidence, not wishful thinking. Examples include recent purchasers, recently active subscribers, users who explicitly selected a topic, or recipients who opened a confirmation email. Do not treat historical imports and fresh opt-ins as equivalent audiences.

A reasonable internal lifecycle policy can include:

  • Immediately suppress: hard bounces, explicit unsubscribes, spam complaints received through available feedback channels, and addresses identified as invalid by your sending platform.
  • Pause and investigate: a sudden rise in soft bounces, deferrals, authentication failures, complaint signals, or a campaign that performs materially worse than similar sends.
  • Reconfirm before resuming: long-inactive marketing contacts, migrated lists with incomplete consent records, and contacts from an acquired business whose permission language is unclear.
  • Never mail without approval: purchased lists, scraped contacts, guessed corporate addresses, and lists provided by a partner without verifiable consent language and collection records.

Do not set one universal bounce-rate threshold and pretend it applies to every provider, industry, or mail stream. Instead, establish a baseline for each stream, watch changes by domain and campaign, and use SMTP codes plus authentication results to identify the cause. A password-reset stream and a promotional newsletter have different expected patterns.

A worked example: launching a product newsletter safely

Imagine ExampleCo wants to launch a weekly product newsletter from news@exampleco.com to 18,000 subscribers. The company already sends receipts from receipts@exampleco.com through a separate provider.

Step 1: define the stream

The deliverability owner records:

  • Purpose: weekly product education and occasional product announcements.
  • Visible From: ExampleCo News <news@exampleco.com>.
  • Sending platform: the approved marketing provider.
  • Audience: newsletter subscribers collected through the website form and account preference center.
  • Cadence: weekly, with separate consent for event reminders.
  • Owner: lifecycle marketing manager; technical approver: platform engineer.

The policy prohibits importing the sales team’s conference badge scans unless each contact’s consent covers newsletter marketing. If the event registration language only promised event logistics, that audience is not automatically eligible.

Step 2: configure domain authentication

ExampleCo asks the provider for its exact SPF include value, DKIM selectors, and custom return-path instructions. The DNS owner adds the supplied records, then sends a test message to Gmail, Yahoo, and Outlook test accounts.

In each received message, the team checks the raw headers for results resembling:

spf=pass
 dkim=pass header.d=exampleco.com
 dmarc=pass header.from=exampleco.com

Exact header formatting differs by mailbox provider. The success condition is not merely that a DNS lookup returns a record; it is that the received message shows passing authentication and DMARC alignment for the visible From domain.

ExampleCo begins DMARC monitoring with p=none and an aggregate-report mailbox. It reviews reports to ensure that the newsletter provider, receipt provider, support desk, and corporate mail service are all understood before considering p=quarantine or p=reject.

Step 3: implement opt-out correctly

The newsletter includes a clearly visible footer link to a preference center and the provider adds List-Unsubscribe headers. The team clicks the body link, tests the mail-client unsubscribe control where visible, and confirms that opting out removes the test address from both the next scheduled campaign and an automated nurture journey.

The service-level target is immediate suppression, with an operational maximum of two days for marketing mail. That is faster than the U.S. statutory maximum and aligns with Yahoo’s stated sender expectation. (senders.yahooinc.com)

Step 4: send in controlled segments

Rather than mailing all 18,000 subscribers with an untested template, ExampleCo starts with the most recently active, clearly opted-in segment. It watches delivery events, bounces, unsubscribe requests, and spam-related signals before sending to the remaining eligible audience.

If the campaign returns unexpected authentication failures, provider deferrals, or a complaint spike, the policy requires a pause. The team does not “fix” the issue by changing the From name every hour or switching to a random new domain. It identifies the stream, audience source, content, and technical change that preceded the problem.

Step 5: verify that it worked

The launch is considered successful only when all of the following are true:

  1. Test messages show SPF, DKIM, and DMARC passing with aligned identities.
  2. The unsubscribe header and footer link work, and suppression applies across marketing systems.
  3. Hard bounces are removed from future marketing sends.
  4. Gmail Postmaster Tools, if the domain has enough qualifying traffic, shows no authentication or delivery-error pattern requiring remediation.
  5. Campaign metrics remain within ExampleCo’s documented baseline, with no unexplained increase in complaints, bounces, or deferrals.

This is the core distinction between “we sent it” and “we operate a deliverable email program.”

Common email deliverability policy mistakes

Treating a DMARC record as a complete solution

Publishing _dmarc with p=none is an important visibility step, but it does not automatically improve content relevance, eliminate bad addresses, or create recipient permission. It also does not guarantee that every vendor is authorized. DMARC reports and message-header tests are what reveal gaps.

Adding multiple SPF records

Teams often add a separate SPF record for each vendor because each vendor’s onboarding screen says “add this TXT record.” SPF must be consolidated into one record for the domain. Merge authorized mechanisms carefully, then check the DNS lookup count and test the result. (datatracker.ietf.org)

Using a different From domain than the authenticated domain

A campaign may technically have SPF pass for a vendor-owned return-path while DKIM signs with a different domain, yet fail DMARC because neither aligns with the visible From address. Gmail’s bulk-sender requirements explicitly call for the From domain to align with the SPF or DKIM domain for direct mail. (support.google.com)

Confusing one-click unsubscribe with a preference center

A preference center is useful, but it is not the same as RFC 8058 one-click unsubscribe. The latter uses List-Unsubscribe headers and a POST signal so clients can offer an easy unsubscribe action. Keep the preference center, but also implement the headers for qualifying marketing mail. (datatracker.ietf.org)

Suppressing in only one tool

If the marketing platform honors an unsubscribe but the CRM sequence, billing tool, and customer-engagement platform do not, the recipient still receives unwanted mail. This is a governance failure, not just an integration bug. Centralize suppression or audit every sender against the same suppression event.

Measuring only opens and clicks

Open tracking is affected by mailbox-client behavior and privacy features, so it is a weak standalone measure of consent or inbox placement. Review delivery errors, authentication results, complaint data where available, hard and soft bounce trends, unsubscribes, and recipient behavior together.

A copy-and-adapt email deliverability policy template

Use this as a starting point, then have security, legal, engineering, and marketing adapt it to your systems and jurisdictions.

Purpose. We send email only for documented business purposes and in a manner designed to protect recipients, comply with applicable rules, and maintain reliable delivery.

Scope. This policy applies to all employees, contractors, applications, vendors, domains, subdomains, and IP addresses that send email on behalf of the company.

Permission. Marketing email may be sent only to recipients with documented permission or another lawful basis approved by legal. Purchased, scraped, guessed, or unverifiable lists are prohibited.

Sender identity. Every message must use an accurate From name, From address, and subject line. Each sending domain and vendor must be recorded in the approved sender inventory.

Authentication. Approved sending domains must use SPF and DKIM. Domains that require or benefit from DMARC must publish and monitor a DMARC record. Changes to authentication, From domains, return paths, DKIM selectors, or sending vendors require technical review and testing.

Marketing unsubscribe. Marketing and subscription email must include a prominent body unsubscribe link and, where applicable, List-Unsubscribe headers supporting one-click unsubscribe. Opt-out requests must be applied immediately where possible and no later than two days after receipt.

Suppression. Unsubscribes, hard bounces, and spam complaints must be suppressed across all non-essential marketing senders. Suppression records may not be overwritten by imports or vendor migrations.

List hygiene. Permanent delivery failures must be removed from future mailings. Re-engagement, legacy imports, and unclear-consent lists require documented approval before use.

Monitoring. The deliverability owner reviews authentication, delivery failures, bounces, complaints where available, unsubscribes, and sending-volume changes on a defined schedule and before major campaigns.

Incident response. The deliverability owner may pause any campaign that produces authentication failures, sustained delivery errors, abnormal complaints, or evidence of unauthorized sending. Root cause, remediation, and approval to resume must be documented.

Review. This policy and the approved-sender inventory are reviewed at least annually and whenever the company adds a sending vendor, acquires a list or business, changes domains, or experiences a deliverability incident.

How to audit your policy every quarter

A quarterly audit prevents DNS drift and forgotten systems from becoming reputation problems. Keep it short enough that it is actually completed.

  1. Export every domain, subdomain, application, mailbox, and vendor that can send as your company.
  2. Check whether each approved sender has the correct SPF authorization, DKIM signing, and DMARC alignment.
  3. Send live tests and inspect received headers at major mailbox providers.
  4. Confirm that marketing templates include functioning body unsubscribe links and appropriate List-Unsubscribe headers.
  5. Test a real unsubscribe and verify suppression in campaigns, automations, CRM sequences, and any secondary sending tools.
  6. Review hard-bounce suppression, deferred-mail patterns, provider error codes, complaints where available, and volume changes.
  7. Remove unused vendors, stale DNS authorizations, and old DKIM selectors only after confirming no legitimate mail depends on them.
  8. Record findings, owners, due dates, and the exact evidence that each fix was verified.

A policy is working when normal launches do not require frantic DNS changes, recipients can leave easily, new tools cannot send without review, and your team can explain every message source appearing in DMARC reports or delivery logs.

FAQ

What should an email deliverability policy include?

Include consent rules, approved sender inventory, stream definitions, SPF/DKIM/DMARC requirements, unsubscribe and suppression handling, bounce management, monitoring metrics, incident response, owners, and a review schedule.

Is DMARC required for all email senders?

Requirements depend on the recipient provider and volume. Gmail requires SPF or DKIM for all senders to personal Gmail accounts and SPF, DKIM, and DMARC for bulk senders; Gmail defines that bulk category as 5,000 or more messages per day to personal Gmail accounts. Yahoo and Microsoft also publish authentication expectations for significant or high-volume senders. (support.google.com)

What is the difference between email compliance and deliverability?

Compliance concerns legal and contractual obligations, such as truthful identification, opt-outs, and privacy rules. Deliverability concerns whether recipient systems accept and place your mail. They overlap: an ignored opt-out can create both legal risk and complaint-driven deliverability damage.

How fast should we honor an unsubscribe request?

For marketing email, make it immediate when technically possible. U.S. CAN-SPAM allows up to 10 business days, while Yahoo’s sender guidance says unsubscribes should be honored within two days. Building to the stricter operational standard reduces risk and recipient frustration. (govinfo.gov)

Does a low spam rate guarantee inbox placement?

No. A spam rate below Gmail’s stated 0.3% ceiling is an important requirement, but inbox placement also depends on authentication, sending reputation, list quality, message characteristics, and each provider’s filtering decisions. Treat deliverability as ongoing monitoring rather than a one-time certification. (support.google.com)