Setup Guides · beehiiv

beehiiv Custom Domain Setup: SPF, DKIM & DMARC

beehiiv does most of the authentication work for you: connect a custom domain and it hands you a set of CNAME records that delegate SPF and DKIM to sending infrastructure it manages - your root SPF record is never touched. What it does not do is DMARC: since February 2024 beehiiv requires every custom-domain publication to publish a valid DMARC record, and that record - and everything it implies about alignment and enforcement - is yours. A growing newsletter also sits close to the Gmail and Yahoo bulk-sender rules (Gmail draws the line at about 5,000 messages a day; Yahoo deliberately publishes no number). This is the record set, the SPF mistake we see most often, and the DMARC path from p=none to p=reject.

Last updated 25 September 2026 · applies to beehiiv custom email domains

Written by Sandeep Saxena, email deliverability consultant

Shared domain vs custom domain: what you actually control

Every beehiiv account can send from beehiiv's shared infrastructure - your newsletter goes out from beehiiv's own domain (mail.beehiiv.com). That works, but the authentication, reputation and DMARC story all belong to beehiiv, not to you: subscribers see a third-party domain, you inherit whatever the shared pool's reputation is that day, and the authentication is beehiiv's to run, not yours.

A custom domain flips that: mail goes out as [email protected], DKIM signs with your domain, the bounce path lives on your domain, and your DMARC policy governs it. From that point the domain's sending reputation is yours to build - which is the whole reason to do this before your list gets big. beehiiv's pricing page lists custom domains as available on every plan, including the free Launch tier, though it does not separate the website domain from the sending domain there - check what your own dashboard offers before planning around it.

Under the hood, the email side of a beehiiv custom domain follows the classic ESP delegation pattern: you publish CNAME records, beehiiv maintains the real SPF and DKIM values behind them. On live beehiiv-powered domains you can see the shape in public DNS - DKIM selector CNAMEs pointing into sendgrid.net infrastructure, and a root SPF record that contains no beehiiv or SendGrid include at all. If you have read our SendGrid authentication guide, this model will look familiar.

What you need

A beehiiv publication with the custom-domain option in its dashboard (beehiiv lists custom domains on every plan, including free Launch).
Access to your domain's public DNS (registrar or DNS host) to add CNAME and TXT records.
A decision: send from the root domain or a subdomain (see step 1).

The setup, step by step

1 Decide which domain sends the newsletter

beehiiv lets you set up a web domain (where the publication lives) and an email domain (what your sends come from), and they do not have to be the same host. For the email domain you have two sane choices:

Root domain (yourdomain.com) - simplest, strongest brand match, and fine for most publications.
Dedicated subdomain (mail.yourdomain.com, news.yourdomain.com) - isolates the newsletter's bulk-sending reputation from your day-to-day business mail, and gives DMARC a cleaner per-stream story. This is what we recommend once a business runs both transactional/corporate mail and a high-volume newsletter on one brand.

Whichever you pick, the address you send from lives on the authenticated domain. The reply-to is separate: beehiiv lets you use any address you verify ownership of (it defaults to your account email), and recommends - but does not require - a custom-domain address for brand trust.

2 Add the custom domain and copy the email records

In beehiiv go to Settings → Domains → Set up Custom Domain and work through the flow for your email domain. beehiiv's manual flow starts with an ownership-verification TXT record (its step 1 of 3), and a full setup (web + redirect + email + branded links) generates 12 DNS records in total; the Email tab holds the authentication subset this guide cares about. Those email records are CNAMEs following this shape (the bracketed parts are generated per account - always publish exactly what your beehiiv dashboard shows, not what any guide prints):

Type   Host                              Value
CNAME  em[####].yourdomain.com           u[#######].wl[###].sendgrid.net
CNAME  s1._domainkey.yourdomain.com      s1.domainkey.u[#######].wl[###].sendgrid.net
CNAME  s2._domainkey.yourdomain.com      s2.domainkey.u[#######].wl[###].sendgrid.net

The em[####] record is the return-path (bounce) subdomain - SPF for your beehiiv mail is published there, behind the CNAME, which is why your root SPF stays clean. The two _domainkey records are DKIM selectors, which let keys rotate without you republishing anything.

Publish them DNS-only, never proxied

On Cloudflare, set every one of these CNAMEs to DNS only (grey cloud), not proxied (orange cloud). A proxied CNAME hides the real target behind Cloudflare addresses, so verification and receiving systems cannot resolve the delegated records. beehiiv's own docs call this out, and it is the single most common verification failure we see across every CNAME-based ESP.

3 Wait for propagation, then verify - and do not fiddle

beehiiv says verification can take up to 72 hours while DNS propagates. Two rules for the waiting period:

Match the Type, Name and Value fields exactly. If your DNS host auto-appends the zone name, enter just the host label (em1234, not em1234.yourdomain.com) - otherwise you end up with em1234.yourdomain.com.yourdomain.com and verification never passes.
Do not delete and re-add the records while verification is pending. beehiiv warns that removing and re-adding domain records during verification can trigger a block or rate limit - the impatient fix makes it worse.

Deal with conflicting records first - carefully: most DNS hosts will not let a CNAME coexist with an A or TXT record at the same hostname, and a leftover record at em[####] or s1._domainkey silently blocks the new one. But before deleting anything, work out what the existing record belongs to - a DKIM selector at the same name may still be authenticating another active sender, and removing it breaks that sender's mail.

Finally, verification alone does not mean beehiiv is sending from the domain yet: if the email domain shows as Verified but not In use, activate it as your sending domain in the same Domains screen.

4 Publish the DMARC record - the part beehiiv leaves to you

Since February 2024, beehiiv requires every account on a custom domain to have a valid DMARC record. beehiiv does not create it - it is yours to publish. Check for an existing record first (dig +short TXT _dmarc.yourdomain.com): if one exists, update it rather than adding a second record at the same name - two DMARC records make the policy invalid - and never replace an established p=quarantine/p=reject policy with a p=none example from a guide. If there is none, publish one TXT record at _dmarc:

Type  Host                    Value
TXT   _dmarc.yourdomain.com   v=DMARC1; p=none; rua=mailto:[email protected];

p=none satisfies beehiiv's requirement and starts the flow of aggregate reports to your rua address - but it is monitoring only, not protection. Read the reports (a monitor like the Postbox DMARC Monitor turns the XML into a weekly digest), confirm your beehiiv sends and every other legitimate source pass aligned, then tighten to p=quarantine and finally p=reject. Our DMARC enforcement guide walks that path, including the current DMARCbis tags (np= for non-existent subdomains, and why pct= has been removed).

Sending from a subdomain? The org-domain record at _dmarc.yourdomain.com covers news.yourdomain.com automatically through DMARC's inheritance - a separate _dmarc.news.yourdomain.com record is only needed if you want a different policy for the newsletter stream than for the rest of the domain.

About the example in beehiiv's own DMARC article

beehiiv's help article on DMARC shows two example records - a clean v=DMARC1; p=none; rua=… (good) and one of the form v=DMARC1; p=reject; pct=50; rua=…; ruf=…;. Two cautions before you copy the second: pct= has been removed in DMARCbis (RFC 9989) (receivers never applied it consistently, and a percentage-enforced policy gives a false sense of a staged rollout - stage through the policy levels instead, none → quarantine → reject), and ruf= failure reports are ignored by almost every major receiver, so publishing a ruf address mostly just exposes an email address in public DNS. A clean modern record needs only the policy and a rua address.

How SPF, DKIM and DMARC line up here

SPF - published on the em[####] return-path subdomain via the CNAME, managed for you. Your root SPF is unchanged, and that is correct: with DMARC's default relaxed SPF alignment, a Return-Path of em1234.yourdomain.com aligns with a visible From of yourdomain.com because both share the organizational domain. You never add include:sendgrid.net (or any beehiiv include) to your root record - see the failures below.
DKIM - your beehiiv mail is signed with d= your email domain using the delegated selectors, so DKIM is aligned. This matters more than SPF: DKIM survives forwarding, and an aligned DKIM pass alone is enough to pass DMARC.
DMARC - passes on aligned DKIM (and usually aligned SPF too); either one aligning is enough, both are not required. The policy, the rua reporting and the move to enforcement are entirely yours - beehiiv checks for a valid record; the policy choices stay with you. For the full picture of how the three protocols fit together, see our SPF, DKIM and DMARC guide.

The Gmail/Yahoo bulk-sender rules, mapped to beehiiv

Gmail applies its bulk-sender requirements from about 5,000 messages a day to Gmail addresses; Yahoo deliberately publishes no threshold and applies its requirements to senders it classifies as bulk. A growing newsletter should assume the rules apply. Split by who owns each item:

beehiiv's side (platform): the sending infrastructure, TLS, and unsubscribe handling ride on the platform. You still choose sensible sending practices - a real From name, no misleading subjects, a warmed-up cadence for a fresh domain. (At very high volume the IP itself becomes a topic: beehiiv requires a dedicated IP above 700,000 emails a day per publication, available on its Enterprise tier.)
Your side (domain): aligned SPF and DKIM (the CNAMEs above), a published DMARC policy of at least p=none, and a spam complaint rate kept below 0.1% - and never reaching 0.3%, which is Google's actual guidance. Watch it in Google Postmaster Tools (that is Gmail's view of you; Yahoo's you see only in your bounce and complaint feedback), because complaint rate is the metric that actually gets newsletter domains filtered, and no DNS record fixes it.

The failures we keep finding

Adding include:sendgrid.net to the root SPF "to be safe"

The beehiiv-specific mistake we run into most often. The CNAME setup already publishes SPF where DMARC looks for it (the return-path subdomain); the root include adds nothing for alignment and spends several of your ten SPF DNS lookups, pushing an already-busy record toward a permerror that fails SPF for all your mail. Live beehiiv-powered domains confirm the correct state: root SPF with only the mailbox provider in it.

Proxied (orange-cloud) CNAMEs on Cloudflare

If the email CNAMEs are proxied, verification fails and authentication cannot resolve. Set each one to DNS only. Because web-domain records on the same zone often should be proxied, it is easy to leave the email set orange by habit - check them record by record.

Deleting and re-adding records while verification is pending

Verification can take up to 72 hours, and beehiiv warns that removing and re-adding domain records during that window can trigger a block or rate limit. Publish once, verify the values with a lookup, then leave it alone.

Sending from a domain you did not authenticate

The From address must live on the authenticated email domain - authenticate mail.yourdomain.com and then send as [email protected] and your mail no longer carries the aligned identity you set up. The reply-to is a different animal: DMARC never looks at it, and beehiiv accepts any reply-to you verify ownership of. Keeping it on your own domain is good branding practice, not an authentication requirement - what actually matters is that it is a working mailbox someone reads, because subscriber replies are a positive engagement signal.

A conflicting record already sits at the hostname

An old A record at the web host, a leftover TXT at s1._domainkey from a previous ESP, or a wildcard that answers for everything - most DNS hosts refuse the new CNAME or serve the stale answer. Confirm the old record is genuinely unused before removing it (a selector may still be signing for another live sender), then look up each hostname after publishing and confirm the CNAME target is what beehiiv issued.

Growing a serious list on the shared beehiiv domain

Fine for issue #1; a liability by the time sponsors ask about your open rates. On the shared domain your deliverability is coupled to every other shared-domain sender, your brand never accrues its own reputation, and you cannot publish DMARC for mail you do not send from your domain. Move to a custom domain before the list gets big - reputation takes weeks to build and follows the domain, not the account.

Verify it end to end

DNS checkers only prove the records exist. To prove beehiiv mail actually authenticates:

Confirm the records resolve: dig +short CNAME s1._domainkey.yourdomain.com should return the sendgrid.net target beehiiv issued (same for s2 and the em host).
Send a test issue to Postbox Mailtester and confirm SPF pass, DKIM pass with d= your email domain, and DMARC pass (aligned).
Or open a received issue's headers and check Authentication-Results shows dkim=pass header.d=yourdomain.com and dmarc=pass. If DKIM shows a beehiiv or shared domain instead of yours, the custom email domain is not live yet - go back to step 2.

Frequently asked questions

What DNS records does beehiiv need for email authentication?

beehiiv generates the email authentication records for you as CNAME records - a return-path record plus DKIM selector records - shown under Settings → Domains when you set up a custom domain. You publish them exactly as displayed. On top of those, beehiiv requires you to create one TXT record yourself: a DMARC record at _dmarc.yourdomain.com. SPF and DKIM are handled behind the CNAMEs; DMARC is the only record you author.

Do I need to add anything to my SPF record for beehiiv?

No. beehiiv delegates SPF to a sending subdomain through a CNAME, so your root domain's SPF record stays untouched. Live beehiiv-powered domains confirm this: their root SPF contains only their mailbox provider (for example include:_spf.google.com) and no newsletter-platform include at all. Adding include:sendgrid.net to your root SPF does nothing for beehiiv mail and burns several of your ten SPF DNS lookups.

Which beehiiv plan do I need for a custom email domain?

beehiiv's pricing page lists custom domains as available on every plan, including the free Launch tier - though it does not separate the website domain from the email sending domain there, so check what your own dashboard offers. Until a custom email domain is set up and in use, your newsletter sends from beehiiv's shared domain (mail.beehiiv.com), where the authentication belongs to beehiiv and there is no DMARC, reputation or alignment control for your brand.

Does beehiiv set up DMARC for me?

No - and since February 2024 beehiiv requires every custom-domain account to publish a valid DMARC record. beehiiv provisions SPF and DKIM via CNAMEs but the DMARC TXT at _dmarc.yourdomain.com is yours to create. Start with v=DMARC1; p=none; rua=mailto:[email protected];, read the reports, then move to p=quarantine and p=reject once everything aligns.

Can I use the same domain that already runs Google Workspace or Microsoft 365?

Yes. Because beehiiv never touches your root SPF, there is no conflict with an existing include:_spf.google.com or include:spf.protection.outlook.com record, and the DKIM selector CNAMEs beehiiv adds sit alongside your mailbox provider's selectors without clashing. That said, many publishers put the newsletter on a dedicated subdomain (for example mail.yourdomain.com) so its bulk-sending reputation is insulated from day-to-day business mail.

Why is my beehiiv domain verification failing?

The usual causes: the records have not propagated yet (beehiiv says verification can take up to 72 hours), the CNAMEs are proxied on Cloudflare (set every one to DNS only - grey cloud), your DNS host auto-appended the zone so the hostname doubled up, or a conflicting A/CNAME record already exists at the same hostname. Do not delete and re-add the records while verification is pending - beehiiv warns that can trigger a block or rate limit.

Sources: beehiiv Help Center - How to use a custom domain for your publication · Setting up DMARC for a custom domain · Reply-to address · Dedicated IPs · beehiiv pricing · Twilio SendGrid: domain authentication · Google sender guidelines. The CNAME shapes and untouched-root-SPF behaviour were additionally confirmed by public-DNS inspection of live beehiiv-powered newsletter domains (September 2026). Plan gating and record details are beehiiv's to change - always follow what your dashboard shows.

Not sure your newsletter domain is actually aligned?

Test it with Postbox Mailtester Talk to a deliverability expert