Email deliverability checklist (2026)
The DNS, authentication, infrastructure and list practices that decide whether your mail reaches the inbox, with a check for each item.
How receivers decide
No single setting guarantees the inbox. Receivers first check whether a message is authentic, then whether the sending infrastructure looks legitimate, and finally whether recipients want this kind of mail from you. Failing the first layer usually means rejection or the spam folder regardless of content.
The large mailbox providers have made the first two layers explicit. Since February 2024 Google and Yahoo require every sender to authenticate and use valid DNS, and they add further rules for bulk senders of roughly 5,000 messages a day or more. Microsoft announced similar requirements for Outlook.com in 2025.
1. Authentication
| Item | Target | Check with |
|---|---|---|
| SPF record | One record, 10 lookups or fewer, ends with ~all or -all | Email Security |
| DKIM | Every sender signs with d= your domain, 2048-bit RSA, rsa-sha256 | Email Header Analyzer |
| DMARC record | One record at _dmarc with a rua address | Email Security |
| Alignment | SPF or DKIM domain matches the From domain | Aggregate reports, message headers |
| DMARC policy | Moving toward quarantine or reject | Email Security |
Google's guidelines require all senders to set up SPF or DKIM, and bulk senders to set up both plus DMARC with at least p=none. For bulk mail, the From domain must also align with either the SPF or the DKIM domain. Treat those as the minimum and aim for DKIM alignment on every stream, because it survives forwarding.
Walk through the DMARC rollout plan once the records exist. An enforced policy protects your domain's reputation from spoofing, which receivers otherwise attribute partly to you.
2. Sending infrastructure
Forward and reverse DNS
Every IP address that sends mail should have a PTR record, and the host name in it should resolve back to the same IP. This forward-confirmed reverse DNS is part of Google's requirements for all senders. Hosted providers handle it for their servers; if you run your own mail server, ask the owner of the IP range to set the PTR.
10.2.0.192.in-addr.arpa. IN PTR mail.example.com.
mail.example.com. IN A 192.0.2.10Check both directions with the Reverse DNS tool for the IP and the DNS Lookup for the host name. A generic PTR like 192-0-2-10.dynamic.example.net looks like a residential connection to many filters.
TLS
Receivers expect mail to arrive over TLS, and Google lists it as a requirement. Modern mail software uses STARTTLS automatically when the receiving server offers it. For your inbound mail, MTA-STS and TLS reporting let you require TLS and see failures; the MTA-STS guide covers the setup.
Blocklists
A listing on a major DNS blocklist can cause rejections at every receiver that uses it. Check your sending IPs with the Blacklist Check after incidents and on a schedule. If you are listed, the removal playbook explains the process per list.
Message format
Messages should follow RFC 5322: one From header, a valid Date and Message-ID, and no headers that impersonate another domain. Mail that claims to be from a large mailbox provider's domain while being sent elsewhere is rejected by those providers under their own DMARC policies.
3. Rules for bulk and marketing mail
One-click unsubscribe
Marketing and subscription messages from bulk senders must support one-click unsubscribe as described in RFC 8058. The message carries a List-Unsubscribe header with an HTTPS URL and a List-Unsubscribe-Post header; the mailbox provider sends a POST request to that URL when the user clicks unsubscribe. Google asks senders to honour unsubscribe requests within two days.
List-Unsubscribe: <https://example.com/unsubscribe?id=3f9a1c>, <mailto:unsubscribe@example.com?subject=3f9a1c>
List-Unsubscribe-Post: List-Unsubscribe=One-ClickBoth headers must be covered by the DKIM signature, and the URL must work without a login or confirmation page for the POST request. Transactional mail such as receipts and password resets does not need one-click unsubscribe.
Complaint rate
Google asks bulk senders to keep the spam complaint rate reported in Postmaster Tools below 0.1% and to avoid ever reaching 0.3%. Complaints come from recipients clicking "Report spam", so the fix is almost always about who receives the mail and how easy it is to leave.
- Send only to people who asked for the mail; confirmed opt-in removes typos and fake sign-ups.
- Remove addresses that hard bounce immediately and stop sending to long-inactive recipients.
- Make the sender name and subject recognisable, so recipients do not mistake you for spam.
- Keep unsubscribe visible in the message body as well as in the headers.
- Separate marketing from transactional mail with different subdomains, so complaints about one do not affect the other.
Content and links
Authentication decides whether a message is trusted to come from you; content decides whether it looks like something recipients want. Filters look at the domains of links as well as your sending domain. A link to a domain with a poor reputation, or a public URL shortener used by spammers, can pull a clean message into the spam folder.
- Link to your own domain or a subdomain of it, and make click-tracking domains branded (for example
links.example.com). - Send a plain-text part alongside HTML; image-only messages with little text look like spam.
- Use a From name and address that recipients recognise, and a working Reply-To.
- Keep the HTML clean: no hidden text, no huge attachments, no scripts, which mail clients remove anyway.
- Check that every link and image URL uses HTTPS and does not redirect through several unrelated domains.
The Redirect Checker shows the full chain behind a tracking link, including every hop and the final URL. A link that bounces through three domains before reaching your site is worth simplifying.
Provider programs worth joining
Several mailbox providers offer free programs that show how they see your mail. They require proof that you own the domain or IP range, and some only report data above a minimum volume. They are the only direct view you get of reputation at those providers.
| Program | Provider | What it gives you |
|---|---|---|
| Postmaster Tools | Spam rate, domain and IP reputation, authentication and encryption rates for Gmail traffic | |
| Smart Network Data Services (SNDS) | Microsoft | Data about mail from your IP addresses to Outlook.com, including complaint information |
| Junk Mail Reporting Program (JMRP) | Microsoft | Copies of messages Outlook.com users marked as junk, for IPs you register |
| Complaint Feedback Loop | Yahoo | Reports of messages Yahoo users marked as spam, for DKIM domains you register |
Feedback loops are most useful when your sending platform unsubscribes complaining recipients automatically. A complaint is the clearest signal someone does not want your mail, and continuing to send to them raises your complaint rate further.
4. Volume and warm-up
Receivers judge new IP addresses and new sending domains cautiously. Sudden jumps from a few messages to large campaigns look like a compromised account or a spammer, even when the list is clean. Increase volume over days or weeks, starting with your most engaged recipients.
Shared IP pools at an email service provider come with an existing reputation, which is why most senders do not warm up anything themselves. Dedicated IPs make sense only when volume is steady and high enough to build a reputation of their own. In both cases, the domain reputation still follows your From domain, DKIM domain and content.
Transactional mail deserves its own lane
Password resets, receipts and security alerts are the messages users most need, and they are hurt most by marketing problems. If newsletters and receipts share a From domain, a DKIM key and an IP pool, a spike in complaints about a campaign lowers the reputation that receipts depend on. Separating them is the single most effective structural change for many organisations.
| Stream | From domain | Sending path |
|---|---|---|
| Staff mail | example.com | Mailbox provider |
| Transactional | notify.example.com | Transactional email service or your relay |
| Marketing | news.example.com | Email service provider |
Each subdomain gets its own SPF record and DKIM selector and inherits the organizational DMARC policy. Monitoring stays simple because aggregate reports show the From domain of every row. Keep transactional messages free of promotional content, since mixing the two brings back the complaint risk you separated.
5. Monitoring
| Signal | Where | How often |
|---|---|---|
| DMARC pass rate per sender | Aggregate reports | Weekly |
| Spam rate and domain reputation at Gmail | Google Postmaster Tools | Weekly for bulk senders |
| Outlook.com data for your IPs | Microsoft SNDS | Weekly for dedicated IPs |
| Blocklist status | Blacklist Check | After incidents and monthly |
| Bounces and deferrals | Your sending platform's logs | Daily for large volumes |
| Records still valid | Domain Health | After every DNS change |
Most deliverability problems announce themselves before they become outages: a rising deferral rate, a new failing source in DMARC reports, or a drop in reputation in a postmaster dashboard. A weekly look at these numbers catches them while the fix is still small.
DMARC aggregate reports deserve special attention because they cover every receiver that reports, not just one provider. A service that stops signing or a new marketing tool shows up there first.
When mail starts going to spam
- Check authentication on a fresh message with the Email Header Analyzer: SPF, DKIM and DMARC should pass with your domain.
- Run Domain Health to catch a broken SPF record, a missing DMARC record or DNS errors.
- Check your sending IPs and domain on the Blacklist Check.
- Look at complaint and reputation data in the postmaster dashboards of the affected provider.
- Review what changed recently: a new list import, a new sending tool, a DNS migration or a big increase in volume.
- Fix the cause before sending again at full volume; resume gradually.
Do not switch domains to escape a bad reputation
The checklist
- SPF: one record, 10 lookups or fewer, explicit
-allor~all. - DKIM: every stream signed with your domain, 2048-bit keys, rotation plan.
- DMARC: one record,
ruareports read weekly, policy moving toreject. - PTR records for sending IPs that resolve back to the same IP.
- TLS on outbound delivery; MTA-STS and TLS-RPT for inbound mail.
- No listings on major blocklists.
- RFC 8058 one-click unsubscribe on marketing mail, honoured within two days.
- Complaint rate below 0.1% at Gmail; confirmed opt-in and bounce removal.
- Marketing, transactional and personal mail separated by subdomain.
- Weekly look at DMARC reports and postmaster dashboards.
FAQ
Do the bulk sender rules apply to small senders?
The stricter rules apply to senders of roughly 5,000 messages a day to a provider's users. Authentication, valid reverse DNS and TLS are expected of every sender, and meeting the bulk rules helps small senders too.
Is a DMARC record with p=none enough?
It meets the minimum for bulk senders and gives you reports. It does not stop spoofing of your domain, so plan the move to quarantine and reject.
Does one-click unsubscribe apply to transactional mail?
No. Receipts, password resets and account notifications are not subscriptions. Marketing and newsletter mail need it.
What complaint rate is acceptable?
Google asks bulk senders to stay below 0.1% as shown in Postmaster Tools and never reach 0.3%. Lower is always better.
Do I need a dedicated IP address?
Usually not. Shared pools at a reputable provider work well for most senders. Dedicated IPs need steady, high volume to build and keep a reputation.
Why does mail reach Gmail but not Outlook, or the other way round?
Each provider keeps its own reputation data and filters. Check authentication first, then look at the provider's own sender program (Postmaster Tools for Gmail, SNDS for Outlook.com) for the one where delivery fails.
How do I check if my IP is on a blocklist?
Use the Blacklist Check with the IP address of your sending server. The list owner's website explains the reason and the removal process.