beehiiv newsletter going to spam? Look at the orange cloud first

If your beehiiv newsletter is landing in spam and your DNS is on Cloudflare, there's a decent chance the whole problem is one toggle: the orange cloud. beehiiv's custom-domain records must be DNS-only (grey cloud), and Cloudflare proxies new CNAMEs by default. A proxied record answers with Cloudflare's addresses instead of its real target, so verification fails, DKIM never signs, and your newsletter ships on shared reputation while your dashboard shows records that look present. Run the free beehiiv checker and you'll see in a minute whether your records answer with their real SendGrid targets or something else.

That's the headline case. The full picture has three parts worth understanding, because they fail in different ways.

How beehiiv sending actually works

beehiiv delivers your newsletter through SendGrid's infrastructure. A custom sending domain means publishing the CNAME records beehiiv generates for you:

• DKIM keys at s1._domainkey and s2._domainkey, pointing into sendgrid.net
• a return-path record with a per-account name (it looks like em1234.yourdomain.com)

When those resolve correctly, your newsletter is signed by your domain and builds your reputation with every send. When they don't, it's signed by shared infrastructure, and February 2024's Gmail and Yahoo rules made that an expensive place to be.

The checker probes s1/s2 and verifies the targets contain sendgrid. If it reports a key pointing somewhere that isn't SendGrid, the proxy is the first suspect; if it reports the name missing entirely, the record was never added or a DNS dashboard mangled the name on entry (auto-appending your domain, so the record exists at s1._domainkey.yourdomain.com.yourdomain.com where nobody looks).

The DMARC rule that took publications by surprise

Since early 2024, beehiiv requires a valid DMARC record on every custom sending domain. Not suggests: requires. Publications migrating in, or set up before the rule, hit this as a wall with an unfamiliar acronym on it.

The record itself is the easy part. One TXT entry at _dmarc.yourdomain.com:

v=DMARC1; p=none; rua=mailto:you@yourdomain.com

That satisfies beehiiv and the mailbox providers today, and starts sending you reports on who's sending as your domain. The part people get wrong is the policy value: seeing that stricter policies exist, they jump straight to p=reject for safety. If your beehiiv records aren't fully working at that moment, you've just instructed every inbox on earth to refuse your own newsletter. Sequence it: records first, verify, then p=none, then tighten when reports show clean alignment.

The quiet third failure: something already lives at that name

DNS providers won't serve a CNAME alongside another record at the same hostname, and while most refuse loudly, some refuse silently: the old record stays, your new CNAME goes nowhere, and beehiiv's verification fails with no visible reason. If one specific record won't verify while its siblings are fine, look at what else answers at exactly that name and clear it out.

Five minutes, in order

1. In beehiiv's settings, open your custom domain and copy the records it shows. Don't retype them; the values are per-account.
2. Add them in your DNS. On Cloudflare, set each one to DNS-only before saving. Anywhere, watch whether the host field auto-appends your domain.
3. Publish the DMARC record above if you don't have one.
4. Run the checker. It reads your live public DNS, so it sees what receivers see: the two DKIM names and their targets, the DMARC record and its policy, plus your SPF, MX and 24-plus blocklists underneath, since a listed domain sends even perfect records to spam.
5. Propagation can take a few hours, and beehiiv evaluates DKIM against real traffic, so a freshly added record sometimes needs a couple of sends before beehiiv's own dashboard catches up. Patience before panic.

A last word from the monitoring side of the fence. Newsletter setups have a particular decay pattern: they're configured once, at launch, with enthusiasm, and then never looked at again, while the publication runs for years. Website migrations happen in those years. So does DNS housekeeping, and so do provider rule changes like the one 2024 delivered. The setup you verify today is a photograph, not a guarantee. Inbox Decay keeps re-checking it and emails you the moment a record breaks, free to start, so the next silent change reaches you before it reaches your open rate.