Do I need to add an SPF include to my root domain for Beehiiv?

No. Beehiiv is CNAME-based: one of the three CNAMEs delegates SPF to a Beehiiv-managed host on a sending subdomain, so your root SPF record is left untouched. DKIM signed as your domain (via the two selector CNAMEs) is what aligns and carries your DMARC pass. There is no include:...beehiiv, and adding one wouldn't help alignment.

Why do my newsletters still send from a beehiiv domain?

Usually one of two reasons. Either you only set up a web custom domain and not an email (sending) domain — run 'Set up email custom domain' in Settings → Domains — or Beehiiv's Smart Warming is still ramping, in which case a portion of your list is intentionally receiving mail from beehiiv's domain while your custom domain warms up.

Which Beehiiv plan do I need for a custom sending domain?

Every plan, including the free Launch tier. Beehiiv includes custom domains — and the email (sending) custom domain that authenticates your newsletters — on all plans, so there's no upgrade required to add the CNAMEs and DMARC record. This changed with beehiiv's 2025 pricing; custom domains were previously a paid feature, so older guides may say otherwise. Check beehiiv's current pricing, as tier names and inclusions change.

Do I really have to set up DMARC?

Yes. Since February 2024 Beehiiv requires a valid DMARC record on every custom domain, and it won't treat your domain as fully authenticated without one. Use Beehiiv's built-in DMARC wizard to generate the TXT record, publish it at _dmarc, and start at p=none.

Are the SPF and DKIM records CNAMEs or TXT records?

All three sending records are CNAMEs — one for SPF delegation and two for DKIM. Only the DMARC record is a TXT record, and it's separate. Add the three exactly as CNAMEs (grey-cloud/DNS-only if you're on Cloudflare).

Will Beehiiv's records conflict with Google Workspace or another sender?

No. Beehiiv uses its own DKIM selectors and its own CNAMEs, so they won't collide with another provider's DKIM or overwrite your root SPF. The only rules: keep exactly one SPF TXT record on your root, and exactly one _dmarc record for the whole domain.

My DKIM won't verify even though the records look right — why?

Common causes: the records were added in the wrong DNS zone (your public nameservers point somewhere other than where you edited — check where the domain actually resolves); a Cloudflare CNAME left orange-clouded/proxied instead of 'DNS only' (grey cloud), so it never resolves to beehiiv's host; host-field doubling (name.yourdomain.com.yourdomain.com) from a registrar that auto-appends your domain; or the CNAME target was altered or flattened to an A record. It can also just be that no mail has been sent yet — DKIM reports as 'Found' only after a receiver has observed a real signature, so send a couple of messages and re-check. If it still fails after propagation (up to 72 hours), re-copy the exact Name/Value pairs from Settings → Domains rather than editing what's already there.

SPF setup guide

SPF, DKIM & DMARC for Beehiiv.

Beehiiv authenticates your newsletter's sending domain with CNAME-based delegation, not by having you paste a shared SPF line. In Settings → Domains you set up a custom email (sending) domain, and Beehiiv hands you three CNAME records — one that stands up SPF on a Beehiiv-managed sending subdomain, and two that delegate rotating DKIM keys back to Beehiiv — plus a DMARC TXT record it builds for you in a guided wizard. Once those verify, your newsletters send as you@yourdomain.com, DKIM signs and aligns to your own domain, DMARC passes, and the sending reputation you build accrues to your brand instead of the pooled beehiiv shared domain. There is no include:...beehiiv to add to your root SPF, and adding one wouldn't help.

CNAME domain authentication

Your DNSAdd the CNAME / TXT records

BeehiivSigns & sends as your domain

The inboxSPF · DKIM · DMARC pass

Why authenticate Beehiiv?

Authenticating your Beehiiv sending domain is the difference between the inbox and the spam folder, and for a newsletter it matters more than for most senders because you are, by definition, a bulk sender. Since February 2024, Gmail and Yahoo have required every bulk sender (roughly 5,000+ messages a day) to pass SPF, DKIM, and DMARC with alignment, and Microsoft extended the same rules to Outlook/Hotmail/Live in 2025 — a growing newsletter clears 5,000 sends a day quickly. Until you set up a custom sending domain, Beehiiv sends from its own shared domain: your From address doesn't align to your domain, DMARC can't pass on your brand, and your reputation is pooled with every other publisher on that shared infrastructure. Beehiiv took this seriously enough that as of February 2024 it made a valid DMARC record mandatory for every custom-domain account. Setting up the CNAMEs plus DMARC aligns DKIM to your domain, lets DMARC pass, removes the shared-domain dependency, and — via Beehiiv's Smart Warming — lets you build a sending reputation that is genuinely your own.

The SPF reality for Beehiiv

Beehiiv is a CNAME-based domain-authentication provider, so for your root domain there is NO "include:...beehiiv" to add — and this trips up people who expect a shared SPF include. Instead, one of the three CNAMEs Beehiiv gives you creates a dedicated sending subdomain on your own domain and points it at a Beehiiv-managed host whose own SPF record already authorizes the sending IPs. Because SPF for that sending subdomain is delegated through the CNAME, it is satisfied automatically and you never touch your root SPF record. The mechanism that reliably carries your DMARC pass is DKIM: the two DKIM selector CNAMEs let Beehiiv sign your mail as d=yourdomain.com, which aligns to your organizational domain. That is why Beehiiv's flow asks for CNAMEs and a DMARC record but never asks you to edit your root SPF. Practically this means the Beehiiv setup adds ZERO DNS lookups to your root SPF's RFC 7208 budget of 10 — a real advantage if you already stack Google Workspace, Microsoft 365, or a transactional relay on your root SPF. Reserve that root SPF record for senders that actually use your root domain as the envelope sender, and let the CNAME-delegated DKIM do the work for Beehiiv. Don't paste a made-up include:beehiiv.com or include:sendgrid.net onto your root — it does nothing for alignment and needlessly burns a lookup.

Two ways to set it up

Recommended

Custom sending domain — CNAME (recommended)

Newsletters send from you@yourdomain.com; DKIM signs and aligns as your own domain
You own the sending reputation instead of sharing beehiiv's pooled sending domain
Adds zero lookups to your root SPF; Beehiiv rotates the DKIM keys automatically via CNAMEs
Required to pass DMARC aligned to your brand and meet the Gmail/Yahoo bulk-sender rules on your own domain

Legacy

Default shared beehiiv sending domain

Works out of the box on every plan with no DNS changes
Mail sends from a beehiiv-owned domain, so reputation is pooled with other publishers
Your visible From address doesn't align to your domain and you can't build your own domain reputation
Fine for getting started, but move to a custom domain before you scale or you'll cap your deliverability

Step by step

In Beehiiv

1
No upgrade needed — custom domains are on every plan
Custom domains, including the email (sending) custom domain that authenticates your newsletters, are included on all beehiiv plans — even the free Launch tier — so there's nothing to buy first. (This changed with beehiiv's 2025 pricing; custom domains were previously a paid feature, so older walkthroughs may tell you to upgrade.) Every account sends from beehiiv's shared subdomain by default; you authenticate your own domain by running the email-domain setup below.
2
Open Settings → Domains
Click Settings in the bottom-left of your publication dashboard, then open the Domains page. This one page manages both your web (website) domain and your email (sending) domain — they are separate setups.
3
Start the email domain setup
Click Set Up Custom Domain and choose 'Set up email custom domain' (or 'Set up web and email custom domain' if you want both). Enter the domain or sending subdomain you'll send newsletters from — this is what authenticates your mail, distinct from the web domain that hosts your publication site.
4
Pick Entri (automatic) or manual
Beehiiv offers 'Verify with Entri', which logs into a supported DNS host (Cloudflare, GoDaddy, Namecheap, and 40+ others) and writes the records for you. Choose Entri for a hands-off setup, or pick manual to copy the records and paste them at your registrar yourself. Both create the identical DNS records.
5
Copy the three CNAME records
On the manual screen Beehiiv shows three CNAME records — one for SPF and two for DKIM — each with a Name and a Value. Copy each Name/Value pair exactly; the selectors and targets are generated for your account.

In your DNS

6
Add the three CNAMEs
At your DNS host, create each record as type CNAME: paste Beehiiv's Name into the Name/Host field and its Value into the Value/Target field. Add all three. Don't change the type to A or TXT, and don't alter the values.
7
Turn off the Cloudflare proxy and fix host doubling
If your DNS is on Cloudflare, set each CNAME to 'DNS only' (grey cloud) — an orange-cloud proxied record won't resolve to Beehiiv's host and verification fails. If your registrar auto-appends your domain, enter just the record label (not the full name.yourdomain.com) to avoid doubling.
8
Build and publish the DMARC record
DMARC is mandatory for every Beehiiv custom domain since February 2024. Use Beehiiv's built-in DMARC wizard to generate the record, then add it as a TXT record at host _dmarc — e.g. v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. Start at p=none (monitor-only). Skip creating a second one if a _dmarc record already exists.

Verify

9
Click Verify Setup
Back in Beehiiv, click Verify Setup. When the records resolve, an 'Email' checkmark appears at the top of the domain. Propagation is usually minutes but can take up to 72 hours; if it stalls, wait a few hours and re-check rather than repeatedly clicking Verify.
10
Set your From address and send a test
Go to Settings → Emails → Sending Details and set your From address to one on the authenticated domain (e.g. hello@yourdomain.com). Send a test to a Gmail account, open ⋮ → Show original, and confirm DKIM: PASS with d=yourdomain.com plus DMARC: PASS. DKIM only shows as 'Found' after real mail has flowed and a receiver has observed the signature.

Records to add

Beehiiv generates the exact values in its setup wizard — these show the shape of what you'll add at your DNS host.

Type	Host	Value
CNAME	em	sending.beehiiv.comSending subdomain — this CNAME delegates SPF to Beehiiv's mail host, so your root SPF is untouched. Illustrative: copy the exact Name and Value from Beehiiv's Settings → Domains email setup.
CNAME	bh1._domainkey	bh1.dkim.beehiiv.comDKIM key 1 (Beehiiv-managed, auto-rotated). Illustrative — the real selector and target are generated per account; use the exact values Beehiiv shows you.
CNAME	bh2._domainkey	bh2.dkim.beehiiv.comDKIM key 2 — the second selector lets Beehiiv rotate keys without you re-editing DNS. Illustrative — per-account values.
TXT	_dmarc	v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comMandatory for all Beehiiv custom domains since Feb 2024. Build it with Beehiiv's DMARC wizard; keep exactly one _dmarc record per domain and start at p=none.

Keep exactly one SPF (v=spf1) TXT record on your root domain — merge every sender into it. Two SPF records is itself an error.

The 10-lookup budget

SPF is capped at a hard 10 DNS lookups — go over and it returns a permerror and stops validating everywhere. Here's what Beehiiv's setup costs against that budget.

SPF 10-lookup budget0 used · 10 free

Beehiiv's recommended setup adds 0 lookups — all 10 stay free for the senders that do need an include.

DKIM

DKIM is the mechanism that actually carries your DMARC pass on Beehiiv, and it's handled by two of the three CNAME records — two DKIM selector records (shown for your account) that delegate the public keys back to Beehiiv. Because these are CNAMEs, not TXT records you paste, Beehiiv holds the matching private keys and uses the two selectors to rotate the published keys automatically without you ever editing DNS again. Once verified, Beehiiv signs your newsletters with d=yourdomain.com, so DKIM aligns to your organizational domain and satisfies DMARC even when a message is forwarded (which breaks SPF). Two Beehiiv-specific things to know. First, if your DNS is behind Cloudflare, set both selector CNAMEs to 'DNS only' (grey cloud) — a proxied CNAME won't resolve to Beehiiv's host and DKIM will never validate. Second, a freshly-added DKIM record can show as pending or 'not found' until you've actually sent mail: receivers (and verification tools) confirm DKIM by observing a real signature, so send a few messages after the records resolve before you expect a clean 'Found' status. You do not create a DKIM TXT record yourself and there is no public key to copy — just add the two selector CNAMEs exactly as Beehiiv shows them.

DMARC

DMARC is not optional on Beehiiv — as of February 2024 every custom-domain account must have a valid DMARC record, and Beehiiv won't treat your sending domain as fully authenticated without one. Beehiiv makes this easy with a built-in DMARC wizard: it takes your domain and a policy choice and outputs the exact TXT record to publish at _dmarc.yourdomain.com, starting with v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. p=none is monitor-only: it changes nothing about delivery but asks receivers to email you aggregate (rua) reports so you can confirm Beehiiv is passing DKIM aligned to your domain before you tighten anything. Watch those reports for a week or two, make sure every legitimate sender — Beehiiv plus any other tools on the domain — is authenticating, then ramp the policy to p=quarantine and eventually p=reject. Keep exactly one _dmarc record for the whole organizational domain no matter how many senders you use; never publish a second DMARC record specifically for Beehiiv. Note the wizard defaults to p=none, which satisfies the mandatory-record requirement, but p=reject is what actually protects your domain from being spoofed.

Check it actually worked

Don't trust the 'Email' checkmark alone — confirm authentication on a real message. Send a test newsletter (or a preview) from an address on your authenticated domain, open it in Gmail, and choose ⋮ → Show original: you want DKIM: PASS with d=yourdomain.com (not a beehiiv domain), SPF: PASS, and DMARC: PASS. Remember DKIM only reports as 'Found'/verified after mail has actually flowed, so send a couple of messages first if the status looks pending. You can spot-check the raw records with dig CNAME on the two selector hosts and dig TXT _dmarc.yourdomain.com. Then run your domain through Qualisend's domain health check to confirm all three CNAMEs and the DMARC record resolve cleanly and your root SPF stays under the 10-lookup limit, and once DMARC aggregate reports start arriving, drop one into the DMARC report analyzer — Beehiiv should show up as an aligned, passing source. If DMARC still shows a beehiiv sending domain in the headers, you may simply be mid-warmup (see Smart Warming below), not misconfigured.

Domain health check DMARC report analyzer

Common gotchas

Coverage
Custom domains are free on every beehiiv plan — including the free Launch tier — so there's no upgrade to buy (this changed with beehiiv's 2025 pricing). But every account sends from beehiiv's shared domain by default, so nothing authenticates to your brand until you actually run the email-domain setup.
Breaks auth
Web domain and email domain are two different setups. Authenticating your publication's web domain does NOT authenticate your sending — you must run 'Set up email custom domain' specifically, or your newsletters still go out on the shared beehiiv domain.
DNS setup
DMARC is mandatory since February 2024. Beehiiv won't consider a custom domain fully authenticated without a valid _dmarc TXT record — use its built-in DMARC wizard and publish the result before expecting clean sending.
DNS setup
Cloudflare proxy breaks it: set every Beehiiv CNAME to 'DNS only' (grey cloud). An orange-cloud proxied CNAME won't resolve to Beehiiv's host and both SPF-delegation and DKIM verification fail.
DNS setup
Host-field doubling: many registrars auto-append your domain, so entering the full record name produces name.yourdomain.com.yourdomain.com. Enter just the label Beehiiv shows if your panel adds the domain for you.
Coverage
Smart Warming means custom-domain sending ramps gradually — for a few weeks (typically 6-8 for publications sending at least weekly) only a subset of subscribers get mail from your domain while the rest still come from beehiiv. Seeing a beehiiv domain in some headers during warm-up is expected, not a broken setup.
Coverage
DKIM shows 'Found' only after you've actually sent mail so a receiver can observe the signature — a correctly-added record can look pending until the first sends go out. Don't assume it failed.
Breaks auth
Don't invent a root SPF include for Beehiiv. The CNAME setup adds zero lookups to your root SPF, and a bogus include:beehiiv or include:sendgrid does nothing for DMARC alignment while wasting one of your 10 SPF lookups.

Build your SPF record

Beehiiv doesn't need an SPF include: on your root domain — use the generator to assemble one clean record for your other senders, and keep it to a single line.

Sending sources

Search for each platform you send email through and tick it.

Search for your email platform above, or .

This domain's own servers

Authorize the domain itself, if it sends mail directly (not through a platform above).

a — the domain's own A recordmx — the domain's MX hosts

Other senders & IPs

Anything not in the list — another provider's SPF host, or specific IP addresses.

Additional includes

We add the include: prefix — enter the hostname your provider documents.

IPv4 addresses

IPv6 addresses

Policy for everyone else

What receivers should do with mail from any server not listed above (the all mechanism).

-all (fail)Strict — receivers should reject mail from any server not listed.~all (softfail)Recommended default — unlisted senders are accepted but marked suspicious.?all (neutral)No opinion — provides almost no protection; use only while testing.

Your SPF record0/10 DNS lookups

v=spf1 ~all

No senders yet, so every message would hit the ~all policy. Add the platforms you send through in step 1.

Publish it as a TXT record at your root domain — host @ (the bare domain), value the full string above.
Keep only one SPF record per domain. Merge every sending source into this single line — a second TXT record starting v=spf1 makes both invalid.
Stay at or under 10 DNS lookups. Each include:, a and mx counts, and an include can trigger more lookups inside itself — ip4: and ip6: are free.

Authentication published? The next step is sending to a clean, verified list.

Verify a list