Enter each recipient's full address, comma-separated, up to 50. Matching is exact — only addresses on the list are approved at the gate.
PDF Email Verification
Named people, listed exactly
Stops forwarded links dead
Records are named, not anonymous
Only approved emails get through.
Email verification turns a public share link into a named-recipient gate. Build an allowlist of addresses or domains; only matching readers receive a code and can open the PDF.
No account, no password, no sign-up flow on the reader side. They type an email, receive a code from that inbox, and they're in — if and only if the address is on your list.
Email allowlist
Up to 50 addresses
Named records
No reader account
Forwarded URLs still reach the verification page — but outsiders never receive a code, so the PDF never renders.
Each opener identifies themselves via email. Your access log shows names, not just IPs — much more actionable.
Verify email
Allowlist gate
Named opens
Works on any device
The gate is a web page. Readers verify on desktop or phone with no app install.
Layered with other rules
Combine with open limit, expiry, watermark, and view mode for layered protection.
Workflow
From allowlist to verified open in four steps.
You configure the allowlist once during upload; every subsequent reader session passes through the same gate.
1
Build the allowlist
On the upload page, paste in the recipients’ full email addresses, separated by commas. This is the gate that decides who can proceed.
2
Send the same link
Share one link or QR with everyone. Each reader will verify their own email — no per-recipient links needed.
3
Reader verifies
Reader enters their email. If it's on the list, a code arrives in that inbox. They enter the code and the PDF opens.
4
Named record logged
The verified email and timestamp are saved against the share, so you know who opened what and when.
Non-approved addresses never receive a code — so they can't get in by guessing.
Approved readers can come back later with the same email; no re-invitation needed.
The list is fixed at upload. To change it later you replace the share — same link, new settings.
The Allowlist
How you write the list, and how you change it later.
The list is a set of complete email addresses, separated by commas, up to 50 of them. It is fixed when you upload — but the share can be replaced at any time, and the replacement carries a new list.
Full addresses, comma-separated
- Each entry must be a complete address —
[email protected], not@company.com. - There are no domain wildcards. Matching is exact, so a bare domain matches nobody.
- To cover a whole team, paste the batch in — copy the addresses out of your address book or staff list and separate them with commas.
- Up to 50 addresses per share. Records show each recipient's address beside the timestamp.
Replace the share, keep the link
- There is no in-place editor for the allowlist — nothing to open and retype.
- Instead you replace: upload a second PDF with the list you now want, then point the original reading link at it.
- The link people already have keeps working and stays the same; the allowlist behind it changes.
- Replacing moves a whole set of settings at once, not just the list — see below.
Replacing a Share
Two routes to the same result — with or without an account.
Both routes take the settings from a second PDF you uploaded and apply them to an existing reading link. Which one you use depends on whether you were signed in when you created the share.
Guest replace
maipdf.com/pdf/replace-file.html
- Needs four values: the current reading link (or code) and its modification code, plus the new PDF's reading link (or code) and its modification code.
- Proves ownership with the modification codes, so no sign-in is required.
- Carries over: the file, the session length, the open count, the expiry date, the read-alert setting, and the email allowlist.
- Keep your modification codes. Without them this route is closed to you.
Control Center replace
maipdf.com/6/control-center.html
- Both PDFs must sit in the same account; you pick them from your list instead of typing codes.
- Carries over: the file, the session length, the open count, the read-alert setting, and the email allowlist.
- Does not change the expiry date — the original deadline stays in force. This is the one difference from the guest route.
- Convenient when you manage many shares, since nothing has to be copied by hand.
Replacing moves a set of settings, not one field. Check the second PDF's open count and password before you replace, or you will inherit those too.
Because the open count travels with the replacement, the same action is how you top up a share that has run out of opens.
Reader Flow
What the approved reader sees.
The gate is light and familiar — no account, no installation, no captcha theatre. Most readers are through in under 30 seconds.
1
Open the link
They click the link or scan the QR. A lightweight MaiPDF page asks for an email address — no form fields for name, phone, or password.
2
Enter approved email
If the address is on the allowlist (individual or domain match), MaiPDF emails them a one-time code. Otherwise they see an access-not-available message.
3
Enter the code
They paste the code from their inbox into the verification field. The PDF loads inside the MaiPDF viewer.
4
Read the document
They can read, and — depending on your view-mode choice — print, download, or only view on-screen. Their open is logged against their verified email.
No reader account is ever created.
The code is sent only for addresses on the allowlist.
Returning readers typically re-verify quickly — often in one click.
Use Cases
Where email verification earns its keep.
Email gating shines when "who the reader is" matters — not just "does someone have the link".
HR & legal
Share offer letters, contracts, or internal HR documents only with named recipients. No more chasing whether the right person opened the right draft.
- Individual allowlist for each named recipient.
- Combine with view-only to keep drafts off personal devices.
- Records show each signer's email.
Education & training
Restrict course material to students on a school or organisation domain, without maintaining a class roster inside MaiPDF.
- Paste the class list of student addresses into the allowlist.
- Set an expiry for the end of the term.
- Download usually allowed for offline study.
Sales & business development
Share a detailed proposal with a shortlist of known contacts; prevent forwards to competitors or unintended parties.
- Individual allowlist for the decision-maker group.
- Layer with Telegram read alerts for real-time follow-up.
- Replace the share if the proposal evolves — same link, new file.
Internal comms
Make a confidential memo or all-hands deck readable only by the staff you list — not by the open internet.
- Paste the staff addresses from your directory into the allowlist.
- No-download to keep the official copy central.
- Records provide audit trail of who opened the notice.
Investor relations
Send the latest fundraising deck or diligence pack only to investors you've met with — no more accidental deck leaks to the wider VC grapevine.
- Individual allowlist for each investor.
- Combine with the dynamic watermark; move to App DRM if screenshots are the real concern.
- Swap the file per round without issuing a new link.
Consulting & research
Limit a confidential deliverable or a draft report to the specific client team agreed in the engagement letter.
- Mixed allowlist: named partners + client domain.
- View-only for draft reports; download allowed for final.
- Named records make sign-off much cleaner.
Compare
Email verification vs. the usual alternatives.
Most "share-only-with-these-people" needs are solved by one of three approaches — here's how email verification stacks up.
| Approach | Friction for the reader | Who can actually open | Record quality |
|---|---|---|---|
| Shared password | Low — one password for everyone | Anyone the password reaches — including forwards | Anonymous (no identity) |
| Per-recipient link | Low, but you must build and track many links | Whoever holds each specific link | Per-link, not per-reader |
| Full account / SSO | High — sign-up, password, MFA | Whoever can pass account sign-up | Strong, but heavy for one-off shares |
| MaiPDF email verification | Low — type email, paste code | Only addresses on your allowlist | Named email per open |
No shared password to leak or rotate.
One link serves everyone — you don't manage dozens of URLs.
Friction stays low; security stays high.
Records
Named opens, not anonymous hits.
Because every opener verifies an email, the access log is a clean list of recipient emails and timestamps — not just a stream of IP addresses.
Named opens
Each entry shows the verified email that opened the PDF, plus the time and, where possible, the region.
Counts per address
See how often each recipient opened the file. Useful signal for engagement — or for spotting a single address being shared around.
Works with read alerts
Layer Telegram read alerts on top; each alert can include the verified email so you know exactly who opened it in real time.
Exportable audit trail
Review-ready log for compliance, board reporting, or sales follow-up — named, not anonymised.
FAQ
Questions that come up before the first gated share.
If you're on the fence about email verification, these answers usually cover it.
How does the allowlist actually decide who's in?
You enter the approved addresses during upload, separated by commas. When a reader types an email, MaiPDF checks it against the list. Matches get a code by email; non-matches are stopped with an access-not-available message and never receive a code.
Can I allow an entire domain like @company.com?
No — MaiPDF has no domain wildcards. Matching is exact, so an entry of
@company.com approves nobody at all. What you do instead is paste the addresses in: copy the staff or class list out of your directory and drop it into the allowlist field, separated by commas, up to 50 per share. It takes one paste, and it has an advantage over a wildcard — the records name exactly who opened the file, and nobody who later joins that domain gets in automatically.Do recipients need a MaiPDF account?
No. The gate is just two fields — email and a one-time code from the inbox. No password, no sign-up, no profile. That keeps friction low even for non-technical recipients.
How do I format the list, and how many addresses fit?
One complete address per entry, separated by commas —
[email protected], [email protected], [email protected] — up to 50 addresses per share. Internal and external recipients sit on the same list; there is no separate field for them. Because matching is exact, check for typos and stray spaces before you upload: a mistyped address simply never receives a code, and the reader sees the same “not available” message as a stranger would.What happens if a reader mistypes their email?
If the typo still matches a list entry (e.g. a colleague's address), a code will be sent there — so your list entries should be correct. If the typo does not match, no code is sent and the reader can simply type again.
Can I change the allowlist after sharing?
Not by editing it — there is no screen where you open the list and retype it. You change it by replacing the share: upload a second PDF carrying the allowlist you now want, then point the original reading link at it. The link your recipients already have keeps working and stays the same, but the allowlist behind it is now the new one. Two routes do this: without an account, maipdf.com/pdf/replace-file.html, which asks for both reading codes and both modification codes; signed in, maipdf.com/6/control-center.html, where you pick both PDFs from your own list. One caution: replacing moves a set of settings — the file, password, open count, read alerts and the allowlist all travel together — so check the second PDF’s settings first. The guest route also carries the expiry date across; the signed-in route leaves the original deadline in place.
Can approved readers open the PDF more than once?
Yes, unless you've also set an open limit. Email verification is about who can open; the open limit controls how many times. Combine them for tighter control (e.g. a single named recipient with an open limit of 3).
Does email verification work with Telegram read alerts?
Yes. The two settings coexist on the same panel. With both on, each verified open also triggers a Telegram alert — so you know in real time which named recipient just opened the PDF.
How is this different from a password-protected PDF?
A password is one secret shared among everyone — it leaks, it stays the same, and your records are anonymous. Email verification is per-reader: each recipient proves control of their own inbox, so records are named and forwarded links are useless to outsiders.
Can I use email verification for a public-facing share?
Usually no — it is designed for named or organisation-scoped audiences. For public-facing distribution, skip email verification and rely on open limits, expiry, watermarking, and view mode instead.
Does MaiPDF support SMS verification instead of email?
Yes, but on a different site. This page describes maipdf.com, the international version, which verifies by email. The Chinese version at maipdf.cn verifies by SMS — the allowlist holds mobile numbers and the one-time code arrives as a text message. It accepts mainland Chinese mobile numbers only (11 digits beginning with 1, sent with a
+86 prefix). It exists because email is far less widely used in China: many readers there have a phone number but no working email address, so an email gate would lock them out. Otherwise the two work the same — a 6-digit code valid for 5 minutes, matched exactly, no wildcards. The two sites are separate, so a share made on one is not managed from the other.Why are maipdf.com and maipdf.cn separate systems?
Network reachability. Getting to a server outside mainland China from inside it — or the reverse — is often slow and sometimes fails, so running one global stack would leave half the readers with a bad experience. The two are therefore entirely separate systems on separate infrastructure: maipdf.com runs on Cloudflare, maipdf.cn runs on Tencent Cloud. That is also why reader verification differs — email on .com, SMS on .cn — and why .cn has no Telegram alerts, since Telegram is not reachable there. Because they are separate systems the data does not cross over: a share made on one cannot be managed from the other, and accounts, reading codes and access records are independent. Choose the site by where your readers actually are.
Product boundary · Online Sharing vs App DRM
Use the browser for reach. Use the app for capture protection.
Everything on this page describes online sharing — a link opened in an ordinary browser. A browser cannot refuse an operating-system screenshot, so no online setting blocks Win+Shift+S or a phone screenshot; what it gives you is reach, records, and rules you can change after sending. When you need the capture itself blocked — encrypted .maipdf files, device binding, remote revoke — that is MaiPDF App DRM, a separate route where the reader installs an app.
Regional Versions
Two versions of MaiPDF, two ways to verify a reader.
Everything on this page describes maipdf.com, the international version, which verifies readers by email. A separate Chinese version runs at maipdf.cn and verifies by SMS instead.
Email verification — international
- The allowlist holds email addresses. Approved readers receive a one-time code in their inbox.
- Works for recipients anywhere; no phone number is ever collected.
- This is the version documented on this page.
SMS verification — China
- The allowlist holds mobile numbers. Approved readers receive the one-time code by text message.
- Mainland Chinese mobile numbers only — 11 digits beginning with 1, sent with a
+86prefix. - It exists because email is far less widely used in China than elsewhere; many readers there have a phone number but no working email address, and an email gate would simply lock them out.
Apart from what is being checked, the two behave the same way: a 6-digit code valid for 5 minutes, matched exactly against the list, with no wildcards on either side.
Why there are two systems at all: the network. Reaching a server outside mainland China from inside it — or the reverse — is often slow and sometimes fails outright. So the two are entirely separate stacks on separate infrastructure: maipdf.com runs on Cloudflare, maipdf.cn runs on Tencent Cloud. Readers open whichever one is on their side of that boundary, and the speed difference is large.
Because they are separate systems, the data does not cross over either: a share created on one is not managed from the other, and accounts, reading codes and access records are independent. Pick the version that matches where your readers are and how you can actually reach them.
Start Here
Build the allowlist, then share the link.
Upload your PDF, paste in the approved email addresses, and copy the gated link. Only those inboxes can receive a code — with a named record for each open.