How to set up DMARC/DKIM/SPF for Beehiiv
Published 26 Jun 2026
Updated 28 Oct 2026
12 min read
Summarize with
Updated on 28 Oct 2026: We updated the Beehiiv setup steps and DMARC enforcement guidance, with clearer DNS checks and message-header examples.
Beehiiv custom sending domains need one Beehiiv-managed SPF CNAME, two Beehiiv-managed DKIM CNAMEs, and a valid DMARC TXT policy. Reuse an existing valid DMARC record instead of creating a duplicate. Authenticate the email domain first, check DMARC at _dmarc, then test a real newsletter send. Beehiiv manages SPF, DKIM, and DMARC when you use a Beehiiv-provided subdomain.
Beehiiv's DMARC setup guide says SPF and DKIM are handled through CNAME records during custom domain setup, while DMARC remains a TXT record you publish in DNS.
Add your Beehiiv sending domain
Beehiiv's custom domain setup requires a paid plan and a workspace Admin role. You also need access to the authoritative DNS host, which is not always your domain registrar. Generate records inside Beehiiv for this publication instead of copying an old setup.
Beehiiv domain settings showing the email domain verification area.
- In Beehiiv, open Settings, then Domains, and select Set up custom domain.
- Choose Send my newsletters, or Set up both if Beehiiv will also host your website. Connecting only a web domain does not authenticate newsletter sending.
- Enter the Email domain or subdomain used in your From address, such as newsletter.example.com or example.com. Enter the Sending address, which is the part before the @.
- For automatic setup with Entri, connect your DNS host when supported and review the generated changes.
- For manual setup, choose I'll add the records myself. Add the ownership TXT record and click Verify ownership before copying the email CNAMEs. Shorten only the Name field if your DNS host appends the domain automatically.
- Click Verify record for each group, then Done for now if records are pending. Beehiiv keeps checking for up to 72 hours. Wait until the email sending address shows Live before sending from the new domain.
Entri setup
- Use case: Use it when Beehiiv supports your DNS host and you have admin access.
- Records: Review the SPF CNAME and both DKIM CNAMEs before approval.
- Verification: Return to Beehiiv and confirm that the email domain becomes live.
Manual setup
- Use case: Use it when your DNS host is unsupported or DNS changes need review.
- Records: Complete the ownership TXT check, then copy each email CNAME host and target.
- Risk: Extra domain suffixes added by DNS hosts are a common mistake.
Before you save DNS
- Authenticate the From domain: The domain in the visible From address must be the domain you configured for sending.
- Set reply-to separately: Reply-To does not affect DMARC alignment. Use a valid address and complete Beehiiv's verification when prompted.
- Prefer a subdomain: Use a dedicated newsletter subdomain when your root domain already has other senders.
- Keep a record: Save Beehiiv's generated DNS table so future audits can compare it with live DNS.
Set up SPF
Beehiiv manages SPF through the return-path CNAME generated during custom email domain setup. SPF is evaluated through that delegated host. Keep existing SPF TXT records for your other senders; Beehiiv does not need a second root-domain SPF record or an invented include value.
- Find the SPF CNAME: In Beehiiv's DNS table, identify the CNAME record marked for SPF or email domain verification.
- Create the CNAME: Add the Beehiiv-generated host as the CNAME name and the generated target as the value.
- Do not add TXT at that host: A CNAME cannot coexist with an SPF TXT record at the same exact host.
- Check the return path: Inspect a real Beehiiv message and confirm SPF passes for the domain shown in Return-Path.
- Confirm DMARC matching: SPF contributes to DMARC only when the authenticated Return-Path domain matches the visible From domain under relaxed or strict matching.
|
|
|
|---|---|---|
SPF | CNAME | Delegates the Beehiiv return-path host used for SPF. |
DKIM | CNAME | Delegates the two DKIM selector hosts to Beehiiv-managed public keys. |
DMARC | TXT | Sets policy and reporting for the visible From domain. |
Beehiiv authentication records are generated per domain, so use your in-app values.
SPF checker
Find SPF syntax issues, lookup limits, and weak records.
?/16tests passed
After the CNAME is live, inspect a real Beehiiv message and test the domain in Return-Path. SPF authenticates the envelope sender, not the visible From address. Compare both domains to confirm SPF alignment for DMARC.
If SPF still fails
- Check host labels: Some DNS hosts append the domain automatically, so a pasted full host becomes doubled.
- Check record conflicts: A CNAME host cannot have another DNS record at the same exact name.
- Check the right host: Test the Return-Path domain from a Beehiiv message, not just the visible From domain.
- Keep other senders working: Resolve a conflict only at Beehiiv's exact generated host. Do not remove a root-domain SPF record that other services still use.
Set up DKIM
DKIM can preserve a DMARC pass after forwarding changes the SPF path, provided the message still passes signature verification. Beehiiv gives you two DKIM CNAME records so receivers can fetch its public keys. Keep both records published even when a message uses only one selector.
Beehiiv DKIM CNAME records ready to copy into DNS.
- Copy selector one: Create the first DKIM CNAME exactly as Beehiiv displays it.
- Copy selector two: Create the second DKIM CNAME exactly as Beehiiv displays it.
- Do not convert to TXT: Beehiiv expects CNAME delegation for these keys, not pasted public-key TXT records.
- Allow for DNS propagation: Records often resolve within minutes, but Beehiiv says domain verification can take up to 72 hours.
- Send a message: Send a real Beehiiv email after verification so you can inspect the signature receivers evaluate.
DKIM CNAME template, replace every placeholderDNS
Type: CNAME Name: <first DKIM Name copied from Beehiiv> Target: <first DKIM Value copied from Beehiiv> Type: CNAME Name: <second DKIM Name copied from Beehiiv> Target: <second DKIM Value copied from Beehiiv>
DNS verification and observed DKIM results
The CNAME and the public-key TXT record at its target can be checked before sending. Beehiiv verification and DMARC report visibility are separate: verify DNS, send a fresh message, then inspect the recipient server's Authentication-Results header. Reports need actual traffic before they contain DKIM results.
Set up DMARC
DMARC passes when at least one of SPF or DKIM passes with domain alignment to the visible From address. Its TXT policy at _dmarc requests receiver handling for messages that fail DMARC. For a new DMARC deployment, start with p=none. If your domain is already stable on p=quarantine or p=reject, keep that policy and fix Beehiiv until it passes.
Starting DMARC recordDNS
v=DMARC1; p=none; rua=mailto:dmarc@example.com
Use the DMARC record generator if you want the record assembled with your reporting address and policy choices.
- For From addresses at newsletter.example.com, publish TXT at _dmarc.newsletter.example.com. In the example.com DNS zone, enter _dmarc.newsletter as the relative Name; for example.com itself, enter _dmarc.
- For a new policy, use p=none while identifying Beehiiv and other legitimate senders in reports. Keep an existing enforcement policy in place.
- Use a report address: Replace dmarc@example.com with a dedicated address that someone monitors.
- Check inherited policy: An exact-domain record takes precedence. RFC 9989 uses a DNS tree walk when no exact record exists. On the organizational-domain record, sp controls existing subdomains; otherwise p applies.
- Keep relaxed matching: Use default relaxed SPF and DKIM domain matching unless you have a strict domain-control requirement.
- Keep one DMARC policy per hostname: Edit an existing DMARC TXT record instead of adding a second one. Records at separate subdomain hostnames are separate policies.
Beehiiv DMARC setup screen showing the TXT record to add in DNS.
Use a dedicated reporting address
The address in the rua tag is public in DNS and receives machine-readable XML reports. Use a dedicated monitored address, or copy the reporting destination supplied by Suped's DMARC reporting platform to review Beehiiv and other senders separately.
If reports go to another organization's domain, confirm that the report receiver has published external reporting authorization, as required by RFC 9990. Reports normally arrive daily rather than immediately after a test.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
Good starting record
For a new DMARC deployment, a monitor-only policy requests no DMARC-based filtering while you collect reports. Other spam filtering still applies.
- Policy: Use p=none when establishing a new policy; preserve existing enforcement.
- Reports: Send aggregate reports to a dedicated address you monitor.
- Next step: Move only after every legitimate source passes DMARC.
Risky starting record
A new enforcement policy puts failing legitimate mail at risk before you know every approved sending source.
- Policy: Avoid a new p=reject record without report data.
- Reports: A missing rua address leaves you without aggregate visibility.
- Impact: Unknown legitimate senders can be filtered once enforcement starts.
Verify Beehiiv authentication and troubleshoot
Verification needs both DNS checks and a real Beehiiv message. DNS proves the records exist. The recipient server's headers show how that message was authenticated. Passing authentication does not guarantee inbox placement.
- Send a test: Send a Beehiiv email to a mailbox where you can view full headers.
- Read the recipient server's Authentication-Results header and confirm dkim=pass and dmarc=pass. Compare header.d with the visible From domain to check DKIM alignment.
- Check SPF alignment: Confirm SPF passes for the Return-Path domain, then compare it with the visible From domain.
- Check Beehiiv: The Beehiiv Domains screen should show the generated CNAME records as verified and the email domain as live.
- Allow up to 72 hours for verification. Check public DNS for name or target errors immediately; leave correct records in place while caches expire. If verification still fails after that window, contact Beehiiv support with the domain and current DNS values.
Illustrative message headers, use your actual domainstext
From: Newsletter <hello@newsletter.example.com> Return-Path: <bounce@bounce.newsletter.example.com> Authentication-Results: mx.example.net; spf=pass smtp.mailfrom=bounce.newsletter.example.com; dkim=pass header.d=newsletter.example.com header.s=example-selector; dmarc=pass header.from=newsletter.example.com
DKIM uses the exact From domain in these illustrative headers. In the DKIM-Signature header, d= is the signing domain and s= is the selector. The public key is queried at <selector>._domainkey.<signing-domain>; use those values to check the active Beehiiv selector.
Check the From domain during Smart Warming
Beehiiv's Smart Warming sends some messages from a shared Beehiiv domain while it builds volume on your custom domain. Check the actual From address before treating a delivered message as evidence that your custom domain passes authentication.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
Send the email tester address a Beehiiv email, then review SPF, DKIM, DMARC, and header diagnostics in one report. Compare the From and Return-Path domains, then check the DKIM signing domain separately.
|
|
|
|---|---|---|
Beehiiv pending | CNAME names | Compare all generated values |
SPF fail | Return-Path | Check the generated CNAME and resolved SPF policy; retest a direct send. |
DKIM fail | Both selectors | Check both CNAMEs and the active public key, then resend. |
No DMARC | Policy location | Check the exact From-domain policy and any inherited policy before adding TXT. |
DMARC fail | Domain alignment | Make at least one passing SPF or DKIM domain match the From domain under the policy. |
Multiple DMARC records | TXT records at the same hostname | Merge the intended settings into one DMARC policy record. |
Use this when Beehiiv verification or message authentication does not match expectations.
Common Beehiiv DNS mistakes
- Doubled domain: A full host pasted into a relative Name field gains the root domain twice.
- Wrong record type: Beehiiv SPF and DKIM records are CNAME records, while DMARC is TXT.
- Proxied CNAME: If your DNS host offers proxying, set Beehiiv CNAMEs to DNS only so Beehiiv can resolve their targets.
- Conflicting record: A CNAME cannot coexist with ordinary A, AAAA, or TXT records at its name. A different existing CNAME target also needs review before replacement; preserve records that other services use.
- Old sender still active: DMARC reports can show non-Beehiiv traffic that needs its own SPF or DKIM fix.
Monitor Beehiiv authentication changes
Beehiiv's setup screen confirms the initial configuration, but ongoing authentication needs monitoring. Suped's DMARC reporting platform groups aggregate reports by sending source. Use its DMARC monitoring to spot Beehiiv failures and investigate authentication changes.
- Watch new sources: Alert when a new sender starts using your domain outside Beehiiv.
- Catch DNS drift: Detect when a CNAME, TXT record, or reporting address changes.
- Track failures: Separate Beehiiv DKIM failures from unrelated senders so fixes stay precise.
- Monitor reputation: Use blocklist (blacklist) monitoring alongside authentication checks.
- Notify owners: Send alerts to the person who owns DNS or newsletter operations.
Useful alert conditions
- Beehiiv drop: Beehiiv volume moves from DMARC pass to fail.
- Unknown sender: A new source uses the same From domain without approval.
- SPF lookup issue: An SPF record approaches lookup limits or returns DNS errors.
- Policy mismatch: A domain stays in monitor mode after all legitimate sources have clean data.
Secure your domain with p=reject
The target state is p=reject once Beehiiv and every legitimate source passes DMARC. Use Suped's source reports to check Beehiiv and every other approved sender before changing the policy.
- Collect data: Keep p=none until Beehiiv volume appears with DKIM pass and DMARC pass.
- Inventory legitimate senders: Authenticate each approved non-Beehiiv source or stop it from using the domain.
- Move to quarantine: Use p=quarantine when legitimate mail is consistently passing.
- Stage by sending domain: Enforce a verified newsletter subdomain while other domains remain under review. Do not rely on pct, which RFC 9989 marks historic.
- Publish reject: Set p=reject after Beehiiv and all approved sources stay clean.
Enforced DMARC recordDNS
v=DMARC1; p=reject; rua=mailto:dmarc@example.com
DMARC policy readiness
A practical gate for moving a Beehiiv domain toward enforcement.
Monitor
p=none
Identify legitimate sources without requesting DMARC filtering.
Request quarantine
p=quarantine
Use after legitimate traffic passes.
Request rejection
p=reject
Use after every legitimate source passes.
If DNS changes are slow or multiple teams share the domain, Hosted DMARC in Suped's DMARC platform lets you change the hosted policy after initial DNS setup. Check reports after each policy change.
Do not jump to reject
- Beehiiv first: Confirm DKIM passes with a signing domain that meets the DMARC matching requirement for the From domain.
- Other senders: Find transactional and support mail before enforcement filters legitimate messages.
- Reports first: Collect data that covers each legitimate sender and a representative sending cycle before enforcement.
- Stay alerted: Keep alerts on after reject because vendors and DNS records change.
FAQ
Yes. For a Beehiiv custom sending domain, Beehiiv gives you one SPF CNAME and two DKIM CNAME records. Add or reuse a DMARC TXT policy at _dmarc.<sending-domain>. Beehiiv manages all three protocols for Beehiiv-provided subdomains.
Use a newsletter subdomain when your root domain already has other senders. It isolates Beehiiv's DNS records, makes reporting easier to read, and reduces the risk of changing authentication for unrelated mail.
Check for an incorrect CNAME host, proxying, a conflicting record, or DNS caching. Both selectors can be checked in DNS before sending. Once they resolve correctly, send a new Beehiiv message and inspect its headers; report dashboards need actual traffic to display observed DKIM results.
Records often resolve within minutes, but Beehiiv says verification can take up to 72 hours. Keep CNAME records set to DNS only, check for name or record conflicts, and avoid removing and re-adding correct records during that window.
Use p=none for a new setup until reports show Beehiiv and every legitimate sender passing DMARC. If the domain already runs cleanly at p=quarantine or p=reject, keep that policy and fix Beehiiv records until it passes.
Those passes can authenticate domains unrelated to your visible From address. DMARC requires at least one passing SPF or DKIM result with domain alignment to the From domain. Compare smtp.mailfrom and header.d with header.from in the recipient server's results.
