Ad: affiliate links. We may earn a commission from some links. Our recommendations explain what the tools can and cannot do. How we fund this guide.
The short answer

A delivery event, an inbox-placement observation, an open-tracking event and a human reply measure different things. No single dashboard label proves the whole journey. Combine the sending record with recipient evidence and keep engagement questions separate from technical delivery questions.

Think of the journey as separate observations

A person presses Send. The sending service processes the message. A receiving system may accept it. That system decides how to handle it. A person may then see it, read it and reply.

Evidence at one stage does not establish every later stage. A useful investigation names the stage it can actually observe.

What “delivered” tells you

Check your provider’s definition of its delivery status. In many sending dashboards, a delivery event relates to acceptance or handling by a receiving system. It is not a read receipt from the person you hoped to reach.

Ask which system recorded the event and whether it identifies a final mailbox outcome. If the destination is external, the sending platform may not have visibility of all recipient-side filtering.

For Microsoft 365, an authorised administrator can inspect message trace. Keep the exact event and its context rather than translating every favourable status into “the candidate saw it”.

What open tracking tells you

Open tracking commonly relies on loading a remote image. A person can read a message without loading that image. Privacy features or automated systems can also affect what the sender sees.

Apple’s Mail Privacy Protection is one documented reason to avoid treating an open event as a simple record of a person reading. Loxo also warns about the accuracy and deliverability implications of tracking in its preferences guidance.

Use open metrics cautiously for patterns. Don’t describe one recorded open as proof that a specific person read and ignored your message.

What a seed test tells you

A seed test observes the outcome in the test accounts used by that service. It can expose a difference between providers or message versions under those conditions.

It does not sample every relationship and policy in your real audience. A strong seed score is not proof that all client mailboxes behave the same way, and an unfavourable result does not identify every cause on its own.

The testing guide explains how to set a question, use the real sending route and record a comparable retest.

What replies tell you

A genuine reply is evidence of a conversation. No reply is ambiguous: the person may be busy, uninterested, unavailable or never have seen the message.

Look at replies alongside relevance and timing. Separate a recipient’s expected interview update from a broad business-development sequence. Those messages serve different purposes and should not share one assumed benchmark.

Avoid repeated sending solely to force an engagement signal. The absence of a reply does not justify removing opt-outs or ignoring a recipient’s preferences.

Build a better investigation table

For a small set of authorised examples, record the sending route, message type, provider, sending event, error if any, confirmed folder if known, and any genuine response. Keep unknown cells unknown.

You may find that the problem is concentrated in one route or audience. You may also find that there is no confirmed delivery failure and the next useful work is improving targeting or the message itself.

Use the email diagnostic to choose a next check. It will not invent a placement result from an open or reply rate.

Ad / GlockApps affiliate link

Need to see where a test message lands?

GlockApps can show placement in its test mailboxes. Use your actual sending route and read the results by provider. It cannot guarantee placement with your candidates or clients.

We may earn a commission from an eligible purchase. Check current allowances and pricing with GlockApps. How links are funded.

Sources & scope

This is a documentation-led guide, not a claim of hands-on testing in your account. Sources checked 19 October 2026. Product settings and provider policies can change.

How we write and check guides →

Give IT something useful to work with.

Turn the symptoms and checks into a clear, private handoff.

Build an IT handoff