Email deliverability guide: reach the inbox, not spam

Deliverability is the gap between 'the email was sent' and 'the email reached the inbox.' Your application can send a message successfully (the API returns 202, the SMTP server accepts it), and the recipient still never sees it because it landed in spam, was silently dropped, or bounced.

For transactional email, deliverability is everything. A marketing email that lands in the Promotions tab is an inconvenience. A password reset email that lands in spam is a broken product. Users don't check spam for password resets; they click 'reset' again, then again, then contact support, then lose trust in your application.

This guide covers the technical and operational practices that determine whether your transactional emails reach the inbox. It's written for developers who are setting up transactional email for the first time or debugging deliverability problems with an existing setup.

Authentication: the foundation

Email authentication is the single most important factor in deliverability. Without it, receiving mail servers have no way to verify that a message claiming to be from your domain actually came from an authorized sender. The three protocols you need are SPF, DKIM, and DMARC.

SPF (Sender Policy Framework)

SPF is a DNS TXT record that lists which IP addresses and mail servers are authorized to send email for your domain. When a receiving server gets a message from your domain, it checks your SPF record to see if the sending server's IP is on the list.

A typical SPF record for a domain using Envello looks like: v=spf1 include:_spf.envello.dev ~all. The 'include' directive delegates to your provider's SPF record, which lists their sending IPs. The '~all' at the end is a soft fail for any IP not on the list.

Common mistakes: having multiple SPF records on the same domain (only the first is evaluated, the rest are ignored), exceeding the 10 DNS lookup limit (each 'include' counts as a lookup, and nested includes compound), and forgetting to add a provider after setting them up for sending.

Check your SPF record with a DNS lookup tool. If you're getting soft fails or permerrors, fix the record before worrying about anything else.

DKIM (DomainKeys Identified Mail)

DKIM adds a cryptographic signature to each outgoing message. Your email provider signs the message with a private key; the receiving server retrieves your public key from a DNS CNAME or TXT record and verifies the signature. If the signature is valid, the server knows the message wasn't tampered with in transit and that an authorized sender produced it.

Your email provider generates the DKIM key pair during domain setup and gives you one or two DNS records to publish. Once published, every message sent through that provider for your domain gets signed automatically.

DKIM alignment matters for DMARC: the domain in the DKIM signature (the d= value) must match the From domain in the message header. If your provider signs with a different domain (some do by default), DMARC alignment fails even though the signature itself is valid. Verify that your provider signs with your domain, not theirs.

DMARC (Domain-based Message Authentication, Reporting, and Conformance)

DMARC ties SPF and DKIM together and tells receiving servers what to do when neither passes. It also sets up reporting so you can see who is sending email as your domain, whether legitimate or not.

DMARC has three policy levels: 'none' (monitor only, don't take action on failures), 'quarantine' (send failures to spam), and 'reject' (block failures entirely).

Start with p=none and the rua tag pointing to an address where you can receive aggregate reports: v=DMARC1; p=none; rua=mailto:[email protected]. Monitor the reports for a few weeks to make sure all legitimate sending sources pass authentication. Then move to p=quarantine, monitor again, and finally p=reject.

Skipping straight to p=reject without monitoring is risky: if a legitimate sending source (your application, a SaaS tool that sends on your behalf, a forwarding service) fails authentication, those messages get blocked. The monitoring phase catches these before they become outages.

For new domains with no legacy sending, the ramp from none to reject can happen in a week. For established domains with multiple sending sources, give it a month.

Sender reputation

Authentication gets your message accepted. Reputation determines inbox vs. spam.

Mailbox providers (Gmail, Outlook, Yahoo, and others) maintain internal sender scores based on your domain's and IP's sending history. The score is influenced by bounce rate, complaint rate, engagement signals (opens, clicks, replies vs. deletes-without-opening), spam trap hits, and volume consistency.

You don't get to see the score directly. Google Postmaster Tools shows some reputation data for Gmail; Microsoft SNDS shows some for Outlook. Beyond that, you infer reputation from your delivery metrics.

For transactional email, the biggest reputation risks are sending to invalid addresses (bounces), sharing IP space with senders who generate complaints, and sudden volume spikes that look like a compromised account.

Bounce handling

Bounces are the most direct signal to mailbox providers about your list quality. There are two types, and they require different handling.

Hard bounces (5xx SMTP errors: '550 User unknown,' '550 Domain not found') are permanent. The address doesn't exist and never will. Suppress it immediately, meaning add it to your suppression list and never attempt delivery to that address again. Continuing to send to hard-bounced addresses tells mailbox providers you don't maintain your list, which damages reputation.

Soft bounces (4xx SMTP errors: '452 Mailbox full,' '421 Try again later') are temporary. Most email providers retry soft bounces automatically with exponential backoff. If a soft bounce persists across multiple retry cycles (typically 24-72 hours), treat it as a hard bounce and suppress.

Target: keep your hard bounce rate under 2%. If it's consistently above that, something is wrong with how addresses enter your system. Common causes: no email verification at signup, accepting typo-ridden addresses without validation, or importing old user lists without cleaning them first.

Complaint handling

A complaint happens when a recipient clicks 'Report spam' or 'Mark as junk' in their email client. The mailbox provider sends a feedback loop (FBL) notification to your email provider, who passes it along as a webhook event.

Complaints are the most damaging signal for sender reputation. Gmail's threshold is 0.1%: if more than 1 in 1,000 recipients complain, your reputation starts taking hits. Other providers have similar thresholds.

For transactional email, complaints are rare because the messages are expected. When they do happen, it's usually because the user doesn't recognize the sender (use a clear, recognizable From name), the message arrived too late to be useful, or the content was confusingly similar to marketing.

When a complaint fires, suppress that address. Even if it was accidental, sending again to someone who complained risks another complaint. Your provider's suppression list handles this automatically; make sure your application respects it too.

Warming up a new domain or IP

A brand-new sending domain or IP address has no reputation. Mailbox providers are cautious with unknown senders, which means your first messages may face higher scrutiny, slower inbox placement, or temporary rate limiting.

Warmup is the process of gradually increasing sending volume from a new domain so mailbox providers can build a positive reputation profile. Start with your most engaged users (those most likely to open and interact with the message), send small batches, and ramp volume over 2-4 weeks.

A reasonable warmup ladder for a new transactional domain:

• Week 1: 50-200 emails/day, prioritizing email-verified users
• Week 2: 500-1,000 emails/day, expanding to all active users
• Week 3: 2,000-5,000 emails/day, approaching normal volume
• Week 4: full volume, monitoring metrics throughout

Warmup continued

Monitor bounce rate, complaint rate, and inbox placement at each stage. If any metric spikes, hold at the current volume until it stabilizes before ramping further.

For shared-IP sending (most providers, including Envello's default shared pool), warmup is less critical because the IP already has established reputation from other senders. Domain warmup still matters, but the ramp can be faster.

For dedicated IPs (available on Envello's Scale plan), warmup is essential. A dedicated IP starts cold, and sending high volume immediately from a cold IP is the fastest way to land in spam across all major mailbox providers.

Suppression lists

A suppression list is a per-account record of email addresses you should never send to again. It typically includes hard-bounced addresses, addresses that generated complaints, and addresses manually added (user unsubscribe requests, legal requests).

Your email provider maintains a suppression list and should automatically prevent sends to suppressed addresses (returning an error instead of accepting the message). Check that your provider does this, and check that your application handles the error gracefully: don't retry a suppressed send, surface the suppression reason to your support team.

Suppression lists should be append-mostly. Removing an address from suppression and attempting delivery again is risky: if the address bounced before, it'll probably bounce again, and the second bounce damages reputation more than the first because it shows you didn't learn from it.

Content and formatting factors

Content plays a smaller role in deliverability than authentication and reputation, but it's not zero.

Spam filters look for patterns in message content, headers, and structure. For transactional email, the main content-related risks are: HTML-only messages with no plain-text alternative (some filters flag this), a high image-to-text ratio, URL shorteners in links (which look like they're hiding the destination), and missing or suspicious List-Unsubscribe headers.

Best practices: always include a plain-text version alongside HTML, use your own domain for links (not shortened URLs), keep the message focused on the transaction (no promotional sidebars or 'you might also like' sections), and set the Subject to clearly describe the message content.

The From name matters more than most developers think. Use a recognizable name: 'Acme' or 'Acme Security' rather than '[email protected].' Recipients who don't recognize the sender are more likely to ignore, delete, or report the message.

Monitoring deliverability

You can't improve what you don't measure. Track these metrics continuously, not just when something breaks.

• Delivery rate: percentage of sends that result in a successful delivery (not just accepted by the provider, but confirmed delivered to the recipient's server). Target: above 98%.
• Bounce rate: percentage of sends that hard-bounce. Target: below 2%, ideally below 0.5%.
• Complaint rate: percentage of delivered messages that generate a spam complaint. Target: below 0.1%.
• Inbox placement: the percentage of delivered messages that land in the inbox vs. spam. This is harder to measure directly; tools like Google Postmaster Tools give partial visibility for Gmail.
• Send latency: time from API call to delivery confirmation. For transactional email, speed matters; a password reset that takes 5 minutes to arrive feels broken.

Monitoring continued

Set up alerts on bounce rate and complaint rate. A sudden spike in either usually means something broke: a bad user import, a code change that sends to the wrong audience, or an authentication record that was accidentally deleted.

Review Google Postmaster Tools weekly if you have significant Gmail volume. It shows domain reputation, spam rate, authentication pass rates, and delivery errors. Microsoft SNDS provides similar data for Outlook/Hotmail.

Your email provider's dashboard is the first place to look when diagnosing a delivery problem. Check the event timeline for the specific message: was it accepted? Delivered? Bounced? Delayed? The event log tells you where in the pipeline the problem occurred.

Common deliverability problems and fixes

Here are the issues you'll encounter most often, with concrete fixes.

• Messages landing in spam for Gmail users: check Google Postmaster Tools for reputation. Verify SPF, DKIM, and DMARC all pass (use the 'Show original' feature in Gmail to inspect headers). If reputation is 'Bad,' investigate recent bounce/complaint spikes.
• High bounce rate after a deployment: a code change probably introduced a bug in address handling, sending to test addresses, or breaking the email verification flow. Roll back the change, suppress the bounced addresses, and fix the bug.
• Sudden complaint spike: check whether a transactional message was accidentally sent to a marketing segment, or if a code change made a message look like marketing (added promotional content, changed the From name to something unrecognizable).
• Intermittent delivery delays: check your provider's status page. If the provider is healthy, check whether your sending volume spiked suddenly (which can trigger rate limiting from mailbox providers). Smoothing send volume with a queue helps.
• Authentication failures (SPF/DKIM/DMARC): run your domain through a checker tool. Common causes: DNS propagation lag after a record change, a deleted DKIM record, or an SPF record that exceeded the 10-lookup limit after adding a new service.

Dedicated IPs vs. shared pools

Most email providers default to a shared IP pool: your messages are sent from the same IPs as other customers. This means your reputation is partially tied to theirs, for better or worse.

A dedicated IP gives you your own sending IP, so your reputation is entirely your own. The trade-off: you need enough volume (typically 50,000+ emails/month) to maintain a warm IP, and you're responsible for warming it up from scratch.

For most transactional senders under 100,000 emails/month, a shared pool from a reputable provider is the better choice. The provider maintains the IP reputation across all senders, which means you benefit from their aggregate volume and reputation management. A dedicated IP at low volume can actually hurt deliverability because mailbox providers don't have enough data to build a confident reputation profile.

Consider a dedicated IP if you send 100,000+ emails/month, if you need to isolate your reputation from other senders on the pool, or if a customer's security requirements mandate a dedicated sending infrastructure.

Blocklist monitoring

Blocklists (sometimes called blacklists) are databases of IP addresses and domains identified as spam sources. If your sending IP or domain appears on a major blocklist (Spamhaus, Barracuda, SORBS), deliverability drops immediately.

For shared-IP sending, your provider monitors and manages blocklist status for the pool. For dedicated IPs, you're responsible. Check your IP against major blocklists regularly (MXToolbox is a common free tool), and act immediately if listed.

Getting delisted usually involves identifying and fixing the root cause (a spike in bounces or complaints, an open relay, a compromised account), then submitting a delisting request to the blocklist operator. Most operators have automated delisting forms; Spamhaus requires manual review for persistent issues.

Prevention is better than delisting: maintain clean sending practices, suppress bounces and complaints immediately, and monitor your metrics so problems don't escalate to a blocklist event.

Summary: the deliverability checklist

Deliverability isn't a one-time setup. It's an ongoing practice. Here's the checklist, in priority order.

• Authenticate your domain: SPF, DKIM, and DMARC all configured and passing. DMARC policy at p=reject once you've confirmed all legitimate sources pass.
• Handle bounces: hard bounces suppressed immediately, soft bounces retried then suppressed. Bounce rate under 2%.
• Handle complaints: complaints suppressed immediately. Complaint rate under 0.1%.
• Warm up new domains/IPs: gradual volume ramp over 2-4 weeks, monitoring metrics at each stage.
• Separate transactional from marketing: different domains, different IPs, ideally different providers.
• Monitor continuously: delivery rate, bounce rate, complaint rate, and send latency. Alerts on anomalies.
• Keep content focused: no promotional content in transactional messages, recognizable From name, plain-text version included.
• Use a reputable provider: one that handles suppression automatically, provides webhook events, and surfaces delivery metrics.