beehiiv SMTP Settings and Configuration (2026)

There is no relay to configure, so nothing goes into WP Mail SMTP, Nodemailer or a printer’s scan-to-email form. If you need a host and port 587, the platforms that publish one are Postmark, Amazon SES, Resend, Mailgun and Brevo. If your newsletter still leaves from a beehiiv subdomain and you want hello@yourdomain.com instead, skip to sending domain authentication – supported, free, and filed under Domains rather than SMTP.

Quick reference

Why beehiiv has no SMTP relay

beehiiv is a publishing platform, not email infrastructure. A beehiiv email is not a message you hand to a server; it is a post assembled from typed blocks in the Post Builder, and the renderer wraps every send in a fixed shell carrying the CAN-SPAM and GDPR footer, the unsubscribe mechanics, and the referral and recommendation widgets the business model runs on. The Send API documentation is blunt: the beehiiv email structure is fixed, you cannot replace the header or standard footer elements, and beehiiv does not currently offer the ability to send 100% custom HTML email. An SMTP relay is by definition an arbitrary RFC 5322 message pipe; exposing one would bypass that shell, and with it the ad units, paid-recommendation placements and referral tracking that monetise a send.

So the absence is a product decision, not a roadmap gap, and it is stable enough to plan around. beehiiv is also not its own MTA at the bottom of the stack: Twilio publishes it as a SendGrid customer, so the relay you want already exists one layer down, under beehiiv’s account rather than yours. beehiiv buys deliverability wholesale and sells a publishing product on top: you get its sender reputation, never a credential that puts your own bytes on the wire. “Dedicated IP Addresses” in the Enterprise column is a deliverability option for beehiiv’s own sending, not relay access, and it is the most common misreading of that page.

What you actually need instead

Searches for beehiiv SMTP settings resolve into three jobs. Each has a real answer; none is a relay.

Sending transactional email

Password resets, receipts, order confirmations, magic links, alerts. beehiiv cannot do this on any plan, and the Send API does not change that, it dispatches a newsletter to your audience, not a one-off message to an arbitrary address. You need a dedicated relay. Postmark is the usual pick when transactional deliverability outweighs unit price; Amazon SES is cheapest at volume if you are comfortable operating it; Resend and MailerSend sit in the middle with modern APIs; Brevo works if you also want a marketing surface. All publish a hostname and port 587 with STARTTLS, the thing beehiiv does not have.

Connecting a CMS or app

If the goal is “publish in WordPress or Webflow, send the issue from beehiiv”, that is the Send API’s headline use case, on Max or Enterprise only. Your CMS calls POST /v2/publications/{publicationId}/posts with a title plus blocks. If the goal is “make WordPress send its own mail”, beehiiv is irrelevant: install WP Mail SMTP and point it at a relay.

Routing notifications

Internal alerts, form submissions, cron output and monitoring pings should never travel through a newsletter platform. Route them through a relay on a dedicated subdomain, or off email entirely, beehiiv’s Slack integration and its 26 webhook event types cover most cases. Webhooks are a Scale-tier entitlement, created at POST /v2/publications/{publicationId}/webhooks.

Sending domain authentication

This is the task most beehiiv SMTP searchers are actually trying to complete. beehiiv supports an authenticated custom sending domain on every plan including free Launch, a genuine commercial difference: Substack charges a one-time $50 fee and still sends from a substack.com address afterwards. On beehiiv the From address becomes yours.

SPF and DKIM setup

Go to Settings › Domains. beehiiv separates four roles: Web Domain hosts your content, Email Domain changes your sending address, Redirect Domain forwards between versions of your domain, and Branded Links puts your domain on click-tracking links. Adding a domain offers three sending choices, a new domain or subdomain, the same domain, or the free beehiiv subdomain. beehiiv recommends a subdomain when the root domain already carries business mail.

You will not paste an SPF include or a DKIM public key here. beehiiv generates CNAME records for you to add at your registrar, so authentication is delegated: keys rotate without your involvement, and the records are per-publication. That is why no universal include value or selector hostname can be printed in advance, here or anywhere else.

;  Settings › Domains generates 12 records per publication: web,
;  email authentication, branded links. Auth is delegated - CNAMEs,
;  never a pasted SPF include or DKIM public key.

TYPE   HOST                          TARGET
CNAME  (generated per publication)   (generated per publication)   ; SPF
CNAME  (generated per publication)   (generated per publication)   ; DKIM
CNAME  (generated per publication)   (generated per publication)   ; links

;  DMARC is the one record you may write by hand.
TXT    _dmarc.example.com            v=DMARC1; p=none; rua=mailto:dmarc@example.com

;  Recommended split: news.example.com -> beehiiv,
;  mail.example.com -> your transactional relay.

At supported registrars beehiiv embeds Entri, which writes all 12 records in one click; otherwise you copy them by hand. The status flips to Live once propagation completes.

DMARC alignment

DMARC is mandatory on beehiiv, not advisory: all users on a custom domain are required to set it up. beehiiv ships an in-app wizard that generates the record, and its help article is explicit that the published example is only a template. Publish p=none with a rua address, read two weeks of aggregate reports, confirm that beehiiv and every other sender on the domain, relay, helpdesk, CRM, the invoicing tool nobody remembers installing, are passing and aligned, then move to p=quarantine and later p=reject.

The alignment detail specific to beehiiv: because SPF and DKIM are delegated through CNAMEs, your DKIM signature carries a beehiiv-managed key under a hostname in your domain, which is what produces alignment with your From domain. If the newsletter sits on a subdomain and the DMARC record sits on the organisational domain, relaxed alignment covers it; strict alignment (adkim=s) does not, and is the usual reason a working beehiiv domain starts failing DMARC after someone tightens the policy.

Sending limits

beehiiv publishes no throughput limits in the SMTP sense, because there is no SMTP path to throttle. What is published is an API request budget and a per-plan subscriber ceiling, with unlimited sends within that ceiling on every tier.

Budget that request limit carefully, because the defaults work against you. A 50,000-subscriber walk is 500 calls at the maximum page size, roughly three minutes of the whole organisation’s budget. Use the Exports resource for anything bulk, and read the throttle headers by their real names: beehiiv uses the bare RateLimit-Limit, RateLimit-Remaining and RateLimit-Reset, not the X-RateLimit- prefix most clients look for.

Common mistakes

Pairing beehiiv with an SMTP provider

Almost every serious beehiiv operator runs two senders: beehiiv for the newsletter, a relay for everything the product emits. Done carelessly that is two systems fighting over one domain’s reputation; done properly it makes both more reliable.

Recommended setup

Split by subdomain and keep the roles apart. Run beehiiv’s newsletter authentication on one host – news.example.com conventionally, and the transactional relay on another, mail.example.com, leaving the root domain for ordinary business mail. The payoff is concrete: a complaint spike on a newsletter send cannot degrade password-reset delivery, because the two hosts accumulate reputation separately at every mailbox provider.

For the relay, pick on the shape of your traffic rather than price alone: Postmark separates transactional and broadcast streams by design, Amazon SES wins on cost once volume is real, and Resend and MailerSend are the friendliest to integrate. Complete its SPF and DKIM setup on the transactional subdomain before the first send, and verify the two providers’ records live on different hosts.

Keeping the two systems from colliding

Three failure modes account for most of the trouble. The first is double-sending: a subscriber in both systems gets the welcome twice, once from beehiiv’s send_welcome_email flag on subscription create, once from your onboarding sequence. Decide which system owns the welcome and set the flag explicitly. The second is DMARC scope: one record governs the organisational domain and every subdomain under it, so tightening to p=reject for the relay silently applies to beehiiv too. Check both senders in aggregate reports before each policy step.

The third is selector and return-path collision, which the subdomain split prevents: two providers publishing CNAMEs into the same host eventually clash on a name, and the fix is always to move one. Do it on day one, not during an incident. Finally, keep suppression lists reconciled: an address that hard-bounced on the relay should not keep receiving newsletters, and beehiiv’s webhooks give you enough signal to sync the two.

Frequently asked questions