The blog
Engineering notes on owning your email stack
Deep dives, honest comparisons, and field notes on running your own inbox, sender, and newsletter on Cloudflare. 97 articles
Generate and rotate DKIM keys for sending on Cloudflare
DKIM (DomainKeys Identified Mail) lets a receiver confirm that mail claiming to be from your domain was signed by someone holding your private key, and that the signed parts were not altered in transit. It is half of what DMARC needs to pass (SPF being the other half), and on a new sending domain it is non-negotiable: Gmail and Yahoo bulk sender rules treat missing DKIM as a reason to throttle or reject. It is one box on the Gmail and Yahoo bulk sender checklist you have to clear before a first campaign.
Latest
Email to task automation: turn inbound mail into actions
Email to task automation is the practice of reading each inbound message, deciding whether it implies an action, extracting the fields that action needs, and creating the task (or firing the webhook) without a human retyping anything. The mail is structured data wearing a text costume. The job is to undress it once, reliably, and route it.
Email for AI agents: give your agent its own address and inbox
To give an AI agent its own email, you provision a real address ( agent@yourdomain.com ), route inbound mail to a handler that stores it, and expose both reading and sending as scoped tools the agent can call. The agent becomes the principal: it owns the mailbox, reads through typed tools instead of a screen, and sends from its own address over an HTTPS API. This guide builds the whole thing the hard way first (MX routing, MIME parsing, a message store, an HTTPS send path, and a scoped tool layer), then shows the one-command version at the end.
Self-hosted email tracking: open and click tracking that respects privacy
Email analytics is one of the few places where the "just use the vendor" answer quietly costs you something real: every open pixel and every wrapped link in a typical campaign points at the vendor's tracking domain, not yours. That means your subscriber list, their open behavior, and their click behavior all pass through someone else's infrastructure. For a transactional receipt that might be fine. For a newsletter you are trying to keep private, or a product where subscriber behavior is sensitive, it is a leak you signed up for without noticing.
Build a SaaS onboarding email sequence triggered by product events
"Send a welcome email" is trivial. "Send a five-step onboarding sequence that branches on behavior and shuts up when the user converts" is a small state machine running once per user, and that is where the real work lives. The naive version, a cron that fires "day 3" email to everyone who signed up three days ago, is worse than nothing: it emails people who already activated, it double-sends when invocations overlap, and it keeps drip-ing users who long since converted.
Process bounce and complaint webhooks into a suppression list
Bounce and complaint webhooks are not the hard part. Providers (Resend, Postmark, SendGrid, SES) all emit them, and receiving an HTTP POST is trivial. The work is the loop after the POST: verify the payload is real, classify what kind of failure it is, decide whether the address gets one strike or several, write it to a suppression list, and (the step everyone forgets) check that list before the next send. This tutorial builds that whole loop by hand on Cloudflare Workers and D1, including the failure modes that quietly let suppressed addresses slip back into your sends. At the end, the shortcut if you would rather register the flow than maintain it.
How to check SPF, DKIM, and DMARC are actually passing
The only way to know SPF, DKIM, and DMARC are actually passing is to read the Authentication-Results header on a message that a real receiver accepted. Send a test email to an account you control at Gmail or Outlook, open the raw source, and read the spf= , dkim= , and dmarc= verdicts the receiver wrote. A green checkmark in a vendor dashboard tells you a DNS record exists. The Authentication-Results header tells you the record evaluated to pass against the IP you actually sent from, with the keys you actually signed with. Those are different facts, and the gap between them is where mail quietly goes to spam.
Email archival to R2 cold storage while keeping search working
Email is append-only and mostly cold. You read a message once, maybe reply, and then it sits there forever. The bodies, especially the HTML ones, are by far the largest part of a message and the part you almost never look at again. Keeping all of that hot in your primary database is the email equivalent of renting climate-controlled storage for boxes you will never open.
Rate limiting your email API on Cloudflare Workers
An open send endpoint is the most dangerous route in your whole app. Not because of the bill (Workers and edge sending are cheap), but because volume is reputation. Senders earn deliverability slowly and lose it fast, and a runaway loop or a stolen token can burn through years of good behavior in an afternoon. A rate limit is one of several defenses that protect that standing; the rest are in the ways to build and protect your sender reputation, and a sudden unthrottled burst is itself one of the reasons transactional email lands in spam. The fix here is a per-caller rate limit that caps how much any one client can send in a window.
DMARC report analysis: reading aggregate reports without a paid tool
DMARC monitoring services exist because the raw reports are unfriendly: gzipped XML, one per provider per day, in a schema most people never learn. Those tools charge monthly to draw you a dashboard on top of data the providers already mail you for free. The dashboards are nice. They are also not necessary to answer the only questions that matter: who is sending as my domain, and is it authenticating?