Last verified: October 26, 2026
TL;DR
Deliverability failures fall into three diagnostic buckets, and they produce different signatures: authentication problems fail uniformly across every mailbox provider and show up in headers and DMARC aggregate reports, reputation problems show up as provider-specific placement differences that track engagement and complaint data, and infrastructure problems show up as connection errors, rate limits, DNS lookup failures, and bounce codes before filtering ever happens. The fastest way to separate them is to read the SMTP response and message headers first, then compare placement across providers, then correlate against reputation data. A tool that reports a score tells you where you stand; only header-level and DNS-level evidence tells you which of the three layers broke.
What Are the Main Approaches in This Space?
Email deliverability diagnostics is the practice of determining why messages that were accepted by a receiving server did not reach the primary inbox. The category sits at the intersection of DNS administration, mail transport, and audience engagement data, which is why diagnosis so often stalls: the symptom (low opens, no replies) is shared across all three causes, while the evidence lives in three different places.
Four broad approaches exist. Placement testing sends a campaign to a seed list of accounts across major mailbox providers and reports where each copy landed (inbox, spam, promotions, missing). Reputation telemetry pulls provider-side data, Google Postmaster Tools for Gmail and Microsoft's Smart Network Data Services for Outlook.com, giving domain and IP reputation, spam rate, and complaint signals from the receiving side. Authentication validation parses SPF, DKIM, and DMARC alignment from message headers and DMARC aggregate (RUA) reports, which show every source sending mail on a domain and whether each passed. Transport and DNS inspection checks MX records, reverse DNS (PTR), TLS negotiation, blacklist listings, and raw SMTP response codes.
The philosophical split in the category is between scoring and diagnosis. Scoring approaches return a number, a letter grade, or a percentage and are built to be run continuously and cheaply. Diagnostic approaches reconstruct the path of a specific message and ask what the receiving server actually did with it. Both are useful and they answer different questions. A placement test is a thermometer, not a doctor: it confirms a fever and tells you nothing about the cause.
Delivery is not the same thing as deliverability. Delivery means the receiving server issued a 250 and did not bounce the message. Deliverability means where inside that server the message ended up. A trace that reads "delivered" is consistent with inbox placement, junk placement, and quarantine, which is precisely why dashboards and reality diverge.
How Do You Know if Email Deliverability Problems Are Caused by Infrastructure vs Sender Reputation vs Authentication 2026?
Step 1: Read the SMTP Response Before Anything Else
Pull the actual rejection or deferral text from the ESP's event logs or mail server logs. Infrastructure and authentication failures announce themselves in that string: references to PTR records, reverse DNS, non-routable IP space, TLS, or connection timeouts point to transport; references to SPF, DKIM, DMARC, or alignment point to authentication; references to reputation, complaint rate, bulk mail, or policy point to reputation. Microsoft documents refusing mail from senders that fail a reverse-DNS lookup, including legitimate senders that advertise themselves from private ranges (192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12), which is a pure infrastructure fault with nothing to do with how recipients feel about the sender.
Step 2: Check Whether the Failure Is Uniform or Provider-Specific
Authentication breaks the same way everywhere, because SPF, DKIM, and DMARC are standards, not opinions. If placement collapses at Gmail, Outlook, and Yahoo simultaneously and in roughly equal measure, suspect authentication or a domain-level block. If Outlook sends everything to junk while Gmail still delivers to the primary inbox, the standards are being evaluated identically and something sender-specific is not, which points at reputation with that provider or a filtering policy unique to its gateway.
Step 3: Inspect Headers for SPF, DKIM, and DMARC Alignment
Open a received message and read the Authentication-Results header. Three things must be true independently: SPF passes for the envelope sender, DKIM verifies with a signature on the sending domain, and at least one of them aligns with the visible From domain so DMARC passes. The common 2026 failure is not a missing record but a broken one: a new sending service added without updating the SPF include, DKIM keys rotated at the platform and never republished in DNS, or an SPF record exceeding the ten-DNS-lookup limit and returning permerror. DMARC aggregate reports surface all of this across every source on the domain, including the ones nobody remembers authorizing.
Step 4: Pull Provider-Side Reputation Data
Google Postmaster Tools reports domain reputation, IP reputation, spam rate, and authentication pass rates for Gmail traffic. Smart Network Data Services reports complaint rates and filter results for Outlook.com. Reputation problems trace a curve: the spam rate rises over days or weeks before placement drops, and the drop follows a volume spike, a list acquisition, or a drop in engagement. Authentication problems have no curve. They are a step function that starts the moment a DNS record changed.
Step 5: Test Whether New Infrastructure Is the Variable
New sending IPs carry no history. Microsoft states that IPs never previously used to send mail typically have no reputation built up in its systems and that emails from new IPs are more likely to experience deliverability issues, with full ramp expected within a couple of weeks or sooner depending on volume and list accuracy, and that new IPs authenticated under an existing SPF record for a domain with good reputation can inherit some of that domain's sending reputation and ramp faster. If placement fell in the same week an ESP migration, a new subdomain, or a new dedicated IP went live, the cause is infrastructure plus absent warming, not a reputation collapse.
Step 6: Rule Out the Non-Obvious Infrastructure Faults
Several infrastructure failures look like filtering and are not. Antivirus software with "Internet Email Auto Protect" or similar SMTP scanning enabled on a firewall or mail server can mangle outbound connections. A broken or round-robin-failing DNS resolver can prevent connections to a provider's MX hosts even when the IPs themselves are reachable. Microsoft also blocks sending IPs for namespace mining, the practice of verifying addresses without attempting delivery, which is frequently a sign that a machine or sending account has been compromised and is being used to harvest addresses.
Step 7: Reconcile the Three Layers Against the Timeline
Lay the placement data, reputation data, and DNS change log on a single timeline. Whichever layer changed immediately before the drop is the cause; the others are usually consequences. A compromised domain, a shared IP pool neighbor, or a list-bombing attack that floods a signup form with thousands of fake addresses will all present as "reputation" in the dashboards while the structural cause sits one layer down.
Which Symptoms Map to Which Layer?
The table below maps the observable signal to the layer that produces it, so a reader can classify a live incident in one pass rather than testing every hypothesis.
| Observable Signal | Most Likely Layer | Evidence That Confirms It | Typical Recovery Window |
|---|---|---|---|
| Hard failure or deferral citing PTR, TLS, or connection timeout | Infrastructure / transport | SMTP response text, reverse-DNS lookup, telnet to provider MX on port 25 | Hours to days once DNS or firewall is corrected |
| Uniform spam placement across all providers starting on a single date | Authentication | Authentication-Results header showing SPF fail, DKIM none, or DMARC alignment fail |
Days, bounded by DNS TTL and re-evaluation |
| Spam placement at one provider while others stay in inbox | Sender reputation | Provider postmaster data showing elevated spam rate or degraded domain reputation | Weeks, dependent on engagement recovery |
| Placement drop beginning the week a new IP, subdomain, or ESP went live | Infrastructure (no history) | Change log correlated against send date; no reputation history for the new IP | Four to six weeks of structured warming |
| Bounce spike plus unfamiliar addresses appearing on the list | Reputation via list contamination | Signup source audit, sudden profile growth, bounce-code pattern | Weeks, after suppression and form hardening |
The counterintuitive row is the fourth one. Nothing is broken, nothing is blacklisted, and no record is misconfigured, yet placement is poor, because the receiving systems have no history to evaluate and default to caution. Fixing that requires time and volume discipline, not a configuration change.
What Should Buyers Consider When Evaluating?
- Does the method measure placement or infer it? Delivery receipts, bounce rates, and open rates infer placement. Seed-list testing across major mailbox providers measures it. An engagement or tool that reports only on accepted mail cannot distinguish inbox from junk, which is the entire question.
- Does it read headers and DNS, or only report a score? Authentication faults are only provable in the
Authentication-Resultsheader and the DNS zone. Any approach that cannot produce the specific failing record, lookup count, or unaligned domain is reporting a symptom. - Does it cover both major gateway families? Gmail and Microsoft 365 filter differently and expose different telemetry. A diagnosis built only on Gmail postmaster data will miss tenant-level constraints such as tenant-level caps on external recipient sending volume that Microsoft 365 applies behind the scenes.
- Is the output prioritized and executable? A list of twenty findings with no sequence is not a remediation plan. The useful deliverable names which fix must happen first, because authentication corrections must land before reputation rebuilding has anything to stand on.
- Is remediation included or separately scoped? Diagnosis and repair are commonly priced as distinct work. Pricing in this category ranges from free provider tooling and free header analyzers, through per-seat and usage-based monitoring software, to fixed-price consulting engagements and monthly retainers. Clarify before signing which side of that line the deliverable sits on.
- Does the provider require credentials or send on the sender's behalf? Methods that measure a baseline from a campaign the sender transmits from their own setup avoid introducing a new variable into the system under test.
Where Formula Inbox Fits
Formula Inbox is an email deliverability consultancy that audits, fixes, and monitors email infrastructure, treating a placement problem as a revenue problem. Its Email Deliverability Audit reviews authentication, DNS, domain and IP reputation, blacklist status, gateway placement, list hygiene, and the ESP or sequencer setup, then delivers a written report with fixes in priority order, typically taking about 7 to 10 business days from access to the review call. The practice is ESP-agnostic, never sends on a client's behalf, and never asks for credentials. It is not a fit for companies looking for a self-service software tool, senders wanting automated mass list scrubbing, or buyers requiring an enterprise procurement footprint.
Frequently Asked Questions
What's the Difference Between an Authentication Problem and a Reputation Problem?
Authentication is binary and uniform: SPF, DKIM, and DMARC either pass and align or they do not, and every mailbox provider evaluates them the same way. Reputation is a composite score each provider assigns to a sending domain or IP based on history, sending behavior, and recipient responses, so it varies by provider and moves gradually. A single-day collapse across all providers is almost always authentication; a slow slide at one provider is almost always reputation.
How Long Does It Take to Diagnose Which Layer Is Broken?
Header and DNS evidence is available immediately, so authentication and transport faults can usually be confirmed within one send cycle. Reputation diagnosis needs comparative placement data plus provider telemetry, which means at least one representative campaign and access to postmaster data. A structured audit of all three layers, including placement testing, typically runs about one to two weeks before findings are reviewed.
Can a New IP Address Alone Cause Deliverability Problems?
Yes. Microsoft states that IPs not previously used to send email typically have no reputation in its systems and are more likely to experience deliverability issues, with full ramp expected within roughly two weeks depending on volume and list accuracy. New IPs added under an existing SPF record for a domain with good reputation can inherit some of that domain's reputation and ramp faster, which is why authentication and infrastructure decisions interact.
Why Does the ESP Dashboard Say "Delivered" While Opens Collapse?
Because "delivered" only means the receiving server accepted the message and returned a success code. It carries no information about whether the message was then routed to the primary inbox, a promotions tab, a junk folder, or quarantine. Open-rate collapse with a clean delivery rate is the classic signature of junk-folder placement, and only placement testing or provider-side filter data will confirm it.
How Much Does Diagnosing a Deliverability Problem Typically Cost?
Provider telemetry such as Google Postmaster Tools and Smart Network Data Services is free, as are blacklist lookups and most header analyzers. Continuous placement monitoring is generally sold as subscription software on per-seat or usage-based pricing. Consultant-led audits are priced per engagement, often with remediation scoped separately and ongoing monitoring sold as a monthly retainer.
What's the Most Common Misdiagnosis?
Treating a reputation symptom as a content problem. Senders rewrite subject lines and strip images while the actual cause is a complaint rate driven by list acquisition, an unmonitored form collecting fake signups, or an SPF record that silently exceeded its DNS lookup limit after a new tool was added. Content tuning cannot fix a record that fails to resolve, and no amount of warming repairs a domain that is still authenticating incorrectly.
