HubSpot sends marketing emails, transactional emails, and CRM-connected messages from your domain, making it a significant source of outbound mail that must be covered by your email authentication records. Without SPF, DKIM, and DMARC in place, HubSpot-originated messages risk landing in spam or being rejected entirely by receiving mail servers. By the end of this guide you will have a valid SPF record including HubSpot's sending infrastructure, a published DKIM record tied to your domain, and a monitoring-mode DMARC policy you can progressively enforce.
Before you begin
- DNS write access to your domain (via your registrar or DNS host — Cloudflare, Route 53, GoDaddy, etc.)
- Super Admin or Account Owner access inside your HubSpot portal
- A verified sending domain configured in HubSpot (the domain you send email from, not just your website domain)
- The ability to send a test email from that domain and view full message headers
- A list of any other services that send email on behalf of your domain (Google Workspace, Mailchimp, Salesforce, etc.) — you will need them when editing your SPF record
Step 1: Identify what's sending from HubSpot
HubSpot routes outbound email through its own shared and dedicated sending infrastructure. Depending on your portal tier and configuration, mail may leave via HubSpot's shared IP pools, a dedicated IP address provisioned to your account, or a connected inbox (such as Gmail or Outlook) that HubSpot sends through on your behalf. Each path has different authentication requirements. Before touching DNS, log in to HubSpot and confirm which sending domain is configured and whether you are using shared or dedicated IPs — HubSpot documents this distinction in its email sending settings. If you send through a connected inbox, that inbox provider's own SPF and DKIM records handle authentication for those messages; the steps below apply to mail HubSpot sends directly.
Step 2: Add the SPF include
HubSpot requires you to add an include mechanism to your domain's SPF TXT record so that HubSpot's sending servers are authorised to send mail from your domain. According to HubSpot's published DNS setup documentation, the include string to use is:
include:_spf.hubspot.com
Verify this value in your HubSpot portal under the email sending domain settings before publishing — HubSpot may update or supplement this string, and if you use dedicated IPs you may need an additional include or an ip4: mechanism for your assigned IP range.
Edit your existing SPF record — do not create a second TXT record for SPF on the same hostname, as only one SPF record is permitted per name. Below is a representative before-and-after for a domain that already sends through Google Workspace:
# BEFORE — Google Workspace only
your-domain.com. IN TXT "v=spf1 include:_spf.google.com ~all"
# AFTER — Google Workspace + HubSpot
your-domain.com. IN TXT "v=spf1 include:_spf.google.com include:_spf.hubspot.com ~all"
Keep the ~all (softfail) qualifier while you are in monitoring mode. Once DMARC is enforced and you are confident all legitimate sources are covered, you can tighten to -all (hardfail).
SPF lookup limit warning: The SPF specification hard-caps DNS lookups at 10. Every
include:,a:,mx:, andredirect=mechanism that requires a DNS query counts toward this limit — and each include can itself chain to further lookups. HubSpot's include typically resolves to two or three lookups internally. If your SPF record already covers several SaaS senders (Salesforce, Zendesk, SendGrid, etc.), adding HubSpot may push you over the limit, causingSPF permerrorfailures. Audit your current lookup count before saving the record.
Step 3: Enable DKIM in HubSpot
HubSpot generates a DKIM key pair per sending domain and gives you a TXT record to publish in DNS. The general workflow is as follows:
- In your HubSpot portal, navigate to Settings (the gear icon), then to the Marketing or Email section. Look for a Sending Domains or Email Sending page — HubSpot's exact menu labels vary by portal version, so consult HubSpot's current help documentation if the path has changed.
- Find the domain you send from and look for a DKIM or DNS authentication setup option. HubSpot will display two DNS records you need to publish: a DKIM TXT record and, in some configurations, a CNAME record used for click-tracking or additional authentication.
- Copy the exact hostname and value that HubSpot displays. HubSpot's DKIM record names follow a pattern similar to
smtpapi._domainkey.your-domain.com, but the exact selector name shown in your portal is authoritative — do not guess or substitute a different selector. - In your DNS provider, create a new TXT record using the hostname and value exactly as HubSpot provides them. The general form of the record looks like this:
# DKIM TXT record (use the exact name and value from your HubSpot portal)
<selector>._domainkey.your-domain.com. IN TXT "v=DKIM1; k=rsa; p=<your-public-key>"
If HubSpot provides a CNAME record instead of a TXT record for DKIM (some platforms delegate key rotation this way), publish a CNAME record rather than a TXT record — the record type HubSpot specifies is intentional.
After publishing, return to HubSpot's sending domain settings and use any built-in verification button to confirm HubSpot can see the record resolving correctly. DNS propagation typically takes a few minutes to a few hours.
Step 4: Publish your DMARC record
With SPF and DKIM in place, publish a DMARC record at _dmarc.your-domain.com. Start with p=none — this policy instructs receiving servers to take no action on failing mail but to send you aggregate reports, giving you at least 14 days of visibility into your mail streams before you risk blocking legitimate email.
_dmarc.your-domain.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-rua@dmarcbusta.pro; ruf=mailto:ruf@dmarcbusta.pro; fo=1; adkim=r; aspf=r"
Tag reference for this record:
| Tag | Value | Meaning |
|---|---|---|
p |
none |
Monitor only — no enforcement action taken yet |
rua |
mailto:dmarc-rua@dmarcbusta.pro |
Aggregate report destination (daily XML digests from receiving servers) |
ruf |
mailto:ruf@dmarcbusta.pro |
Forensic/failure report destination (not all receivers send these) |
fo |
1 |
Generate a failure report if either SPF or DKIM fails (not only when both fail) |
adkim |
r |
Relaxed DKIM alignment (subdomain matches count) |
aspf |
r |
Relaxed SPF alignment (subdomain matches count) |
After reviewing aggregate reports and confirming that all legitimate sending sources pass authentication, progress to p=quarantine (routes failing mail to spam), then to p=reject (blocks failing mail outright). A typical progression timeline is 14 days at none, 14–30 days at quarantine with a low pct value, then full reject.
Step 5: Verify it works
Before sending a test email, confirm your DMARC record actually published. Use our free DMARC Checker to look up _dmarc.your-domain.com and verify the record is live, has the correct policy (p=none, quarantine, or reject), and is configured for aggregate reporting. While you are there, run the SPF Checker against your domain to make sure the SPF lookup tree is clean — once both records check out, the live email test below will give you the final confirmation.
Send a test email from HubSpot to a Gmail or Yahoo Mail address you control, then view the full message headers:
- Gmail: Open the message, click the three-dot menu in the top-right corner, select Show original. The Authentication-Results header appears near the top.
- Yahoo Mail: Open the message, click the three-dot menu, select View raw message.
Look for the Authentication-Results header and confirm all three checks pass:
Authentication-Results: mx.google.com;
spf=pass (google.com: domain of sender@your-domain.com designates x.x.x.x as permitted sender)
dkim=pass header.i=@your-domain.com header.s=<selector>
dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=your-domain.com
- spf=pass — the sending IP is listed as authorised in your SPF record
- dkim=pass — the message signature validates against the public key in DNS
- dmarc=pass — at least one of SPF or DKIM passes and the authenticated domain aligns with the From header domain
If any check shows fail or permerror, the common errors section below covers the most likely causes.
Common errors with HubSpot
- DKIM selector not found or still propagating. If HubSpot's verification step returns an error immediately after you publish the record, wait 15–30 minutes and try again. If it fails after several hours, confirm the record name matches exactly what HubSpot displayed — a single character difference in the selector name will cause a lookup failure.
- SPF permerror from too many lookups. HubSpot's include chain can consume several of your 10 available DNS lookups. If you already include Google, Microsoft, Salesforce, and other senders, you may exceed the limit before HubSpot is added. Use an SPF lookup counter tool to audit your current count and consider flattening or delegating SPF management.
- Multiple SPF records published on the same hostname. Publishing a second
v=spf1TXT record instead of editing the existing one causes an immediatepermerror. There must be exactly one SPF record per hostname. Delete any duplicates. - DMARC alignment failure despite SPF passing. If HubSpot sends mail from a subdomain (e.g.
email.your-domain.com) but your From header uses the root domain (your-domain.com), SPF will pass for the subdomain but fail DMARC alignment under strict mode. The default relaxed alignment (aspf=r) handles most cases, but confirm your HubSpot sending domain matches or is a subdomain of your From address domain. - DKIM key split incorrectly across TXT strings. Some DNS providers split long TXT values at 255 characters automatically; others require you to split manually. If the key is not reassembled correctly by the DNS provider, DKIM validation will fail. Verify the published TXT record using
dig TXT <selector>._domainkey.your-domain.comand compare the full value to what HubSpot shows in its portal.
How DMARC Busta helps
The steps above get you to a working baseline, but maintaining email authentication across HubSpot and every other platform sending from your domain is an ongoing operational task — new senders appear, SPF records drift over the 10-lookup limit, and DMARC policies need to be advanced deliberately once reporting data confirms it is safe to do so.
DMARC Busta's Autopilot mode is designed to manage DMARC policy progression automatically, advancing from
p=nonetop=quarantinetop=rejectbased on aggregate report data rather than manual review. SPF Auto-Repair handles SPF delegation and lookup-count management so your record stays valid as new services are added or removed. Managed DMARC reporting parses and normalises aggregate XML reports into actionable dashboards — designed to support individual domains up to large MSP environments managing 10,000+ domains from a single interface. If you followed this guide manually, DMARC Busta can take over ongoing management from the point you are at now.
Start your free trial and put your email authentication on autopilot.