Email authentication for HubSpot: SPF, DKIM and DMARC

10 May 2026 · 12 min read

HubSpot is a sending service, not a mailbox provider. When you send marketing emails, sales sequences, workflow emails or transactional mail through HubSpot using your own @yourdomain.com address, HubSpot relays that mail on your behalf from its own infrastructure. For Gmail, Yahoo and Microsoft to accept it without a spam stamp, and for your DMARC policy to ever reach p=reject safely, that relayed mail has to pass SPF or DKIM and align with the domain in your From address.

This guide is specific to HubSpot: the exact SPF include HubSpot asks you to publish, how HubSpot's CNAME-based DKIM works (including its two rotating selectors), why the custom bounce subdomain matters for alignment, and how to walk a HubSpot-sending domain from monitoring to enforcement without losing email. If you want the underlying theory rather than the HubSpot wiring, the glossary and what is DMARC cover the concepts.

How HubSpot sends your email

There are two distinct things HubSpot calls "connecting a domain", and conflating them is the most common reason authentication looks broken.

1. Email sending domain (sometimes called the connected email domain or branded sending domain). This is the domain you authorise HubSpot to send from. Connecting it publishes DKIM and lets you set a custom return-path so HubSpot mail aligns to your domain.
2. The default, unconnected state. If you never connect your domain, HubSpot still lets you send, but it uses an unbranded path. SPF is checked against a HubSpot-owned domain, DKIM (if present) signs with a HubSpot domain, and the visible return-path is a HubSpot bounce domain. None of that aligns with your From domain, so under an enforcing DMARC policy that mail fails.

The whole job of HubSpot email authentication is to move from state 2 to state 1: get DKIM signing under your domain and get the return-path under your domain, so both DMARC alignment checks can pass.

You can confirm which state you are in right now. Send yourself a HubSpot email, open the raw headers, and look at the Return-Path: and the d= value in the DKIM-Signature header. If both contain hubspot rather than your domain, you are unconnected. Our email header analyzer will parse those headers for you.

SPF for HubSpot

SPF authorises the IP addresses that may send mail using your domain in the envelope sender (the Return-Path / MAIL FROM), and it is checked against whatever domain appears in that envelope sender, not the visible From.

The modern HubSpot setup: a dedicated bounce subdomain

When you connect an email sending domain in HubSpot, HubSpot provisions a custom bounce subdomain for you, typically something like:

hs1._sending.yourdomain.com

or, depending on your portal and region, a bounce host such as <token>.bnc.yourdomain.com. HubSpot tells you the exact host to create in Settings > Marketing Email > Email Domains (or the connect-a-domain wizard). You publish the CNAME records HubSpot gives you, and HubSpot then sets the Return-Path to that subdomain. Because that subdomain belongs to your organisational domain, SPF is now checked against your domain (via the delegated subdomain), and crucially the envelope sender now aligns with your From domain at the organisational level.

This is the important point: with the dedicated bounce subdomain, you usually do not add a HubSpot include to your main domain's SPF record at all. The SPF that matters lives on the bounce subdomain, and HubSpot manages it for you through the CNAME you published. Adding HubSpot includes to your apex SPF on top of this is a common cause of unnecessary DNS lookups.

The legacy / shared setup: the SPF include

If you are using HubSpot's older shared sending path, or HubSpot explicitly instructs you to update SPF on your main domain, the include HubSpot publishes is:

v=spf1 include:_spf.hubspot.com ~all

You will also see older guidance referencing hubspotemail.net. Always copy the exact include string from your portal, because HubSpot has changed this mechanism over time and the include resolves to whatever sending ranges HubSpot currently uses.

A complete SPF record for a domain that sends through HubSpot and Google Workspace might look like:

v=spf1 include:_spf.google.com include:_spf.hubspot.com ~all

Three rules that trip people up:

• One SPF record only. You publish exactly one v=spf1 TXT record on a given name. If you already have one for Microsoft 365 or Google, add the HubSpot include to that record. Do not publish a second v=spf1 record; two of them is a permerror and SPF stops working. See SPF explained.
• Mind the 10-lookup limit. Every include costs DNS lookups, and SPF hard-fails with permerror once the total exceeds ten. Stacking HubSpot, Google or Microsoft, your CRM, your invoicing tool and your help desk blows past ten quickly. Our SPF checker counts the lookups for you, and fix SPF permerror explains the cure. This is exactly what hosted SPF flattening on our SPF product solves.
• SPF alignment needs the return-path under your domain. SPF passing is not enough for DMARC. DMARC requires the SPF-authenticated domain (the envelope sender) to align with your From domain. On HubSpot's default path the envelope sender is a HubSpot domain, so SPF passes but does not align, and DMARC ignores it. This is precisely why the custom bounce subdomain in the section above is the part that matters.

Generate or sanity-check a record with the SPF generator before you publish.

DKIM for HubSpot

DKIM is where HubSpot does most of the heavy lifting, and it is the more robust of the two mechanisms because, unlike SPF, DKIM survives forwarding. Get HubSpot DKIM right and you have a reliable aligned pass even when mail is forwarded or routed through mailing lists.

HubSpot uses CNAME-based DKIM with two selectors

HubSpot does not ask you to paste a long public key into a TXT record. Instead it uses CNAME delegation: you publish CNAME records that point at HubSpot-hosted DKIM keys, and HubSpot manages the actual key material (and rotation) on its side.

When you enable DKIM for a connected email sending domain, HubSpot gives you two CNAME records to publish, using two selectors. They look like this:

hs1-<portalID>._domainkey.yourdomain.com.   CNAME   <token>.dkim.hubspot.com.
hs2-<portalID>._domainkey.yourdomain.com.   CNAME   <token>.dkim.hubspot.com.

The exact left-hand selector labels (hs1-... and hs2-...) and the right-hand targets are unique to your portal and are shown in Settings > Marketing Email > Email Domains during the connect flow. Publish both. The two-selector design exists so HubSpot can rotate signing keys with zero downtime: it can sign with one selector while the other is being rotated, and your mail keeps passing throughout. This is the same reasoning explained in DKIM key rotation.

A few HubSpot-specific gotchas:

• Publish CNAMEs exactly as given, with no extra dots or trailing-dot mistakes. Some DNS hosts auto-append your domain, so entering hs1-12345._domainkey.yourdomain.com produces hs1-12345._domainkey.yourdomain.com.yourdomain.com. If verification fails, this doubled suffix is the usual culprit. Enter just the host label your host expects.
• Do not "flatten" the CNAME into a TXT record. Because HubSpot rotates the key behind the CNAME, copying the current TXT value it resolves to will break the moment HubSpot rotates. The CNAME must stay a CNAME.
• CNAME and existing TXT at the same name can conflict. DNS does not allow a CNAME to coexist with other record types at the identical name. The _domainkey selectors HubSpot uses are unique, so this is rarely an issue, but if verification stalls, check there is no leftover TXT at the same selector host.
• Wait for HubSpot to verify before sending real campaigns. HubSpot polls DNS and flips the domain to "Connected / Authenticated". Until it does, your mail may still go out on the unbranded path.

Once verified, HubSpot signs with d=yourdomain.com, which is what makes DKIM align for DMARC. Confirm the published selectors resolve and sign correctly with the DKIM checker; enter the selector (for example hs1-12345) and your domain. Background reading: what is DKIM and DKIM selectors explained.

Alignment: the part HubSpot users miss

DMARC does not care that SPF or DKIM merely "passed". It cares about alignment: the domain that passed must match the domain in your visible From address.

• DKIM alignment: the d= in the DKIM signature must match (or be an organisational match for) your From domain. After you connect the domain, HubSpot signs with d=yourdomain.com, so this aligns.
• SPF alignment: the envelope-sender (Return-Path) domain must match your From domain. After you set the custom bounce subdomain, the Return-Path is something.yourdomain.com, which aligns at the organisational level.

DMARC passes if either aligned mechanism passes. In practice, for HubSpot:

• Connect the domain -> aligned DKIM. This alone is enough for DMARC to pass, and it survives forwarding, so it is your primary line.
• Set the custom bounce subdomain -> aligned SPF as a second, independent pass.

If you only ever do one thing, make it DKIM, because aligned DKIM is what keeps you passing through forwarders and mailing lists where SPF alignment quietly dies. The mechanics are covered in DMARC alignment explained and DKIM alignment and forwarding.

A worked example

Suppose your From address is hello@yourdomain.com and you send through HubSpot. After a correct connection, a delivered message's headers should show:

From: hello@yourdomain.com
Return-Path: <bounce@hs1._sending.yourdomain.com>
DKIM-Signature: v=1; a=rsa-sha256; d=yourdomain.com; s=hs1-12345; ...
Authentication-Results: mx.google.com;
   dkim=pass header.d=yourdomain.com;
   spf=pass smtp.mailfrom=hs1._sending.yourdomain.com;
   dmarc=pass (p=NONE) header.from=yourdomain.com

Both dkim=pass header.d=yourdomain.com and the SPF smtp.mailfrom are under your domain, so both align, and dmarc=pass. That is the target state. Paste any real delivered message into the DMARC report analyzer workflow, or read the headers directly with the email header analyzer, to confirm yours looks like this.

Reaching DMARC enforcement with HubSpot in the mix

DMARC is published as a TXT record at _dmarc.yourdomain.com. The policy you set, p=none, p=quarantine or p=reject, tells receivers what to do with mail that fails alignment. The mistake is to jump straight to p=reject while HubSpot (or any other tool) is still unaligned: legitimate marketing and transactional mail gets quarantined or rejected, and you find out from angry colleagues, not from a report. Read will enforcing DMARC break my email before you touch the policy.

The safe sequence for a HubSpot-sending domain:

1. Start at monitoring with reporting on

Publish a p=none record that requests aggregate reports so you can see every source sending as your domain, including HubSpot, before you enforce anything:

v=DMARC1; p=none; rua=mailto:reports@yourdomain.com; fo=1;

p=none changes nothing about delivery; it only asks receivers to send you XML reports. Build the record with the DMARC generator and confirm it is live with the DMARC checker. More on the policy ladder in DMARC policy: none, quarantine, reject.

2. Read the reports and find HubSpot

Aggregate reports are XML, one per receiver per day, and reading them by eye is miserable. Feed them into the DMARC report analyzer. You are looking specifically for HubSpot's sending IPs and whether they show:

• dkim=pass aligned to yourdomain.com (good, the CNAMEs worked), or
• dkim=pass but d=hubspot... (not connected, or connected on the wrong domain), or
• SPF/DKIM aligned to a HubSpot domain only (still on the unbranded path).

Reading your first DMARC report walks through exactly what these rows mean. If your reports come back empty, DMARC reports are empty explains the usual causes.

3. Fix HubSpot until it is aligned

If HubSpot is not aligning, the fix is almost always one of: the DKIM CNAMEs were never published (or have the doubled-suffix typo), the domain was never connected, or you connected a different domain (for example marketing.yourdomain.com) than the one in your From address. Resolve those, re-verify in HubSpot, and watch the next few days of reports flip HubSpot's rows to aligned passes.

Do not move the policy while any legitimate source is failing. The whole point of the monitoring phase is to reach a state where every real sender, HubSpot included, passes.

4. Step up gradually

Once HubSpot and your other senders are reliably aligned in the reports, raise the policy in stages. You can ramp with the pct tag to apply enforcement to a fraction of mail first:

v=DMARC1; p=quarantine; pct=25; rua=mailto:reports@yourdomain.com; fo=1;

Watch the reports, increase pct toward 100, then move to:

v=DMARC1; p=reject; rua=mailto:reports@yourdomain.com; fo=1;

The detail on sampling lives in DMARC pct sampling, and the full journey in reach p=reject without breaking email and our enforcement journey doc.

5. Subdomains and the From domain you actually use

Many HubSpot setups send from a subdomain such as email.yourdomain.com or marketing.yourdomain.com. DMARC's subdomain policy (sp=) and alignment then apply at that level. Make sure you connected the exact subdomain you send from in HubSpot, and that your DMARC sp policy is not stricter than that subdomain is ready for. See DMARC subdomain policy (sp) and subdomain DMARC record.

Common HubSpot authentication failures and what they mean

• DMARC fails only on HubSpot mail, everything else passes. The domain is unconnected or DKIM CNAMEs are missing or mistyped. Re-publish both hs1- and hs2- CNAMEs and re-verify.
• HubSpot says "Connected" but reports still show failures. You likely connected a different domain or subdomain than the From address actually uses, or the change has not propagated yet. Recheck the From domain on the specific email, and confirm propagation with the DNS propagation checker.
• SPF passes but DMARC still fails. Classic alignment problem: SPF passed against a HubSpot bounce domain, not yours. Set the custom bounce subdomain so the Return-Path is under your domain, or simply rely on aligned DKIM, which is enough on its own.
• Worked for months, then suddenly failed. If you flattened HubSpot's DKIM CNAME into a static TXT, a key rotation just broke you. Restore the CNAME. This is why CNAME-based DKIM exists.
• SPF permerror after adding HubSpot. You crossed the 10-lookup limit. See SPF permerror and the 10-lookup limit and consider flattening via our SPF product.
• Forwarded HubSpot mail fails for some recipients. SPF alignment breaks on forwarding; aligned DKIM does not. If DKIM is connected correctly you are covered. Detail in forwarding and DMARC.

Where this fits with other senders

Almost nobody sends only through HubSpot. You probably also send normal staff email through Google Workspace or Microsoft 365, invoices through an accounting tool, and notifications through a transactional provider. Each of those needs the same treatment: aligned DKIM, an authorised and ideally aligned SPF path, and a place in your single SPF record without breaking the lookup limit. The provider-specific companions are DMARC for Google Workspace, DMARC for Microsoft 365 and SPF for common providers. The meta-requirements that pushed all of this from "nice to have" to mandatory are in sender requirements 2024/2025 and our requirements page.

The practical takeaway

To authenticate HubSpot email properly:

1. Connect your sending domain in HubSpot and publish the two CNAME DKIM records (hs1-... and hs2-..._domainkey) exactly as given. Aligned DKIM is your most durable pass and it survives forwarding.
2. Set the custom bounce subdomain HubSpot provisions so the Return-Path is under your domain, giving you aligned SPF too. On the modern path you usually do not need a HubSpot include on your apex SPF at all; on the legacy path add include:_spf.hubspot.com to your single SPF record and watch the 10-lookup limit.
3. Publish DMARC at p=none with rua first, read the reports until HubSpot and every other real sender is aligned, then step up through quarantine (optionally with pct) to p=reject.

Verify each layer as you go with the DKIM checker, SPF checker and DMARC checker, and watch HubSpot's behaviour over time in the DMARC report analyzer.

If you would rather not babysit selectors, lookup limits and policy ramps by hand, that is exactly what we do for you. DMARC Engine takes a HubSpot-sending domain from p=none to p=reject with no email outage, hosts your SPF, DKIM and DMARC, and emails you the moment a source like HubSpot stops aligning. Start with continuous monitoring or read how the hosted DMARC service handles the whole journey.