Email Deliverability: The Checklist Before You Send

Quick answer: Most deliverability failures come from authentication gaps, list quality, or a domain that has never been warmed up. Before you press send, verify SPF, DKIM, and DMARC are passing, clean your list of hard bounces and role addresses, and check that your content and sending rhythm look like a real person mailing real subscribers.

Key takeaways

• Authentication is binary: if SPF, DKIM, or DMARC fails, filters treat your mail as suspect regardless of how good the content is.
• List hygiene is not optional. Hard bounces, role addresses, and spam traps hurt reputation faster than any subject line.
• Separate transactional mail from bulk campaigns on different subdomains or IPs so a bad campaign does not poison password resets.
• Warm up new domains and IPs gradually, and read bounce logs and complaint rates after every send, not just before.

The four layers deliverability is judged on

Every message is evaluated on four layers: infrastructure and domain reputation, authentication, list quality, and content and engagement. Infrastructure is the domain and IP you send from and what receivers already know about them. Authentication is the SPF, DKIM, and DMARC records that prove you are allowed to send. List quality is who you are mailing and whether they expect to hear from you. Content and engagement cover what the message looks like and how recipients react.

In practice, the layer that breaks first is almost always authentication or list quality, not content. A perfectly written newsletter from an unauthenticated domain on a shared host will land in spam. So will a well-authenticated campaign sent to a purchased list. Content filters mostly catch the obvious mistakes: image-only mail, mismatched From and Reply-To, and sudden changes in link domains.

Work through the layers in order. Fix authentication first because it is a one-time setup. Then clean the list. Then look at content and sending rhythm. If you are choosing an email platform, the top email marketing tools for small businesses handle much of the authentication and bounce processing for you, but you still need to verify the records.

Set up SPF correctly and avoid the lookup-limit trap

SPF is a DNS TXT record that lists which servers may send mail for your domain. A basic record looks like v=spf1 include:_spf.provider.com ~all. The ~all means soft fail; -all means hard fail. Use ~all while testing and move to -all once you are confident every sender is listed.

The trap is the lookup limit. SPF allows a maximum of 10 DNS lookups during evaluation, and each include: can trigger more lookups inside the included record. Include chains that look short can silently exceed the limit, and when they do, SPF returns a permerror and fails. This is common when you stack your ESP, your CRM, your helpdesk, and a transactional provider into one record.

Count your lookups before you publish. Many DNS tools and SPF flattening services will count them for you. If you are over the limit, remove senders you no longer use, or split sending across subdomains so each one has a shorter record. Register or manage the sending domain where you edit the DNS zone, such as Namecheap, so you can see every record in one place.

Missing DKIM versus a record on the wrong host

DKIM adds a cryptographic signature to each message, and the receiver checks it against a public key published in DNS. A missing DKIM record is easy to spot: the selector returns nothing. The more common failure is a record published on the wrong host. Selectors are often built as default._domainkey.yourdomain.com, and if the provider tells you to publish default._domainkey.yourdomain.com.yourdomain.com, that double-domain host is what the receiver will query.

Copy the host exactly as the provider gives it, including any trailing domain. If DKIM fails with dkim=permerror, the record is malformed or on the wrong host, not missing. Check the selector name, the key format, and whether the record is a TXT record at the exact host. A DKIM record that passes is one of the strongest signals you can give a receiver.

DKIM: the record that is easy to publish and easy to break

SPF says which servers may send for your domain. DKIM proves the message was not altered in transit, by attaching a cryptographic signature that the receiving server verifies against a public key published in DNS. If SPF is the envelope check, DKIM is the seal on the letter itself — and it is the record most often published in the wrong place.

The usual mistake is the selector host. A provider gives you a selector such as default and a value, and the record must be created at default._domainkey inside your zone. Paste the full name default._domainkey.yourdomain.com into the host field and the panel stores it as default._domainkey.yourdomain.com.yourdomain.com. The record looks present in the dashboard while the rest of the world sees nothing, and every message fails with dkim=permerror and no key for signature in the header. On a provider where the DNS zone is edited by hand, this is the first thing to check when authentication looks broken but everything appears configured.

Test the record before trusting it: query default._domainkey.yourdomain.com as a TXT record from outside your own network, and confirm the returned value starts with v=DKIM1. A long key often gets split into multiple strings when a panel or a copy-paste adds line breaks; the record must be one continuous value or the verification fails.

Keep one selector per sender. If the newsletter platform and the transactional sender both sign with the same key, rotating one key breaks the other. Most platforms let you use their default shared key on a subdomain, which is the cleaner option: news.yourdomain.com for campaigns, the root domain for receipts and password resets.

DMARC: from p=none to quarantine to reject

DMARC tells receivers what to do when SPF and DKIM both fail, and it sends you reports. Start with v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. At p=none you are only observing; nothing is blocked. Leave it there long enough to collect aggregate reports and confirm that all your legitimate senders pass.

Aggregate reports arrive as XML files, usually daily. They show the sending IP, the authentication result, and the volume. Read them for sources you do not recognize; those are either forgotten senders or spoofing. Once every legitimate source passes, move to p=quarantine, then to p=reject. Do not jump straight to reject; you will block your own mail if a sender is still failing.

Keep the policy at p=none while you are still adding senders, and only tighten when the reports are clean for a few weeks. If you use a subdomain for bulk campaigns, publish a DMARC record there too. The business case for getting this right is straightforward: mail that reaches the inbox is the only mail that can support business growth through email marketing.

Transactional mail and bulk campaigns should not share a domain or IP

Transactional mail is triggered by a user action: password resets, receipts, welcome messages. Bulk campaigns are newsletters and promotions sent to a list. They have different tolerance for failure. A missed receipt is a support ticket; a missed promotion is a lost sale. If they share a domain or IP, a campaign that spikes complaints can drag down the reputation of your password resets. A cheap shared host that throttles outgoing mail or gets its IP range blocklisted will take your receipts down with it, which is one of the reasons the type of web hosting you choose matters for email as much as for pages.

Use a subdomain for each stream, for example mail.yourdomain.com for campaigns and receipts.yourdomain.com for transactional. Each subdomain gets its own SPF, DKIM, and DMARC records. If you are on a shared host or ESP, ask whether you get a dedicated IP; if not, the subdomain separation still limits the blast radius.

This separation also makes diagnosis easier. When a message lands in spam, the header tells you which stream and which authentication path failed. The welcome sequence is a good example: it is transactional in intent but often sent through the campaign stream. Protect it by keeping its authentication clean and its content close to what the subscriber expects. The checks here are what keep a welcome sequence landing in the inbox.

List hygiene: bounces, role addresses, and spam traps

Hard bounces are permanent failures: the address does not exist. Remove them immediately and never retry. Soft bounces are temporary: mailbox full, server busy, message too large. Retry a few times over a day or two, then suppress. A list that keeps hard bounces is telling receivers you do not clean, which is a reputation problem.

Role addresses like info@, sales@, and admin@ often go to shared inboxes or automated systems. They are more likely to complain and less likely to engage. Suppress them on signup or at first send. Spam traps are addresses that never opt in and exist only to catch bad senders; they are the main reason purchased lists fail. Do not buy lists. The quality of your list starts with where the signups come from, which is why growing your email list with permission matters more than list size.

Engagement-based sunsetting keeps the list healthy. If a subscriber has not opened or clicked in a long stretch, move them to a re-engagement segment, then suppress them if they stay silent. This lowers volume but raises engagement rates, which receivers notice. Sending to people who ignore you is the slowest way to damage a domain.

Content signals that trigger filters

Filters look for patterns that correlate with unwanted mail. An image-only message with little text is a classic trigger; include a plain-text version and a real text-to-image ratio. Link shorteners hide the destination and are treated with suspicion; use your own domain for links. A From address that does not match the Reply-To, or a Reply-To on a different domain, looks like spoofing.

Sudden changes in link domains are risky. If your newsletter usually links to your own site and one send links to a file-sharing domain, filters notice. Keep links on domains you own and have used before. Attachments in bulk campaigns are another trigger; host the file and link to it instead. For transactional mail, attachments are expected, but keep them small and named clearly.

Subject lines and body copy matter less than structure, but obvious spam phrases still add risk. Write like a person, not a billboard. Sending practices that keep engagement high are covered in how to email marketing like a pro, and they overlap heavily with what filters reward.

Warm-up and sending rhythm for a new domain or IP

A new domain or IP has no reputation. Receivers limit volume until they see consistent, low-complaint sending. Warm up by starting with your most engaged subscribers, a few hundred a day, and increasing gradually over a few weeks. Send at a steady rhythm rather than in one giant blast. A sudden jump from zero to thousands looks like a compromised account.

Keep the same sending pattern for transactional and campaign streams separately. If you move to a new ESP, warm up again even if the domain is old; the IP and the sending path are new. Watch bounce and complaint rates daily during warm-up. If complaints rise, slow down and re-check the list rather than pushing through.

What to check in one pre-send pass

Run this pass before every campaign and before the first send of a new sequence. It takes minutes and catches most avoidable failures.

• SPF record exists, is under 10 lookups, and ends in ~all or -all.
• DKIM selector resolves at the exact host the provider gave you, and a test message shows dkim=pass.
• DMARC record is published and the policy matches your current stage.
• Hard bounces and role addresses are suppressed from the segment.
• From and Reply-To match, and links use your own domain.
• A plain-text version exists and the message is not image-only.
• Volume fits your warm-up stage and recent sending rhythm.

Comparison: what each layer catches

Layer	What it proves	Typical failure	Where to check
SPF	Sending server is authorized	Too many lookups, permerror	DNS TXT record, SPF counter
DKIM	Message is signed and unaltered	Wrong host, permerror	Selector DNS, test message header
DMARC	Policy and reporting are set	Policy too strict too early	Aggregate XML reports
List quality	Recipients expect the mail	Hard bounces, spam traps	Bounce log, signup source
Content	Message looks legitimate	Image-only, shorteners	Preview and link audit

What to read after the send

After the send, read the bounce log first. Separate hard from soft bounces and suppress the hard ones. Then check your postmaster tools or ESP reputation dashboard for complaint rate. A rising complaint rate is the clearest signal to slow down and review the list. Finally, look at engagement by segment; a drop in opens from one segment usually points to list quality, not content.

Keep a simple log of sends, volume, bounce rate, and complaint rate. Patterns show up over a few sends that are invisible in one. If a domain starts landing in spam, the log tells you whether it started after a volume jump, a list import, or a content change.

Diagnosing a message that lands in spam

Open the full headers of the message that landed in spam. Look for Authentication-Results. It shows the SPF, DKIM, and DMARC results as the receiver saw them. Then look for Received-SPF to see which IP was checked and what the result was. If you see dkim=permerror, the record exists but is malformed or on the wrong host; a missing record usually shows as dkim=none.

Compare the header result with what you published. A common case is SPF passing for one sender and failing for another because the include chain exceeded the lookup limit. Another is DKIM passing on the campaign subdomain but failing on the root domain because the selector was published only once. Fix the record, then send a test to a seed address and re-read the header before the next campaign.

Frequently asked questions

Why does my email go to spam even though SPF and DKIM pass?

Authentication proves you are allowed to send, not that the recipient wants the mail. If SPF and DKIM pass but mail still lands in spam, look at list quality and engagement. Hard bounces, role addresses, and low open rates on a segment are common causes. Content structure, such as image-only mail or link shorteners, can also tip a passing message into spam.

Do I need DMARC if I already have SPF and DKIM?

Yes. DMARC ties SPF and DKIM to your domain and tells receivers what to do when both fail. Without it, a spoofed message can still pass SPF on a shared host. Start at p=none to collect reports, then tighten the policy once every legitimate sender passes.

How many SPF lookups is too many?

The limit is 10 DNS lookups during evaluation. Include chains count toward it, so a record with three includes can exceed the limit if each include pulls in more. When the limit is exceeded, SPF returns permerror and fails. Count lookups before publishing and remove senders you no longer use.

Can I send campaigns and transactional mail from the same domain?

You can, but you should not. A campaign that spikes complaints can damage the reputation of your password resets and receipts. Use separate subdomains for each stream, each with its own SPF, DKIM, and DMARC records. This also makes header diagnosis clearer when something fails.

How long does it take to warm up a new sending domain?

Usually a few weeks of steady, low-volume sending to engaged subscribers, increasing gradually. The exact pace depends on your list size and complaint rate. Watch bounce and complaint rates daily and slow down if either rises. Moving to a new ESP means warming up again even if the domain is old.

What to do next

Open your DNS zone and confirm three records: SPF under the lookup limit, DKIM at the exact host your provider gave you, and a DMARC record at p=none if you are still collecting reports. Then suppress hard bounces and role addresses from your next segment. Send a test to a seed address and read the Authentication-Results header before you send to the list. If anything fails, fix the record first; content changes will not rescue an authentication failure.

Disclosure: some links in this article are affiliate links. If you buy through them we may earn a commission at no extra cost to you.