The Complete Email Deliverability Guide: Authentication, Reputation, and Inbox Placement

You sent 50,000 emails last month. Your ESP (Email Service Provider) reported a 98% delivery rate. The marketing team celebrated. But when someone finally checked inbox placement, only 64% of those messages actually landed where a human would see them. That is 18,000 emails that your recipients never read. Eighteen thousand chances to close a deal, onboard a customer, or prevent a support ticket, all gone.

That gap between "delivered" and "seen" is the deliverability problem. And it costs real money.

According to Validity's 2026 Email Deliverability Benchmark Report, the global average inbox placement rate sits at 83.5% [1]. Roughly 1 in 6 legitimate marketing emails never gets seen. For some industries, the numbers are worse. SaaS companies average 80.9% inbox placement. Asia-Pacific senders hover around 78%. If you are sending a million emails a month, even a small improvement in inbox placement can translate to thousands of additional conversions.

This guide covers everything that determines whether your emails reach the inbox: how the SMTP delivery pipeline actually works, the authentication protocols that prove your identity, the reputation signals providers use to judge you, the compliance rules that can get you blocked overnight, and the monitoring practices that keep it all running. Whether you are setting up email for the first time or diagnosing why your open rates dropped last Tuesday, this is the reference.

Table of Contents

1. The real cost of poor deliverability
2. How email delivery actually works under the hood
3. Email authentication: SPF, DKIM, and DMARC
4. Sender reputation and how providers judge you
5. Inbox placement vs delivery rate
6. Transactional vs marketing email: why separation matters
7. Bulk sender compliance: Google, Yahoo, and Microsoft
8. Content, engagement, and filtering
9. Platform-specific setup
10. Monitoring and ongoing maintenance
11. Troubleshooting common problems
12. Brand protection with BIMI
13. What comes next
14. References

---

The Real Cost of Poor Deliverability

Poor deliverability is not just an email problem. It is a business problem with a dollar amount attached.

Start with the direct revenue impact. If your email marketing generates $100,000 per month and your inbox placement drops from 85% to 70%, you just lost roughly $17,600 in expected revenue. That math is straightforward: fewer people see your emails, fewer people click, fewer people buy. Litmus's 2023 State of Email report found that email marketing returns an average of $36 for every $1 spent [6]. When deliverability suffers, that return drops proportionally.

Then there is the security cost. The FBI's Internet Crime Complaint Center (IC3) reported 193,407 phishing and spoofing complaints in 2024, with BEC (Business Email Compromise) schemes responsible for $2.77 billion in losses and total internet crime losses reaching $16.6 billion [4]. The APWG (Anti-Phishing Working Group) observed 3.8 million phishing attacks in 2025 alone [5]. If your domain lacks proper authentication, attackers can spoof it to send phishing emails to your customers, your employees, or anyone else. The reputational damage from a successful phishing attack using your domain is hard to quantify but easy to imagine.

There is also the support overhead. When legitimate emails land in spam, customers call support. "I never got my receipt." "Where is my password reset?" "I didn't receive my shipping confirmation." Each of those tickets costs money to resolve, typically $5 to $15 per interaction depending on your support model. A company sending 100,000 transactional emails per month with 10% going to spam could generate 2,000 to 5,000 support contacts monthly, just from delivery failures.

Finally, there is the compounding effect. Poor deliverability leads to lower engagement. Lower engagement signals to inbox providers that your emails are unwanted. That further damages your reputation, which pushes more email to spam, which lowers engagement further. It is a downward spiral, and the longer you wait to address it, the harder it is to reverse.

For a deeper look at these fundamentals, see our guide on what email deliverability is and why it matters and the broader sender reputation guide.

---

How Email Delivery Actually Works Under the Hood

Before diving into authentication and reputation, it helps to understand what happens mechanically when you hit "send." The process is more complex than most people realize, and understanding it makes troubleshooting much easier.

The SMTP Handshake

Every email travels via SMTP (Simple Mail Transfer Protocol), a protocol that dates back to 1982 (RFC 821, updated by RFC 5321) [10]. Here is what happens step by step:

1. MX lookup. Your sending server queries DNS for the recipient domain's MX (Mail Exchange) records. These records specify which servers accept mail for that domain and in what priority order. If MX records are missing or misconfigured, delivery fails immediately. See MX record troubleshooting for common problems.

2. TCP connection. Your server opens a TCP connection to the highest-priority MX server on port 25 (or 587 for submission). If the server supports STARTTLS, the connection is upgraded to TLS (Transport Layer Security) encryption. As of 2026, all major providers expect encrypted connections. Unencrypted SMTP is increasingly flagged or rejected. See TLS email encryption for details.

3. EHLO/HELO greeting. Your server identifies itself to the receiving server. This is where the conversation begins. The receiving server responds with a list of extensions it supports (like STARTTLS, SIZE limits, and 8BITMIME).

4. MAIL FROM (envelope sender). Your server declares the envelope sender address. This is not the same as the "From" header that the recipient sees in their email client. The envelope sender is used for bounce handling and is the address checked by SPF. The distinction between envelope From and header From is one of the most misunderstood aspects of email delivery, and it is central to how DMARC alignment works.

5. RCPT TO (recipient). Your server specifies who the email is for. The receiving server can accept or reject this at the connection level. A 550 response here means the address does not exist or is blocked by policy.

6. DATA transfer. The actual email content (headers, body, attachments) is transmitted. The receiving server accepts it into a queue for further processing.

7. Post-acceptance processing. After accepting the message, the receiving server runs its full battery of checks: SPF validation against the envelope sender, DKIM signature verification, DMARC policy evaluation, reputation lookups, content filtering, and engagement scoring. Based on all of these signals, it decides where to place the message: inbox, spam, quarantine, or a specific tab like Gmail's Promotions.

Envelope From vs Header From

This distinction trips up a lot of senders. The envelope From (also called the return-path or bounce address) is set during the SMTP MAIL FROM command. It is invisible to most recipients. SPF checks this address.

The header From is what appears in the recipient's email client. It is set inside the email headers and is what DMARC evaluates for alignment. DMARC requires that at least one of SPF or DKIM "aligns" with the domain in the header From.

When you use a third-party ESP, the envelope From is often a subdomain of the ESP (like bounce.esp-provider.com), while the header From is your domain (like yourcompany.com). This is why DKIM alignment becomes critical for DMARC to pass. SPF will pass for the ESP's domain, but it will not align with your header From domain unless you have set up a custom return-path. See DMARC alignment explained for the full picture.

Where Things Break

Understanding this flow reveals the common failure points:

• DNS is down or misconfigured. If MX records are missing, no mail gets through. If SPF or DKIM DNS records are wrong, authentication fails. See DNS propagation and email.
• TLS negotiation fails. If your server's certificate is expired or misconfigured, some receivers will downgrade to unencrypted or reject outright. MTA-STS prevents downgrade attacks.
• Envelope/header mismatch. If your ESP's envelope domain and your header From domain do not align, DMARC fails even when SPF and DKIM individually pass.
• Greylisting. Some servers temporarily reject first-time senders with a 4xx code, expecting legitimate servers to retry. Poorly configured sending systems that do not retry will lose these messages.

For a comprehensive authentication walkthrough, see the email authentication guide.

---

Email Authentication: SPF, DKIM, and DMARC

Authentication is the foundation. Without it, nothing else matters. As of 2026, every major inbox provider requires SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail), and DMARC (Domain-based Message Authentication, Reporting, and Conformance) for bulk senders. Miss any one of them and your emails will be rejected outright.

These three protocols are defined by IETF (Internet Engineering Task Force) standards: RFC 7208 for SPF [7], RFC 6376 for DKIM [8], and RFC 7489 for DMARC [9].

SPF: Who Can Send for You

SPF lets you publish a DNS TXT record that lists every server authorized to send email on behalf of your domain. When a receiving server gets an email claiming to be from your domain, it checks this record against the sending server's IP address. If the IP is not listed, the check fails.

The SPF check happens against the envelope sender domain (the MAIL FROM in the SMTP handshake), not the header From that recipients see. This is why SPF alone is not enough for domain protection. Someone can spoof your header From while passing SPF with a completely different envelope domain.

Common SPF problems:

• Too many DNS lookups. SPF allows a maximum of 10 DNS lookups. Every include: mechanism counts as one. Add enough third-party senders (your CRM, your marketing platform, your transactional email service) and you will hit the limit. When you do, the entire SPF record becomes invalid, and every SPF check returns a "permerror" result. See our guide on fixing the 10-lookup limit.
• Multiple SPF records. A domain can only have one SPF record. Two or more and both are invalid per the RFC [7]. This happens more often than you would think, usually when someone adds a new record instead of updating the existing one. More on this in SPF multiple records.
• Softfail vs hardfail confusion. The difference between ~all (softfail) and -all (hardfail) matters for how receivers handle unauthorized senders. Our breakdown of softfail vs hardfail explains when to use each.
• Record too long. DNS TXT records have a 255-character string limit (though multiple strings can be concatenated). Extremely long SPF records can cause truncation or lookup failures in some resolvers. See SPF record too long.

You can check your SPF record at SPF Record Check to verify your setup.

For a comprehensive look at SPF configuration, including the include mechanism and flattening, see:

• SPF Include Mechanism Explained
• SPF Fail Explained

DKIM: Proving Your Email Was Not Tampered With

DKIM works differently from SPF. Instead of checking who sent the email, it checks whether the email was altered after it was sent. Your mail server signs each outgoing message with a private key, creating a cryptographic signature that covers specific headers and the body. The receiving server retrieves the matching public key from your DNS records and verifies the signature.

If the signature matches, the email is authentic and unmodified. If it does not, someone (or something) changed the message in transit, or the keys are misconfigured.

DKIM is especially important for third-party sending. Because the signature is tied to your domain (via the d= tag in the DKIM header), it provides domain-level authentication that can align with your header From for DMARC purposes, even when the envelope sender is a different domain.

DKIM problems to watch for:

• Missing or expired keys. If your DKIM public key is not published in DNS or has been removed, every DKIM check fails. This is common during DNS migrations or when changing email providers. See the monitoring section below for how to catch this before it damages your reputation.
• Key length. Older 512-bit and 1024-bit keys are increasingly considered weak. Most providers now recommend 2048-bit keys. See DKIM key length best practices.
• Selector mismatches. DKIM uses selectors to identify which key pair to use. If your email is signed with selector s1 but your DNS only has a record for google, the check fails. This is a common misconfiguration when migrating between providers.
• Key rotation failures. DKIM keys should be rotated periodically (every 6 to 12 months is a common recommendation). If the rotation process breaks, old keys may be removed before new keys are fully propagated. See DKIM key rotation.

Test your DKIM at DKIM Test to verify signatures are working. For troubleshooting, see DKIM errors and how to fix them.

DMARC: Tying It All Together

DMARC builds on top of SPF and DKIM. It does two things:

1. Tells receiving servers what to do when SPF or DKIM checks fail (reject the email, quarantine it, or do nothing)
2. Sends you reports about who is sending email using your domain, including unauthorized senders

DMARC adds a critical concept: alignment. It is not enough for SPF or DKIM to pass. The domain that passes SPF or DKIM must match (or be a subdomain of) the domain in the header From field. This prevents attackers from passing SPF with their own domain while spoofing yours in the visible From header. See DMARC alignment explained for the details.

DMARC policies come in three levels:

• p=none means "monitor only, do not take action." This is where you start, but it offers no protection. See DMARC p=none explained.
• p=quarantine means "send failing emails to spam." This is the first real enforcement step.
• p=reject means "block failing emails entirely." This is full protection.

As of early 2026, 71% of domains worldwide still have no effective DMARC protection, according to DmarcDkim.com's analysis of 859,048 domains [2]. Only 10.7% have full protection with a p=reject policy at 100% enforcement. The gap is closing, but slowly. Fortune 500 adoption is much higher, with 475 out of 500 companies now publishing DMARC records and over 80% at enforcement-level policies [3].

Check your DMARC policy at DMARC Record Checker.

For more on DMARC:

• DMARC Aggregate Reports Explained covers reading and acting on your reports
• DMARC Forensic Reports covers detailed failure reports
• DMARC Fail covers diagnosing alignment and policy failures

How the Three Protocols Work Together

SPF, DKIM, and DMARC are not alternatives to each other. They are layers. SPF verifies the sending server. DKIM verifies the message integrity. DMARC enforces the policy when either check fails and ensures both are aligned with the domain in the From header.

Here is a practical example. You use SendGrid to send marketing emails from yourcompany.com:

1. SPF: Your SPF record includes include:sendgrid.net. When SendGrid's servers send your email, SPF passes. But the envelope sender is something like bounces.sendgrid.net, so SPF does not align with your header From domain.
2. DKIM: You have configured SendGrid to sign emails with your domain's DKIM key (selector s1._domainkey.yourcompany.com). DKIM passes and aligns with yourcompany.com.
3. DMARC: The receiving server checks DMARC. SPF passed but did not align. DKIM passed and aligned. DMARC passes because at least one protocol both passed and aligned.

If you had not configured DKIM with your own domain, DMARC would fail even though both SPF and DKIM individually passed. Alignment is the key.

For a side-by-side comparison, see SPF vs DKIM vs DMARC: what is the difference and why you need all three.

Beyond the Core Three

Several additional protocols strengthen email security:

• MTA-STS (Mail Transfer Agent Strict Transport Security) forces encrypted connections between mail servers, preventing downgrade attacks. See MTA-STS explained.
• TLS encryption is now expected by all major providers. Unencrypted connections are increasingly flagged. See TLS email encryption.
• PTR (Pointer) records map your sending IP back to a domain name. Missing PTR records are a red flag for spam filters. See why reverse DNS matters.
• ARC (Authenticated Received Chain) preserves authentication results when emails are forwarded through mailing lists or intermediaries. This matters because email forwarding breaks SPF, and ARC is the fix.

---

Sender Reputation and How Providers Judge You

Authentication proves you are who you say you are. Reputation determines whether providers trust you.

Every domain and IP address that sends email has a reputation, and it is judged by every major provider independently. Gmail's view of your reputation may differ from Outlook's. Neither shares their scoring system publicly, but the signals they watch are well documented. For the full deep dive, see the sender reputation guide.

What Builds (and Destroys) Reputation

Spam complaint rate is the single most important metric. Google recommends keeping it below 0.1% and requires it under 0.3% [11]. Microsoft and Yahoo enforce similar thresholds. One bad campaign to an old list can spike your complaint rate and tank your reputation for weeks. The math is unforgiving: sending to a 50,000-person list where even 200 people hit "Report Spam" puts you at 0.4%, above Google's hard limit. See email complaint rate for how to track and manage this.

Bounce rate signals list quality. High bounce rates mean you are sending to invalid addresses, which suggests poor list hygiene or purchased lists. A bounce rate above 2% is a warning sign. Above 5% and you are in dangerous territory. See email bounce rates and hard bounce vs soft bounce for the details.

Engagement patterns matter more than ever. Providers track whether recipients open, click, reply to, or forward your emails. Low engagement tells the provider that your recipients do not value your messages. High engagement does the opposite. See how engagement affects deliverability.

Volume consistency is a signal. Sending 500 emails a day for six months and then suddenly sending 50,000 looks like a compromised account or a spammer. Ramp gradually. See email warmup and how to warm up a new domain.

Blacklist status is a binary signal with outsized impact. If your domain or IP appears on a major blacklist like Spamhaus, Barracuda, or SORBS, entire swaths of the internet may reject your email. Some blacklists are referenced by thousands of mail servers. Getting listed on Spamhaus SBL, for example, can immediately block your email at companies that rely on Spamhaus for filtering, which includes many enterprise mail gateways. Check your blacklist status and see our blacklist removal guide if you are listed.

Domain Reputation vs IP Reputation

Both matter, but domain reputation has become the primary signal over the past several years. Here is why.

Shared IP addresses are common. Most ESPs send email from pools of shared IPs. Your IP reputation on a shared pool is partly determined by the behavior of other senders on the same pool. You could do everything right and still suffer because another sender on your shared IP blasted a purchased list.

Dedicated IPs give you full control over your IP reputation, but they require enough volume to establish that reputation. If you send fewer than 50,000 emails per month, a dedicated IP may actually hurt you because there is not enough data for providers to build a positive reputation profile.

Domain reputation, by contrast, is entirely under your control regardless of your IP setup. Google has explicitly stated that domain reputation is weighted more heavily than IP reputation in their filtering decisions [11]. This is why proper DKIM configuration (which ties messages to your domain) is so critical.

See our comparison of dedicated vs shared IP and our deep dive on IP reputation.

Checking Your Reputation

You cannot see a single "reputation score" because each provider calculates their own. But you can use available tools:

• Google Postmaster Tools shows your domain and IP reputation for Gmail on a four-tier scale: Bad, Low, Medium, High. See our Postmaster Tools guide.
• Microsoft SNDS (Smart Network Data Services) provides data for Outlook and Hotmail, including complaint rates and trap hits.
• Sender Score by Validity provides a 0-100 score based on sending behavior. See Sender Score explained.
• Feedback loops from major providers tell you when recipients mark your email as spam. See email feedback loops.

For a broader overview, see email sender reputation and how to check your domain reputation.

---

Inbox Placement vs Delivery Rate

Your ESP says 98% of emails were delivered. That sounds great. But "delivered" only means the receiving server accepted the message. It says nothing about where the message ended up.

Inbox placement is the metric that actually matters. It measures what percentage of accepted emails land in the primary inbox rather than spam, junk, quarantine, or a tabbed category like Promotions.

The Math That Matters

Let's walk through a concrete example to see why the distinction is so important.

You send 100,000 emails. Your ESP reports:

• 2,000 bounced (2% bounce rate)
• 98,000 "delivered" (98% delivery rate)

That 98% looks great in a dashboard. But here is what actually happened to those 98,000 "delivered" messages:

• 68,600 landed in the primary inbox (70% inbox placement)
• 14,700 went to the Promotions or Other tab (15%)
• 12,740 went to spam (13%)
• 1,960 were silently dropped or quarantined (2%)

Your real reach is 68,600 people, not 98,000. If your average email drives $0.50 in revenue, the difference between 98% delivery and 70% inbox placement is $14,700 in lost revenue per send.

Validity's 2026 benchmark data shows a global deliverability health score of 88/100 but an actual inbox placement rate of only 83.5% [1]. In practice, many senders see a much wider gap, especially those with authentication problems or reputation issues.

Why Tabs Matter Too

Gmail's tabbed inbox (Primary, Social, Promotions, Updates) adds another layer of complexity. An email that lands in the Promotions tab is technically in the inbox, not in spam. But engagement rates for Promotions tab emails are significantly lower than Primary tab emails. Some studies show open rates 50-70% lower in the Promotions tab compared to Primary.

Whether you count Promotions tab placement as "inbox placement" depends on your definition. For marketing emails, landing in Promotions is the expected behavior and is not necessarily a problem. For transactional emails (receipts, password resets, shipping confirmations), ending up in Promotions is a real issue.

See inbox placement for how to measure it and email deliverability metrics for which numbers actually tell you something useful.

---

Transactional vs Marketing Email: Why Separation Matters

One of the most impactful things you can do for deliverability is separate your transactional and marketing email streams. This means using different subdomains (and ideally different IPs) for each type.

Why Separate?

Transactional emails (order confirmations, password resets, account notifications) have naturally high engagement. People expect them and open them quickly. Marketing emails (newsletters, promotions, product announcements) have naturally lower engagement. Some percentage of recipients will ignore them, and some will mark them as spam.

When both types share the same sending domain and IP, the lower engagement of your marketing emails drags down the reputation of your transactional emails. A bad marketing campaign that spikes your complaint rate can suddenly cause password reset emails to land in spam. That is a much bigger problem than a promotional offer going unseen.

How to Separate

The standard approach is subdomain isolation:

• Transactional: mail.yourcompany.com or notify.yourcompany.com
• Marketing: news.yourcompany.com or marketing.yourcompany.com
• Corporate: yourcompany.com (for person-to-person business email)

Each subdomain gets its own SPF record, DKIM keys, and DMARC policy. Each builds its own reputation independently. If your marketing subdomain takes a reputation hit, your transactional subdomain is insulated.

For detailed implementation guidance, see transactional vs marketing email and subdomain email strategy.

A Real-World Scenario

Consider an e-commerce company sending from a single domain. Their Black Friday campaign goes to their entire list, including 18-month inactive subscribers. Complaints spike to 0.5%. Gmail downgrades their domain reputation from High to Low.

Now their order confirmation emails go to spam. Customers do not get shipping notifications. Support tickets surge. Revenue from abandoned-cart emails drops to near zero. All because a marketing decision polluted the shared sending reputation.

With subdomain separation, the Black Friday campaign damages marketing.store.com but orders.store.com continues delivering to the inbox. The blast radius is contained.

This is not a theoretical concern. It is one of the most common deliverability disasters we see, and one of the easiest to prevent. See the email platform setup guide for how to configure this across major ESPs.

---

Bulk Sender Compliance: Google, Yahoo, and Microsoft

The single biggest shift in email deliverability in recent years happened on February 1, 2024, when Google and Yahoo began enforcing authentication requirements for bulk senders (anyone sending more than 5,000 emails per day to their domains) [11].

Microsoft followed on May 5, 2025, applying similar requirements to Outlook.com, Hotmail.com, and Live.com [12].

As of 2026, these requirements are industry standard. Non-compliant email is rejected outright with permanent 5xx errors. There is no grace period left.

The Requirements

All three providers require:

1. SPF authentication with accurate authorized IP addresses
2. DKIM signing for message integrity
3. DMARC published at minimum p=none, aligned with SPF or DKIM (preferably both)
4. One-click unsubscribe via the List-Unsubscribe-Post header for marketing email
5. Spam complaint rate under 0.3% (Google recommends under 0.1%)
6. Valid From and Reply-To addresses that can receive mail
7. TLS encryption for message transmission

The Enforcement Timeline

• Feb 2024: Google and Yahoo begin enforcement. Soft warnings and spam folder placement for non-compliant messages.
• Apr 2024: Google and Yahoo begin rejecting a percentage of non-compliant traffic.
• Jun 2024: One-click unsubscribe requirement takes effect.
• May 2025: Microsoft begins rejecting non-compliant bulk mail (550 5.7.515 errors).
• Nov 2025: Google escalates to permanent rejections for all non-compliant mail.
• 2026: Full enforcement across all three providers. No exceptions.

For the full requirements breakdown, see Google and Yahoo bulk sender rules, Yahoo and AOL sender requirements, and the bulk sender compliance guide.

---

Content, Engagement, and Filtering

Authentication and reputation get you past the gate. Content and engagement determine whether you stay in the inbox.

How Spam Filters Evaluate Content

Modern spam filters are far more sophisticated than keyword matching. They use machine learning models trained on billions of messages. They evaluate:

• Message structure: HTML quality, image-to-text ratio, header formatting. An email that is a single large image with no text is a classic spam pattern.
• Link reputation: Where your links point and whether those destinations have been flagged. Using URL shorteners (like bit.ly) in email can hurt you because spammers use them to obscure malicious destinations.
• Personalization signals: Generic "Dear Customer" vs actual personalization. Providers can detect merge-tag personalization vs real customization.
• Unsubscribe experience: Is the unsubscribe link functional, easy to find, and honored promptly? The List-Unsubscribe and List-Unsubscribe-Post headers are now required for bulk senders.

That said, obvious spam patterns still matter. ALL CAPS subject lines, excessive exclamation marks, and misleading preview text will hurt you. See email content spam triggers for what to avoid and how spam filters work for the technical details.

Why Engagement Keeps Getting More Important

ISPs (Internet Service Providers) now layer behavioral data on top of technical checks. Gmail, for example, weighs:

• Opens (tracked via pixel, less reliable since Apple MPP, but still tracked for non-Apple clients)
• Clicks and replies (strong positive signals, especially replies)
• Moving email from spam to inbox (a very strong positive signal that trains the filter)
• Moving email from inbox to spam (a strong negative signal, equivalent to a complaint)
• Time spent reading (Gmail can track how long a message is viewed)
• Deletion without reading (a mild negative signal at scale)

Perfect authentication with poor engagement still gets you filtered. This is why some senders with impeccable DNS records still end up in spam.

Apple Mail Privacy Protection and Open Tracking

Apple introduced MPP (Mail Privacy Protection) in iOS 15 (September 2021) [13], and by 2026 it is widely adopted across Apple Mail on iOS, iPadOS, and macOS. MPP pre-fetches email content (including tracking pixels) through proxy servers, regardless of whether the recipient actually opens the email. The result: open rates for Apple Mail users are artificially inflated to near 100%.

What this means for you:

• Open rates are unreliable as a primary metric. If 40-60% of your audience uses Apple Mail, your open rate is significantly inflated. You cannot trust it as a signal of actual engagement.
• Click rates become the primary engagement metric. Clicks require deliberate action and are not affected by MPP.
• Reply rates are gold. A reply is the strongest engagement signal available. Emails that generate replies see significant deliverability benefits.
• Inbox providers still track opens for non-Apple users. Gmail on Android, Outlook on Windows, and webmail users are still tracked normally. So opens still matter for placement decisions, they are just less useful for your own analytics.

The Gmail Promotions Tab

Gmail sorts emails into tabs: Primary, Social, Promotions, Updates, and Forums. Marketing email overwhelmingly lands in Promotions. This is not a spam problem. It is expected behavior for bulk email. But it does significantly impact visibility.

Factors that influence tab placement include:

• Sender category. Known marketing platforms and email addresses trigger Promotions tab placement.
• Content patterns. Heavy HTML formatting, multiple images, promotional language, and unsubscribe links all signal "promotion."
• Recipient behavior. If a user manually moves your email from Promotions to Primary, Gmail learns to deliver future messages to Primary for that user.

You cannot fully control tab placement, and trying to "trick" Gmail by stripping HTML or removing unsubscribe links will hurt your deliverability far more than the Promotions tab ever will. The better approach: send email that people actually want, so they engage with it regardless of which tab it lands in.

The Practical Implication

Send relevant email to people who want it. Remove disengaged subscribers before they become complaint risks. Focus on metrics you can trust (clicks, replies, conversions) rather than metrics that are increasingly unreliable (opens). See email list hygiene for how to clean your list without losing good subscribers.

---

Platform-Specific Setup

Different email platforms handle authentication differently. Each has its own process for setting up SPF, DKIM, and DMARC, and each has its own quirks that can cause deliverability issues.

We have dedicated setup guides for each major platform:

• Google Workspace
• HubSpot
• Salesforce
• Klaviyo
• Mailchimp
• SendGrid
• Brevo (formerly Sendinblue)
• ActiveCampaign
• Amazon SES
• WordPress
• Shopify
• Zoho Mail

If you are managing deliverability across multiple ESPs simultaneously, see managing deliverability across multiple ESPs. For the full walkthrough of platform setup, see the email platform setup guide.

---

Monitoring and Ongoing Maintenance

Setting up authentication once is not enough. DNS records change. Providers update their requirements. Team members make well-meaning changes that break things. A configuration that was perfect six months ago may be broken today without anyone noticing.

What to Monitor

• SPF record validity including lookup count (must stay under 10)
• DKIM key availability and signature verification across all selectors
• DMARC policy status and alignment rates from aggregate reports
• MX record health for inbound mail routing
• Blacklist status across major blacklists (Spamhaus, Barracuda, SORBS, and others)
• DMARC aggregate reports for unauthorized senders using your domain
• Bounce rates and complaint rates trending over time
• Inbox placement rates (not just delivery rates)

Real Failure Scenarios

The difference between "deliverability is fine" and "deliverability is broken" can be a single DNS record change. Here are failure scenarios we see regularly:

DNS migration breaks DKIM. Your company migrates DNS providers (say, from GoDaddy to Cloudflare). The migration tool copies A records, MX records, and your SPF TXT record. But it misses the DKIM CNAME records because they are on a subdomain (like s1._domainkey.yourcompany.com). Everything looks fine for a day or two because DKIM failures take time to impact reputation. By the time someone notices open rates dropping, your domain reputation has already been downgraded. The fix takes five minutes (re-add the CNAME records), but recovering the reputation takes weeks.

Someone adds a second SPF record. A new team member needs to set up a marketing tool. The tool's documentation says "add this SPF record to your DNS." So they add a new TXT record instead of updating the existing one. Now you have two SPF records, which makes both invalid per RFC 7208 [7]. Every SPF check returns "permerror." If your DMARC policy relies on SPF alignment, your DMARC pass rate drops to whatever DKIM alone provides. If DKIM is not perfectly configured either, emails start going to spam. See SPF multiple records.

Blacklist from a shared IP. You are on a shared sending IP through your ESP. Another sender on the same IP blasts a purchased list and gets the IP added to Spamhaus SBL. Your deliverability craters even though you did nothing wrong. You might not even notice for days if you are not monitoring blacklist status. Check your blacklist status regularly.

DKIM key rotation gone wrong. Your security team rotates DKIM keys quarterly (good practice). During the rotation, they publish the new public key and update the signing configuration to use the new private key. But DNS propagation takes time. For a window of 30 minutes to several hours, some receiving servers see the old public key while emails are signed with the new private key. DKIM fails for those messages. The solution is to publish the new key 24-48 hours before switching the signing configuration, then remove the old key 24-48 hours after. See DKIM key rotation.

ESP configuration change. Your ESP updates their sending infrastructure and changes the IP ranges they use. Your SPF record still includes their old SPF mechanism, which covers the old IPs. Emails from the new IPs fail SPF. Most ESPs handle this transparently through their include mechanism, but not all do, and custom SPF configurations are especially vulnerable.

Why Continuous Monitoring Matters

These problems are invisible until someone complains, or until you notice your open rates have been declining for weeks. By then, the reputation damage may already be done. A proactive monitoring setup catches these issues within hours, not weeks.

See why set-and-forget authentication is a myth and our 30-minute deliverability audit checklist for a quick health check.

---

Troubleshooting Common Problems

When deliverability breaks, the symptoms are usually vague: declining open rates, missing replies, customer complaints about not receiving emails. Here is where to start diagnosing. For the complete troubleshooting framework, see the email troubleshooting guide.

Emails Going to Spam

The most common deliverability problem. Start with authentication, then check reputation, then look at content and engagement. See why emails go to spam for a systematic walkthrough.

Provider-specific guides:

• Gmail spam issues
• Outlook junk folder issues
• Apple iCloud Mail deliverability

Bounces and Rejections

Not all bounces are the same. A 550 permanent error means the address does not exist or your email was rejected by policy. A 421 temporary error means "try again later." Understanding the difference saves time and prevents you from removing valid addresses from your list. See email bounce codes explained and hard bounce vs soft bounce.

If you are seeing the specific error 554 5.7.5 permanent error evaluating DMARC policy, see our 554 DMARC error guide.

Authentication Failures

When SPF, DKIM, or DMARC fail, the fix depends on which protocol failed and why. See email authentication failed for a decision tree that covers all three protocols, or our guides on specific failures:

• SPF fail
• DKIM fail
• DMARC fail

Sudden Deliverability Drops

If your deliverability dropped suddenly, check these in order:

1. DNS changes: Did anyone modify your DNS records recently? Even a well-intentioned change can break authentication. See DNS propagation and email.
2. Blacklists: Have you been added to a blacklist? Check here.
3. Volume spikes: Did you significantly increase your sending volume? Sudden increases look suspicious to inbox providers. See email throttling explained.
4. List quality: Did you email an old or purchased list? Re-engagement campaigns to dormant subscribers are a common trigger.
5. Provider policy changes: Did a provider update their enforcement? Check our email deliverability news.
6. ESP infrastructure changes: Did your ESP change IPs or sending configurations? Check with their support team.

See common email deliverability issues for a broader diagnostic framework.

---

Brand Protection with BIMI

BIMI (Brand Indicators for Message Identification) lets you display your brand logo next to your emails in supporting inboxes. It is not just about branding. BIMI requires DMARC enforcement at p=quarantine or p=reject, which means it is also a signal of strong authentication and a reward for doing deliverability right.

As of 2026, BIMI has 72% email client support, but adoption remains low: only 8% of domains have a BIMI DNS record and less than 1% have a VMC (Verified Mark Certificate), according to industry data. The main barrier is cost. VMCs run $1,500 or more per year from certificate authorities like DigiCert and Entrust.

Gmail and Yahoo have the most consistent BIMI support. Microsoft support is more limited.

See what is BIMI for the full overview, BIMI setup guide for implementation, and VMC certificates for the certification process.

---

What Comes Next

Email deliverability is not a set-it-and-forget-it problem. The landscape is shifting, and the senders who keep their emails in the inbox are the ones who treat deliverability as an ongoing practice. Here is what is on the horizon.

DMARCbis: The Next DMARC Standard

The IETF DMARC working group has been developing DMARCbis, an updated DMARC specification that will be published as a Proposed Standard (replacing the current Informational RFC 7489). The key changes:

• The pct tag is being removed. Currently, pct=50 means "apply the DMARC policy to 50% of failing messages." DMARCbis replaces this with a binary t=y testing flag. You are either in testing mode or you are not. No more partial enforcement.
• Tree walk for organizational domains. DMARCbis changes how the "organizational domain" is determined, moving away from reliance on the Public Suffix List and toward a DNS-based tree walk. This affects how subdomain policies are inherited.
• Clarified subdomain policy handling. The sp= tag behavior is being refined, with clearer rules for how subdomains inherit or override the parent domain's policy.

Records will still use v=DMARC1, so existing records will not break. But senders using pct= for gradual rollout will need to adjust their approach.

AI-Generated Phishing and Authentication's Growing Importance

The rise of large language models has made phishing emails dramatically more convincing. The awkward grammar and obvious translation errors that used to be telltale signs of phishing are disappearing. AI can generate polished, personalized phishing emails at scale, in any language.

This makes domain authentication more important than ever. When the content of a phishing email is indistinguishable from a legitimate message, authentication (specifically DMARC at p=reject) becomes the primary defense. If your domain is properly protected, attackers cannot send email that passes authentication checks for your domain. They can still send phishing emails pretending to be from your company using a lookalike domain, but they cannot spoof your actual domain.

Organizations that are still at p=none are leaving the door open. The combination of AI-generated content and unprotected domains is a potent threat.

Engagement Weighting and the Future of Filtering

Inbox providers are increasingly moving toward engagement-weighted filtering. The direction is clear: technical authentication becomes table stakes (you need it just to get in the door), and engagement signals become the primary determinant of inbox vs spam placement.

Google has been moving in this direction for years, and other providers are following. Some specific trends:

• Reply-based signals are gaining weight. Emails that generate replies are strongly rewarded. This favors conversational marketing approaches over broadcast-only campaigns.
• Read time is becoming a factor. How long someone spends viewing your email signals relevance. Short view times at scale suggest low-quality content.
• Cross-channel signals may emerge. There is speculation that providers could incorporate signals from other products (like whether a user visits your website after receiving an email) into filtering decisions. Google is uniquely positioned for this given their ownership of both Gmail and Chrome.

The practical takeaway: deliverability will increasingly reward senders who send email people genuinely want to receive and penalize those who optimize for volume over relevance. List quality, segmentation, and content relevance will matter more, not less.

For the latest developments, see our email deliverability news and 2027 deliverability trends.

What You Should Do Today

The most important things you can do right now:

1. Check your authentication. Use our free deliverability checker to test your SPF, DKIM, DMARC, BIMI, MX records, and blacklist status in one lookup.
2. Move beyond p=none. If your DMARC policy is still at p=none, you are getting reports but no protection. Start planning your path to enforcement.
3. Separate your mail streams. If transactional and marketing email share a domain, set up subdomain isolation before a bad campaign takes down your order confirmations.
4. Monitor continuously. DNS records break. Blacklists update. Configurations drift. Catch problems when they happen, not when your recipients tell you (or worse, when they stop telling you).
5. Clean your list. Remove hard bounces immediately, suppress chronic non-openers after a re-engagement attempt, and never, ever buy a list.

---

References

1. Validity, "2026 Email Deliverability Benchmark Report." Global inbox placement rate of 83.5%, deliverability health score of 88/100.
2. DmarcDkim.com, "DMARC Adoption Statistics 2026." Analysis of 859,048 domains: 71% with no effective DMARC protection, 10.7% at p=reject.
3. EasyDMARC, "2026 DMARC Adoption & Enforcement Report." Fortune 500 DMARC adoption at 475/500, with 80%+ at enforcement-level policies.
4. FBI IC3, "2024 Internet Crime Report." 193,407 phishing/spoofing complaints; $2.77 billion in BEC losses; $16.6 billion total internet crime losses.
5. APWG (Anti-Phishing Working Group), "Phishing Activity Trends Report 2025." 3.8 million phishing attacks observed in 2025.
6. Litmus, "State of Email 2023." Email marketing ROI of $36 for every $1 spent.
7. IETF RFC 7208, "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email."
8. IETF RFC 6376, "DomainKeys Identified Mail (DKIM) Signatures."
9. IETF RFC 7489, "Domain-based Message Authentication, Reporting, and Conformance (DMARC)."
10. IETF RFC 5321, "Simple Mail Transfer Protocol." Updated SMTP specification.
11. Google, "Email Sender Guidelines." Requirements for bulk senders to Gmail.
12. Microsoft Tech Community, "Strengthening Email Ecosystem: Outlook's New Requirements for High-Volume Senders." May 2025 enforcement announcement.
13. Apple, "Mail Privacy Protection." iOS 15 feature that pre-fetches email content through proxy servers.