Section
Guides
Deeper reference material and conceptual walkthroughs for running email infrastructure you own. 32 articles
Programmable Inboxes for AI Agents and E2E Tests
Programmable inboxes sit between email testing tools and agent infrastructure. A browser test needs a one-off address so it can sign up for a service and read the OTP. An AI agent needs its own address so it can receive replies, process attachments, and act under a separate identity from any human. The mechanics are similar: create an address, receive mail, expose the messages to code, and keep the authority narrow.
Why your email goes to spam and how to diagnose it
Spam placement is frustrating precisely because it is silent. A hard bounce gives you an SMTP code and a reason. A spam-foldered message gives you nothing: it was accepted, delivered, and quietly filed where nobody looks. So people guess. They reword subject lines, strip the word "free," add more text, and ship again, hoping. That is debugging by superstition, and it mostly does not work because the wording was rarely the problem.
How to build a white-label email platform for each client
White-labeling email sounds like a theming task and ends up being an infrastructure decision. A client-branded inbox with the wrong logo is embarrassing; a client-branded inbox where one client's query accidentally returns another client's mail is a breach. This guide walks the whole thing the honest way: what actually has to be branded, the two real multi-tenancy models and where each one hurts, and how to do it without reselling someone else's bill. At the end we show where a self-contained stack like Tinbox collapses the boilerplate, with the current limits stated plainly so you can plan around them.
How to warm up a new email sending domain
Warming up a new sending domain means starting at low daily volume and increasing it gradually, over roughly 4 to 6 weeks, while keeping recipients engaged and complaints near zero. A brand-new domain has no reputation. Gmail, Outlook, Yahoo, and the rest cannot tell a legitimate sender from a spammer who just registered acme-deals-2026.com an hour ago, so they default to suspicion: low send caps, aggressive filtering, and a spam folder placement until you prove otherwise.
Upgrade your self-hosted email stack without breaking sending
When you move off Gmail and Resend and Mailchimp onto your own Cloudflare account, you stop paying per contact and per email, and you stop handing your data to three vendors. You also inherit a job those vendors quietly did: shipping new versions without taking the service down. SaaS rolls forward behind a load balancer and you never notice. On your own D1 and R2 and Workers, the rollout is yours, and the failure modes are real: a migration that locks a table the live worker reads, a deploy that ships code expecting a column the database does not have yet, or a rollback you did not plan and now cannot perform.
Email migration with two-way sync: run Tinbox alongside an existing mailbox
The reason email migrations stall is not technical difficulty. It is that the failure mode is silent and expensive: if you flip MX and something is wrong, mail bounces or vanishes and you find out from an angry customer, not a monitoring alert. So the project sits in the backlog forever. The way out is to make the migration reversible at every step by running the new system alongside the old one, sending nothing through it until you trust it, and keeping the old mailbox authoritative the whole time. This guide walks that overlap strategy honestly, including the part most "two-way sync" pitches skip: real bidirectional sync is hard, and you usually do not want it.
Why you should separate transactional and marketing email
You should separate transactional and marketing email by sending them from different subdomains, each with its own DKIM key and DMARC policy, because mailbox providers score sending reputation per domain and your highest-complaint stream sets the ceiling for everything else. Receipts, password resets, and confirmations have naturally high engagement and near-zero complaints. Newsletters and campaigns have lower engagement and more complaints, no matter how good they are, because some recipients always forget they subscribed. Put both on one domain and the campaign's complaints lower the score that delivers the receipts.
SPF, DKIM, and DMARC setup: the three DNS records that get mail delivered
This guide is tightly scoped to those three records: what each one proves, the exact syntax, how to add them on Cloudflare DNS, and how to confirm they actually pass at the receiver. Everything around the records (warmup, reputation, bounce handling, list hygiene) is a separate topic covered in how warmup, reputation, and bounces work beyond the records. Set the records here; build the reputation there. If the surrounding jargon is the blocker, every email authentication acronym in one sentence each is a quick primer to read alongside this.
Avoid email spam traps with real subscriber list hygiene
The reliable way to avoid email spam traps is to remove the conditions they live in: collect addresses only through confirmed opt-in, never buy or scrape a list, and stop mailing addresses that have gone quiet. You cannot detect a trap directly. A trap address looks exactly like a real one, never opens, never clicks, never complains, and (in the worst case) never even bounces, so there is no signal to filter on. The defense is structural, not reactive: control what enters your list and aggressively remove what has stopped engaging. Do that and traps have nowhere to hide; skip it and a single dormant address can poison delivery to your entire list.
Self-hosted email for agencies: a per-client white-label playbook
Agencies end up reselling email whether they planned to or not. A client needs transactional sends, then a newsletter, then a shared inbox, and suddenly you are the line item that forwards a Resend bill, a Mailchimp bill, and a Front bill, marking them up a little and owning none of it. This is a playbook for the other model: deploy an isolated, white-label email stack per client on your own Cloudflare account, own the relationship, and keep the spread.
Multi-tenant email on Cloudflare: one account, every tenant
If you run email for more than one brand (an agency with clients, a holding company with several products, a builder with side projects on different domains), the first question is how the tenancy actually works. The honest answer for Tinbox is unusual enough that it is worth being precise about, because the wrong assumption leads to the wrong architecture. This guide is the technical mechanics: how brand-scoped naming works, how many tenants fit in one Cloudflare account, where the isolation boundaries are, and what is genuinely shipped versus what is still on the drawing board. The business and margin side (pricing clients, packaging the service) lives in the agency playbook on top of this model; this article is the plumbing.
How to migrate your team off Google Workspace email
Google Workspace is a genuinely good product. Gmail's spam filtering is excellent, the uptime is better than most teams can match, and the admin console is mature. None of that is in dispute. The reasons to leave are about ownership and cost, not quality: per-seat billing that scales with headcount whether or not those seats send much mail, subscriber and message data that lives on Google's terms in Google's regions, and a black box where you cannot inspect or replay how your own mail was handled. For a privacy-conscious team or a CTO answering data-residency questions in an audit, those are real. If you are still weighing the destination rather than the mechanics, the ways to move your team off Google Workspace email lay out the routes at a higher level before you commit to the steps below.
Handling email bounces and suppression the right way
Handling bounces correctly means doing two things on every send: classify each failure as permanent or temporary, and maintain a suppression list of addresses you must never mail again. Hard bounces (permanent) go onto that list immediately. Soft bounces (temporary) get a bounded retry, then get suppressed if they keep failing. The suppression list is checked before you send, not consulted after the damage is done. Skip either step and you re-mail dead addresses, your bounce rate climbs, and mailbox providers start treating your domain like a spammer's.
Meeting Gmail and Yahoo bulk sender requirements
If you send more than 5,000 messages a day to Gmail or Yahoo, you must do three things or your mail gets blocked: authenticate every message with SPF, DKIM, and DMARC (with domain alignment), support RFC 8058 one-click unsubscribe, and keep your spam complaint rate under 0.3 percent. These are not best-practice suggestions anymore. Since the rules took effect in February 2024, mail that fails them is rejected at the SMTP layer or filed straight to spam, and the failure is silent unless you read the bounce codes.
GDPR email data residency: keeping subscriber data in your own region
Most teams treat email as plumbing and never ask where the plumbing runs. Then a customer sends a data subject access request, or a security questionnaire lands with a "list all subprocessors and their data processing regions" field, or a German enterprise prospect's legal team asks for your DPA, and suddenly the location of your subscriber list is a board-level question. The honest answer for a typical stack (Gmail for human mail, a transactional sender like Resend or SendGrid, a marketing tool like Mailchimp) is that subscriber personal data is spread across three vendors, each in a region you didn't choose, each with its own chain of subprocessors you've never enumerated.
Testing email rendering across clients before you hit send
To test email rendering across clients before you send, render your template to its final HTML, lint the markup, then do a seed send: deliver the real message to test accounts you own at Gmail, Outlook, Apple Mail, and one mobile client, and inspect each on a real device, including dark mode and with images disabled. You cannot test every client perfectly, and you do not need to. You need to catch the four failures that actually happen in the wild: Outlook's Word rendering engine, dark-mode color inversion, blocked images, and layouts that collapse on narrow screens.
Backing up and restoring a Cloudflare email stack (D1 + R2)
Moving off Gmail and Resend and Mailchimp onto your own Cloudflare account buys you control, residency, and an end to per-contact pricing. It also hands you a responsibility those SaaS vendors quietly carried: if the data is gone, you are the one who has to bring it back. There is no vendor with a hot standby of your mailbox.
How to reduce your email spam score: write content filters trust
To reduce your email spam score, focus on the content signals filters actually evaluate (a working plaintext part, a sane text-to-image ratio, honest links, and a real unsubscribe mechanism) and stop chasing the folklore list of "trigger words" that modern filters mostly ignore. The single biggest lever is not content at all: it is reputation and authentication. But content does matter at the margins, and getting it wrong gives an already-skeptical filter the excuse it was looking for.
Email deliverability monitoring and alerts before mail goes dark
Email deliverability monitoring means tracking the leading indicators of sender reputation (bounce rate, complaint rate, blocklist presence, and authentication pass rate) and alerting the moment any of them moves the wrong way, so you act before delivery visibly fails. The defining property of a deliverability problem is that it is invisible until it is expensive: mail does not bounce loudly, it just quietly starts going to spam, and the only downstream signal is a slow drop in signups, replies, or revenue that you notice days too late. Monitoring closes that gap. It turns a silent multi-day slide into a webhook that fires within hours.
Email deliverability monitoring: catch problems before customers do
Email is the one part of your stack that can fail completely while reporting total success. A spam-foldered message is accepted by the receiver, delivered without error, and quietly filed where nobody looks. There is no 500, no exception, no log line that says "this went to spam." So most teams run blind: they find out mail is broken when a customer complains, which means by definition some number of customers already silently churned, reset nothing, and moved on.
Email deliverability guide: how warmup, reputation, and bounces actually work
This is the long version of the answer to "why does my email go to spam." It is not a checklist, because checklists imply deliverability is a finite task you complete. It is not. Deliverability is a discipline you run continuously: build reputation, watch the feedback signals, and stay off the lists that hurt you. This guide gives you the mental model and the practical levers, and it is honest about which of those levers you own and which a sending stack can pull for you. If you came here looking for the authentication record syntax, that is a sibling topic: see the three authentication records, in full. This guide owns everything around the records.
Build an email cost calculator to compare providers honestly
You cannot compare email providers by reading their pricing pages side by side. Each page is engineered to make its own number look small: the transactional sender anchors you on a per-email rate, the newsletter tool anchors you on a generous free contact tier, and the inbox quotes a low per-seat price. None of them shows you the same number, so there is nothing to line up. The honest comparison only exists once you put every provider through identical inputs and watch what each one charges. That is a cost calculator, and you can build a correct one in about thirty minutes.
Email blocklist removal: getting your domain or IP delisted
Email blocklist removal starts with confirming the listing, then fixing the cause, then requesting delisting, in that order. A blocklist (a DNSBL, RBL, or "blacklist") is a published list of IPs or domains that receiving mail servers query in real time to decide whether to accept your message. If you are on one a receiver consults, your mail is rejected or silently filed in spam before content filtering even runs. The frustrating part is that nothing in your own stack reports it: the rejection happens at the receiving end, and the only symptom is mail that quietly disappears.
First-party email analytics without sending data to a vendor
Open and click analytics are the one part of email almost everyone outsources without thinking. You drop in a sending SaaS, it rewrites your links and injects a pixel pointing at its domain, and you get a dashboard. The price is that your subscriber engagement data, arguably the most sensitive thing you hold about your list, now lives with a vendor, gets mingled into their analytics subprocessors, and shows up as another line in your privacy policy you have to disclose. For a privacy-conscious sender, that is exactly backwards: the people whose behavior you are measuring are your relationship, and the measurement should stay on your side of the wire.
Cloudflare D1 correlated subquery pitfalls and how to avoid silent wrong results
The dangerous part is not that D1 is a different database. It is that D1 is almost the same database. It is SQLite, your ORM speaks SQLite, your local test driver is SQLite, and 99% of your queries behave identically. So you stop thinking about portability. Then one query class, the correlated subquery used as a projected column, diverges, and because the divergence is in the values and not in an error, nothing in your pipeline flags it.
Passing a security audit with self-hosted email
Email is the part of the stack teams forget to threat-model until an auditor forces the question. A transactional sender holds every recipient address and the body of every receipt, reset, and notification you send. A marketing platform holds your entire subscriber list with names, tags, and engagement history. An inbox or webmail provider holds years of received mail and attachments. Each one is a third party processing your customers' personal data, which makes each one a subprocessor an auditor expects you to name, contract with, assess, and keep watching.
Cloudflare Pages vs Workers for an email app: which to host on
Both Pages and Workers can serve a web app on Cloudflare's edge, run server-side code, and bind to D1, R2, and KV. For a generic CRUD app the choice is mostly taste. For an email app it is not taste, because email has a specific shape: things arrive, things get queued, things run on a schedule, and a human looks at a UI in between. That shape lines up cleanly with one of these products and awkwardly with the other.
What the Cloudflare free tier actually covers for an email stack
The Cloudflare free tier carries a real email workload further than you would expect: 100,000 Workers requests per day, 5 million D1 rows read and 100,000 written per day with 5 GB of storage, 10 GB of R2 with free egress, and 10,000 Queues operations per day. For a small transactional sender plus a human inbox plus a modest newsletter, the binding limit is usually D1 writes per day or Queues operations per day, which works out to a few thousand emails per day before you pay anything. When you do cross over, it is a flat $5/month Workers Paid minimum, not a per-email charge.
Do you need Durable Objects for an email app on Cloudflare?
Short version: for the inbox itself, you want D1. Durable Objects are a sharp, valuable tool, but they solve a coordination problem most email apps do not have. Both are part of the small set of Cloudflare primitives every email stack is built on, and knowing which one each job belongs to is most of the battle. The trap is reaching for the more exotic primitive because it sounds like it fits ("a mailbox is stateful, Durable Objects are stateful state machines, therefore..."), then discovering you have to build SQL, indexes, and search from scratch inside it.
Buy, build, or self-host your email stack: a decision framework
There are three honest ways to put email behind your product: rent it from a SaaS (buy), write it yourself (build), or run a packaged stack on infrastructure you own (self-host). Most teams back into one of these by accident. This is a framework for choosing on purpose, with the tradeoffs stated plainly and the cases where each option genuinely wins.
Answer engine optimization: getting your docs cited by AI
Answer engine optimization (AEO), often used interchangeably with generative engine optimization (GEO), is the discipline of structuring content so AI answer engines extract, quote, and attribute it. The shift it responds to is concrete: a growing share of technical research now happens inside ChatGPT, Claude, Perplexity, and Google's AI Overviews, where the output is a paragraph, not a list of ten blue links. The unit of success is no longer the ranked page. It is the extracted sentence.
How to safely let an AI agent send email without it going rogue
Sending email is an irreversible, reputation-bearing action. You cannot un-send. And unlike a database write you can roll back, a sent message can torch your sending reputation, leak data, or annoy real humans, all from a single bad tool call. So the question is not "can the model send email" (any tool-calling model can) but "how do I constrain the send so the model's mistakes and the attacker's injections cannot turn into outbound mail."