Cold email deliverability: the rules that decide the inbox

Cold email reaches the inbox when four things are true: the sending domain is authenticated with SPF, DKIM and DMARC; volume rises slowly from a low start; spam complaints and bounces stay well under the limits mailbox providers publish; and every message is one its recipient could plausibly want. Gmail, Yahoo and Outlook all document these rules. Most deliverability problems come from ignoring one of them.

Deliverability is usually sold as a dark art, with secret warmup tricks and magic sending times. It is mostly not. The three largest mailbox providers publish what they expect, and since 2024 they have enforced it. This guide covers what they require, what the standards behind those requirements say, and the stricter limits Snaut applies on top.

What changed in 2024 and 2025

For years, the rules for bulk email were recommendations. That ended when Google and Yahoo announced requirements that took effect in February 2024, and Microsoft followed for Outlook in 2025. The details differ, but the direction is the same: authenticate your domain, make leaving easy, and keep complaints low.

Google states that since February 1, 2024, all senders to Gmail accounts must meet its baseline requirements, and it asks senders to keep the spam rate reported in Postmaster Tools below 0.10% and to avoid ever reaching 0.30%. Yahoo's sender best practices set the same 0.3% ceiling and require bulk senders to honor unsubscribe requests within two days.

Microsoft's announcement covers domains sending more than 5,000 messages a day to Outlook. As updated, it says messages that fail its authentication requirements are rejected with the error 550 5.7.515, starting May 5, 2025, rather than routed to Junk as first planned.

A cold sender working from one or two mailboxes will rarely cross 5,000 messages a day. That does not make the high-volume requirements optional in practice. Authentication is the cheapest signal of legitimacy you can send, and a domain that skips it competes for inbox placement with one hand tied. We set up every requirement in the right-hand column regardless of volume, and we recommend you do the same.

Authentication, in plain words

Authentication answers one question for the receiving server: is this message really from who it says it is from? Three records in your domain's DNS do the work, each covering a gap the others leave.

SPF: which servers may send for you

Sender Policy Framework is a single TXT record that lists the servers allowed to send mail for your domain. Two details cause most of the problems. First, you may publish only one SPF record; two records for the same domain make SPF fail. Second, the standard limits how many DNS lookups an SPF check may trigger. RFC 7208 caps it at 10 terms that cause DNS queries, such as include, a, mx, ptr, exists and redirect, and exceeding that limit is a permanent error. Every service you add with an include, such as a newsletter tool or a help desk, uses up part of that budget.

The record should end in ~all or -all, never +all, which would authorize every server on the internet to send as you. Snaut's guardian checks all three: one record, no more than 10 lookups, and no +all. It also checks that your mailbox provider's include is present, because a record that forgets Google or Microsoft fails for exactly the mail you care about.

DKIM: a signature that proves the message was not altered

DomainKeys Identified Mail adds a cryptographic signature to every message, which the receiver verifies against a public key published in your DNS. Google and Yahoo both require keys of at least 1024 bits, and 2048 bits is the recommended length where your provider supports it. Snaut treats a key under 1024 bits as a failure and a key under 2048 bits as a warning, and it confirms that a test message's signature actually verifies, because a published key that does not match the signing key is worse than no key at all.

DMARC: what to do when the first two fail

Domain-based Message Authentication, Reporting and Conformance ties SPF and DKIM to the address in the From line and tells receivers what to do with mail that fails. It also asks receivers to send you reports. The standard was updated in May 2026: RFC 9989 replaces the 2015 informational specification, RFC 7489. One practical change is that the old pct tag, which let a domain apply its policy to a percentage of mail, has been removed and replaced by a simpler test-mode flag. If you copy a DMARC record from an older guide, drop the pct tag.

RFC 9989 describes the deployment path clearly. Set up a mailbox for aggregate reports, then publish a record at p=none with a rua tag pointing at it. The standard calls this monitoring mode, and gives the reason for starting there: in all but the simplest setups, a domain owner can overlook a server or a third-party service that sends on its behalf, and the reports reveal those streams before a strict policy breaks them. Fix the unaligned streams, then move toward enforcement.

Snaut follows that path. It asks for p=none with a rua address, recommends moving to p=quarantine after about two clean weeks of reports, and treats p=reject as optional once the stream stays clean. It will not suggest tightening a policy while reporting is missing.

example.com.         TXT  "v=spf1 include:_spf.google.com ~all"
google._domainkey    TXT  "v=DKIM1; k=rsa; p=<public key from your provider>"
_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

These three lines are illustrative. Your mailbox provider gives you the exact SPF include and DKIM key, and the selector name varies by provider. Google's baseline also requires valid forward and reverse DNS for sending servers and TLS for the connection. If you send through Google Workspace or Microsoft 365, the provider handles those two for you.

The numbers that matter

Mailbox providers watch many signals, most of which they do not publish. A few they do publish, and those are the ones worth managing actively.

The complaint threshold deserves a closer look, because it is stricter than it sounds. A 0.1% limit means one complaint per thousand messages. A mailbox that sent 200 messages this week and received one complaint is at 0.5%, five times over the line. That is deliberate. At low volume, a single person marking you as spam is a strong signal that the list or the message is wrong, and pausing costs a day while ignoring it can cost the domain.

Bounces matter for a different reason. A bounce means the address does not exist or cannot receive mail, and a sender with many bounces looks like someone guessing addresses or mailing an old, unmaintained list. Both are behaviors spam filters are built to catch.

Volume: why slow wins

Every mailbox has a hard ceiling set by its provider. Google Workspace, for example, limits a user to 2,000 messages a day, 500 for trial accounts, measured over a rolling 24 hours, and Google notes that these limits can change without notice. That ceiling covers all mail from the account, and it is a limit, not a target. Sending cold email anywhere near it is how a working mailbox stops working.

Reputation is built by consistency: a sender whose volume rises gradually, whose recipients open and reply rather than complain, and whose pattern looks like a person working through a day. Snaut's pacing is built to look like exactly that, because for a careful sender it is exactly that.

• Two limits apply at once, and the lower one wins: the ramp above, and the deliverability guardian's default caps of 25 per mailbox and 75 per sending domain.
• A newly connected mailbox runs at half its cap for its first seven days. That applies even to mailboxes a vendor describes as pre-warmed, because we cannot verify the claim.
• Messages are spaced between 4 and 11 minutes apart, never in a burst.
• A mailbox sends at most one message per recipient domain per day, so five people at one company do not hear from you on the same morning.
• Messages go out between 09:00 and 17:00 on weekdays, in the recipient's time zone, not yours.

If those numbers look small, compare them with the alternative. Ten careful messages a day is 50 a week and more than 200 a month from a single mailbox. That is enough to learn which buyers respond, and it is a volume at which you can still read every draft before it goes. Our guide to getting more clients without hiring explains why a short list of well-chosen companies outperforms a long one.

Keep cold email off your main domain

Your main domain carries invoices, password resets, support replies and every conversation your team has with existing customers. If cold outreach damages its reputation, all of that is at risk of landing in spam too. Separating the two keeps one stream's problems from spilling into the other.

The usual practice is a separate domain that clearly belongs to you, used only for outreach and authenticated exactly as carefully as the main one. Snaut enforces this. It blocks cold sending from the workspace's main website domain unless an admin logs an override, and it treats subdomains of the main domain the same way, because reputation is not reliably isolated between a domain and its subdomains. The override exists because some businesses decide to accept the risk. The warning stays visible either way.

Snaut does not sell domains or mailboxes, and it does not warm them for you. You bring your own Google Workspace or Microsoft 365 mailbox on a domain you control. That keeps the reputation yours, rather than shared with every other customer of a sending pool.

Verify every address before the first send

The fastest way to damage a new domain is to send to addresses that do not exist. Snaut verifies every address before a first message can be sent, and the send gate refuses an address that has not been verified as valid within the last 30 days. Two kinds of address get special treatment:

• Catch-all domains accept mail for any address, so verification cannot confirm the person exists. Snaut sends to a catch-all address only after a person approves it.
• Role addresses such as info@ or sales@ are never sent cold outreach. They are not a named person, and messages to them are far more likely to be reported.

Be careful with how verification is done. Outlook.com's sender policies prohibit namespace mining, which means probing a mail server to find valid addresses without delivering mail, and they ask senders not to retry after a permanent 5xx rejection. Ask any verification provider how it checks addresses, and prefer one that respects the receiving provider's rules.

Make leaving easy

Every cold email Snaut sends includes a footer with a working way to opt out and the sender's physical postal address, and the send gate blocks any message missing either. Recipients in the EU and UK also get a privacy line linking to how their data is handled. The message headers carry List-Unsubscribe and List-Unsubscribe-Post, the pair of headers defined in RFC 8058 that lets a mail client offer one-click unsubscribe.

An opt-out is honored as soon as it arrives, and permanently. Suppressed addresses are stored as one-way hashes, kept so that the person is never contacted again, including by a future import of the same list. That is stricter than U.S. law: the FTC's CAN-SPAM guide allows up to 10 business days to honor a request. We cover the legal side in detail in our guide to whether cold email is legal.

Making leaving easy is not only compliance. A person who cannot find an unsubscribe option has one button left, and it is the spam button. Every complaint that a visible opt-out prevents protects your sending reputation directly.

Write messages people do not report

Authentication gets you considered. Content and relevance decide what happens next. Providers do not publish their filtering rules, so claims about forbidden words or magic formats should be treated with suspicion. What the providers do say consistently is that they measure how recipients react. A message that is relevant to its reader gets opened, sometimes answered, and rarely reported.

That makes deliverability and message quality the same problem seen from two ends. A message that names something real about the recipient's company, makes one clear point and asks one easy question is less likely to be marked as spam than a template sent to a thousand strangers. Snaut's checker removes the sentences that make cold email feel automated, such as invented compliments and fake familiarity, and we explain why in our article on AI sales emails that make things up. The structure of a message that earns replies is covered in how to write a first message that gets replies.

Every message is a vote on your domain's reputation, cast by the person who reads it.

The display name and subject are part of the message

Gmail's sender guidelines are unusually specific about the parts of a message a filter can read without opening it: the display name and the subject line. The guidance says a display name should identify the sender and nothing else, and it lists the patterns it considers deceptive. A display name built from the recipient's first name, such as a name followed by an address at your domain, implies a personal relationship that does not exist. A display name that reads like an alert or a deadline imitates system mail. A name with a number in brackets imitates a reply thread.

The same logic applies to the subject line. Google states plainly that a sender should not start a subject with Re: or Fwd: unless the message is an actual reply or forward. For a first cold email, a fabricated Re: is the cheapest possible lie, and it is the kind of thing that turns a recipient from indifferent into annoyed. Snaut's checker rejects a subject starting with Re: for that reason, and its subject rules go further: between two and six words, so the line survives a phone lock screen.

Emojis get similar treatment. Google asks senders not to use emojis or other non-standard characters to imitate graphic elements with deceptive intent, including in display names, and not to hide content with HTML or CSS, since hidden content can cause a message to be marked as spam. None of this forbids a plain, well-written subject. It rules out the tricks that exist to get past a reader's judgment rather than earn it.

There is a practical benefit beyond deliverability. A display name that is a real person at a real company, and a subject that says what the message is about, are the two strongest signals a reader has that the email is worth opening. Every other tactic is a way of borrowing attention that the message then has to repay.

Three beliefs that cost senders their inbox

Open rates tell you whether you have a deliverability problem

They do not, and Google says so directly: it does not track open rates, it cannot verify the accuracy of open rates reported by third parties, and low open rates are not necessarily an accurate indicator of deliverability or spam classification issues. Modern mail clients block tracking pixels, and Apple's Mail Privacy Protection preloads images, which registers an open for a message nobody read. Watch the spam rate, the bounce rate and replies instead. Those three are measured by systems that are not guessing.

A warmup service makes a new mailbox safe

Google publishes no standard for warmup products and does not vouch for any. What it does publish is the practice that works: start with a low volume to engaged recipients and increase it slowly, keep the rate steady rather than sending in bursts, and monitor responses as the number grows. That is a description of gradual sending, not of a product that trades opens between strangers. Snaut implements the gradual part: the four-week ramp, half the cap for the first week, and a pause on any complaint spike.

A sending platform removes the need for your own domain

Gmail's guidance for senders who use an email service provider is blunt. Google does not accept allowlist requests from providers, it cannot guarantee that messages sent through any provider will pass its filters, and it recommends verifying that the provider follows the published guidelines. The domain's reputation belongs to the domain, which is why Snaut asks you to bring your own mailbox on a domain you control rather than sending from a pool shared with strangers.

Watch the right dashboards

You cannot manage what you do not see. These sources are free and worth checking weekly:

• Google Postmaster Tools shows the spam rate Gmail measures for your domain, which is the number Google's 0.10% and 0.30% thresholds refer to.
• DMARC aggregate reports show every server sending as your domain and whether it passed. Read them through a parsing tool rather than as raw XML.
• Your own bounce and complaint counts, by mailbox, over the last seven days. Snaut tracks these and pauses automatically.
• Blocklists. Snaut's guardian checks for blacklist hits and treats a hit as a reason to stop.

Snaut also watches the DNS records themselves. If SPF, DKIM or DMARC changes unexpectedly, it pauses sending until someone confirms the change, because an accidental edit can break authentication for every message that follows. When Snaut edits a record on your behalf, it saves a snapshot of the existing records first, and it never touches records it did not create.

When your email lands in spam

If replies dry up or a test message lands in spam, work through this in order:

1. Stop sending from the affected mailbox. More volume does not fix reputation; it spends what is left.
2. Check authentication. Confirm SPF, DKIM and DMARC all pass for a test message, and check for a recent DNS change.
3. Check blocklists and your Postmaster Tools spam rate.
4. Look at the last week's list. Where did the addresses come from, and how many bounced?
5. Look at the last week's messages. Would the recipients have recognized why you wrote to them?
6. Resume at a fraction of the previous volume, and only after the cause is fixed.

Recovery is slower than damage. Reputation that took months to build can be harmed in a week, which is the strongest argument for the conservative limits throughout this article.

A pre-send checklist

1. Use a separate domain for cold outreach, not your main domain or one of its subdomains.
2. Publish exactly one SPF record with your provider's include, no more than 10 lookups, ending in ~all or -all.
3. Enable DKIM with a 2048-bit key if your provider supports it, and confirm a test message verifies.
4. Publish DMARC at p=none with a rua reporting address, and read the reports.
5. Make sure the domain has MX records, so replies can arrive.
6. Verify every address within the last 30 days, and skip role addresses.
7. Start at 10 messages a day per mailbox and increase weekly.
8. Include a working opt-out and your postal address in every message.
9. Send only during the recipient's working hours, spaced minutes apart.
10. Pause on a complaint rate above 0.1% or a bounce rate above 3%, and find out why before resuming.
11. Move DMARC to p=quarantine once the reports have been clean for about two weeks.

Snaut runs most of this list automatically and blocks a send when an item fails, but the list works with any tool. If you are still deciding which kind of tool you need, our buying guide compares AI SDRs, sending platforms and lead databases.

Provider requirements change. The figures here were checked against each provider's published guidance in October 2026; the sources below link to the current versions. Snaut's limits are its production defaults at the same date.