This is the no-DNS-engineer setup for HubSpot Marketing Email authentication in 2026: the two CNAME records DKIM needs, the SPF TXT record, the DMARC policy Google and Yahoo want, and the trap where HubSpot reports an email as delivered while half your list never sees it. The fix is free, takes under an hour of work, and it is almost always your DNS, not HubSpot.
I get the same call about once a month. A marketing lead at a B2B SMB rings me: "Our newsletter open rate dropped from 28% to 9% in three weeks. HubSpot says everything is delivered. What broke?" Nine times out of ten, nothing broke at HubSpot. Their domain was never properly authenticated, Gmail quietly tightened the rules, and now half the list lands in a quarantine nobody checks. HubSpot still logs those as delivered. The inbox never sees them.
Here is the part clients do not want to hear: the newsletter going to spam is usually their own DNS, not the tool. Fixing it is a DNS job, and it is one you can do yourself in an afternoon. This post is that job, written for a marketing ops person who has never opened a DNS console before.
What is HubSpot email authentication and why it matters in 2026
HubSpot email authentication is the set of DNS records (DKIM, SPF, DMARC) you publish on your sending domain so Gmail, Outlook, and Yahoo trust the emails HubSpot sends on your behalf. Without DKIM at minimum, HubSpot will not let you use your own domain in the From address and rewrites the sender to a HubSpot-hosted system domain instead, which drags your deliverability down.
The mechanics are simple. DKIM signs each outgoing email with a cryptographic signature that mailbox providers verify against a public key sitting in your DNS. SPF tells receiving servers which senders are allowed to send mail for your domain. DMARC ties the two together and tells receivers what to do when something fails: reject, quarantine, or just report it.
Two things raised the stakes. In early 2024 Google and Yahoo started enforcing DMARC, DKIM, and SPF for bulk senders. By 2026 the bar keeps rising, and even low-volume B2B senders without proper auth see real inbox-rate drops at Gmail, Outlook 365, and the major Polish providers. If you send any marketing email from your own domain, this is no longer optional.
Who needs to set this up
If you send HubSpot Marketing Email from your own domain (for example marketing@yourcompany.com rather than a HubSpot-hosted system address), you need DKIM at minimum. Sales sequences and 1:1 emails from connected inboxes inherit authentication from Gmail or Microsoft 365 and are usually fine. The pain point is almost always Marketing Email and automated workflow emails.
You need three roles available, and in an SMB it is often one person wearing all three hats: someone with HubSpot Super Admin access, someone with access to your DNS provider (Cloudflare, GoDaddy, OVH, home.pl, Route 53, whatever you run), and someone who can decide the DMARC policy. That is fine. One person, three logins, one afternoon.
How much does HubSpot email authentication cost
Zero. Email authentication is included with every HubSpot subscription that sends email, from Marketing Hub Starter, Professional, and Enterprise through Sales Hub, Service Hub, and Content Hub tiers. There is no paid gate and no add-on. If your DNS provider charged for record changes (none of the mainstream ones do), that would be the only cost.
Time cost: 30 to 45 minutes if your DNS provider is on HubSpot's auto-connect list. 60 to 90 minutes if you copy records manually. Then 24 to 48 hours of DNS propagation before you can verify.
How to configure DKIM, SPF, and DMARC for HubSpot
Follow this order and do not reorder it. DKIM comes first because HubSpot will not let you use your domain in the From address until that handshake verifies. Here is the exact sequence I run on client portals.
Step 1: connect your sending domain in HubSpot
In HubSpot, click the settings icon in the top nav, then go to Content, then Domains and URLs, then the Email Sending tab, then Connect sending domain. Enter the email address you actually send marketing emails from. HubSpot extracts the domain (the part after the @) and that becomes your sending domain.
If your DNS provider is one HubSpot can talk to directly, you get a one-click connect option. If not, and most Polish DNS providers like home.pl, nazwa.pl, and OVH fall in this bucket, HubSpot hands you the records to paste manually.
Step 2: add the two DKIM CNAME records
HubSpot's DKIM uses two CNAME records, not one. This trips up anyone who set up DKIM for Mailchimp or SendGrid and expects a single TXT record. The two CNAMEs let HubSpot rotate signing keys without you touching DNS again, but you have to add both or DKIM fails.
Each record looks like hs1-XXXXXXXX._domainkey.yourdomain.com pointing to a HubSpot-hosted target. Copy them exactly from the HubSpot UI into your DNS provider. The common mistake: pasting the full domain in the Name field when your DNS provider only wants the prefix. If your DNS UI already appends .yourdomain.com as a suffix, you type only the hs1-XXXXXXXX._domainkey part.
Step 3: add or update the SPF record
SPF lives as a single TXT record on your root domain, and you can only have one SPF record per domain. This is the rule everyone breaks. If you already have an SPF record (because you use Google Workspace, Microsoft 365, or another sender), do NOT add a second one. You edit the existing record and add HubSpot's include statement inside it.
A working SPF record for a company using Google Workspace and HubSpot looks like v=spf1 include:_spf.google.com include:[HubSpot's include] ~all. HubSpot shows you the exact include string in the connect-domain flow. Two separate SPF TXT records mean both fail. One combined record passes.
Step 4: publish a DMARC policy
DMARC is a single TXT record on _dmarc.yourdomain.com. For a first deployment I always start with v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com. The p=none means "do not reject or quarantine anything, just send me reports". You get aggregate XML reports from Google, Microsoft, and others showing which senders claim to be your domain. Read them for two weeks, fix any unauthenticated sources (a sales tool, your accounting system, a forgotten Mailchimp account), then move to p=quarantine, then eventually p=reject. HubSpot supports DMARC on your sending domain.
Do NOT start at p=reject. One client killed their own invoice emails for a week because they enforced DMARC before realizing their billing system was sending from the same domain through a different provider. Start loud on reports, quiet on enforcement.
Step 5: verify in HubSpot and send a test
Back in HubSpot, click Verify in the email sending UI. DNS propagation runs from 5 minutes to 48 hours. If verification still fails after 24 hours, the record is almost always typed wrong: usually a stray dot on the DKIM CNAME or the wrong target. Send a test marketing email to a Gmail address you control, open it, click Show original in the three-dots menu, and confirm DKIM=PASS, SPF=PASS, DMARC=PASS in the headers.
The "delivered but not delivered" trap
HubSpot's delivered count reflects emails the receiving mail server accepted, not emails that reached the inbox. This is the reason for half my deliverability rescue calls. When Gmail's SMTP servers say "ok, got it", HubSpot logs a delivery, even if Gmail then routes the message to spam or quarantine.
Quarantined emails appear as delivered in HubSpot but stay hidden from the recipient. They do not land in spam. They do not bounce. They sit in an admin-only quarantine queue that most B2B recipients never open. To HubSpot the send looks successful. To your prospect the email never existed.
The signal that this is happening: your HubSpot delivery rate holds at 98 to 99 percent, but your open rate drops 50 to 70 percent over a few weeks with no other change. If you see that pattern, read your DMARC reports first. They name the sources failing authentication.
What HubSpot email authentication does NOT fix
Authentication is the entry ticket, not the win condition. Setting up DKIM, SPF, and DMARC correctly will not save you from the problems below, and I regularly meet teams who treat DKIM as the single fix and then wonder why inbox rates stay low.
- A dirty contact list. Scraped or bought lists tank your sender reputation regardless of auth. Mailbox providers measure complaint rates and engagement, not just headers.
- Spammy copy. Subject lines screaming "FREE!!!" or an email that is 90 percent image still get filtered.
- A brand-new domain. Domain reputation builds over weeks. A cold domain with perfect auth still lands in spam on the first sends. Warm it up gradually.
- Subdomain confusion. Auth on
yourcompany.comdoes not automatically covermail.yourcompany.com. Each sending subdomain needs its own setup. - Skipping list hygiene. Contacts unengaged for more than 12 months should be sunset regardless of authentication state.
If your team also runs HubSpot Service Hub for ticket routing, the same authentication covers ticket reply emails sent from your domain: one setup, several Hubs benefit. And if you are unsure which contacts to keep sending to, the way you build your HubSpot Segments and suppression lists matters as much as the DNS records.
When to do it yourself and when to call someone
One domain, one sending tool, DNS provider on HubSpot's auto-connect list: this is a Tuesday afternoon job for one person, and you should not pay anyone for it. Follow the five steps above and you are done.
Call us if any of these apply: multiple sending domains and subdomains, mail going out from HubSpot AND a transactional provider (Postmark, SendGrid, Mailgun) AND Google Workspace, DMARC reports that already look like a war zone, or DNS living at a registrar like home.pl where the UI does not match HubSpot's screenshots. We have configured email authentication across 40+ B2B portals, and the edge cases get expensive when you learn them on production data. Start with a portal audit and we catch auth gaps alongside the other things B2B portals quietly get wrong, or book a discovery call for a direct read.
