Why I Built My Own Email Infrastructure

Most developers don't think about email infrastructure until it breaks something. The signup confirmation lands in spam. The password reset never arrives. A customer says they didn't get an invoice, support checks the logs, and the email shows as sent. It went out fine. It just never reached an inbox.

This is usually a deliverability problem, and deliverability problems are almost always configuration problems. SPF records that don't match the sending server. DKIM signatures that are missing or misaligned. DMARC policies that don't exist at all. None of this shows up in a typical "send email" tutorial, and most teams find out about it only after a mailbox provider quietly starts routing their messages to spam.

Prawnwire exists because I kept running into this same problem across different projects and got tired of solving it from scratch each time.

What deliverability actually depends on

Getting an email delivered isn't really about the email. It's about whether the receiving mail server trusts the sender enough to put the message in front of a person rather than filtering it away.

That trust comes from a handful of technical signals. SPF tells receiving servers which IP addresses are allowed to send mail for your domain. DKIM signs outgoing messages so the receiver can verify they weren't tampered with in transit. DMARC ties the two together and tells receivers what to do when a message fails those checks. Get any of these wrong, and your emails can technically send successfully while landing nowhere useful.

The frustrating part is that all three are usually configured once, correctly, and then forgotten. Until a domain's sending reputation degrades, or a new sending service is added without updating the records, and suddenly delivery rates drop with no obvious cause.

What Prawnwire does

Prawnwire is a transactional email platform built to handle this properly from the start. It provides SMTP infrastructure for applications that need to send transactional email (signups, password resets, receipts, notifications) with SPF, DKIM, and DMARC configured correctly and monitored on an ongoing basis.

The API layer is built on Hono with PostgreSQL for storage, currently running on top of established mail server software while the platform grows. The plan over time is to bring more of the mail delivery stack in-house, but the priority from day one has been getting the configuration right, not building everything from scratch before it's needed.

Why this is worth getting right

For most products, email is invisible infrastructure until it fails, and when it fails it tends to fail quietly. A signup flow with broken email delivery doesn't throw an error. It just loses users who never confirmed their account and never knew why.

Prawnwire is the version of that infrastructure I'd want underneath any product I'm building: configured correctly once, monitored continuously, and built so that deliverability isn't something you find out is broken from a support ticket.

Current status

Prawnwire is currently in private alpha, running on a small set of domains while the platform gets hardened. If you're interested in early access, reach out and I can let you know about availability.

More at prawnwire.com.