HubSpot sends your marketing and sales email from its own servers, so inbox providers only trust it if your DNS says HubSpot is allowed to send as you. The connect-sending-domain flow does this with a small set of CNAME records: two for DKIM and one for the return-path that makes SPF align to your domain. Add those records, publish a DMARC policy, confirm every one resolves, and only then click Verify in HubSpot.
Reads public DNS only. Nothing is stored unless you save the domain to an account.
Where the connection lives in HubSpot
Open Settings, then go to Content > Domains & URLs on older accounts or Settings > Account Setup > Domains & URLs on newer ones. Choose Connect a domain and pick Email Sending. HubSpot asks for the domain you send from (for example yourdomain.com) and then generates the exact DNS records you need to publish. Keep that screen open. The target values are specific to your account, and you will copy them verbatim into your DNS host.
Decide two things up front. First, use the domain your recipients already recognise as your brand, not a throwaway subdomain, so DMARC alignment works in your favour. Second, make sure you have access to your DNS provider (Cloudflare, Route 53, GoDaddy, and so on) before you start, because the connection stays pending until the records resolve publicly.
The DKIM records are two CNAMEs, not one TXT
HubSpot signs every message with DKIM and hands you two CNAME records rather than a single TXT record. They follow this shape:
hs1._domainkey.yourdomain.com CNAME yourdomain.com.hs1.dkim.hubspotemail.net
hs2._domainkey.yourdomain.com CNAME yourdomain.com.hs2.dkim.hubspotemail.net
Copy the exact target hostnames from your HubSpot screen. The labels above show the pattern, not literal values to paste. Two selectors let HubSpot rotate keys without breaking your signing: it can retire one selector and stand up the other with zero downtime. Because these are CNAMEs, HubSpot controls the underlying public key and can rotate it on its side without asking you to edit DNS again. That is the practical difference from a TXT-based DKIM record, which you would have to change by hand on every rotation. The trade-off is covered in dkim cname vs txt record.
The d= value in HubSpot's signature is your domain, so DKIM is aligned for DMARC from the start. You do not configure alignment separately.
The return-path record and why it matters
The third record is the return-path, also called the bounce domain or envelope sender. It is a CNAME on a subdomain of your domain, shaped like this:
smtp.yourdomain.com CNAME <hubspot-value>.hubspotemail.net
The envelope MAIL FROM address HubSpot stamps on each message uses this subdomain of your domain, and that is the quirk that trips people up. SPF is checked against the envelope MAIL FROM domain, not the visible From header. Because HubSpot's return-path lives on your domain and points, through the CNAME, at HubSpot's SPF-authorised infrastructure, SPF passes and, just as important, aligns with your From domain under relaxed alignment. You get an aligned SPF pass without ever adding HubSpot to your root SPF record.
This subdomain does not need an MX record. Bounces route through HubSpot's servers via the CNAME target, so you are not running a mail server on smtp.yourdomain.com. If your DNS host tries to auto-add an MX or an A record on that name, remove it and keep only the CNAME HubSpot specified.
SPF: usually leave your root record alone
Because the return-path sits on a HubSpot-controlled subdomain, most HubSpot senders do not touch the SPF record on their root domain at all. This surprises teams who assume every sending tool needs an include in the main SPF record. Adding include entries you do not need is exactly how domains drift toward the ten-lookup SPF limit and start throwing PermError.
Keep your existing root SPF for the tools that actually send with your root domain as the envelope sender, such as your mailbox provider and your transactional relay. A typical root record still looks like:
v=spf1 include:_spf.google.com ~all
Leave HubSpot out of it unless HubSpot's own screen explicitly tells you to add an include for your specific configuration. If it does, follow that instruction, but the standard connected-domain flow relies on the return-path CNAME instead. If you want the full model of how the three checks fit together, read spf, dkim and dmarc explained.
DMARC and the Google and Yahoo bulk rules
HubSpot does not publish DMARC for you. You add it yourself as a TXT record at _dmarc.yourdomain.com. A first record can be as simple as:
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com
Since February 2024, Google and Yahoo require any domain sending more than roughly 5,000 messages a day to have SPF, DKIM and a DMARC record, with at least one authenticated identifier aligned to the From domain. The connected HubSpot domain gives you both an aligned DKIM signature and an aligned SPF return-path, so you clear the alignment bar comfortably. A policy of p=none is enough to satisfy the requirement to have a DMARC record while you watch reports.
Do not leave it at none forever. Once your aggregate reports confirm that HubSpot and your other legitimate senders pass, tighten the policy to quarantine and then reject so spoofed mail is actually blocked. Walk that path safely with move dmarc from none to reject, and check the full inbox-provider list in the Google and Yahoo sender requirements.
One alignment note: p=reject on your root domain does not interfere with HubSpot as long as the DKIM d= and the return-path both stay on your domain, which the connected flow guarantees. If you ever see DMARC failures from HubSpot after moving to reject, the usual cause is that someone reconfigured the return-path or removed the DKIM CNAMEs.
Verify DNS first, click Verify second
The most common HubSpot ticket is "I added the records and Verify still fails." Almost always the records simply have not propagated yet, or one value was pasted with a trailing typo. Before you click Verify in HubSpot, confirm every record resolves publicly. Run your domain through the scanner above and check that both DKIM selectors return, the return-path CNAME resolves, and your DMARC record is present and syntactically valid. When all of them show green, go back to HubSpot and click Verify. This ordering saves you from HubSpot's slower re-check cycle and from guessing which record is wrong.
Propagation can take anywhere from a few minutes to a couple of hours depending on your DNS host's TTL. If a record still does not resolve after that, look for a duplicate CNAME, a proxied (orange-cloud) record on Cloudflare that should be set to DNS-only, or your provider silently appending your domain to an already fully qualified target.
Frequently asked questions
Do I need to add HubSpot to my SPF record?
Usually no. HubSpot's connected sending domain uses a return-path on a subdomain of your own domain, and SPF is evaluated against that return-path, not your root domain. That produces an aligned SPF pass without an include. Only add an include if HubSpot's setup screen explicitly instructs it for your account.
Why does HubSpot give me two DKIM records?
Two selectors (hs1 and hs2) let HubSpot rotate signing keys without downtime. It can move signing to the second selector while retiring the first, so your mail keeps a valid DKIM signature throughout the change. Publish both CNAMEs and leave them in place.
Will a DMARC policy of reject break my HubSpot email?
No, as long as the connected domain is intact. HubSpot signs with your domain in the DKIM d= tag and uses a return-path on your domain, so both SPF and DKIM align. DMARC passes on an aligned identifier, so quarantine or reject applies only to unauthenticated mail, not your HubSpot campaigns.
How long before I can click Verify in HubSpot?
Wait until the records resolve publicly, which is usually minutes but can stretch to a couple of hours on high-TTL hosts. Confirm both DKIM CNAMEs, the return-path CNAME and your DMARC TXT record all resolve with the scanner first, then click Verify so HubSpot checks against records that are already live.