Cold email deliverability: getting to the inbox
Deliverability is whether your email reaches the inbox rather than spam or nowhere. It comes down to three things: proving the email is really from you, earning a good reputation, and not giving recipients a reason to complain. Here is each one, with the rules the big mailbox providers publish.
Updated 8 November 2026 · 15 min read
How the inbox decision is made
When your email arrives, the receiving provider asks roughly three questions. Is it really from who it says (authentication)? Has mail from this domain, IP and mailbox been wanted before (reputation)? Does this particular message look like something the recipient wants (content and engagement)? None of the providers publish their filters, but Google, Yahoo and Microsoft do publish requirements, and missing them is the most common reason good emails go to spam or get rejected.
Two terms matter here. Delivery means the receiving server accepted the email. Inbox placement means it was put in the inbox rather than spam. A 0% bounce rate tells you nothing about the second.
Authentication: SPF, DKIM and DMARC
SPF
SPF is a DNS TXT record listing the servers allowed to send mail for your domain. Receivers check the server that delivered the message against it. Keep the record short: RFC 7208 limits SPF evaluation to 10 DNS-querying terms (such as include, a and mx), and going over makes SPF fail with a permanent error (RFC 7208). Each sending service you add usually adds an include, so remove the ones you no longer use.
DKIM
DKIM adds a cryptographic signature to each message, with the public key published in your DNS. It proves the message wasn’t changed and that a domain took responsibility for it. Your mailbox provider (Google Workspace, Microsoft 365 and so on) gives you the record to publish. Gmail requires keys of at least 1024 bits and recommends 2048 where your provider supports it (Google).
DMARC
DMARC ties the two to the address people see. A message passes DMARC when SPF or DKIM passes and the domain that passed matches the From: domain (alignment). Your DMARC record also tells receivers what to do with mail that fails (p=none, quarantine or reject) and where to send reports. Start at p=none with a reporting address, read the reports, fix anything legitimate that fails, then move towards enforcement.
DMARC was first published as RFC 7489 in 2015. In May 2026 the IETF published it as a Proposed Standard in RFC 9989, with aggregate and failure reporting moved to RFC 9990 and RFC 9991, which obsolete RFC 7489 (RFC Editor). Existing DMARC records keep working; the providers’ requirements below still describe the same basic record.
Inboxed’s domain checker looks these records up live and explains fixes in plain language. Inside the app, Inboxed can also collect your DMARC aggregate reports at a dedicated address and alert you when failures spike.
What Gmail, Yahoo and Microsoft require
Gmail
- All senders: SPF or DKIM; valid forward and reverse DNS (PTR) for sending IPs; TLS; messages formatted to RFC 5322; spam rate in Postmaster Tools below 0.3%.
- More than 5,000 messages a day to Gmail accounts: SPF and DKIM and DMARC (policy can be
none), with the From: domain aligned to SPF or DKIM; one-click unsubscribe and a visible unsubscribe link for marketing and subscribed messages; spam rate below 0.3%. - Google recommends keeping the spam rate below 0.1% and avoiding ever reaching 0.3% (Google). Its FAQ adds that senders who cross the 5,000 threshold once are permanently treated as bulk senders, that unsubscribe requests should be honoured within 48 hours, and that Gmail began ramping up enforcement on non-compliant traffic in November 2025 (Google FAQ).
Yahoo
- All senders: SPF or DKIM; complaint rate below 0.3%; valid forward and reverse DNS; RFC 5321 and 5322 compliance.
- Bulk senders: SPF and DKIM, a DMARC policy of at least
p=nonethat passes with alignment, a one-click List-Unsubscribe header (Yahoo highly recommends the RFC 8058 POST method), a visible unsubscribe link, and unsubscribes honoured within 2 days (Yahoo).
Outlook.com
- Domains sending more than 5,000 emails a day to Outlook.com, Hotmail.com and Live.com addresses must pass SPF and DKIM and publish DMARC of at least
p=none, aligned with SPF or DKIM. Since 5 May 2025 non-compliant mail is rejected with error550 5.7.515(Microsoft). - Microsoft also recommends a valid From or Reply-To address that can receive replies, a visible way to opt out, and removing invalid addresses regularly.
Cold email teams rarely send 5,000 emails a day to one provider from one domain, but meeting the bulk rules anyway costs little and removes a whole class of problems.
Reputation: domain, IP and mailbox
Sender reputation is the providers’ memory of how recipients treated your mail. It attaches to your domain, to the IP addresses that send it and, at the big providers, to the individual mailbox. When you send through Google Workspace or Microsoft 365, the IPs are shared and well managed, so your domain and mailbox reputation matter most.
Reputation is built by people opening, replying to and not reporting your email, and lost through bounces, spam traps, complaints and sudden jumps in volume. A domain can also be listed on a blocklist such as the Spamhaus Domain Blocklist, which lists domains with poor reputation (Spamhaus).
Inboxed checks each sending domain against Spamhaus DBL, SURBL and URIBL every 6 hours. If a domain is listed, every mailbox on it is paused, with the reason shown, so you don’t make it worse while you investigate.
Warmup and ramp-up
New domains and mailboxes have no reputation. Warmup gives them a history by exchanging ordinary emails with other mailboxes that open, reply and move them out of spam. It is not a way around the rules: a warmed-up mailbox sending to a bad list still ends up in spam. Treat it as the first few weeks of a gradual ramp.
In Inboxed, warmup is free for every connected mailbox. It starts at 2 emails a day and adds 2 a day up to 40 (you can change the ramp), keeps running at a lower volume while you send, and never shows up in your team inbox. Each mailbox gets a health score from 0 to 100: the share of its warmup emails that landed in the inbox over the last 14 days.
List quality: bounces and spam traps
A hard bounce means the address doesn’t exist. Sending to many of them signals that you didn’t get the addresses from the people themselves. Verify before every campaign, and re-verify old lists. Catch-all domains accept every address at the SMTP stage, so verification can’t confirm the mailbox; send to them cautiously.
Spam traps are addresses run by providers and blocklist operators to catch senders who don’t collect addresses properly; M3AAWG publishes best practices for how they are built and operated (M3AAWG). There is no reliable way to spot a trap in a list, which is why sourcing matters more than cleaning.
Inboxed reads bounce reports in your mailbox, marks the lead as bounced and stops their sequence. If more than 5% of a mailbox’s recent emails hard-bounce (once it has sent at least 20), the mailbox pauses itself; a campaign pauses above 8% (after at least 50). You get an alert when a workspace’s bounce rate jumps.
Complaints
A spam complaint is a recipient pressing “Report spam”. It is the strongest negative signal you can send, and the thresholds are low: Google and Yahoo both use 0.3% as a limit, and Google recommends staying under 0.1%. In practice, complaints fall when the list is relevant, the email is honest about who you are, and leaving is easier than complaining.
That is the point of one-click unsubscribe. RFC 8058 defines two headers, List-Unsubscribe with an HTTPS address and List-Unsubscribe-Post: List-Unsubscribe=One-Click, that let the mail app show an Unsubscribe button; both headers need to be covered by a valid DKIM signature for receivers to offer it (RFC 8058). Inboxed adds both headers and a visible unsubscribe line to every campaign email. A click unsubscribes the person from everything your workspace sends, and they can undo it themselves within 24 hours.
Providers share complaints with senders through feedback loops. Inboxed adds a Feedback-ID header to campaign emails that identifies the campaign and workspace, and spam reports filed through its report abuse page put the address on your suppression list. Feedback loops are described in RFC 6449 (IETF); Yahoo’s Complaint Feedback Loop is something you sign up for with your DKIM domain (Yahoo).
Content and formatting
- Plain text, or HTML that looks like plain text. No large images, no image-only emails, no attachments in the first email.
- One link at most, to your own domain. Link shorteners and links to domains with poor reputation hurt.
- Subject lines that describe the email honestly. Deceptive subjects are illegal under CAN-SPAM as well as bad for complaints.
- Avoid tracking you don’t need. Open tracking adds an image and click tracking rewrites links; if you use them, use a custom tracking domain.
- Vary wording across a large campaign so emails aren’t identical, for example with spintax, but never to disguise what the email is.
Inboxed runs a content scan before launch and on every email as it’s sent, and blocks known spam patterns. You can check a draft with the free spam word checker.
Volume and pacing
Sudden volume is suspicious. Raise daily volume per mailbox slowly, send during business hours, put gaps between emails, and spread a campaign over several mailboxes (inbox rotation) instead of pushing one. Inboxed defaults to 30 emails a day per new mailbox and a random 60 to 180 second gap between a mailbox’s sends, and can prefer a sending mailbox on the same provider as the recipient (Google to Google, Microsoft to Microsoft) when you turn that on.
Monitoring
- Google Postmaster Tools shows your spam rate and authentication results at Gmail once you verify your domain. Inboxed can read it daily when you connect your own Google account.
- DMARC aggregate reports show every server sending as your domain and whether it passes.
- Inbox placement tests send a test email to seed mailboxes and check which folder it lands in. In Inboxed you add your own seed mailboxes at Gmail, Outlook.com, Yahoo and others, and Gmail seeds also report the Promotions, Social, Updates and Forums tabs.
- Blocklists, checked for you every 6 hours.
- Bounce, complaint and reply rates per mailbox and campaign.
When it goes wrong
- Pause the affected mailbox or campaign. Don’t keep sending to find out.
- Check authentication first. A DNS change or a new sending service often breaks SPF or DKIM alignment.
- Check blocklists and Postmaster Tools for the domain.
- Look at the list: where did it come from, when was it verified, how many bounces and complaints?
- Look at the content: new links, tracking turned on, a new attachment or image?
- Restart slowly, with a small, well-chosen segment, while warmup continues.
Common questions
Do SPF, DKIM and DMARC matter if I send fewer than 5,000 emails a day?
Yes. Gmail and Yahoo require SPF or DKIM from every sender, and the full set is what the providers expect from anyone sending at volume. Setting all three up costs little and removes a common cause of spam placement.
What spam complaint rate is too high?
Gmail and Yahoo both use 0.3% as a limit. Google recommends keeping the rate reported in Postmaster Tools below 0.1%.
Does warmup guarantee inbox placement?
No. Warmup builds a sending history for a new mailbox. A bad list, misleading content or a spike in volume will still send email to spam.
Try it with Inboxed
Warmup, verification and the team inbox are free. Start free; you pay $1 per 1,000 emails that send, from a prepaid wallet, with no subscription. How pricing works.
Sources
Sources checked on 8 November 2026. Rules change, so check the source before you rely on a detail.
- Email sender guidelines · Google, Gmail Help
- Email sender guidelines FAQ · Google, Gmail Help
- Sender Best Practices · Yahoo Sender Hub
- Strengthening Email Ecosystem: Outlook’s New Requirements for High‐Volume Senders · Microsoft Tech Community
- RFC 7208: Sender Policy Framework (SPF) · IETF / RFC Editor
- RFC 7489: DMARC (2015, now obsoleted) · IETF / RFC Editor
- DMARC RFCs, including RFC 9989, 9990 and 9991 (May 2026) · RFC Editor
- RFC 8058: Signaling One-Click Functionality for List Email Headers · IETF / RFC Editor
- RFC 6449: Complaint Feedback Loop Operational Recommendations · IETF
- Domain Blocklist FAQ · Spamhaus
- Best Current Practices for Building and Operating a Spam Trap · M3AAWG
- Trust in Email Begins with Authentication · M3AAWG
- Sender Best Communications Practices, Version 3.0 · M3AAWG