How to set up SPF, DKIM and DMARC with HubSpot

Connect your email sending domain in HubSpot before you send anything. Until you do, HubSpot sends on its own domain's authority, nothing is signed with a key under your domain, and any receiver enforcing your DMARC policy fails the message. Connecting the domain means publishing a short set of CNAME records that HubSpot generates, and then verifying from a delivered message rather than from the dashboard.

How HubSpot authentication is shaped

HubSpot's email domain connection is CNAME-based. You publish records that point into HubSpot's zone, and HubSpot serves the DKIM keys and envelope configuration behind them. Two consequences worth understanding:

• You never maintain a public key. No 255-character TXT string splitting, no republishing when HubSpot rotates.
• The envelope sender ends up on a subdomain of yours, which means the SPF pass *aligns* with your From domain under relaxed alignment. A platform using its own bounce domain gives you an SPF pass that does not align and therefore does nothing for DMARC.

The exact host names and targets are account-specific and generated per portal. Take them from HubSpot's *Settings → Website → Domains* (email sending domain) screen. Any values you copy from an article will be wrong.

Publishing the records

1. In HubSpot, start the email sending domain connection and enter the domain you want in From.
2. HubSpot issues a set of CNAMEs — typically two DKIM records under _domainkey with account-specific prefixes, plus a record for the sending or return path. Copy each host and target exactly.
3. Enter only the relative host if your DNS provider appends the zone automatically, or you will create hs1-12345._domainkey.yourdomain.com.yourdomain.com.
4. Keep every record DNS-only. A CNAME proxied through a CDN returns the proxy's address instead of following the delegation, and authentication silently fails.
5. Remove any conflicting record at the same host. A CNAME cannot coexist with another record type at the same name.
6. Click verify in HubSpot, then verify yourself.

dig +short CNAME <the DKIM host HubSpot gave you>
dig +short TXT   <the DKIM host HubSpot gave you>
dig +short TXT   _dmarc.yourdomain.com

The TXT query on a CNAME host should return v=DKIM1; k=rsa; p=.... That is the resolver following the chain into HubSpot's zone, and it is the proof the setup works end to end. An empty result with a working CNAME usually means HubSpot has not provisioned yet — wait and re-check rather than editing.

Where SPF fits, and where it does not

Look at your apex SPF record before touching it:

dig +short TXT yourdomain.com | grep spf1

Exactly one line should come back. Two v=spf1 records is a specification violation: receivers return PermError and SPF fails for all your mail, including mail that would otherwise pass. And remember SPF's ceiling of 10 DNS-querying mechanisms per evaluation, counted recursively through every include, with no more than two lookups that return nothing.

With a CNAME-based setup, the envelope is on a subdomain whose SPF data HubSpot serves, so your apex record generally needs no change at all. Confirm by reading the Return-Path header of a delivered message: if it is on your subdomain, your apex SPF record is not what is being evaluated, and adding an include for the platform would spend a lookup for nothing.

Confirm with headers

Return-Path: <bounce@<subdomain>.yourdomain.com>
From: Marketing <hello@yourdomain.com>
Authentication-Results: mx.google.com;
  spf=pass smtp.mailfrom=<subdomain>.yourdomain.com;
  dkim=pass header.i=@yourdomain.com;
  dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=yourdomain.com

Both mechanisms aligned is the resilient state: a DKIM problem still leaves an aligned SPF pass, and forwarding still leaves an aligned DKIM signature. Note that spf=pass on a subdomain aligns with the apex only under relaxed alignment (aspf=r, the default). Switching to aspf=s would break it, which is the main reason not to enable strict alignment casually.

Unauthenticated and variable From domains

Two situations come up constantly in CRM sending and both have the same answer.

Sales reps sending from their own domains. If a user sends HubSpot mail from an address on a domain you have not connected, that mail is unauthenticated for DMARC purposes. Either connect each domain, or route that mail through the user's own mailbox connection so their provider authenticates it. Do not leave a mixed state where some reps pass and some fail — you will see it in reports as an unexplained fail stream and misdiagnose it as spoofing.

Free-mail From addresses. A gmail.com or yahoo.com address in From fails DMARC by design: those providers publish p=reject on their own domains specifically to stop third-party platforms sending as their users. There is no fix on your side.

DMARC rollout

_dmarc.yourdomain.com   TXT   "v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; fo=1"

Run p=none for a week, inventory every sender from the aggregate reports — the CRM, the helpdesk, the invoicing tool, the calendar tool — fix each to produce an aligned signature, then p=quarantine, then p=reject. Set sp= explicitly when you enforce, so a subdomain sending application mail is not caught by a policy nobody tested it against.

If rua points at a mailbox on another domain, that domain must authorise reports with a v=DMARC1 record at yourdomain.com._report._dmarc.<their-domain>.

What not to do

• Do not send marketing mail from a domain you have not connected.
• Do not proxy authentication CNAMEs through a CDN.
• Do not publish a second SPF record at the apex when adding a platform.
• Do not switch to strict alignment while using a sending subdomain.
• Do not treat a verified badge in the dashboard as proof of DMARC alignment. It means the platform can send; the d= tag in a real message tells you whether receivers credit it to your domain.

MailPilot checks SPF, DKIM and DMARC for every connected mailbox's sending domain and measures real per-provider inbox placement with a seed-inbox network, so an unconnected domain or a dropped CNAME shows up as a failing check rather than as a quarter of missing replies.