Gmail/Outlook delivery issues: the checks that matter in 2025

October 25, 2025 • February 3, 2026 • Read: 20 min • Views: 11

Was this helpful?

You shipped a perfectly reasonable email. The customer never saw it. Support swears it “must be Gmail,” sales swears it “must be Outlook,” and your CEO is forwarding screenshots of an empty inbox like it’s a forensic artifact.

In 2025, deliverability is less about “did my SMTP server speak the protocol” and more about “did I prove—cryptographically, reputationally, and operationally—that I deserve to be in the inbox.” This guide sticks to the checks that change outcomes: what to look at first, what’s noise, and what fixes actually survive the next campaign.

Fast diagnosis playbook (first 15 minutes)

When Gmail or Outlook delivery “suddenly” breaks, there’s a temptation to panic-tune everything at once. Don’t. You need to find the bottleneck: authentication, reputation, content, or transport.

0. Establish the failure mode (2 minutes)

Bounce: you got an NDR/DSN back. Good. It contains clues.
Deferral: 4xx responses; mail sits in queue and “eventually” may deliver.
Spam: delivered but junked; this is often policy + reputation.
Silent missing: sent system says “delivered,” recipient can’t find it. Could be spam/quarantine, transport rejections, or internal routing rules.

1. Check authentication alignment first (5 minutes)

In 2025, SPF or DKIM passing is not enough. Alignment with the visible From domain matters, especially for Gmail and Microsoft.

Grab a real message and inspect Authentication-Results.
Confirm DKIM=pass with your domain (or aligned subdomain).
Confirm SPF=pass and that the SPF domain aligns with From (or DMARC relaxed alignment covers it).
Check DMARC=pass. If DMARC fails, everything else is a coin flip.

2. Then check reputation signals (4 minutes)

Sudden spike in bounces, complaints, or unknown users? That’s reputation death by spreadsheet.
New sending IP or changed provider? Warm-up matters. Yes, even if you “only send receipts.”
Are you on a blocklist? You don’t need a PhD—just check the SMTP logs for RBL-style rejections.

3. Only then check transport (4 minutes)

Are you failing TLS negotiation, MTA-STS policy checks, or getting rate-limited?
Is your queue growing and retries backing off?
Are your outbound connections coming from the IP you think they are?

If you do these three in order, you avoid the classic incident where everyone argues about content while your DKIM selector is missing from DNS.

How delivery fails in 2025 (and why it feels random)

Gmail and Microsoft aren’t evaluating your email like a human. They’re scoring it like a production risk. Authentication is table stakes, but their systems also model sender history, recipient behavior, and patterns that look like abuse—even if you’re “just sending invoices.”

The modern inbox is policy-driven

Gmail’s bulk sender requirements (and Microsoft’s increasingly strict filtering) pushed the industry toward a baseline: authenticated mail, sane list hygiene, complaint management, and consistent infrastructure. That’s not “marketing stuff.” It’s operational hygiene. Your mail system is an API, and the inbox providers are the most opinionated API gateway you’ll ever integrate with.

Four buckets of failure

Authentication: SPF/DKIM/DMARC misconfigured, broken by DNS, or broken by forwarding/rewriting.
Reputation: new IP/domain, spam complaints, high unknown users, compromised accounts, or bursty patterns.
Content and formatting: suspicious URLs, malformed MIME, missing List-Unsubscribe, weird encodings, or “too perfect” templating.
Transport and policy: TLS errors, MTA-STS enforcement, rate limits, 4xx deferrals, or network blocks.

Here’s the uncomfortable truth: you can pass SPF, DKIM, and DMARC and still go to spam. Providers treat authentication as “identity proof,” not “permission to inbox.”

One quote worth keeping on the wall

Hope is not a strategy. — General Gordon R. Sullivan

Deliverability debugging has the same rule. If you can’t prove it with headers, logs, and DNS, you’re doing vibes-based operations.

Interesting facts and historical context (deliverability edition)

SPF started as an anti-forgery mechanism, not a deliverability booster. It was designed to reduce spoofing by tying “who can send” to DNS.
DKIM came out of domain-signing experiments (including DomainKeys and Identified Internet Mail) and became the way to keep integrity through hops—until intermediaries modify messages.
DMARC formalized “alignment”: it’s not enough to authenticate; the authenticated domain must match (align with) the From domain recipients see.
Google and Microsoft learned to distrust “perfect senders”: unusually uniform content or unnatural engagement patterns can be a red flag, even for legitimate transactional mail.
IPv4 reputation became a product: shared IP pools and dedicated IPs exist largely because inbox providers score IP history aggressively.
ARC (Authenticated Received Chain) exists because forwarding breaks SPF and can break DKIM; ARC lets intermediaries preserve authentication results across hops.
BIMI is a branding feature with teeth: it nudges senders toward DMARC enforcement because the logo display requires stronger policy posture.
Spam filters went from keyword hacks to behavior models: user interaction (opens, deletes, replies, spam reports) influences future placement.
List-Unsubscribe became an operational control: inbox providers use it to reduce “this is spam” clicks by offering clean opt-out.

Joke #1: Email deliverability is like dieting—everyone swears they “did everything right,” but the logs remember what really happened.

Headers and bounce codes: stop guessing, start reading

If you’re not reading raw headers and DSNs, you’re diagnosing with a blindfold. Gmail and Microsoft both include enough metadata to tell you what failed—if you know where to look.

Headers that matter

Authentication-Results: SPF/DKIM/DMARC pass/fail and sometimes reasons.
Received chain: confirms the sending host and whether a gateway rewrote the message.
From, Return-Path, Sender: used in alignment and bounce routing.
Message-ID: useful to correlate with logs; also tells you if your app generates weird IDs.
List-Unsubscribe and List-Unsubscribe-Post: increasingly important for bulk mail; missing headers can hurt.

SMTP status codes: what they imply operationally

5xx: rejected. This is not a retry problem. Fix the cause.
4xx: deferred / temporary. Often rate limiting, reputation soft blocks, or transient policy checks. Retry strategy matters.
2xx accepted: accepted by recipient MTA, not necessarily inboxed. For spam placement issues, focus on authentication + reputation + content.

Practical tasks (commands, outputs, decisions)

Below are production-grade tasks you can run today. Each includes: a command, example output, what it means, and the decision you make from it. These assume a Linux mail host with Postfix (common), but the DNS and message analysis applies everywhere.

Task 1 — Identify your actual egress IP (not what you “think” it is)

cr0x@server:~$ curl -s ifconfig.me
203.0.113.45

What it means: That’s the public IP recipients see (unless you relay through a provider).

Decision: All reputation, rDNS/PTR, and allowlisting must match this IP. If you expected a different IP, stop: you’re debugging the wrong sender identity.

Task 2 — Confirm reverse DNS (PTR) exists and matches your HELO strategy

cr0x@server:~$ dig +short -x 203.0.113.45
mail1.example.com.

What it means: The IP maps to mail1.example.com.

Decision: Configure Postfix smtpd_banner/myhostname and outbound smtp_helo_name so HELO/EHLO is a valid hostname that resolves forward to the same IP. If there is no PTR, fix it—Microsoft especially dislikes missing rDNS.

Task 3 — Check forward DNS for the sending hostname (A/AAAA)

cr0x@server:~$ dig +short mail1.example.com A
203.0.113.45

What it means: Forward resolves back to the IP.

Decision: If forward and reverse don’t line up, expect more throttling and spam placement issues. Fix DNS before touching content.

Task 4 — Inspect SPF record and look for “too many DNS lookups” risk

cr0x@server:~$ dig +short TXT example.com | sed 's/" "/""/g'
"v=spf1 include:_spf.google.com include:spf.protection.outlook.com ip4:203.0.113.45 -all"

What it means: SPF permits Google, Microsoft, and a specific IP.

Decision: Verify your actual sending sources match this. If you have many include: mechanisms, you can exceed SPF’s 10-DNS-lookup limit. If SPF intermittently “permerror,” simplify SPF (flatten carefully, or reduce includes).

Task 5 — Validate SPF for a specific IP using a local checker

cr0x@server:~$ spfquery -ip 203.0.113.45 -sender bounce@example.com -helo mail1.example.com
result=pass
smtp.comment=domain of bounce@example.com designates 203.0.113.45 as permitted sender

What it means: SPF passes for the envelope sender domain.

Decision: If this fails, fix SPF. If it passes but DMARC fails later, alignment is your problem (envelope domain != From domain, or relaxed alignment not satisfied).

Task 6 — Check DKIM selector records exist in DNS

cr0x@server:~$ dig +short TXT s1._domainkey.example.com
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtw..."

What it means: Selector s1 exists and publishes a public key.

Decision: If this is empty or truncated, fix DNS (often split TXT records) and re-sign mail. A missing selector is a clean way to get spam-foldered at scale.

Task 7 — Verify DMARC policy and alignment mode

cr0x@server:~$ dig +short TXT _dmarc.example.com
"v=DMARC1; p=quarantine; rua=mailto:dmarc-rua@example.com; ruf=mailto:dmarc-ruf@example.com; adkim=s; aspf=r; pct=100"

What it means: DMARC is enforcing quarantine, DKIM alignment is strict, SPF alignment relaxed.

Decision: If you use third-party senders, strict DKIM alignment (adkim=s) can break them unless they sign with your domain. Decide whether to relax alignment or reconfigure senders to use aligned DKIM.

Task 8 — Pull a live message from logs (Postfix) and inspect the response from Gmail/Microsoft

cr0x@server:~$ sudo grep -E "to=|status=" /var/log/mail.log | tail -n 20
Jan  3 10:17:12 mail1 postfix/smtp[24177]: 8F2C02A1B3: to=, relay=gmail-smtp-in.l.google.com[142.250.102.27]:25, delay=2.1, delays=0.2/0.1/1.2/0.6, dsn=2.0.0, status=sent (250 2.0.0 OK  1704277032 x12-20020a1709032f4c00b003b7c2c1a8d3si1234567plb.123 - gsmtp)
Jan  3 10:18:44 mail1 postfix/smtp[24210]: 1B7D02A1C9: to=, relay=outlook-com.olc.protection.outlook.com[104.47.15.36]:25, delay=45, delays=0.3/0.2/10/34, dsn=4.7.0, status=deferred (host outlook-com.olc.protection.outlook.com[104.47.15.36] said: 451 4.7.0 Temporary server error. Please try again later. PRX4 (in reply to MAIL FROM command))

What it means: Gmail accepted; Microsoft deferred with a 4.7.0 temporary error.

Decision: Gmail issues likely spam placement, not transport. For Outlook deferrals, check rate limiting, reputation, and whether you’re sending bursts. Don’t “fix” by increasing retry frequency; that often worsens throttling.

Task 9 — Inspect the Postfix queue for stuck or exploding mail

cr0x@server:~$ mailq | head -n 25
-Queue ID-  --Size-- ----Arrival Time---- -Sender/Recipient-------
1B7D02A1C9      4123 Fri Jan  3 10:18:44  bounce@example.com
                                         user@outlook.com
                                         (host outlook-com.olc.protection.outlook.com[104.47.15.36] said: 451 4.7.0 Temporary server error. Please try again later. PRX4 (in reply to MAIL FROM command))

-- 1 Kbytes in 1 Request.

What it means: You have deferred messages waiting on Outlook.

Decision: If the queue is growing fast, you need to throttle outbound concurrency to Microsoft, improve reputation, or move bulk sends off your transactional IP. If it’s a small queue with normal retry behavior, don’t panic.

Task 10 — Confirm you are signing DKIM on the messages you think you are

cr0x@server:~$ sudo postcat -q 8F2C02A1B3 | sed -n '1,80p'
*** ENVELOPE RECORDS ***
message_size:            38912            392
sender: bounce@example.com
*** MESSAGE CONTENTS ***
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=s1;
 t=1704277032; bh=7yQf...; h=from:to:subject:date:mime-version;
 b=Z1m...
From: Example Billing 
To: user@gmail.com
Subject: Your receipt

What it means: The message is DKIM-signed with d=example.com, selector s1.

Decision: If DKIM signature is missing for certain app paths (password resets vs invoices), you likely have multiple outbound paths. Consolidate or ensure all paths sign consistently.

Task 11 — Verify TLS handshake and certificate presentation to recipient MTAs

cr0x@server:~$ openssl s_client -starttls smtp -connect gmail-smtp-in.l.google.com:25 -servername gmail-smtp-in.l.google.com -tls1_2 </dev/null | sed -n '1,25p'
CONNECTED(00000003)
depth=2 C=US, O=Google Trust Services LLC, CN=GTS Root R1
verify return:1
depth=1 C=US, O=Google Trust Services LLC, CN=GTS CA 1C3
verify return:1
depth=0 CN=gmail-smtp-in.l.google.com
verify return:1
---
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES128-GCM-SHA256

What it means: Recipient supports modern TLS; your side should too.

Decision: If your outbound MTA negotiates ancient TLS or fails STARTTLS, you’ll see more deferrals and policy failures. Upgrade libraries and Postfix, and ensure your cipher policy isn’t stuck in 2014.

Task 12 — Check whether your domain is publishing MTA-STS and whether it parses

cr0x@server:~$ dig +short TXT _mta-sts.example.com
"v=STSv1; id=20250101T120000Z"

What it means: You publish an MTA-STS policy id.

Decision: If you claim MTA-STS but your policy host is broken, you can cause inbound delivery issues to you (not outbound). Still worth checking because “email is broken” tickets rarely specify direction.

Task 13 — Check local DNS resolution health (because broken resolvers cause flaky SPF/DKIM)

cr0x@server:~$ resolvectl status | sed -n '1,35p'
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Current DNS Server: 10.0.0.53
       DNS Servers: 10.0.0.53 1.1.1.1

What it means: Your MTA depends on these resolvers for SPF/DKIM/DMARC checks.

Decision: If you have intermittent deliverability failures, check resolver timeouts and NXDOMAIN hijacking. Use reliable resolvers and consider local caching (unbound) with sane timeouts.

Task 14 — Confirm your HELO name (Postfix) is what you intend

cr0x@server:~$ postconf smtp_helo_name myhostname | sed 's/^/postfix: /'
postfix: smtp_helo_name = mail1.example.com
postfix: myhostname = mail1.example.com

What it means: Your outbound introduces itself as mail1.example.com.

Decision: If you see a generic HELO like localhost or an internal hostname, fix it. It’s not always fatal, but it screams “unmanaged” to reputation systems.

Task 15 — Spot high bounce/unknown user rates fast (log sampling)

cr0x@server:~$ sudo grep -E "status=bounced|5\.1\.1|User unknown" /var/log/mail.log | tail -n 15
Jan  3 10:10:02 mail1 postfix/smtp[23910]: 9A1F12A0D2: to=, relay=outlook-com.olc.protection.outlook.com[104.47.15.36]:25, delay=3.2, dsn=5.1.1, status=bounced (host outlook-com.olc.protection.outlook.com[104.47.15.36] said: 550 5.1.1 RESOLVER.ADR.RecipNotFound; Recipient not found (in reply to RCPT TO command))

What it means: You’re sending to nonexistent recipients.

Decision: Stop the bleed. Pause bulk sends, clean lists, and enforce address verification at capture time. High 5.1.1 rates wreck reputation quickly, especially on Microsoft.

Task 16 — Confirm you include List-Unsubscribe headers for bulk mail

cr0x@server:~$ sudo postcat -q 7C0A12A19F | grep -i -E '^List-Unsubscribe:|^List-Unsubscribe-Post:'
List-Unsubscribe: , 
List-Unsubscribe-Post: List-Unsubscribe=One-Click

What it means: Bulk messages provide clean unsubscribe options.

Decision: If you send marketing or product updates without these, add them. It reduces spam complaints, and that’s a deliverability lever you can actually control.

Joke #2: If your SPF record has 14 includes, it’s not “security,” it’s interpretive DNS dance.

Three corporate mini-stories from the trenches

Mini-story 1: The incident caused by a wrong assumption

A mid-size SaaS company had a “simple” setup: app servers sent password resets through a cloud email provider, and invoices went through an on-prem Postfix box that had been running since someone’s internship ended.

A new brand domain launched. Marketing updated the visible From: address to billing@newbrand.example everywhere. They did not touch the envelope sender, which remained bounce@oldbrand.example. SPF passed. DKIM passed (for the old domain). DMARC failed. Quietly, consistently, and catastrophically.

The wrong assumption was subtle: “If SPF and DKIM pass, DMARC will pass.” Not how it works. DMARC cares about alignment with the From domain the user sees. The visible identity changed; the authenticated identity didn’t.

Symptoms were ugly but confusing: Gmail delivered to spam, Outlook deferred some mail and junked the rest, and internal stakeholders insisted it was “content” because the template had changed that week.

Fix was boring and immediate: either sign DKIM with d=newbrand.example and set envelope sender aligned, or use relaxed alignment with a controlled subdomain strategy. Once DMARC passed reliably, placement recovered over days, not minutes. Reputation systems have memory; they’re not goldfish.

Mini-story 2: The optimization that backfired

Another company tried to “optimize costs” by consolidating all outbound email—transactional, marketing, partner notifications—through one dedicated IP. One IP to rule them all. One dashboard. One set of firewall rules. Someone even called it “simplification.”

It worked until the quarterly product newsletter. Engagement was mediocre, unsubscribes spiked, and a small fraction of recipients hit “Report spam” because the email looked unfamiliar. The next day, password resets started landing in spam for Gmail users and deferring at Microsoft.

They had created a reputation coupling: the worst-behaved mail stream poisoned the most business-critical mail stream. The incident was expensive, but the lesson was priceless: separate traffic by risk.

The recovery plan wasn’t magical. They split sending: one IP/domain path for transactional, another for marketing, with different rate limits and stricter list hygiene gates on marketing. They also implemented suppression lists and stopped emailing addresses that hadn’t engaged in months. Deliverability gradually returned, and the on-call rotation stopped treating campaign days like hurricane season.

Mini-story 3: The boring but correct practice that saved the day

A large B2B platform had a habit that looked bureaucratic: every DNS change for email auth required a peer review and a “canary check” from a staging domain. No one loved it. Everyone complied.

One Friday, a well-meaning engineer attempted to rotate DKIM keys and clean up “old selectors.” The review caught that a legacy app still signed with selector s0 because it was pinned in a config file that lived in a container image nobody wanted to rebuild.

The key rotation went out with both selectors live. They scheduled the removal of s0 only after confirming—via logs—that no messages were being signed with it. The change was uneventful, which is the only acceptable outcome for authentication changes.

Two weeks later a similar rotation at a partner org caused widespread failures because they deleted the active selector first and asked questions later. The platform’s mail kept flowing, and nobody got paged. The saving grace wasn’t genius; it was a change process designed for the reality that email systems are sprawling and inconsistent.

Checklists / step-by-step plan

Checklist A — If Gmail users report “not receiving”

Get one real recipient example: message ID, timestamp, recipient domain, and whether it was searched in “All Mail” and Spam.
Determine: bounce, deferral, or delivered from your logs.
Pull the raw headers from a delivered sample and confirm DMARC pass and alignment.
Check DKIM selector DNS exists and is stable (no intermittent NXDOMAIN).
Confirm sending IP stability: no surprise NAT changes, no new relays.
Validate list hygiene if it’s bulk: unknown users and complaints will tank you.
Segment streams: keep transactional isolated from marketing if you value your sleep.

Checklist B — If Outlook/Microsoft 365 defers or rejects

Read the SMTP enhanced status code: 4.7.x (throttle), 5.7.x (policy/auth), 5.1.1 (bad recipients).
Check rDNS and HELO: Microsoft is not sentimental about misconfigured senders.
Throttle and smooth: bursty sends trigger deferrals; reduce concurrency and ramp gradually.
Check for compromised accounts: Microsoft deferrals often coincide with sudden spikes from one sender identity.
Separate bulk vs transactional by IP/domain if you haven’t already.
Confirm DKIM/DMARC alignment and that headers aren’t being rewritten by intermediate relays.

Checklist C — Authentication baseline for 2025 (do this once, then monitor)

SPF: minimal includes; -all once you’re confident; keep under 10 DNS lookups.
DKIM: 2048-bit keys where feasible; rotate; keep selectors documented.
DMARC: start at p=none to observe, then quarantine, then reject when aligned streams are clean.
Alignment strategy: decide whether From uses root domain or a dedicated subdomain; keep consistent.
ARC: if you run forwarding services (helpdesk, ticketing), implement ARC to preserve auth trust.
List-Unsubscribe: include for bulk; support one-click if you can.

Common mistakes: symptom → root cause → fix

These are the failures I see repeatedly in production. They’re not glamorous, but they’re the reason your mail is “fine in staging” and cursed in the real world.

1) Symptom: Gmail accepts (250 OK) but users find mail in Spam

Root cause: DMARC fails or passes inconsistently; sender reputation degraded; bulk headers missing.
Fix: Make DMARC pass with aligned SPF or DKIM. Add List-Unsubscribe for bulk. Split marketing from transactional. Stop sending to cold lists.

2) Symptom: Outlook returns 451 4.7.0 temporary error for many recipients

Root cause: Throttling due to reputation, burst rate, or poor IP hygiene (rDNS/HELO mismatch).
Fix: Smooth sending (lower concurrency, consistent cadence). Fix rDNS and HELO. Separate streams. Clean bounce-heavy recipient sets.

3) Symptom: “SPF passes” but DMARC fails

Root cause: SPF domain is the envelope sender domain, not aligned with From domain.
Fix: Use aligned return-path domain (or subdomain) and ensure SPF authorizes the true sending source; or rely on aligned DKIM for DMARC pass.

4) Symptom: DKIM sometimes fails only for certain message types

Root cause: Multiple outbound paths; one path not signing, or a relay modifies the body/headers after signing.
Fix: Centralize signing at the last trusted hop. Ensure canonicalization is appropriate. Avoid intermediaries that rewrite content post-sign.

5) Symptom: Sudden collapse after a DNS “cleanup”

Root cause: Deleted active DKIM selector; broke SPF include chain; changed DMARC policy too aggressively.
Fix: Restore selectors. Roll out DMARC gradually (pct, monitor reports). Treat DNS for email auth like production config, not a hobby.

6) Symptom: High bounce rate (5.1.1) and then everything gets worse

Root cause: List hygiene failure; old lists; typos; sign-up abuse.
Fix: Implement suppression, validation, and double opt-in where appropriate. Stop sending to addresses that hard bounce—immediately, automatically.

7) Symptom: Messages vanish when forwarded (especially to Gmail)

Root cause: Forwarding breaks SPF; DKIM broken by modifications; DMARC policy causes rejection/quarantine.
Fix: Encourage use of modern forwarding that supports ARC. For your own forwarding services, implement ARC and avoid content rewriting.

8) Symptom: Internal tests succeed, external recipients fail

Root cause: You’re testing against permissive internal MTAs. External providers enforce stricter policy and reputation scoring.
Fix: Test with real external mailboxes, inspect headers, and stage authentication changes with canary domains.

FAQ

1) “We’re not a bulk sender. Do Gmail’s bulk rules matter?”

They matter indirectly. Providers increasingly apply “bulk-like” expectations (authentication, unsubscribe patterns, complaint control) to anyone who behaves like bulk—even accidentally. A transactional sender with a compromised account can look bulk in minutes.

2) If SPF passes, why does Outlook still throttle us?

Because SPF is identity, not reputation. Throttling is often about rate patterns, unknown users, complaint signals, and infrastructure hygiene (rDNS/HELO). SPF pass doesn’t buy you a fast lane.

3) Should we set DMARC to p=reject immediately?

Only if you’re confident every legitimate stream aligns (SPF or DKIM) and you’ve observed reports long enough to catch weird legacy senders. Otherwise you’ll reject your own mail and call it “security.”

4) Is DKIM or SPF more important in 2025?

DKIM tends to be more robust for DMARC alignment because SPF breaks on forwarding and some relays. Best practice remains: publish both, make sure at least one aligns, and monitor DMARC results.

5) Can a content change alone cause spam placement?

Yes, but content is usually the multiplier, not the root cause. If your authentication and reputation are healthy, content tweaks rarely cause a total cliff. If you’re already marginal, one “innocent” change (new link domain, URL shorteners, tracking changes) can tip you.

6) Why do some recipients get the mail and others don’t?

Providers do per-recipient and per-domain scoring. A sender can be temporarily throttled for certain regions, mailbox clusters, or recipient cohorts. Also, your own system may route mail differently based on recipient domain (different relays, different IPs).

7) What’s the single most useful artifact to request from a user?

The full headers of a message that landed in spam, or the exact bounce/NDR text. Screenshots are decorative; headers are evidence.

8) Does changing our sending IP help?

Sometimes, but it’s also a great way to reset your reputation to “unknown,” which can be worse. Change IPs when the current one is irredeemably poisoned or shared with bad actors, and plan a warm-up.

9) We use a third-party email platform. What can we actually control?

More than you think: From domain strategy, DKIM alignment, DMARC policy, list hygiene, segmentation (transactional vs marketing), content/link domains, and sending cadence. Also, you can control whether you pick shared vs dedicated IPs and how you onboard/warm up.

10) Why do “delivered” dashboards disagree with reality?

Many dashboards mean “accepted by recipient MTA,” not “in inbox.” Inbox placement is a separate outcome. Use headers, recipient feedback loops (where available), and your own engagement metrics to validate.

Conclusion: next steps that hold up under load

Deliverability incidents feel personal because they block money and trust. But the fixes are mechanical: prove identity (aligned SPF/DKIM/DMARC), protect reputation (hygiene and segmentation), and keep transport boring (rDNS, HELO, TLS, sane retry behavior).

Next steps that actually move the needle:

Pick one failing example (recipient + timestamp) and trace it end-to-end using logs and headers.
Make DMARC pass consistently with alignment. Do not negotiate with this requirement.
Separate transactional and bulk streams by IP and/or domain, and enforce stricter hygiene on bulk.
Stabilize infrastructure identity: rDNS, forward DNS, HELO name, and consistent egress IP.
Add operational guardrails: DNS change review, DKIM selector inventory, queue monitoring, bounce-rate alarms.

The inbox providers are not your friends, but they are predictable if you treat email like production traffic. Measure. Verify. Change one thing at a time. And keep the logs close.