HubSpot SPF, DKIM and DMARC setup, step by step

To set up HubSpot SPF and DKIM, connect the domain used in your marketing From address, publish the DNS values generated in your HubSpot account, and verify a delivered marketing message. HubSpot uses two DKIM CNAME records. Its shared-server SPF configuration and dedicated-IP return-path setup differ, so there is no universal HubSpot SPF record to paste into every domain. HubSpot authentication overview

This guide covers HubSpot marketing email, with a separate decision point for dedicated-IP and transactional sending. A salesperson’s connected Google Workspace or Microsoft 365 inbox needs its own provider configuration.

This is a documentation-based implementation guide, not a report of changes or test sends performed in your account.

Choose the HubSpot sending route first

HubSpot’s marketing editor and marketing workflows send through HubSpot’s network. Emails sent through a connected inbox, including connected-inbox sequences and one-to-one CRM messages, use the inbox provider instead. Authenticate the service that actually transports the message. HubSpot sending routes

Before opening DNS, write down:

• The exact From address for the campaign or workflow.
• Whether the send uses shared HubSpot infrastructure, a dedicated IP, or a connected mailbox.
• The HubSpot account and brand responsible for that identity.
• Who controls the authoritative DNS zone and who owns the existing DMARC policy.
• Which other applications send using the same domain.

For example, a campaign from news@example.com and a salesperson’s email from alex@example.com can share a visible domain while using different outbound systems. Successfully authenticating one route should not close the other route’s configuration ticket.

For the separate employee-mail route, use the Microsoft 365 authentication guide when Microsoft 365 actually sends the message. Its records do not replace the HubSpot marketing setup.

Keep transactional tests separate as well. HubSpot distinguishes the Dedicated IP Address Add-On for marketing from the Transactional Email Add-On for transactional traffic. Use the onboarding requirements for the add-on you actually have. Dedicated-IP requirements

What should the HubSpot SPF record contain?

On shared servers, HubSpot already configures SPF for its envelope return-path domain. It also recommends adding the account-provided HubSpot authorization to the visible From domain’s SPF record. Dedicated-IP customers configure SPF on their envelope return-path domain during setup. Obtain the value from domain settings rather than borrowing another customer’s include hostname. HubSpot SPF behavior

SPF evaluates the envelope sender, not simply the address displayed to the reader. Adding authorization to a different domain does not change the envelope identity. If an SPF change is requested, preserve one SPF TXT record at that owner name and check the ten DNS-lookup-term limit, including nested lookups. SPF specification, RFC 7208

A safe change request should contain the existing full policy, the proposed full policy, and the reason each authorization remains. Do not replace the company’s Microsoft 365 or Google Workspace policy with a HubSpot-only example. Do not remove an unfamiliar include until its owner confirms that the sender has been retired.

If an existing SPF policy uses redirect=, preserve its intended authorizations and final semantics through a reviewed merge. Any all mechanism causes redirect to be ignored, so appending a canned policy or an all without reviewing that dependency can change which senders are authorized. SPF redirect semantics.

Connect the marketing sending domain

Prerequisites: HubSpot lists Starter, Professional or Enterprise subscriptions in Marketing, Sales, Service or Content Hub for this feature. The person connecting the domain needs Domain settings permission and DNS access. HubSpot access requirements

In HubSpot, open Settings → Content → Domains & URLs → Email Sending → Connect sending domain. Enter the marketing email address and confirm its domain. Choose the offered DNS-provider connection or manual setup. Copy the generated Host and Required data fields. The current guide identifies two DKIM CNAMEs, SPF and DMARC TXT records, and references MX in its overall connection requirements. Follow the records actually generated for your route; do not invent an MX target. HubSpot connection instructions

Before approving an automated change, compare its requested edits with your DNS inventory. Manual setup is useful when a separate administrator must review the policy or when existing records require reconciliation. Neither method removes the need to check what became publicly visible.

Use this worksheet. Every bracketed item must come from your account, not from this article:

HubSpot currently limits sending-domain choices to a domain not already used for another purpose such as website hosting. A subdomain can be used, and the connected domain should match the marketing From address. Confirm this before choosing a company’s website hostname. Sending-domain limitations

Handle a dedicated-IP return path separately

This route requires Marketing Hub Professional or Enterprise and the Dedicated IP Address Add-On or Transactional Email Add-On. Confirm entitlement before planning the dedicated-IP change. Dedicated-IP prerequisites

The dedicated-IP wizard distinguishes the recipient-visible sending domain from the dedicated-IP sending domain used in return-path headers. It provides A, MX, SPF TXT and DKIM CNAME records; its MX priority is 0. Publish those records at the exact generated owners. Do not replace your company’s inbound-mail MX records merely because an MX appears in this wizard. HubSpot dedicated-IP setup

For this separate wizard, open Content → Domains & URLs → Connect a domain, choose Dedicated IP, then Connect. Review the visible sending domain and return-path domain before copying records. After publication, use Check again if needed, require Verified, then choose Done. The provider allows up to 24 hours for this check. Marketing Dedicated IP warm-up gradually shifts traffic over 40 days; the Transactional Email Add-On differs, so a first sample does not prove all future traffic already uses the dedicated IP. Dedicated-IP sequence and transition.

Before publishing any generated A or MX record, compare its exact full owner, type, IP or target, and MX priority with the mail-routing owner’s separately approved plan. The wizard’s DNS packet is not permission to redirect inbound mail or activate an unapproved destination. Resolve discrepancies before publication or activation; preserve unrelated receiving routes. Dedicated-IP record requirements.

For an existing dedicated-IP deployment, compare the proposed change with the current return-path domain before touching records. If a migration is planned, keep a record of which campaigns or transactional integrations still use the old setup. Removing old authentication records too early can break messages already queued or applications not yet migrated.

Publish DNS without breaking other services

Export the current zone or save the affected records before editing. Confirm that the DNS interface belongs to the nameservers authoritative for the domain. A registrar account can display editable records without being the active DNS host.

Check how the editor handles names. If it automatically appends example.com, entering a full name may accidentally produce a duplicated suffix. Check the fully qualified published result, not just the saved form. A CNAME also cannot coexist with conflicting data at the same owner; investigate a collision instead of deleting an existing service record. Cloudflare’s explanation of CNAME conflicts

For an issued signing domain such as news.example.com, a full owner SELECTOR._domainkey.news.example.com is SELECTOR._domainkey.news relative to the parent example.com zone, or SELECTOR._domainkey in a separately delegated news.example.com zone. If _domainkey.news.example.com itself is delegated, the relative owner there is SELECTOR. Replace the selector placeholder with the issued value, preserve the account’s exact type and public value, and publish at the actual authority without removing the NS delegation. This example explains name placement, not automatic product eligibility for a new domain. DKIM owner construction, relative DNS names.

For Cloudflare, HubSpot also instructs administrators to turn off domain-wide CNAME flattening and proxy settings; review any wider DNS impact before changing a zone-level setting. HubSpot Cloudflare requirements

Keep authentication aliases DNS-only where your DNS service offers an HTTP proxy. Preserve the account’s generated targets exactly. Treat DMARC changes as a separate policy decision: an example monitoring policy is not permission to weaken an existing enforcement policy.

Current DMARC standards replace older pct percentage-rollout guidance. Do not import that tag, change strict alignment to relaxed, or copy a report recipient simply because an older provider example includes it. Keep existing policy decisions until the owner approves a change. Current DMARC policy.

For authentication records that actually use CNAME, retain a literal CNAME answer to the issued target and use DNS-only rather than HTTP proxying. Turn the relevant per-record Flatten setting off where available, and ensure applicable whole-zone settings do not suppress the alias. On Cloudflare, flatten-all cannot be overridden per record; apex CNAMEs are flattened by default, and same-zone targets are flattened regardless of that setting. These are DNS-host behaviors, not assumed controls in the sending application. If mandatory behavior or shared settings cannot preserve the required CNAME answer, stop and coordinate a supported layout without breaking other services or removing shared NS delegations. Do not blindly disable features across the whole zone. Cloudflare verification guidance, flattening controls and limits.

Only when no direct or applicable inherited policy exists and the domain owner approves first-time monitoring, publish one TXT policy with v=DMARC1; p=none at the intended From domain’s DMARC owner. For example.com, the full owner is _dmarc.example.com, entered as _dmarc in that zone. For news.example.com, use full owner _dmarc.news.example.com: _dmarc.news relative to the parent zone, or _dmarc in the separately delegated child zone. Do not create a child monitoring exception to an existing protective policy. The minimal value requests no reports; append ; rua=mailto:APPROVED_REPORT_ADDRESS only after replacing the placeholder with a provisioned, approved destination. DMARC policy publication.

Compare the Organizational Domain of the aggregate-report URI host with the Organizational Domain of the domain where the DMARC policy was found, not automatically the visible From domain. If they differ, the report-generating receiver must check the destination’s DNS authorization. A destination in the same Organizational Domain as that policy domain is excepted, even when its hostname differs. This protocol check does not replace the domain owner’s separate approval to share report data with that recipient. RFC 9990 section 4.

Verify DNS, HubSpot status, and a real message

HubSpot recommends waiting at least 20 minutes after DNS edits before checking. It documents typical updates of 10–70 minutes, with some taking up to 48 hours. HubSpot verification timing

For a layout that issues A or MX records, query those exact full owners at authoritative and recursive resolvers as well. Compare the complete address set and MX numeric-priority/target set with the separately approved routing plan before accepting the configuration. A nonempty response is insufficient, and the dedicated MX priority must match the documented requirement. Do not alter root mailbox routing during this check. Dedicated-IP DNS requirements.

Use three independent checks:

1. Public DNS: query each generated DKIM hostname for CNAME and confirm the returned target. For TXT-based requirements, inspect the complete TXT value. Query the authoritative nameserver and a public recursive resolver if their results disagree.
2. HubSpot: return to the Email Sending tab and review authentication status. A green account result is useful configuration evidence, but it is not a delivered-message test.
3. Recipient: send a small, authorized campaign through the same marketing route intended for production. Use a mailbox you control and inspect its full original headers. In Gmail, open the message’s More menu and choose Show original. Google’s header instructions

Record the visible From domain, envelope sender, DKIM signing domain and selector, and the receiving service’s authentication results. The DKIM d= value identifies the signing domain; s= identifies the selector used for its DNS key lookup. DKIM specification

For DMARC, at least one passing mechanism must align with the visible From domain. Relaxed alignment permits the same organizational domain; strict alignment requires an exact match. A passing SPF result for an unrelated return-path domain is not aligned SPF. Current DMARC specification, RFC 9989

Accept the marketing-route test only when the expected HubSpot DKIM signature passes, its signing domain aligns with the intended From domain, and the trusted receiver reports DMARC pass. DNS visibility and account status alone do not meet this completion check.

Retain a redacted header sample and the send date. Use the receiving system’s trusted Authentication-Results, rather than assuming every header with that name is trustworthy. Authentication-Results standard

Use receiver-controlled diagnostic output, or have the receiving administrator establish which fields were generated inside its known processing boundary and document how externally supplied Authentication-Results are removed or distinguished. A familiar authserv-id string or header position alone does not establish provenance. Ignore attacker-inserted or otherwise untrusted results, including a forged field naming the expected receiver. Operational receiving-boundary requirements.

Diagnose SPF at the actual smtp.mailfrom independently, even when aligned DKIM supplies DMARC pass. fail or softfail calls for checking whether the connecting sender is authorized for that envelope route; temperror indicates transient evaluation trouble such as a DNS timeout; permerror calls for checking malformed syntax, duplicate policies and the evaluated DNS-term budget. A passing but unaligned SPF identity is a separate condition. SPF result meanings.

Troubleshoot by the failed layer

DNS record missing: check the authoritative zone, duplicated domain suffix, record type, and CNAME target. Repeatedly saving the same value will not repair a change made at an inactive DNS provider.

HubSpot accepts the domain but DMARC fails: compare the actual message identities. Confirm the campaign used the authenticated From domain and that a connected-inbox sample has not been mistaken for a marketing sample.

SPF passes but alignment fails: inspect the envelope domain. Evaluate aligned DKIM before assuming that another SPF include will help.

Mail is authenticated but lands in spam: examine recipient consent, complaint rates, content, sending history and list quality. Authentication is only part of a receiver’s delivery decision. Google’s sender guidance also addresses unsubscribe handling and spam complaints. Gmail sender requirements

When escalating, provide the route, affected domain, UTC timestamp, exact validation message, public DNS result and redacted received headers. Avoid sending credentials, API keys or an unrestricted DNS-zone export.