Email deliverability for online stores: a complete guide

"Delivered" and "deliverable" measure different things. Delivery rate is the share of sends your ESP didn't get a hard bounce on - a 98% delivery rate just means the receiving server accepted the message with a 250 response. Deliverability is whether that accepted message reached the inbox instead of the spam folder, and ecommerce sending has specific patterns that push that number down.

Why ecommerce risk differs from B2B

A B2B sender typically has a smaller, more intentional list with a longer sales cycle and fewer sends per contact. Ecommerce senders usually have:

• Much larger lists built through checkout opt-ins and pop-ups, with lower average intent per address.
• Frequent sends (several a week during active periods), which raises both engagement and fatigue-driven complaints.
• Seasonal volume spikes that look anomalous to filtering systems even when they're legitimate.

Each of these raises the baseline complaint and spam-rate risk, which is exactly what Google's bulk-sender requirements target.

Shared sending pools are a hidden risk

Many ecommerce-focused ESPs send marketing mail from shared IP pools by default. That means your deliverability is partly determined by the sending behavior of other stores on the same pool - a wave of complaints from an unrelated sender can lower inbox placement for every store sharing that IP range. A dedicated sending domain (even on a shared IP, since IP reputation matters less than domain reputation at Gmail and Outlook now) keeps your reputation isolated from pool-mates.

Reading your platform's deliverability signals

• Google Postmaster Tools (domain-verified): since the retirement of its older per-domain/IP reputation charts, the current version (v2) surfaces spam rate, authentication results, delivery errors, and compliance status, with a newer Deliverability analysis view added in 2026. It only shows data for domains sending meaningful Gmail volume.
• Microsoft SNDS: IP-based reputation and complaint data for Outlook.com/Hotmail sends - useful if you send from a dedicated IP, less useful on shared ESP infrastructure.
• Your ESP's bounce classification: distinguish hard bounces (bad address, stop sending) from soft bounces (temporary, like a full mailbox) - treating both the same way either suppresses good addresses or keeps mailing bad ones.

Diagnosing a deliverability problem

1. Check authentication first - SPF, DKIM and DMARC alignment, for the exact domain the mail is sent "from," not just a parent domain.
2. Check Postmaster Tools spam rate. Above 0.30% is Google's hard bulk-sender threshold; above roughly 0.10% is worth investigating even if you're not yet over the line.
3. Run a seed-inbox placement test to see actual inbox-vs-spam placement across providers, since label-based opens (especially Gmail Promotions, which still carries the INBOX label) overstate how much mail reaches Primary.
4. Segment the complaint and bounce data by acquisition source - checkout opt-in, pop-up, imported list - to find which channel is actually causing the problem.

Separating transactional and marketing streams

Order confirmations and shipping updates have near-100% expected engagement and should never share a sending domain or IP reputation with promotional blasts. Most ESPs support a separate transactional subdomain (e.g. notifications.yourstore.com) - use it, with its own SPF/DKIM, so a marketing campaign's complaint rate never threatens order-confirmation delivery.

A worked example: separating transactional and marketing DNS

A store sending marketing mail from yourstore.com and transactional mail from notifications.yourstore.com needs independent authentication for each:

; marketing domain
yourstore.com.              TXT  "v=spf1 include:_spf.youresp.com ~all"
default._domainkey.yourstore.com. TXT "v=DKIM1; k=rsa; p=MIGfMA0G..."
_dmarc.yourstore.com.       TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@yourstore.com"

; transactional subdomain
notifications.yourstore.com. TXT "v=spf1 include:_spf.transactionalesp.com ~all"
default._domainkey.notifications.yourstore.com. TXT "v=DKIM1; k=rsa; p=MIIBIj..."
_dmarc.notifications.yourstore.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc@yourstore.com"

Because DMARC policy is read at the exact sending domain first (falling back up the tree if nothing is published there), the transactional subdomain can run its own, more conservative policy (p=none while it proves itself) independently of the marketing domain's p=quarantine - a complaint-driven enforcement action on one never touches the other's deliverability.

Reading Postmaster Tools for two domains side by side

Verify both yourstore.com and notifications.yourstore.com separately in Google Postmaster Tools - they report independently. A common finding: the transactional subdomain shows a near-zero spam rate and the marketing domain shows a higher, more variable one, confirming the split is doing its job of isolating risk rather than the two streams actually behaving the same.

Postmaster Tools vs. SNDS, side by side

A store on shared ESP infrastructure typically only gets meaningful signal from Postmaster Tools, since SNDS reports at the IP level and a shared IP's data reflects every tenant on it, not just one store's sending behavior.

MailPilot warms new sending domains and subdomains against real inbox placement, checks SPF/DKIM/DMARC as actually published, and tracks per-mailbox reputation daily - useful for separating a transactional subdomain's health from a marketing domain's, and for seeing placement ahead of a seasonal volume ramp rather than after open rates have already dropped.