Launched this week
InboundVerify
Email Ownership Verification
9 followers
Email Ownership Verification
9 followers
InboundVerify makes email ownership verification simple. Skip SMTP setup, verification emails, and email templates. Create a verification task, let users send an email to a unique address, then get the result through a simple API. Perfect for user registration, account recovery, automated testing, and developer tools. Fast integration, developer-friendly, and free to start.
How do you handle the deliverability side, like bounce handling or spam folders, since the user is just sending to a unique address?
@ouzhanwebe6kif I use Cloudflare Email Routing as the inbound mail gateway.
Users send an email to a unique address (e.g. verify+token@mydomain.com). The domain's MX records point to Cloudflare, so the entire SMTP receiving process is handled by Cloudflare rather than my own server.
Regarding deliverability, my service is receive-only. It never sends verification emails, so traditional outbound deliverability concerns—such as IP reputation, sender warm-up, or bulk email optimization—don't apply. Users are simply sending an email from their own mailbox to a unique address, just like they would to any normal email address.
For spam, Cloudflare handles the SMTP receiving layer, while my backend only processes emails that have already been accepted by Cloudflare. More importantly, not every address is considered valid by my application. Every unique address must first be created by the API and registered as an active verification task. When the Email Worker forwards a message, my backend verifies that the corresponding token exists and is still valid. If the address was never generated by the API or the verification task has expired, the request is rejected. So even if someone sends an email to a random address like verify+randomstring@mydomain.com, it will never produce a successful verification.
For bounces, if the sender's mail server cannot deliver the message to Cloudflare (for example, due to a DNS or SMTP issue), the sender receives the standard SMTP bounce generated during mail delivery. My API only returns a successful verification after Cloudflare has accepted the email, the Email Worker has processed it, and the backend has confirmed that the recipient corresponds to a valid verification task. As a result, failed deliveries or invalid addresses can never be reported as successful verifications.
In short, I deliberately separate the SMTP receiving layer from the verification logic. Cloudflare is responsible for mail reception, while my backend only accepts verification requests for pre-generated, valid addresses. This keeps the system simple, avoids running my own mail infrastructure, and prevents random or malicious emails from affecting the verification process.
Skipped the SMTP setup and got verification running in under five minutes, the API response was clean and exactly what I needed for a side project registration flow.
Skipping the whole SMTP dance for email verification is a nice win, and the unique-address approach feels way simpler than juggling templates. The API response looks clean enough to plug into a signup flow in an afternoon.
a webhook option alongside the polling API would be really helpful so we don't have to keep checking task status in our registration flow
Skipped the SMTP setup headache and just had users email a unique address. Took maybe ten minutes to wire up and the API response was clean and obvious.
Spent a few minutes with the API and was surprised how painless it was, no SMTP setup actually means no SMTP setup. The unique-address approach feels way cleaner than the token-in-template workflows I have wrestled with before.