Deliverability is not a single inbox-placement trick; it is a change-controlled trust system whose technical, legal, data, and recipient signals must agree.
Step 1: Inventory senders, domains, and destination mix
Begin with an inventory, not a warm-up calendar. List every sending domain and subdomain, mailbox provider, envelope-from domain, visible From domain, DKIM signing domain, return path, sending platform, IP type, daily volume, recipient-domain mix, owner, and suppression source. A team cannot diagnose alignment or reputation when several systems send under the same identity without shared change control. Separate transactional and marketing traffic where architecture and policy require it, but do not use separation to evade reputation or recipient expectations.
| Asset | Record |
|---|---|
| Domain | Visible From, envelope From, and purpose |
| DKIM | Selector, signing domain, key owner |
| SPF | Authorized services and lookup design |
| DMARC | Policy, alignment, aggregate-report owner |
| Traffic | Provider, daily volume, and recipient mix |
| Controls | Unsubscribe, suppression, complaint, and incident owner |
Map thresholds by destination. Google's current guidance applies baseline requirements to all senders to personal Gmail accounts and additional requirements to senders of more than 5,000 messages per day to Gmail accounts. Microsoft's Outlook.com requirements target domains sending more than 5,000 emails per day to Outlook.com consumer services. Yahoo describes requirements and best practices for bulk senders. Volumes, scopes, and enforcement can change; recheck the official pages before each major launch.
Decision checkpoint
Before moving on, record the evidence used, the uncertainty that remains, the person who owns the decision, and the condition that would reverse it. This checkpoint turns guidance into an auditable operating choice. It also prevents a later result from being explained away by changing definitions after the fact.
Step 2: Configure SPF and prevent authorization drift
SPF, defined in RFC 7208, lets a domain publish which hosts are authorized to use that domain in the SMTP identity SPF evaluates. Build the record from a verified service inventory. Remove obsolete senders, avoid duplicated SPF records, monitor DNS lookup limits, and assign an owner for every include mechanism. SPF passing does not by itself prove that the visible From domain is aligned, and forwarding can affect evaluation. It is one part of an authenticated identity, not a reputation certificate.
- Confirm every legitimate sending service
- Publish one syntactically valid SPF record
- Review include chains and DNS lookups
- Remove services after decommissioning
- Test actual headers at target providers
- Document owner and rollback
Google requires all senders to personal Gmail accounts to use SPF or DKIM. High-volume senders must meet the additional authentication requirements described in its guidance. Microsoft expects SPF for applicable high-volume Outlook.com senders. Test real messages at the relevant destination providers and read authentication results rather than relying on a dashboard's green icon. A configuration is only complete when the team can connect the sending service to the evaluated domain and explain failures.
Decision checkpoint
Before moving on, record the evidence used, the uncertainty that remains, the person who owns the decision, and the condition that would reverse it. This checkpoint turns guidance into an auditable operating choice. It also prevents a later result from being explained away by changing definitions after the fact.
Step 3: Sign mail with DKIM and manage keys
DKIM, specified in RFC 6376, adds a cryptographic signature so a verifier can assess whether selected message content was signed by a domain and remained intact. Configure a signing domain relevant to the organizational identity, use provider-supported key lengths, protect private keys, rotate selectors through a documented process, and retain the old public key while in-flight messages may still be evaluated. Confirm that message transformations do not routinely break the signature.
| Check | Expected evidence |
|---|---|
| Signature | DKIM-Signature header present |
| DNS | Selector resolves to current public key |
| Result | Authentication-Results reports pass |
| Alignment | Signing domain aligns as required by DMARC |
| Operations | Rotation and rollback are documented |
DKIM success is measured in received headers, not in the sending platform's setup screen. Send samples through the same path, templates, tracking, and gateways used in production. Check the signing domain, selector, algorithm, body and header results, and any intermediary modifications. Google and applicable high-volume Outlook.com rules include DKIM expectations. Pair the result with alignment and recipient signals; a technically valid signature cannot make unwanted mail wanted.
Decision checkpoint
Before moving on, record the evidence used, the uncertainty that remains, the person who owns the decision, and the condition that would reverse it. This checkpoint turns guidance into an auditable operating choice. It also prevents a later result from being explained away by changing definitions after the fact.
Step 4: Publish DMARC, verify alignment, and read reports
DMARC, defined in RFC 7489, connects SPF and DKIM results to the domain visible in the From header through alignment and publishes a requested handling policy. Start from an inventory and reporting plan. A monitoring policy can reveal legitimate and unauthorized streams, but it is not the final objective. Resolve unknown senders, confirm aligned authentication, protect report data, and advance policy only when the organization understands the consequences.
| Phase | Action |
|---|---|
| Discover | Collect aggregate reports and inventory streams |
| Align | Repair SPF or DKIM alignment for legitimate mail |
| Control | Remove or isolate unauthorized senders |
| Enforce | Advance policy with monitored rollback |
| Maintain | Review new services, failures, and reports |
Scope matters. Gmail's additional requirements for senders above 5,000 messages per day include SPF, DKIM, DMARC, and alignment conditions; the baseline does not mean all senders must use DMARC. Microsoft's high-volume Outlook.com policy also calls for SPF, DKIM, and DMARC. Beginning May 5, 2025, Microsoft said noncompliant messages in that high-volume scope would be rejected with 550 5.7.515. Check current enforcement notices because platform policy can evolve.
Decision checkpoint
Before moving on, record the evidence used, the uncertainty that remains, the person who owns the decision, and the condition that would reverse it. This checkpoint turns guidance into an auditable operating choice. It also prevents a later result from being explained away by changing definitions after the fact.
Step 5: Configure unsubscribe and suppression
A recipient must be able to stop commercial email without friction. Gmail's bulk-sender requirements include one-click unsubscribe for applicable marketing and subscribed messages and require honoring unsubscribe requests within the stated timeframe. RFC 8058 defines a header-based one-click signaling mechanism; it is distinct from merely placing a mailto link in the body. Yahoo also emphasizes easy unsubscribe for bulk senders. Apply the exact current platform and legal requirements to the traffic in scope.
| Control | Requirement |
|---|---|
| Header | One-click mechanism where platform rules require it |
| Body | Clear recipient-facing unsubscribe route |
| State | Shared, authoritative suppression record |
| Timing | Honor platform and legal deadlines |
| Audit | Record request, propagation, and exceptions |
The U.S. FTC's CAN-SPAM guide requires accurate routing information, nondeceptive subjects, identification and postal-address elements, a clear opt-out method, and honoring opt-outs within the legal period. UK rules vary by recipient and context; the ICO explains B2B distinctions and data-protection obligations. Maintain one authoritative suppression state across tools. An unsubscribe in one platform must prevent another sequence, import, or agent from reactivating the address.
Step 6: Prepare the list and message
Deliverability cannot be separated from recipient selection. Verify address syntax and source, remove known hard bounces, respect objections, avoid purchased or unexplained data, and confirm that the professional role is relevant. Do not send to catch-all or uncertain addresses merely because a tool assigned a confidence score. Segment by a supportable business context and use honest sender identity, a nondeceptive subject, restrained formatting, and links that match the represented organization.
- Document source and business relevance
- Verify identity and current role
- Remove hard bounces, objections, and suppressions
- Use accurate From and Reply-To information
- Use a truthful subject and bounded claim
- Test links, redirects, and landing-page identity
Content filters are only one part of the problem. The larger risk is unwanted mail. A short plain message to the wrong person can generate complaints; a polished message with authentication can still be inappropriate. Avoid URL shorteners and unnecessary tracking complexity, test redirects, secure landing pages with HTTPS, and ensure that the domain shown to the recipient is consistent with the sender. Treat opens as noisy technical observations, not proof of engagement.
Step 7: Launch with controlled volume and monitoring
There is no universal warm-up schedule that guarantees inbox placement. Begin with a small, genuinely relevant stream that the organization can review and support. Increase volume only when authentication remains stable, hard bounces are controlled, complaints remain low, unsubscribes work, and recipient responses indicate relevance. Avoid sudden volume, infrastructure, audience, or content changes that make cause and effect impossible to isolate.
| Signal | Action |
|---|---|
| Authentication failure | Pause affected stream and repair identity |
| Hard bounce spike | Stop and audit list source |
| Complaint increase | Reduce volume and review relevance |
| Unsubscribe failure | Stop sending until suppression works |
| Provider-specific deferral | Inspect policy, reputation, and traffic change |
| Qualified reply | Measure separately from technical delivery |
Google tells senders to keep user-reported spam below 0.1% and avoid reaching 0.3% or higher; the 0.3% figure is not a target. Monitor Google Postmaster Tools where eligible, Microsoft signals, Yahoo feedback mechanisms, DMARC aggregate reports, bounces, deferrals, block responses, and internal suppression. Segment results by provider and sending stream. A blended delivery rate can hide a serious failure at one destination.
Step 8: Troubleshoot in dependency order
Troubleshooting begins with evidence from the receiving side. Capture the SMTP response, full headers, message ID, timestamp, destination provider, sending IP, envelope identity, visible From, DKIM domain and selector, authentication results, and recent changes. First determine whether the message was rejected, deferred, placed in spam, or accepted but unseen. These are different events. Then test identity and policy before copy.
Use dependency order: DNS reachability and syntax; SPF authorization; DKIM signature; DMARC alignment and policy; TLS and connection behavior; suppression and unsubscribe; list quality; complaint and reputation signals; content and links; volume changes. Change one material variable at a time and record the result. If only one provider is affected, compare its current official guidance with the failing headers and response. Do not rotate domains to escape an unresolved recipient-trust problem.
Step 9: Run monthly change control
Deliverability decays when ownership is unclear. Hold a monthly review of sending services, DNS records, selectors, DMARC reports, provider dashboards, bounce and complaint trends, unsubscribe propagation, suppression imports, destination mix, and planned volume changes. Require a review when a new vendor, domain, market, acquisition source, template system, tracking domain, or AI sending function is added. Record who approved the change and how it can be rolled back.
| Area | Evidence |
|---|---|
| Identity | SPF, DKIM, DMARC, and alignment results |
| Providers | Current Gmail, Outlook.com, and Yahoo guidance |
| Recipients | Bounce, complaint, unsubscribe, and relevance trends |
| Change | New service, domain, list source, or volume |
| Response | Owner, stop rule, incident record, and rollback |
The operating principle is conservative: authentication earns identity, not attention; delivery earns transport, not interest; an open or click records interaction, not buying intent. OKKI Go may be mentioned only within its verified workflow boundary: it supports reviewed outreach preparation and exposes sending status or failure information described by its official materials. The sender remains responsible for configuration, recipient appropriateness, requirements, monitoring, and corrective action.
Frequently asked questions
What is cold email deliverability?
It is the ability of an appropriate commercial message to be accepted and placed where the recipient can see it. It depends on authenticated identity, provider policy, reputation, list quality, recipient relevance, content, unsubscribe, suppression, and operational response.
Do all senders need SPF, DKIM, and DMARC?
Requirements depend on the destination and volume. Google requires SPF or DKIM for all senders to personal Gmail accounts and adds SPF, DKIM, DMARC, alignment, and other controls for senders above its bulk threshold. Check current official guidance for every provider.
What is Gmail's spam-rate threshold?
Google advises keeping user-reported spam below 0.1% and avoiding 0.3% or higher. The 0.3% level is a danger threshold, not an acceptable operating target, and current guidance should be rechecked before launch.
How should deliverability problems be diagnosed?
Classify the event, capture receiving-side evidence, verify authentication and alignment, inspect suppression, bounces and complaints, compare provider-specific policy, and only then test content or volume changes one variable at a time.