Email Delivery Report Explained: Fields, Codes and Fixes

Learn how to read every email delivery report field, SMTP code and complaint threshold, and fix the issues that hide your real inbox results.

The most repeated advice about email delivery reports is to watch the delivered rate and keep bounces low. It's tidy, it fits on a dashboard, and it answers a question nobody in revenue ever asked. A receiving server confirms that it accepted a message. It says nothing about whether a buyer saw it.

That gap is the whole subject. A report built on "delivered" measures transport, not communication, and teams that optimise the number often improve nothing that shows up in pipeline.

The reading rule: a delivered percentage is proof that a server took the message, never proof that a person received it.

What follows treats the delivery report as an incomplete observability tool and rebuilds it around outcomes that can be verified, from SMTP replies to inbox placement to reply data.

Table of Contents

Email Delivery Report Outcomes at a Glance

A delivery percentage can look healthy while leaving the most important outcome unmeasured: where the message appeared. Tools such as Instantly report acceptance, bounces and deliverability figures by campaign. Keep those signals distinct, since each supports a different conclusion and points to a different investigation.

Outcome

Signal source

What it proves

What it does not prove

Accepted by server

SMTP 250 response

The receiving server took the message

Inbox placement

Delivered (platform figure)

Platform report

The platform recorded the message as delivered

That the message reached the inbox or was seen

Inbox placement

Seed or placement tests

The message reached the inbox in the tested conditions

Engagement or intent

Spam placement

Placement tests and complaint data

The message was filtered to spam in the tested conditions

Whether the recipient read it

Missing

Gap between sent and measured results

The message was not observed in the measured inbox or spam results

The cause

Hard bounce

5xx SMTP response

The address or domain was permanently rejected

Sender reputation on its own

Soft bounce or deferral

4xx SMTP response

A temporary failure occurred

That the address is invalid

Policy block

Rejection text citing policy

The provider rejected the message under a policy or rule

Recipient interest

Platform delivery rates and inbox placement rates measure different stages. A platform may record acceptance while placement tests show that some accepted messages did not reach the inbox. Bounce figures cannot account for that gap: they describe rejected or deferred messages, not accepted messages filtered elsewhere.

Use the categories to separate observable outcomes from unknown ones:

A chart explaining four different email delivery report outcomes and their specific definitions for email marketing.

Accepted means the platform recorded the receiving server's acceptance. Inbox placement is a separate result, estimated through placement tests rather than confirmed by the acceptance event. Spam placement indicates filtering in the tested conditions. Missing marks messages that appear in neither measured location, without identifying why.

Keep an explicit unknown category. Receiving systems do not reliably disclose whether a message was quarantined, discarded without notice or missed by a placement test. A gap between sent and measured messages is evidence of incomplete observability, not proof of a specific failure.

Bounces are easier to classify, but they answer a narrower question. A 5xx hard bounce indicates permanent rejection of an address or domain. A 4xx soft bounce or deferral indicates a temporary failure; the address may still be valid.

A policy block should not be filed as an ordinary address bounce. The rejection text may point to authentication, reputation or another provider rule, while the report itself cannot establish whether the recipient would have engaged. Compare these outcomes with replies to understand whether measured delivery is producing evidence of buyer interest.

SMTP Codes and Quota Deferrals

The first thing worth checking in a delivery report isn't the percentage. It's the SMTP reply behind each event, because a platform label of "sent" collapses several different realities into one word. RFC 5321 defines the reply a receiving server gives when it takes a message, the 250 OK response, and that is acceptance at the relay and nothing more. A report that discards the raw reply throws away the only statement the receiving system made.

Every event should carry its response code next to the outcome label, so the next reader can audit it without re-running the campaign.

An illustrated dashboard showing an email delivery report, event logs, and an SMTP code lookup magnifying glass.

Code

Class

Meaning

Retry or action

250 OK

Success

The server accepted the message

Log as accepted, not as inbox placement

4.7.28

Temporary (4.x)

Gmail sending quota or rate limit exceeded

Retry with pacing; do not count as a bad list

4xx (other)

Temporary

Message deferred; try again later

Retry on a backoff schedule

550

Permanent (5xx)

Mailbox unavailable or message rejected

Stop retries; correct or suppress the address

553

Permanent (5xx)

Mailbox name not allowed or address syntax invalid

Correct the address or suppress it

4.7.28 is not a bad address. Gmail's sender guidelines describe what happens when a sender exceeds its sending quota: messages are typically rejected with SMTP error code 4.7.28. It reads like a failure in a bounce column and behaves like a brake. Grouped with invalid-recipient bounces, it makes a clean list look decayed and hides a volume or pacing problem that no amount of list cleaning will fix.

The permanent codes behave the opposite way. A 550 or 553 will not resolve itself, so retrying wastes sending volume on an address that will keep rejecting you, and repeated attempts on a dead domain are the sort of pattern providers remember.

Working through a quota deferral

A deferral is a scheduling problem until proven otherwise. Work it in this order.

  1. Confirm the code. Check that the response is 4.7.28 rather than a 5.x address failure sitting in the same column.

  2. Total the volume. Compare what went out in the window against the sending limit for that account and domain.

  3. Slow the batch. Pause or spread volume across sending accounts and domains so each stays inside its own ceiling.

  4. Retry on a backoff. Queue the deferred messages again on a schedule that widens with each attempt.

  5. Verify the retries. Confirm that retries succeed and that hard bounces remain in their own row, untouched by the deferral fix.

If deferrals remain high after pacing, the cause is usually infrastructure or reputation rather than quota. The surrounding sending configuration that keeps a domain healthy is covered in email deliverability best practices, and it's worth reading before you blame the list.

Fields a Delivery Report Needs to Be Actionable

A delivery report earns the name when every row traces back to a machine-readable notification rather than a marketing label. The standards-based unit is the Delivery Status Notification, defined in RFC 3464 using the MIME multipart/report structure and the message/delivery-status content type. It can express failed, delayed or successful delivery, and its fields let a system tie the notification back to the original transmission.

Capture these six fields for every event:

  • Original recipient: the address the message was sent to, before alias rewriting.

  • Action: delivered, failed or delayed, using the notification's own vocabulary.

  • SMTP status code: the numeric reply, kept as text rather than mapped to a friendly label.

  • Diagnostic code: the provider's own explanation, which often names the policy that fired.

  • Reporting mail system: which server issued the notification, since that determines who you escalate to.

  • Timestamp: when the notification was issued, not when the send was queued.

Segmentation fields that decide the diagnosis

Six more fields turn a status log into a diagnostic system: recipient domain, sending stream, message type, SPF result, DKIM result, and whether the authenticated domain aligns with the visible From domain. Each exists to break an average apart.

Aggregate rates conceal the pattern that matters most, which is a cliff at one provider while everything else looks fine. An alignment failure produces exactly that shape, because the domain that passed authentication isn't the domain the recipient sees. Hard bounces, soft bounces, blocks and policy rejections have to stay in separate columns for the same reason, otherwise one blended bounce rate tells you a number went up without telling you why.

Forwarding adds another layer. When an intermediary rewrites or relays a message, the original authentication assessment can be lost, and RFC 8617 defines the signed chain known as ARC so downstream validators can still evaluate evidence that would otherwise vanish in transit.

None of these fields rescue a list built from unverified addresses, so keep enrichment and verification upstream of the send: Getleads exists to keep the hard bounce row small rather than to explain it afterwards.

Minimum viable report: recipient, action, SMTP code, diagnostic text, reporting system, timestamp, plus authentication result and recipient domain. Without those, you can see that something broke but not whether the cause was the list, the domain or a provider policy.

Reporting by Date Window and Season

An average is a story about a period nobody named. A sender can look healthy in February and lose real visibility in November, and one year-long number hides both. Validity's 2025 benchmark recorded 83.5% of legitimate marketing emails reaching the inbox worldwide in 2024, with 6.7% going to spam and 9.8% missing. Inside the same year, inbox placement was just below 87% in February 2024 and fell to 82.3% during the fourth-quarter peak.

That's a five-point swing in a metric teams treat as a fixed property of their domain.

Report by window in four steps.

  1. Tag every send with its date and campaign period, so no event floats free of a time frame.

  2. Compare shares, not just totals, against the same sender's earlier baseline for inbox, spam and missing.

  3. Flag peak-season windows such as Q4 as expected dip periods before judging the list or the copy.

  4. Re-test placement at the start and end of each peak period, so the dip has a measured boundary.

The diagnosis sits in the shape of the dip. A fall across every provider points to market-wide filtering pressure during a high-volume period, which is a scheduling problem. A fall at one provider points to your reputation or your authentication with that provider, which is a repair you can make.

Complaint and Unsubscribe Thresholds to Track

Complaint rate is the one metric in the report a sender still influences after the message leaves. Google's guidance is unusually concrete: keep the user-reported spam rate below 0.1% and never let it reach 0.3% or higher (Gmail's spam rate guidance). Spam rate is calculated daily, bulk senders above 0.3% can lose access to delivery mitigations, and eligibility returns only after the rate stays below that line for seven consecutive days.

Metric

Threshold

Reporting rule

User-reported spam rate

Below 0.1%

Warning target; show the rate per day

User-reported spam rate

0.3% or higher

Critical; bulk senders can lose delivery mitigations

Recovery after breach

Below 0.3% for 7 consecutive days

Count compliant days, not a cumulative average

One-click unsubscribe

List-Unsubscribe header present (RFC 8058 approach)

Record header presence, request success and processing time

A daily series beats a month-to-date average for a blunt reason. One bad send to a poorly matched segment can sit inside a healthy monthly figure and never trigger a review. Say a team sends 4,000 messages in a day and collects 9 complaints. That's 0.225%, above the warning target and below the critical one, which is exactly the band where a fast correction still costs nothing.

Unsubscribes carry their own technical requirement. Yahoo states that one-click unsubscribe is required for marketing messages, implemented through the List-Unsubscribe header and preferably following the RFC 8058 approach. The report should therefore record whether the header was present, whether one-click requests succeeded, and how quickly opt-outs were processed, which is a separate question from whether a visible unsubscribe link sat in the body.

Published open-rate benchmarks are the number executives ask for first, and typical open rates for creator newsletters collects the ranges different publications report. Treat those as context, not as a target: complaint rate and opt-out behaviour describe how your own list is reacting, while an open figure may only describe how images load.

One-click mechanics also sit inside a wider legal patchwork, and email marketing laws maps the consent and opt-out rules that decide what a report has to show.

Replacing Opens With Evidence You Can Trust

Open rate is the least trustworthy number on the page, and it's also the one that gets tuned the most. Apple Mail Privacy Protection and image caching can register an open when nobody read the message, and the true count of human opens can't be recovered from those proxy events (Mailgun's deliverability review). A report that ranks campaigns by opens will confidently recommend the wrong subject line, the wrong audience and the wrong follow-up timing.

An open is evidence that an image was requested. A reply is evidence that a person read the message and cared enough to type.

Judge campaigns in this order instead: replies, positive replies, qualified meetings, complaint and unsubscribe rates, bounce and deferral patterns, and finally downstream pipeline. Keep opens visible as a directional diagnostic with a caveat attached, never as the deciding column.

The useful join is message-level and provider-aware. Attach each reply to its sending domain, mailbox provider and message variant, so a weak segment isn't blamed on weak copy when the problem was placement at one provider.

Say two variants show near-identical opens. One earns three replies per hundred sends and the other earns one. The reply gap decides the winner, and the per-provider view then shows whether either variant landed in spam at the provider that matters most. Anything less than that join invites a false conclusion in both directions.

Reporting that shows client channel-to-pipeline results exists so a team can always see what's working, and that shapes which measures survive scrutiny. Connecting the measures themselves is the subject of email marketing metrics. Where email replies stay thin, a second channel can supply its own evidence, and HeyReach applies the same message-level attribution logic to LinkedIn outreach.

Symptom-to-Fix Guide for Delivery Problems

A high delivered rate can coexist with poor inbox placement. Treat each symptom as a clue, not a diagnosis: delivery reports show what receiving systems disclose, while placement and replies provide evidence about what happened after acceptance.

Symptom

Likely cause

First fix

Delivered rate high, pipeline flat

Messages filtered to spam or missing after acceptance

Run inbox placement tests by provider

One provider's delivery drops

Authentication misalignment or reputation at that provider

Check SPF, DKIM and DMARC alignment; reduce volume to that provider

Many 4.7.28 responses

Sending quota or rate limit exceeded

Pace sends and spread volume across sending accounts

Rising spam complaints

Weak targeting or a hard-to-find unsubscribe

Tighten the list and add one-click unsubscribe

High hard bounces

Stale or unverified list

Verify addresses and suppress 5xx recipients

Opens rising while replies fall

Privacy-inflated opens

Judge the campaign by replies and meetings

A diagnostic chart illustrating email delivery problems, linking specific symptoms to likely causes and suggested fixes.

The gap between acceptance and inbox placement is measurable. Validity's 2022 global benchmark reported a 98.5% delivery rate, with 86.0% inbox placement, 4.8% spam placement and 9.2% effectively missing from measurement (Validity's 2022 global benchmark). A better headline delivery rate may produce no additional pipeline if messages are filtered after acceptance.

Repair the clearest causes first, then test whether placement and replies improve:

  1. Check authentication alignment between the authenticated domain and visible From domain.

  2. Verify and suppress hard bounces, including recipients returning 5xx codes.

  3. Pace sends against provider quotas and rate limits.

  4. Review targeting and unsubscribe access when complaints rise.

  5. Retest inbox placement by provider before judging the effect of a change.

Sending platforms with sequencing and warm-up controls, such as Instantly, can help teams pace volume deliberately. If a provider has downgraded your domain, it can take longer to fix poor sender reputation than to adjust sending pace, so use provider-specific trends to catch deterioration early.

Some corrections appear in reports within days; reputation recovery can take longer. Keep rejection codes, deferrals, placement and replies separate so a change in one measure is not mistaken for a full recovery. For rejection-specific causes and remedies, see this guide to email delivery failures.

Confirm the Report Before Your Next Campaign

The decision in front of you is simple: does the next campaign go out, or does it wait a week? Run these checks before answering.

  • Four outcomes, four rows. Accepted, bounced, deferred and missing each appear separately.

  • Placement tested. Inbox and spam placement measured for the main recipient domains, not just the aggregate.

  • Alignment verified. The authenticated domain matches the visible From domain.

  • Complaint rate inside the warning band for each of the last seven days, not averaged away.

  • Quota deferrals in their own row, tracked by provider and code.

  • One-click unsubscribe working, with header presence and processing time both logged.

  • Replies and qualified meetings as the primary success measures, with opens demoted to a diagnostic.

A report passing every check tells you the system is healthy. It doesn't tell you the campaign will convert, and no dashboard can, because conversion depends on the offer and the list rather than the pipes.

If the team doesn't have the capacity to run this review every month, The Social Search designs and runs outbound systems in which delivery, reply and pipeline data sit in one dashboard, tuned against real reply data before the system is handed to the client's team.

The single thing to review at your next send: whether the delivered figure moved without the inbox and reply figures moving with it. If it did, you learned something about a server, not about a buyer. Testing the whole chain end to end is worth doing before you scale, and how to test email deliverability walks through the sequence.

If your delivery reports look clean while pipeline stays flat, the gap usually sits between acceptance and the inbox, and that's where The Social Search works. We build outbound systems where placement, reply and pipeline data live in one dashboard, tune the messaging against real replies, then hand the running of it to your team. Visit The Social Search to see how the build and handover work.