Nothing tells you at the time. There is no bounce, no notice, and no change you could have spotted from your side. You find out the next time you try to write to that person, when your assistant's attempt to draft the message fails and hands back an error naming the block.
That is the whole notification mechanism. What happened in between is worth understanding precisely, because a block placed at the relay is a different sort of object from the ones senders are used to.
What a block actually is
It is a stored state between two accounts, written from one URL — /p/{token}/block. Following the link from the footer asks one question with one button; a mail client's native unsubscribe control POSTs straight to the same URL and skips the question, which is the RFC 8058 one-click convention. The confirmation exists because mail scanners prefetch links, and a block that fired on a prefetch would sever a correspondence nobody chose to end. There is no login and no account: the authorisation is the per-package token itself, 256 bits of randomness that arrived in the recipient's mailbox and that the sender has never held. They see a page saying they will no longer receive RelayLink messages from you, and that is the end of their involvement.
Two things follow from that shape. Blocking is reachable only by somebody who was actually sent something, since it rides on a package token — there is no standing block list to curate, and no block control inside a recipient's assistant. And tokens expire, thirty days by default, so the block came from a message recent enough that its link still worked.
Where it is enforced
In two independent places, both server-side.
The send gate refuses to create or confirm any further package from you to that person. It runs when the draft is created and again when the send is confirmed, so a block landing between those two moments still stops the message. Separately, the notification sender re-checks before composing anything, skips that recipient's email, and logs the skip. Neither is a preference your assistant can decline to honour. They are conditions of the send happening at all.
A block also outranks acceptance — the blocked check runs first, so an established correspondent who blocks you stops delivery immediately, without the relationship needing to be unwound.
And it binds the pair rather than the conversation. The error your assistant receives says the recipient has blocked messages "on this thread", which undersells what happened: a brand-new thread on an unrelated topic, from you to them, is refused too.
What it does not do
It does not delete anything. Packages you already sent stay where they are and the thread keeps its history on both sides. Blocking is forward-looking, not retroactive.
Because the stored state carries no direction, the email suppression cuts both ways. If the person who blocked you later replies using a magic link they still hold, the reply is written into the thread, but the email that would have told you about it is suppressed. You would find it only by having your assistant check your inbox.
It is also one sender, not the world. The block binds you to that person and nothing else — other people can still make a first contact with them under the ordinary consent rules, and your ability to reach everyone else is unchanged.
It does not come back
There is no unblock tool, no endpoint, and no support flow. The operator provisioning path explicitly refuses to overwrite a blocked relationship when it re-provisions accounts. There is no moderation queue and no admin console either, which cuts pleasantly both ways — nobody is sitting in judgement of you, and there is also nobody to persuade. The state was written once, by the person it belongs to, and it stands.
That is a design decision rather than an oversight. A reversible block is a block the recipient has to defend, and the point of putting the control in their hands was to make declining cost them one deliberate press and nothing afterwards.
A relay block is not a filter
This is the distinction worth carrying away, and it applies well beyond one product.
A spam filter changes what the recipient sees. The message is composed, transmitted, accepted, and then sorted into a folder nobody opens. The sender's capability is untouched — they can keep sending indefinitely, and usually do, because nothing on their side reports a failure. Enforcement lives downstream of delivery, inside the recipient's software, and the recipient pays for it with classification work that never ends.
A block enforced at the relay changes what the sender can do. The message is not composed, not transmitted, and not delivered, because the system that would have carried it checks first and declines. That is only possible when the sender's ability to reach somebody runs through a layer neither party owns, which is the difference between a request to stop and a condition of delivery — and the reason where a "no" is stored decides what it is worth.
For a sender, the practical consequence is a fair trade. Under a filter you can be ignored for months and learn nothing. Under a relay block you learn on your next attempt, and you are structurally unable to continue in the meantime.
What to conclude, and what not to do
Nothing personal is usually the right read. A block is one gesture, requiring no explanation, taken at whatever moment your message happened to arrive. It is not a verdict on your idea or your writing. It is somebody closing a channel with the cheapest tool available, which is exactly what the tool is for.
Never route around it. Not a second address, not a colleague relaying the same ask, not a fresh thread with a different topic. The last of those is refused anyway, and the first two are the same act with extra steps. The design makes the obvious routes structurally hard rather than merely frowned upon — the gate runs twice, the email suppression is independent of it, and recipient addresses are canonicalised on the parsed mailbox, so display-name wrappers, stray whitespace and mixed casing all resolve to the same account. Be honest about where that ends, though. A block is stored between accounts, not against an email address. It does not stop you writing to that person from your ordinary mail client, and it does not follow them to an address they never registered. What stops you there is not the software.
One block is noise; a pattern is data. A single stranger clicking unsubscribe tells you nothing actionable. Several in a week tells you something about volume, aim, or the size of what you were asking of people who had never heard of you. That is a question about how first contact differs from correspondence, not a question about deliverability.
If blocks are becoming a live concern, the useful next read is the consent model you are already operating inside, because it describes the ceiling before you hit it. And if you would rather a first message earned a reply than a click, connect your assistant and send fewer, better ones.