Email deliverability: the complete guide for people who aren't experts

Deliverability is not a setting you switch on. It’s a reputation, built from every message you’ve ever sent, and mailbox providers reassess it continuously rather than checking it once. The uncomfortable part is that almost everything that damages it is something you did to your list, not a technical box you forgot to tick. A bought list does more harm than a missing DNS record ever will.

Authentication, bulk sender rules and bounce thresholds matter, but they’re the technical floor, not the ceiling. Clear that floor and the rest of your reputation is earned by who you mail and how often they want to hear from you.

Key Takeaways

• Deliverability is decided by receiving mailbox providers, continuously, based on your sending history. There’s no dashboard where you set it.
• SPF, DKIM and DMARC each prove something different. None of them is optional anymore for bulk mail, and none of them alone is enough.
• Gmail and Yahoo require bulk senders (roughly 5,000 messages a day) to authenticate and keep spam complaints under 0.3%. Microsoft enforces a similar authentication bar for the same volume.
• A spam complaint costs you far more reputation than a bounce. Amazon SES, for one, publishes the exact math: its complaint threshold is fifty times tighter than its bounce threshold.
• A purchased or scraped list can blow through every threshold in this article in a single send, and the recovery takes weeks, not a settings change.

What deliverability actually means, and who decides it

Sending an email successfully and it arriving somewhere a person will read it are two different outcomes. Your sending platform can report “accepted” the moment a mailbox provider’s server takes the message off its hands. What happens after that, inbox, Promotions tab, spam folder, or silently dropped with no bounce at all, is decided entirely by the receiving side.

Gmail, Yahoo/AOL and Microsoft’s consumer services (Outlook.com, Hotmail, Live) handle most of the world’s personal inboxes, and each runs its own filtering, with its own signals and its own thresholds, none of which are fully published. What is public is the general shape: how often recipients complain, how often they engage (open, click, reply, or the opposite: delete without opening, mark as spam), whether your messages are authenticated, whether the addresses you’re sending to are real and current, and whether your sending pattern looks like something a real business would do or like an account that was recently compromised.

That reputation is tracked per sending domain and per IP, and it is not something you request or configure. Google’s own free tool, Postmaster Tools, shows large senders a rolling view of their own reputation and spam rate against Gmail, but it reports what already happened. Microsoft offers a comparable view for its own domains through Smart Network Data Services (SNDS). Nothing in the industry lets you query “am I deliverable right now” and get a number back before you send.

There’s also no single fixed window the rate is measured over. Amazon is explicit about this for its own SES enforcement: instead of a fixed number of days, it looks at a “representative volume”, enough recent sending to reflect your actual practices, and that window stretches or shrinks with how much you send. A sender doing ten sends a day and one doing one send a month aren’t judged on the same clock. Assume every major provider works roughly the same way: recent history, weighted toward what’s typical for you, not a monthly reset.

Authentication: what SPF, DKIM and DMARC each prove

None of these three records configures deliverability directly. They prove identity, and providers use failed identity checks as one input into the reputation decision above. It helps to know what each one asserts, separately from how you’d publish it, and SPF, DKIM and DMARC without the acronym soup walks through exactly that, one record at a time.

SPF (Sender Policy Framework) asserts “these servers are authorized to send mail claiming to come from this domain.” It’s a DNS record listing IP addresses or hosts. A receiving server checks the machine that connected against that list. SPF checks the hidden envelope sender, not the From address a reader actually sees, which is one reason it stops less spoofing on its own than people assume.

DKIM (DomainKeys Identified Mail) asserts “this specific message was signed by whoever holds this domain’s private key, and it wasn’t altered after signing.” The sending server attaches a cryptographic signature to the message headers; the receiving server checks it against a public key published in DNS. Unlike SPF, DKIM travels with the message and survives being forwarded through a server SPF wouldn’t recognize.

DMARC (Domain-based Message Authentication, Reporting and Conformance) doesn’t add a new check. It asserts “here’s what to do when a message fails to line up with SPF and DKIM, and here’s where to send a report about it.” Specifically, it requires the domain that passed SPF or DKIM to match the domain visible in the From header, a condition called alignment, and it publishes a policy: p=none (do nothing, just report), p=quarantine (send it to spam), or p=reject (refuse it outright).

Put together: SPF says who’s allowed to send, DKIM proves a specific message came from them unaltered, and DMARC says what to do if either check fails and ties the two together so a message can’t pass on a technicality that doesn’t match what the recipient sees. A domain with none of these has no way to prove anything it sends is genuine, which is why every provider covered below now requires all three for anyone sending at volume.

p=none is the right place to start a new domain, since it only asks receivers to report failures rather than act on them, and those aggregate reports are how you’d find a legitimate sender failing alignment before tightening the policy. Moving to p=quarantine or p=reject once you’re confident nothing legitimate fails is what actually stops someone else from spoofing your domain; a domain parked at p=none indefinitely is publishing a policy that asks for reports and enforces nothing. Setting up email DNS records one at a time covers what each of these records looks like and where it goes regardless of which platform you’re publishing them through, and the DNS records EmailFig generates shows the seven records EmailFig gives you for a sending domain, including the exact host names.

The bulk sender rules Gmail, Yahoo and Microsoft now enforce

Gmail and Yahoo announced matching bulk sender requirements that took effect on February 1, 2024, and Microsoft enforces a similar authentication bar for its own consumer domains. “Bulk” here isn’t about being a big company. It’s a volume line, and plenty of small senders cross it without noticing. Gmail, Yahoo and Microsoft’s bulk sender rules for 2026 quotes each provider’s own policy language directly, since a few of the details differ enough between the three that a summary can flatten them.

Sources: Google’s bulk sender guidelines, Yahoo’s sender best practices, Microsoft’s high-volume sender requirements.

Two details worth knowing before you assume you’re under the line. First, Yahoo’s own FAQ explicitly declines to publish a number, so treat the shared 5,000-a-day figure as the practical trigger there too rather than something Yahoo will confirm. Second, unauthenticated mail from a high-volume Microsoft sender doesn’t just get filtered into junk: it’s refused at the point of connection, the same way a message to a full mailbox is. That’s a rejection your platform will see immediately, not a delayed complaint from someone who never got your email.

The one-click header requirement is worth naming separately from a plain unsubscribe link in the footer. List-Unsubscribe and List-Unsubscribe-Post (RFC 8058) let the mailbox provider itself show an “Unsubscribe” option next to your message, no click into the email required. A footer link alone doesn’t satisfy the requirement, even one a human reader can find and use: the check is for those two headers specifically, and a plain GET link, the kind most footers still use, fails it regardless. One-click unsubscribe and why your footer link doesn’t count goes through the exact header form and where Microsoft’s own requirement is looser than Gmail’s and Yahoo’s.

Bounce and complaint rates, and the thresholds that matter

A bounce is a message a receiving server refused. A hard bounce means it refused permanently: the address doesn’t exist, the domain is invalid. A soft bounce means a temporary condition: a full mailbox, a server that’s briefly down. Providers weigh these very differently, and so should you: a hard bounce means the address should never be mailed again, while a soft bounce only becomes a problem if it repeats. The distinction traces back to the SMTP response code itself, a 5xx is permanent and a 4xx is temporary, and a sender that only logs whether a message bounced, without reading which code came back, ends up treating both the same way at its own cost. Reading a bounce goes through where that split actually breaks down, since not every 5xx means a dead address and not every 4xx means try again later.

A complaint is a recipient pressing “report spam,” and it costs you more reputation per occurrence than a bounce does. A bounce might just mean a list has gone stale. A complaint means a real person, whose inbox you reached successfully, decided your message didn’t belong there. Providers treat that as a much stronger signal, and the public numbers back that up.

Most consumer mailbox providers keep their exact enforcement thresholds private beyond the Gmail and Yahoo spam-rate ceiling above. Amazon SES is the rare exception that discloses its own tiers in full, and the gap between its bounce and complaint tolerances shows how much more a complaint costs you:

Source: AWS’s SES sending review FAQ.

Line the two up and the gap is stark: SES tolerates fifty times more bounces than complaints before either one triggers review. One complaint in a thousand sends is enough to put an account under review. One in two hundred can get it paused. These are AWS’s published numbers for its own infrastructure, not a universal standard, but the shape, complaints weighing far more than bounces, holds across the industry, because a complaint is a person who saw your message and rejected it, and a bounce is often just an old address.

List hygiene, and why a bought list is fatal

A purchased, rented or scraped list is made of addresses that never asked to hear from you. That single fact predicts almost everything that goes wrong with it:

• Addresses nobody verified recently are far more likely to be dead, so bounce rates spike immediately.
• People who never opted in are far more likely to mark the message as spam, since “report spam” is often the fastest way they know to make unwanted mail stop.
• Purchased lists are exactly where spam trap addresses concentrate: addresses list brokers seed or recycle specifically to catch senders who buy rather than build. A trap hit is a stronger negative signal than an ordinary complaint, because it proves the list wasn’t built on real permission at all.

One send to a list like this can push both the bounce and complaint numbers above past every threshold in this article at once. And because reputation is cumulative rather than reset per send, the damage doesn’t end when the bad send does. A domain has to rebuild trust with each provider from wherever that send left it, which is the same slow process as warming up a brand-new domain: start with your most engaged audience, and raise volume gradually. There’s no setting that restores a domain’s standing overnight.

The fix is upstream of sending: never mail an address that didn’t ask for it, and use double opt-in on public signup forms so a mistyped or fake address never gets a first message at all. Legitimate platforms look hard at a newly imported list before mailing it for exactly this reason. See why you shouldn’t send to purchased lists for what happens when one gets sent anyway.

A list you built honestly still needs regular pruning. Contacts who haven’t opened or clicked in months are the most likely people on a legitimate list to eventually mark a message as spam, not because they’re malicious, just because unsubscribing takes more effort than the spam button and they’ve stopped noticing you’re in their inbox at all. Removing the unengaged before that happens protects the rate that matters far more than the size of the list does. What counts as cold depends on your own send frequency rather than a fixed number of days, and giving someone a real chance to come back before removal keeps the cut from catching people who simply haven’t been mailed enough yet to respond. When to sunset cold subscribers walks through that judgment call in full: how to define cold correctly, give one honest re-engagement attempt, and only then remove the rest.

The Promotions tab

Gmail sorts incoming mail into tabs (Primary, Social, Promotions, Updates, Forums) using its own categorization model that runs alongside spam filtering but isn’t the same system (Google’s own explanation of inbox categories). A message in Promotions was delivered. It’s sitting in the recipient’s inbox, just a different tab than Primary, and it still counts as delivered by every metric in this article.

That distinction matters because Promotions placement gets treated as a deliverability failure when it’s really a lower-attention placement, a mixup that why your emails land in the Promotions tab untangles in full. Open rates there tend to run lower, since fewer people check that tab as often as their main one, but a message doesn’t move between Primary and Promotions because your reputation is bad. It moves because Gmail’s model reads your message as promotional content, and neither the exact signals it uses nor a way to request placement are published. There’s no supported trick that reliably moves a sender’s mail into Primary. The only lever that reliably helps is the same one that helps everywhere else: recipients who actually want the email, open it, and treat it as mail worth reading rather than skimming past.

What to do when delivery gets worse

Work down this list in order. Most delivery problems trace back to the first two or three items.

1. Check authentication is still passing. DNS records get overwritten by a registrar change, a migrated domain, or another tool’s setup wizard more often than anyone expects. A domain that verified once can regress. See domain verification statuses and what causes a verified domain to go back to pending.
2. Look at your bounce and complaint rates over the last few sends, not just the last one. A single bad send is a data point; a trend climbing toward the thresholds above is the actual warning.
3. Check whether anything about your list changed recently. A large import, a re-engagement campaign to contacts who’ve gone quiet, or a sudden volume increase are the three most common triggers for a reputation drop, because each one changes your sending pattern faster than a provider’s model expects.
4. Read the checklist for spam placement specifically. If mail is landing in spam rather than just Promotions, work through why emails go to spam in order: it’s usually fixable and rarely down to one thing.
5. Check what Google and Microsoft’s own tools already told you. If you send enough volume to qualify, Postmaster Tools and SNDS report reputation and spam-rate data directly from the providers judging you, often before it shows up anywhere else.
6. Pace back down, then rebuild. If a domain’s reputation has genuinely slipped, sending less for a while and re-warming with your most engaged contacts recovers faster than continuing at full volume and hoping it corrects itself. How to warm up a new sending domain covers the same gradual ramp, just starting from zero instead of from a slip.

None of this is a one-time setup. Reputation is reassessed continuously, on both sides: a domain that’s been healthy for a year can still slip, and a domain recovering from a bad send earns its way back the same gradual way a new one does.

Frequently asked questions

Why are my emails going to spam?

Emails land in spam when a mailbox provider’s ongoing reputation check on your sending domain fails, usually because of unauthenticated mail, a spam complaint rate above the provider’s ceiling, or a sudden change in your sending pattern. Gmail and Yahoo both require bulk senders to keep spam complaints under 0.3% (Google’s bulk sender guidelines), and crossing that line is one of the most common triggers. Work through the checklist for spam placement in order rather than guessing at a single cause, since spam placement is rarely down to one thing.

What bounce rate is too high?

A bounce rate of 5% or higher puts an Amazon SES account under review, and 10% or higher can get sending paused, per AWS’s own SES enforcement thresholds. AWS recommends staying below 2% for best results, and that 2% figure is a reasonable target on any platform, since a rising bounce rate signals a stale or poorly collected list well before it crosses a provider’s hard line.

What is a good spam complaint rate?

Keep your spam complaint rate below 0.1%. Gmail and Yahoo both require it to stay under 0.3% for bulk senders and treat that as a hard ceiling, not a target (Google’s bulk sender guidelines, Yahoo’s sender best practices). Amazon SES uses that same 0.1% figure as its own recommended ceiling, and places an account under review once the complaint rate reaches 0.1% (AWS’s SES enforcement thresholds). A complaint rate that low means treating every “report spam” click as a signal worth investigating, not just a number to watch.

Do I need SPF, DKIM and DMARC?

Yes, if you send more than about 5,000 messages a day to Gmail, Yahoo or Microsoft’s consumer domains, all three records are required, not optional. Gmail and Yahoo both require SPF and DKIM plus a published DMARC record for bulk senders (Google’s bulk sender guidelines), and Microsoft requires SPF and DKIM to pass with an aligned DMARC record at the same volume (Microsoft’s high-volume sender requirements). Below that volume the three records are still worth publishing, since a domain with none of them has no way to prove any message it sends is genuine.

What counts as a bulk sender to Gmail and Yahoo?

Gmail applies its bulk sender requirements once you send more than 5,000 messages a day to Gmail addresses (Google’s bulk sender guidelines). Yahoo mirrors Gmail’s rules, but Yahoo’s own FAQ declines to publish an exact volume cutoff (Yahoo’s sender FAQ), so treat the same 5,000-a-day figure as the practical trigger there too. Crossing that line pulls in marketing and other high-volume mail; a handful of transactional messages a day doesn’t count toward it.

What’s the difference between a hard bounce and a soft bounce?

A hard bounce is a permanent failure, an SMTP 5xx response, and an address that hard-bounces should never be mailed again. A soft bounce is temporary, an SMTP 4xx, and only becomes a problem if it repeats. Reading a bounce goes through where that split actually breaks down.

What this actually takes to run

Every mechanic above (authenticating a domain, tracking bounce and complaint rates against real thresholds, catching a regression before it becomes a spam-folder problem) is ongoing work. Whatever you send through should be doing it continuously in the background: verifying DNS and watching complaint and bounce trends.

EmailFig runs all of that as part of sending, on either of two paths: a managed plan, or your own Amazon SES account connected directly (BYOS), which typically costs less per month than managed at the same list size because you pay Amazon for sending yourself. Both are free up to 4,000 subscribers, no credit card required, and the pricing page lays out both side by side. If you’re already sending through your own SES account and comparing what handles the campaign side of it, Amazon SES for email marketing covers that route end to end, what SES actually costs once you add authentication and reputation tooling prices it, and our writeups of BigMailer and MailBluster cover the hosted options built on top of it.