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, when the draft is refused and the error names the block.
That is the whole notification mechanism. A contact request you send them still answers like a successful ask — saying "you are blocked" would hand you a fact they did not choose to share.
What a block actually is
It is a stored state between two accounts, written from one of two URLs — /p/{token}/block in a briefing notification, /c/{token}/decline in a contact request. 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 from an email is reachable only by somebody who was actually sent something, since it rides on a token that arrived in a message — there is no standing block list to curate. And that link does not expire. It used to: the block was measured against the package's own thirty-day window, which meant the opt-out died before the reply link did, and somebody acting on a two-month-old email could answer it but not refuse it. So a block can now come from a message of any age.
A recipient who has an account has two more routes to the same state, and neither needs an email in hand: the contacts page in their account, and block_contact through their own assistant. What none of them is, is anything you can see.
It binds the pair, not one thread. A brand-new conversation on an unrelated topic, from you to them, is refused too. The error says "on this thread" and undersells that.
It is symmetric. They cannot write to you either. If they want to answer, they unblock first.
Where it is enforced
The send gate, when a draft is created and again when the send is confirmed, so a block that lands between those two still stops the message. The notification sender, independently, skips their address and logs the skip. Every reply path checks it — portal and package page show the refusal; inbound email stays silent, because mail saying the reply was not delivered is the disclosure.
A request link is checked in the same place and answers like the mail path. If they have published one and you write through it, the page thanks you exactly as it thanks anyone, and nothing is delivered or stored. The rule behind the split is who is asking: somebody signed in, or an assistant holding a key, is in a relationship with the account and gets told outright. A form anyone can open is not, and a refusal there would tell a stranger something the person who blocked them did not choose to share — as well as printing the account holder's own address on a page anybody with the link can load.
A block outranks an accepted pair. An established correspondent who blocks you stops delivery immediately. The relationship does not need to be unwound first.
Recipient addresses are canonicalised on the parsed mailbox. Display-name wrappers, stray whitespace and mixed casing resolve to the same account.
What it does not do
It does not delete anything already exchanged. Forward-looking, not retroactive.
It does not stop other people writing to them. One sender, not the world.
It does not follow them to an address they never registered, and it does not stop you using ordinary mail. What stops you there is not this software.
If they still hold a package link and reply on it, the reply can be written into the thread and the mail that would have told you is suppressed. You would find it only by checking your inbox.
They can lift it
There is an unblock — on their contacts page, and as a tool their assistant will run if they ask. It deletes the pair. The states the gate reads are accepted, pending, and blocked. "Formerly blocked" is not one of them, because restoring accepted would silently give back access they had already taken away.
After that you are strangers. To correspond again, someone invites and someone accepts.
Operators and the admin pages cannot unblock for them. The state was written by the person it belongs to. Closing an account keeps a block the other person placed; leaving is a poor way to be unblocked.
People mis-click, especially on a one-click unsubscribe. A block that could never be lifted would be its own trap. A block that quietly restored the old relationship would be a different one.
A relay block is not a filter
A spam filter changes what they see. The message is still composed and transmitted; it lands in a folder nobody opens. You can keep sending. Nothing on your side reports a failure.
A block at the relay changes what you can do. The message is not composed, not transmitted, and not delivered, because the system that would have carried it checks first. That is only possible when reaching somebody runs through a layer neither of you owns — which is why where a "no" is stored decides what it is worth.
What to conclude
Nothing personal is usually the right read. One gesture, no explanation required, taken at whatever moment your message arrived.
Do not 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. The first two are the same act with extra steps.
One block is noise; a pattern is data. Several in a week is a question about first contact, not about deliverability.
If you need the controls on their side, they are in how to block and unblock. If you would rather a first message earned a reply than a click, connect your assistant and send fewer, better ones.