9 Cloudflare Email Mistakes That Land Your Mail in Spam

Cloudflare is a fine place to send email from. The trouble is that nobody hands you a safety net: when you wire up sending yourself, every default a managed provider would have set is now yours to get right.

Most "Cloudflare email" problems are not Cloudflare problems at all. They are the ordinary deliverability mistakes that a SaaS sender used to hide from you, now exposed because you are holding the wires directly. The nine below are the ones that quietly route good mail to spam or get it rejected outright. Each has a fast fix.

1. Sending without DKIM (or signing with the wrong key)

No DKIM signature is the single fastest way to land in spam. Gmail and Yahoo now require it for bulk senders, and most filters treat unsigned mail from a custom domain as suspect. On a self-wired Cloudflare stack there is no provider quietly signing for you, so if you skipped key generation, your mail is going out naked. Generate a keypair, publish the public key as a TXT record, and confirm your sending service signs with the matching private key. For the Cloudflare-specific walkthrough, see generating DKIM keys for a Cloudflare sending domain.

2. Leaving SPF pointed at your old provider

A stale SPF record tells receivers your new sender is unauthorized. If you migrated from Resend or SendGrid but your SPF still only lists their include:, mail sent through your new path fails SPF alignment. Worse is the opposite mistake: publishing two separate SPF TXT records, which is invalid and makes every receiver fall back to a soft or hard fail. You get exactly one SPF record per domain, and it must list every service that sends as you. The full authentication setup is covered in setting up SPF, DKIM, and DMARC.

3. Leaving DMARC at p=none forever

p=none collects reports but enforces nothing, and bulk-sender rules now expect a real policy. Plenty of people publish a p=none DMARC record, see mail flow, and never touch it again. That leaves your domain spoofable and signals to Gmail and Yahoo that you are not serious about authentication. Start at p=none to read your reports, confirm SPF and DKIM align, then move to quarantine and eventually reject. The point of the monitoring phase is to graduate out of it, not to camp there.

4. Mixing transactional and marketing mail on one domain

Your password resets should not share a reputation with your Tuesday newsletter. When receipts and promotions go out from the same domain, a bad campaign (high complaints, a spam-trap hit) drags your critical transactional mail into the spam folder alongside it. Split them: send transactional from one subdomain and marketing from another, so reputation damage stays contained. The reasoning and the subdomain pattern are in separating transactional and marketing email.

5. Blasting a brand-new domain at full volume

A fresh domain with zero history that suddenly sends 50,000 messages looks exactly like a spammer. Receivers have no reputation data for a new domain, so a cold blast triggers rate limits and spam folders immediately. Ramp up: send small volumes to your most engaged recipients first, increase daily over a couple of weeks, and let positive engagement build reputation before you scale. The pacing schedule is in warming up a new sending domain.

6. Sending cold outreach from your product domain

One cold campaign with high bounces and complaints can poison the domain your real users depend on. Cold email is high-risk by nature: unverified addresses, no prior engagement, easy spam-trap hits. Run it from the same domain as your app, and a single bad list can tank deliverability for your transactional mail too. Cold outreach belongs on a separate, dedicated domain you are willing to burn, never your primary sending domain.

7. Ignoring bounces and complaints

If you keep mailing addresses that hard-bounce, receivers read it as a sign you do not maintain your list. A successful send response is not the end of the story; bounces and spam complaints come back asynchronously, and you have to act on them. Suppress hard bounces permanently, retry soft bounces with limits, and pull anyone who marks you as spam. On Cloudflare this means wiring a Worker to consume bounce and complaint events into a suppression list. See handling email bounces and suppression for the mechanics.

8. Trusting the API "success" as proof of delivery

An accepted send is a handoff, not an inbox placement. Your sending service returning 202 means it queued the message, nothing more. The mail can still be filtered to spam, greylisted, or dropped at the receiving server, and you will never know if you only watch send responses. Close the loop with bounce and complaint webhooks, DMARC aggregate reports, and seed-list testing so you can see what recipients actually got. Most of the reasons mail silently disappears are catalogued in why email goes to spam.

9. Fighting Workers to open an SMTP socket

Cloudflare Workers cannot open outbound port 25 for direct-to-MX SMTP, and hours get lost discovering this the hard way. Use the native Email Service binding, a provider REST API, or a runtime-compatible SMTP client pointed at an allowed third-party submission service. Do not point Worker TCP at Cloudflare's own SMTP endpoint because Cloudflare-owned IP ranges are blocked. Choosing the supported handoff first keeps the rest of the stack straightforward.

The pattern behind all nine

Every mistake here comes from the same shift: moving off a managed provider means inheriting the defaults it used to set for you. Authentication, domain separation, warmup, and bounce handling were always running in the background; on your own Cloudflare account they become checklist items you own. That is a fair trade if you want the control and the cost structure, as long as you actually work the checklist. If you want the positive version of this list rather than the failure cases, the 12-point Cloudflare Workers email checklist and the deliverability checklist for serverless senders are the boxes to tick, and the broader deliverability mistakes roundup covers the ones that are not Cloudflare-specific.

Tinbox handles these defaults for you on your own account: it generates DKIM keys, separates transactional from marketing domains, ramps a new domain, and consumes bounce and complaint events into a suppression list, all while the data stays in your D1 and R2. You own the stack; it just refuses to let you skip the boring parts that decide deliverability.

Deploy your own email stack: npx tinbox init <domain>. It runs on your own Cloudflare account, so the defaults and your mail stay yours.