How to deliver a lead magnet without a full email platform

Delivering a lead magnet is three jobs at once: confirm the address is real, hand over the file, and record who took it. The usual rig — form, autoresponder, PDF attached — does the middle job and fumbles the other two. The alternative is to send a link that does the confirming itself. The reader enters an email, gets a six-digit code, types it in, and the download starts. The address is proven before the file moves, and what you keep is a list of people who have demonstrably read one of your emails.

The three jobs, and the one you're probably skipping

Confirm the address. Your form checked that the string had an @ in it. That is a shape test, not a confirmation, and it passes [email protected] as happily as it passes a real mailbox. Nothing downstream fixes this — every report you build later inherits it. There's a longer argument about what separates a typed address from a collected one if you want it.

Hand over the file. The part everyone builds. It is also the part where you decide, usually without noticing, whether the file stays yours after it leaves.

Record who took it. Not the same as recording who signed up. People verify an address and never download; people download the same file four times across two weeks. If you only log the form submit, you're counting intentions.

Why the attachment is the worst option

Emailing the PDF feels like the direct route. It fails in four separate places, and three of them are silent.

It stakes everything on one cold email arriving. No sending history with that recipient, no prior engagement, and a multi-megabyte attachment bolted on. That is close to a spam filter's description of what it exists to catch. When it lands in the junk folder, the reader doesn't check the junk folder — they decide you never sent it.

A typo fails at the worst possible moment. Someone types [email protected], hits submit, sees "check your inbox", and leaves. Your bounce arrives ninety minutes later, addressed to nobody. The reader is gone, the file was never delivered, and the row in your list is dead weight. The only useful moment to catch a wrong address is while the person is still on the page and still wants the thing.

Once it's in an inbox it's a copy, not a link. Forwarded to a colleague, it arrives with no trace back to you. Discover a mistake on page four and every copy already sent is the wrong one. Decide the pricing sheet shouldn't be circulating any more and there is nothing to switch off.

Size limits are set by the recipient, not by you. Attachment caps run to a few tens of megabytes at consumer providers and lower at plenty of corporate gateways. A design template or a video walkthrough doesn't make it through, and the failure is a bounce the reader never sees.

Attachment against gated link, side by side

The link-based version, start to finish

In Replilo the whole delivery path is four steps and none of them involve a mail platform:

1. Upload the file. You get back a short link — replilo.com/s/… — straight away.
2. Put that link wherever the offer lives: a landing page button, a post, the last slide of a talk.
3. A reader opens it and enters an email. The domain is checked against a mirrored blocklist of disposable providers, and its DNS is checked for MX and SPF records, before anything is sent. Then a six-digit code goes out.
4. They enter the code. The download starts, and they're stored as a verified subscriber. Access is remembered per link, so when they come back for the file next month it just downloads.

Notice which email is doing the work. It's a six-digit code with no attachment, sent to someone who is sitting on the page waiting for it — the easiest message in the world to get delivered, and the one piece of mail you can be sure gets opened. The file itself never travels by email at all.

The link carries its own controls once it's out there: an expiry date for material that goes stale, a download cap when you're sharing with a known group, a custom slug when the URL has to be readable out loud, and a pause switch for the afternoon you realise it went to the wrong list.

Getting the record out without building anything

A delivery step that records nothing is just a download button with extra stages. Two events matter and they're worth keeping separate: subscriber.verified when someone proves an address, and document.downloaded when the file actually moves.

Both fire as webhooks, signed with HMAC-SHA256 so your endpoint can tell they came from us, and retried with backoff so a deploy in the middle of a campaign doesn't lose the row. If you'd rather not run an endpoint at all, you can point the webhook at a spreadsheet instead — there's a walkthrough in sending subscribers to a webhook or a Google Sheet.

There's also an MCP server for assistants, which matters more than it sounds when the file was written in a chat window twenty seconds ago: the assistant uploads it and hands back the share link without you opening a dashboard.

The short version

The attachment gives away the file and keeps the guesswork. A verified link inverts that — the file stays behind something you control, and the address is proven while the reader is still in front of you. If you get one thing out of the delivery step, make it the confirmation, because it's the only part of a lead magnet that can't be fixed after the fact. What arrives at a wrong address is gone; what's checked at the door is a subscriber. And if the addresses you're getting look real but behave like they aren't, the next thing to read is how to block disposable email addresses, which is a different problem with a different fix.