HubSpot: authenticating email (DKIM, SPF and DMARC)

hs1._domainkey.example.com.  CNAME  example.com.hs1._domainkey.hubspotemail.net.
hs2._domainkey.example.com.  CNAME  example.com.hs2._domainkey.hubspotemail.net.

DMARC passes on DKIM alone

This is where DMARC's mechanics work in the configuration's favour. DMARC only validates a message if SPF or DKIM passes and aligns — one of the two conditions is enough. With HubSpot, DKIM aligns; SPF does not. The message therefore passes DMARC on the strength of DKIM alone, which is perfectly compliant and sufficient.

This asymmetry has a limit worth knowing: the redundancy is lower. Where a double-alignment arrangement (SPF and DKIM) survives the loss of either, a HubSpot send holds only by DKIM. If an intermediary gateway rewrites the message body and invalidates the signature, nothing catches the message — SPF, unaligned, cannot take over. In practice, on direct marketing traffic (no forwarding or cascading mailing list), this case stays rare, and DKIM holds. The worked examples, from the simplest to the strictest show how to set the _dmarc instruction once DKIM is in place. Under DMARCbis, the organisational domain that serves as reference is determined by the DNS tree walk, with no change to this reasoning.

The one case where the DKIM-only asymmetry really bites is retransmitted messages: an automatic forward, a mailing list that rewrites the subject or adds a footer. There, the DKIM signature can drop, and with no aligned SPF in reserve, the message fails DMARC. The ARC protocol was designed for exactly this — it lets a trusted intermediary attest the original authentication — but not every recipient evaluates it yet. On marketing mail sent directly to subscribers, the subject stays theoretical; it becomes real as soon as retransmissions interpose.

Do not "fix" SPF by mistake

The most frequent mistake around HubSpot is adding include:_spf.hubspot.com (or equivalent) to the domain's root SPF record, believing this aligns SPF. It is useless and counterproductive. Useless, because SPF alignment depends on the envelope domain, not the root SPF includes: as long as the envelope stays on hubspotemail.net, no include will align anything. Counterproductive, because each include consumes one of the ten DNS lookups SPF allows — and a record that stacks services by reflex eventually triggers a permerror that invalidates SPF for the whole domain, including the mail that did align.

The rule is therefore clear: with HubSpot, the root SPF is left untouched for campaigns. One relies on DKIM, watches the ten-DNS-lookup limit for other services, and lets the HubSpot envelope live its life without trying to align it.

Common configuration mistakes

Several traps recur in the body of reports the free DMARC analyzer processes daily.

Expecting SPF to align. The most common: a report shows SPF "fail" (in the alignment sense) on HubSpot traffic, and one tries to correct a defect that is not one. As soon as DKIM aligns, DMARC passes.

Adding HubSpot to the root SPF. Described above: no effect on alignment, at the risk of a permerror.

Publishing the CNAMEs without connecting the domain in HubSpot. As elsewhere, the platform must observe propagation and mark the sending domain as authenticated before signatures are actually applied.

Tightening the policy without verifying DKIM. Moving to p=reject while imagining oneself covered when the CNAMEs have not propagated means rejecting one's own campaigns.

Confusing the connected domain with the From domain. The domain authenticated in HubSpot must match the one shown in the campaigns' sender address; sending under a From @example.com while only another domain is connected leaves that traffic without aligned DKIM, and DMARC fails for those sends.

Shared IP, dedicated IP and marketing reputation

HubSpot sends by default from a shared IP pool, pooled across customers. For high volumes, a dedicated IP is offered as an option: reputation then belongs to the account alone, but it has to be built — a fresh IP must be warmed, ramped up in volume gradually over several days, or receiving providers will treat it as suspect. This choice has no effect on DMARC alignment — DKIM aligns the same way whatever the sending IP — but it weighs on deliverability, and so on what the reports' delivery rates show.

Marketing traffic also has a particular sending profile: peak volumes, higher unsubscribe and complaint rates than transactional mail. This is why it is often wise to send campaigns from a dedicated subdomain rather than the root domain, to isolate marketing reputation from that of human mail. This separation changes nothing in the DKIM mechanics described above: the selector signs in the name of the connected subdomain, which aligns in relaxed mode with the organisational domain — and the root domain, people's own, keeps a separate reputation.

The final proof: RUA reports

The only proof that a configuration holds is not the HubSpot console, but what recipients report. Once a _dmarc record is published with a rua= address, aggregate reports arrive within a few days and detail, source by source, what aligns and what fails. Reading the aggregation reports, read in detail confirms the expected case for HubSpot: on the HubSpot source, DKIM aligned, SPF not aligned — and that is a correct result, not a defect, as long as the DKIM column is green.

Most organisations run HubSpot alongside other senders — a transactional provider, the corporate mail suite, perhaps a helpdesk. Each appears as a distinct source in the reports, and each aligns on its own terms: HubSpot on DKIM only, a mail suite often on both SPF and DKIM. Reading them side by side is what prevents a hasty p=reject while one source is still unaligned — the report, not any single vendor's console, holds the whole picture of what leaves under the domain.

A simple cadence is enough: a first read a few days after publishing the _dmarc record, once several recipients have reported, then a weekly glance while the policy stays at p=none. HubSpot traffic is quick to recognise by its stable address ranges; the point is not to hunt an unaligned SPF, expected here, but to verify that DKIM holds across every campaign before tightening. Once that is confirmed over several days, the move to p=reject carries no risk for HubSpot traffic. The online analyzer reconstructs this state from the published records and the reports received, and places the domain on the path that leads to p=reject.