HubSpot SPF: adding HubSpot's include when you connect a sending domain

When a client's marketing team connects their domain to HubSpot, the MSP usually gets a forwarded screenshot of DNS records and the message "please add these." HubSpot's knowledge base describes four record types: MX, DKIM, SPF and DMARC. Most of the risk is in how the SPF record gets merged. This guide covers what HubSpot documents, where people go wrong, and how to check the result.

What HubSpot asks you to publish

HubSpot's article on managing email authentication says the domain-connection flow sets up "four separate DNS record types: MX, DKIM, SPF, and DMARC." DKIM uses two CNAME records, while SPF and DMARC each use a TXT record. HubSpot generates the values for each account and domain. Copy the Host and Required data columns from the client's HubSpot connection screen (Settings → Content → Domains & URLs → Email Sending → Connect sending domain).

A few constraints from HubSpot's article are worth passing on to the client:

• Use a domain that isn't hosting a website. HubSpot says you can only authenticate a sending domain "that's not currently in use for another purpose, such as hosting your website." A subdomain such as info.client.com is fine, and so is the root domain, "as long as it isn't being used to host content."
• Match the From: address. The connected domain should match the domain in the From address used for marketing email.
• Cloudflare users: HubSpot says to turn off domain-wide CNAME flattening and proxying for the sending domain.
• An account can connect up to 2,000 sending domains, and a domain can be connected to several HubSpot accounts.

The SPF include is generated for the account

HubSpot's article doesn't publish a single universal include. Its example of a merged record is:

```

v=spf1 include:anotherprovider.com include:123456.spf03.hubspotemail.net -all

```

The 123456.spf03.hubspotemail.net part is an example. The real value comes from the client's connection screen. The same article's troubleshooting section tells you to verify that the SPF record "includes include:shared.hubspot.com." Because the two parts of the article differ, go by what the client's HubSpot screen generates, and don't hand-type either value from a blog post, this one included.

Merging, not adding

HubSpot's instruction for domains that already have SPF is the important part:

> If you are prompted to update SPF, and you already have an SPF record, you will need to add HubSpot to the existing record, rather than creating a new one.

It also says to make sure the version tag (v=spf1) and the all term appear only once. Two separate v=spf1 TXT records at the same name give a permerror under RFC 7208 §4.5, and that breaks SPF for Microsoft 365 or Google mail on the domain as well as for HubSpot.

Put the HubSpot include before the existing all term. Keep the client's existing ending (-all or ~all) unless you mean to change it.

Lookup cost

On Oct 13, 2026, a live DNS check of shared.hubspot.com showed ip4 ranges plus one nested include (shared1.hubspot.com), so that include costs two lookups. The account-specific hubspotemail.net hosts weren't checked, because their names depend on the account. Run the client's actual record through the checker after you merge it, especially if the apex already carries Microsoft 365, a CRM and a ticketing tool.

Where HubSpot's records go if you use a subdomain

If the client connects info.client.com instead of the root, the generated records (including the SPF TXT record) are for that subdomain. That's one reason a marketing subdomain is attractive: its SPF record is separate from the apex record, so HubSpot's lookups don't count against the client's main mail flow. HubSpot's article recommends multiple subdomains when you have multiple email types or brands. It also notes that a subdomain counts as authenticated for DMARC if the root domain has a DMARC record, because subdomains inherit DMARC policy.

How HubSpot mail aligns for DMARC

DMARC (RFC 9989) passes when SPF or DKIM passes and the authenticated domain aligns with the From: domain. The default is relaxed alignment, which only needs the same Organizational Domain. HubSpot's two DKIM CNAMEs let HubSpot sign as the client's domain, which is the aligned pass to rely on. RFC 9989 says a domain using p=reject must not rely solely on SPF.

HubSpot's status screen gives you a quick read:

• Not authenticated: none of the three methods are verified.
• Partially authenticated: DKIM is verified, but SPF or DMARC isn't yet.
• Authenticated: DKIM, SPF and DMARC are all verified.

HubSpot says DNS changes usually take 10 to 70 minutes and can take up to 48 hours, and recommends waiting at least 20 minutes before you re-check.

A client checklist

• Agree with the marketing team on the sending domain (root or subdomain) before anyone touches DNS.
• Copy all generated records from HubSpot's connection screen, including the MX record. Don't skip it.
• Merge the SPF include into the single existing record for that host, then recount the lookups.
• Confirm a DMARC record exists at the domain or its root, and don't publish a second one.
• Wait at least 20 minutes, then check that HubSpot shows Authenticated.
• Send a test and confirm dkim=pass for the client's domain in the Authentication-Results header.

Check the client's SPF now

Run the free SPF checker →

It walks the include tree, counts DNS lookups against the RFC 7208 limit of 10, names common senders such as HubSpot, and flags duplicate SPF records, which is the mistake HubSpot's article warns about.

Founding Partner: $1,999, one time. Know the moment a marketing team's DNS change breaks a client's SPF, with weekly rescans and change alerts. Founding Partner covers 50 client domains with full branding (logo and colors), weekly rescans and change alerts, unlimited Security Briefs (150 prospect scans a month), the Grow toolkit, the Policy library, a branded service menu, webhooks, the API, and MCP access (except quote drafts). If you later subscribe to Pro, you pay $299/mo instead of $399 for as long as that Pro subscription stays active. The offer is capped at 50 seats and closes on Dec 15, 2026, or when all 50 seats are claimed, whichever comes first. Proposals and the Service Library require Pro. Founding Partner is non-refundable, except that you're refunded if the seats run out before your payment can be fulfilled.

See Founding Partner details →