"I never got it."
The sentence arrives with an accusation pointing in both directions, and the reflex on the sending side is to prove something. Resist that for ten minutes. Nearly every missing message has a cause mundane enough that arguing about it is pure loss — and if you assert delivery and turn out to be wrong, you have spent credibility you needed for the actual conversation.
Work the explanations in rough order of how often they are true.
The five explanations, in order
It was filtered. Spam folders and low-priority bulk tabs first, and the sender is almost never told. An outright rejection produces a bounce with a code you can read; quiet filing produces silence on both ends. That asymmetry is deliberate, because a filter that explained itself would be a tuning guide for the next spammer. Why mail lands in spam is mostly a verdict on the sender rather than on the sentence.
You used an address they do not read. An old work domain, a personal account they check on Sundays, a role alias that reaches three people and is nobody's job. Boring, extremely common, and the only one on this list you can settle in a single message.
A rule routed it. Corporate mailboxes are full of filters somebody configured years ago — vendor mail into a folder, external senders into a quarantine that emails a digest nobody reads, anything with an attachment into review. Shared inboxes make this worse, because arrived and seen by the person you meant are different events.
They got it and forgot. Read on a phone, meant to answer properly at a desk, and the desk moment never came. People genuinely do not remember doing this, which is why "you must have seen it" is both unprovable and rude.
It actually failed. Real, and last for a reason. A hard bounce, a provider incident, an address that stopped existing between when you saved it and when you used it.
Confirm the address before anything else
Do not ask "what is your email" — you will get the address they believe they gave you, which is the same assumption you already have. Read yours back to them instead, character by character, domain included. If it differs by one letter you have the answer in thirty seconds and nobody has to be wrong about anything larger.
Two details are worth knowing if you send through RelayLink. Recipient addresses are canonicalised from the parsed mailbox, so a display-name wrapper, stray whitespace, or odd capitalisation all resolve to the same account — those are not your bug. But an accepted contact has exactly one RelayLink address, and the contact list says so in as many words. Other addresses you happen to know for that person will not resolve to them.
What to do next
Do not resend the same message the same way. Same path, same filters, same outcome, and now you have sent it twice.
- Move channels. A text, a call, a walk past a desk. The goal is not to re-deliver the message; it is to establish contact and confirm where the message should have gone.
- Ask them to search rather than scroll. A distinctive phrase or your sending domain, with the spam folder included in the search, which most people do not do by default.
- Resend the substance, not the artifact. "Did you get my email" costs the reader time and returns them nothing. Restate the ask in three lines so the message is worth reading whether or not the first one arrived.
- Lead with your own fallibility. "Let me check I have the right address for you" costs nothing and cannot be wrong. "It is definitely in your spam folder" can be, and the odds are worse than they feel.
What a relay can and cannot prove
RelayLink's record is narrower than people assume, and the honest version is worth stating plainly, because the temptation in this exact conversation is to reach for it as proof.
What it can tell you: for a thread waiting on someone else, it reports one flag about the most recent package — they have seen it, or not seen yet. Seen means one of three things happened: their assistant pulled the package, they replied, or they pressed Got it on the web view. Fetching the link is explicitly not one of them, because mail scanners fetch links and a scanner is not a reader. That is a genuine signal about reach, and it is the thing to check before you say anything to anybody.
What it cannot: there is no email-open tracking, and there structurally cannot be, because notifications are plain text with no HTML body and a pixel needs somewhere to live. RelayLink records a send as attempted before the provider call, then records whether the provider accepted or refused it — so the trail distinguishes "we tried" from "the provider took it". Neither of those is delivery. There is no bounce handling and no complaint handling, so a hard bounce leaves no trace, and no delivered state exists anywhere in the vocabulary.
The sharp edge: a notification failure never fails an already-committed send. The package is in the database, the send reports success, and nothing retries the email — deliberately, because the provider's API has no idempotency key and a retry of a request that had actually succeeded would deliver your briefing to the same person twice. The failure is recorded rather than silent now, but nothing tells you it did not go. So "it definitely sent" is a claim about the record, not about their mailbox, and it is exactly the claim not to make in the first message back.
Two things this rules out rather than explains. If they had used the unsubscribe link on an earlier message, you would not be guessing — the next send is refused outright when you try to draft it, not swallowed silently (what that looks like from the sending side). And if the person has no RelayLink account, the email and its magic link are their entire experience of the product; there is no separate inbox for them to check and no assistant for them to ask.
The inverse case
Sometimes the missing message is theirs. If they say they replied, look with read items included — an inbound package stops counting as unread once it has been pulled by your assistant, opened on the web, or replied to, so something you glanced at last week will not resurface on its own. Checking a thread's state takes one question and settles it, and it is a better opening than an accusation in either direction.
The repair is short. Confirm the address, resend the substance somewhere else, and skip the forensics — nobody in the history of correspondence has been persuaded by a headers dump. If the message went nowhere and no one is disputing it, that is a different problem. If you would rather have a dated record of what was asked and when, connect your assistant. It will not stop a filter, but it does mean the next argument is about the answer instead of about whether the message existed.