You send a delivery link, the reply is 'blocked by our security policy.' Nothing is wrong with your file. Here's what actually inspects a link between you and them, why unfamiliar domains lose that inspection, and what you can do from your side.
You finish a deliverable, you send the link, and the reply comes back:
"It's blocked by our security policy."
Or "our firewall won't let me open it," or the message just never arrived. The natural first move is to check your file, re-upload it, and send it again. That almost never works, because the file was never the thing being judged.
Between you sending a link and a person clicking it, the address usually passes through two or three things that never see the content: the mail gateway that scans the message, the network filter on the recipient's office connection, and sometimes the browser's own safe-browsing check.
All three make their decision from the URL and its domain. They look at signals like:
A private delivery link scores awkwardly on several of those by design. It's long and unguessable because that's what keeps it private. It's on a shared service domain, so it inherits the reputation of everyone else using that service rather than yours. Neither of those has anything to do with whether your page is safe, and the filter has no way to tell the difference.
This is a different failure from the one where an AI tool's share link asks your reader to log in. That one happens after they reach the page, and it's about identity. This one happens before, and it's about reputation.
Ask for the exact wording. It's the fastest diagnostic available and it costs one message.
| What they say | What it usually is |
|---|---|
| "It asks me to sign in" | Identity — the page wants them inside a workspace |
| "It's blank" / "it expired" | The link depended on a session or a window that's closed |
| "Blocked by policy" / "security" / names their IT vendor | A gateway or network filter — this article |
| Nothing arrived at all | The message itself was quarantined, often for the link |
Only the third and fourth are what we're talking about here, and they're the two you can't diagnose from your own machine — the link opens perfectly for you, which is precisely why it's confusing.
Send the address as text, not as a button. A linked "click here" hides the destination, and hidden destinations are what phishing filters exist to catch. A visible URL in a plain sentence gets treated more gently by several gateways, and it also lets your reader see where they're going before they commit.
Ask them to try it off the network. If it opens on their phone with wifi off, you've learned the block is their corporate network rather than the domain's general reputation — and that changes who can fix it. It's now a two-line request to their IT, not a problem you can solve by changing tools.
Don't stack redirects. A short link pointing at a tracking link pointing at the page is three domains to be suspicious about instead of one. If you're already fighting a block, take the middle layers out.
Use a domain that belongs to you. This is the real lever, and the reason it works is straightforward: reputation attaches to domains, and a shared service domain can't lend its reputation to you specifically. A custom domain on Studio ($14.99/mo) puts your deliveries on an address your client's systems can build a history with — especially if it's the same domain their mail already comes from. It isn't instant. A brand-new domain starts with no history either. But it's the only one of these four that compounds.
The decision is made by software inside your client's organisation, configured by people you'll probably never speak to, using rules written for a company with different risk than yours. No hosting choice overrides that. If a policy declines the whole "file sharing" category, a better-behaved link in that category is still in that category.
Which is worth saying plainly, because the alternative is a promise nobody can keep. What a delivery link can do is avoid adding reasons — render as a page rather than a download, live on a domain that's yours, sit behind no redirect chain, and look to the reader like the thing they were expecting. After that, the remaining variable is a policy, and policies respond to a request from their own colleague far better than to anything you send.
For a recurring client, that request is usually worth making once. It fixes every delivery after it — which is a much better outcome than switching to an attachment and hoping the size limit holds.
The attachment arrived, nothing was blocked, and your recipient sees markup instead of the page. That's three different email failures people keep merging into one. Here's which one you hit, and why the fix isn't a different attachment.
Upload an .html file to Drive, open it, and you get a wall of markup instead of the page. Nothing is broken — Drive is doing exactly what a filing cabinet does. Here's the mechanism, the workarounds people try, and what actually renders it.
PDF is built for archive and print. HTML is built for live, browser-native delivery. Where the three differences — interactivity, weight, single source of truth — actually decide which format ships.
miinideck turns a single HTML file into an unguessable link with optional password and expiry. Default-private, never indexed.