How to Connect a Beehiiv Custom Domain and Set Up SPF, DKIM and DMARC

To connect a Beehiiv custom sending domain, choose the email domain or subdomain you want subscribers to see, generate its DNS records in Beehiiv, and copy every supplied Type, Name and Value into the authoritative DNS zone exactly as shown. Beehiiv provisions SPF and DKIM through generated CNAME records; you must also publish one valid DMARC TXT policy for your domain.

Complete the setup by verifying the records in Beehiiv, checking their public DNS answers and sending a fresh message to a mailbox where you can inspect full headers. Keep the previous sending configuration available until that message passes DKIM and DMARC for the domain in its visible From address.

1. Give each Beehiiv domain one role

Beehiiv can use related hostnames for different purposes. The web domain hosts the publication, an optional redirect domain forwards visitors, the email domain identifies newsletter mail, and an optional branded-link domain supports tracked links. Authenticating the email domain does not move an existing website or configure its redirects.

For example, a publisher whose main website is example.com could host a Beehiiv publication at newsletter.example.com and send from news.example.com. This is an illustrative arrangement, not a required naming pattern. A dedicated sending subdomain can make newsletter records easier to separate from employee email, transactional systems and other services using the root domain.

The current Beehiiv custom-domain instructions distinguish web, redirect, email and branded-link functions, state that a combined setup requires 12 automatically generated DNS records, allow up to 72 hours for verification, and warn that screens may differ as the setup experience changes. The values displayed for your publication therefore take precedence over examples from tutorials.

2. Audit the authoritative DNS zone first

Identify the service hosting the domain’s authoritative nameservers before editing any records. It may not be the registrar that sold you the domain. Changes made in a registrar’s inactive DNS panel will not affect public answers when the nameservers point to another provider.

Export the current zone or capture a complete record of it, then note the existing Beehiiv sending identity. Search for data on every hostname Beehiiv intends to use, including A, AAAA, CNAME and TXT records. If a generated CNAME name is already occupied, investigate the existing service before removing anything; a CNAME cannot normally share its exact name with other DNS data.

Inventory every legitimate system that sends mail using the organizational domain. The list may include employee mail, invoices, account notifications, support tools, ecommerce platforms and an earlier newsletter provider. This matters before DMARC enforcement because a policy applies to all messages using the relevant visible From domain, not only Beehiiv newsletters.

3. Generate the records in Beehiiv

Open the relevant publication, go to Settings, select Domains, and choose whether you are configuring a web domain, an email domain or both. Enter the intended hostnames, review their assigned roles and finish the setup step to generate the required DNS data.

Beehiiv offers a guided Entri setup for supported DNS providers and a manual route for direct record entry. The guided option can reduce transcription, but review the requested changes against your DNS inventory before authorizing them. Manual setup is appropriate when your provider is unsupported, changes require internal approval or you need a precise change log.

During manual setup, Beehiiv first presents ownership verification and then the records for the selected web, redirect and email domains. Copy the displayed Type, Name and Value fields rather than reconstructing them. Save a private record of each addition, its previous state and the time of the change so that any rollback restores known values.

DNS consoles use different labels for the same fields. Name may appear as Host, Record name or Alias, while Value may appear as Target, Destination or Points to. Some consoles expect a relative label and append the zone name automatically; check the preview so that selector._domainkey.example.com does not become selector._domainkey.example.com.example.com.

4. Publish Beehiiv’s SPF and DKIM CNAMEs

For a custom email domain, Beehiiv supplies three authentication CNAME records: one related to SPF and two for DKIM. Create all three using the exact names and targets generated for your publication. Do not replace the DKIM CNAMEs with public-key TXT records or copy selectors from another Beehiiv account.

The official Beehiiv authentication guide confirms that the custom-domain flow uses one SPF and two DKIM CNAMEs, after which Beehiiv manages SPF and DKIM, while the publisher remains responsible for publishing the valid DMARC record required for a custom domain.

Do not add a second SPF TXT policy at the same hostname. Multiple SPF policies at one DNS node can produce a permanent SPF error. Beehiiv’s generated SPF-related CNAME should be entered where Beehiiv specifies it; do not modify an existing root-domain SPF record unless the generated instructions explicitly require a change at that exact name.

If your DNS provider can proxy CNAME traffic, leave Beehiiv’s authentication records in ordinary DNS-only mode. Verification needs the public CNAME response rather than an HTTP proxy endpoint. Use your organization’s normal TTL policy and avoid repeatedly deleting and recreating records while cached answers are expiring.

5. Add one valid DMARC record

DMARC checks whether a message passes SPF or DKIM with an authenticated domain aligned to the domain in the visible From address. It then tells the receiving system how to treat messages that fail and can direct aggregate data to a designated reporting address.

Before creating a record, query _dmarc.example.com and inspect the DNS console. If a DMARC TXT record already exists at the applicable organizational domain, review and update that policy rather than publishing a competing record. Two DMARC policies at the same name make the result invalid.

For a domain without an established DMARC program, a cautious starting example is v=DMARC1; p=none; rua=mailto:[email protected];. Replace the example address with a monitored role account or reporting service. The reporting address is visible in public DNS and may receive a substantial volume of machine-generated data.

A p=none policy collects information without asking receivers to quarantine or reject failures. Examine the aggregate data and authenticate every legitimate sender before progressing to enforcement. If the organization already uses a tested p=quarantine or p=reject policy, do not weaken it automatically; make Beehiiv pass under the existing policy first.

A DMARC policy at the organizational domain normally covers subdomains unless a more specific record or an sp tag changes the treatment. Confirm which domain appears in the newsletter’s From address before deciding where to publish. Avoid creating separate policies at multiple levels unless you intentionally need different behavior.

6. Verify public DNS before activating the sender

After saving the records, query public DNS rather than relying only on the provider’s dashboard. Substitute the exact hostnames generated for your publication in these illustrative commands:

• dig +short CNAME generated-spf-host.example.com
• dig +short CNAME selector-one._domainkey.example.com
• dig +short CNAME selector-two._domainkey.example.com
• dig +short TXT _dmarc.example.com

The first three queries should return the respective targets supplied by Beehiiv. The DMARC query should return one policy beginning with v=DMARC1. If dig is unavailable, use nslookup or a DNS lookup service and query more than one public resolver when their cached answers disagree.

An empty or unexpected response usually points to the wrong authoritative zone, an incorrectly expanded hostname, the wrong record type, a proxy setting or propagation that has not completed. Compare each public answer character for character with Beehiiv’s table before editing it again.

Return to Beehiiv and run its verification step after the expected public answers appear. For a complete domain setup, the Domains screen should eventually show the configured roles as Live. Do not assume that a web domain becoming live means the email-domain records have also completed verification.

7. Test a real message and inspect its identities

DNS queries prove that records are published; a delivered newsletter proves that Beehiiv used them in a message. Send a fresh Beehiiv test or a small campaign to a mailbox where you can open the original message and inspect all headers. Use a message created after the DNS records became available.

Find the Authentication-Results header and look for spf=pass, dkim=pass and dmarc=pass. Do not stop at the words pass: compare the associated identities. For DMARC, the domain in header.from must align with either the DKIM signing domain shown as header.d or the SPF-authenticated envelope domain.

The independent Suped Beehiiv walkthrough recommends checking a real message, identifies doubled hostnames, incorrect record types, stale SPF data and an old sender still using the domain as common troubleshooting targets, and cautions that generated values are specific to the publication.

Inspect the visible From address, DKIM selector, Return-Path and Reply-To as separate fields. A DKIM pass for an unrelated signing domain does not satisfy alignment for your intended From domain. SPF can also fail after forwarding, which makes an aligned DKIM signature particularly important for consistent DMARC authentication.

8. Resolve verification and delivery failures

When Beehiiv remains pending, begin with the exact live DNS response rather than deleting records. Work from the failed layer:

• No CNAME response: confirm the authoritative provider, the full-versus-relative hostname format and whether proxying is enabled.
• Record conflict: inspect all data at the exact generated hostname before deciding which existing service can be migrated.
• SPF failure: examine the Return-Path identity and confirm that you published Beehiiv’s generated CNAME without creating another SPF policy at that node.
• DKIM failure: verify both selector CNAMEs, send a new message and compare its header.d value with the visible From domain.
• Missing DMARC: query the applicable organizational domain and check for a misspelled _dmarc label or an automatically duplicated suffix.
• DMARC failure despite a pass: inspect domain alignment; SPF or DKIM authentication for an unrelated domain is insufficient.

Passing authentication does not guarantee inbox placement. Sender reputation, complaint levels, recipient engagement, list quality, sending patterns and content can still affect filtering. If a fresh message passes SPF, DKIM and DMARC with the intended identities, stop changing correct DNS and investigate those separate delivery signals.

Keep the former sending configuration until Beehiiv is live and a delivered-message audit succeeds. Preserve the generated record table and examine incoming DMARC aggregate data after cutover. The practical completion test is a Beehiiv newsletter whose visible sender and aligned authentication results correspond to the custom domain subscribers are meant to see.