Diagnosing ecommerce email deliverability problems

Start by separating the two numbers everyone conflates. Delivery rate is the share of messages the receiving server accepted — it will read 99% even while your campaigns sit in spam. Deliverability is placement: inbox, Promotions, or spam folder. Your store platform can report the first and cannot see the second, which is why ecommerce deliverability problems are usually discovered through revenue rather than through a dashboard.

Why ecommerce risk is structurally different

• Addresses come from checkouts, pop-ups and competitions, not from considered opt-ins, so complaint rates are higher at the same quality of execution.
• Most brands send from shared IP pools operated by their email platform. Your placement is partly a function of other tenants' behaviour, and you cannot audit them.
• Many systems send as your domain: the store platform, the reviews app, the loyalty app, the helpdesk, the shipping notifier. Each is a separate authentication and reputation surface.
• Volume is seasonal. A programme that sends 20,000 a week in October sends 200,000 in a Black Friday morning, which is the exact shape receivers throttle.
• Transactional mail is revenue-critical. A campaign-driven reputation problem delays receipts, shipping notices and password resets.

The 2024–2025 requirements, per sending domain

Every one of these is evaluated per sending domain. A brand running mail.brand.com, t.brand.com and a legacy send.brand.com from an old platform has three reputations to maintain, not one.

Diagnose in this order

1. Authentication, on delivered mail. Not in a DNS checker — open a real message and read the header:

Authentication-Results: mx.google.com;
  dkim=pass header.i=@mail.brand.com;
  spf=pass smtp.mailfrom=bounce.platform.example;
  dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=brand.com

Then check SPF for overflow. Ecommerce stacks accumulate include: statements, and SPF permits only 10 DNS-querying mechanisms and 2 void lookups before it returns permerror:

dig txt mail.brand.com +short
dig txt _dmarc.brand.com +short

2. Reputation and blocklists. Google Postmaster Tools for spam rate and authentication rates — the domain reputation chart was retired, so read the spam rate and user-reported spam graphs. Microsoft SNDS if you send from your own IPs. Then check the domain, the IP and your link domains against Spamhaus (SBL/XBL/CSS/DBL), Barracuda, SpamCop, Abusix and the URI lists. Validity's Heatwave blocklist launched on 3 September 2026. SORBS shut down in June 2024, so remove any check against it.

3. The apps sending as you. List every system with your domain in its From address. For each: is DKIM configured for that subdomain, is it inside the SPF budget, and does it respect your suppression list? A reviews app that mails everyone who ever ordered, including unsubscribes, will produce complaints attributed to your domain.

4. Address sources. Split complaint and bounce rates by acquisition source — checkout, pop-up, competition, import, offline. One source almost always dominates. Checkout typos (@gmial.com, @hotmai.com) and competition entries are the usual suspects, and competition lists are where pristine spam traps arrive.

5. What changed. New platform, new subdomain, new app, a template switch to image-heavy HTML, a volume increase above roughly 50% day over day, or a public link shortener introduced into a template.

Symptom to cause

Fix order

1. Repair authentication and alignment for every sending subdomain.
2. Separate transactional onto its own subdomain and warm it with real receipt traffic.
3. Enforce suppression at send time, across every app, and remove hard bounces.
4. Cut the worst address source, and apply double opt-in to pop-ups and competitions.
5. Sunset addresses with no engagement in twelve months.
6. Re-ramp volume gradually rather than returning to full volume once it looks fixed.
7. Only then touch templates.

What not to do

• Do not request blocklist delisting before the cause has stopped; repeat listings are harder to clear.
• Do not move to a dedicated IP to escape a shared pool unless your volume is high and consistent enough to keep it warm. Low, irregular volume on a dedicated IP performs worse.
• Do not change platform, subdomain and template in the same week — you lose all attribution.
• Do not raise volume to test whether the fix worked.
• Do not judge success by delivery rate, and do not test placement by mailing your own account.

MailPilot gives you the measurement layer this diagnosis depends on: warm-up over OAuth or SMTP/IMAP including Amazon SES, SendGrid, Mailgun and Postmark, SPF/DKIM/DMARC verification against delivered mail, daily per-mailbox reputation, and real inbox placement per provider from a seed-inbox network — reported per sending domain, so a marketing problem and a transactional problem never look the same.