HubSpot marketing email and a salesperson's connected mailbox are different sending arrangements. Start by identifying the workflow you are configuring. Authenticating a marketing sending domain does not establish the state of every message associated with the CRM.
This guide concerns the email sending domain used for HubSpot marketing email. Record the relevant account, the From domain and its business owner before making changes.
Choose a domain that fits the workflow
Read the current domain eligibility guidance before selecting the name. HubSpot's present instructions say that an email sending domain must not already be in use for another purpose such as hosting content. A suitable subdomain can keep this route distinct, but it still needs an explicit owner and tested configuration.
Check the exact domain used in the marketing From address against the proposed sending-domain connection. A new name that looks similar to the brand can still be the wrong name for the actual campaign.
Map the other uses of the domain or subdomain: hosted content, receiving mail, redirects, another HubSpot account and outside services. Resolve conflicts before accepting a generated DNS change.
Review the generated DNS request as a change set
Use the current Email Sending connection workflow and the values generated for the account. HubSpot's guidance covers MX, DKIM, SPF and DMARC, with details that must be checked at their specified owner names.
Do not move the organisation's normal mailbox MX records merely because a sender workflow displays an MX requirement. Establish the exact name and purpose in the generated request. A subdomain-specific change and a root-domain change have different consequences.
For SPF, inspect the existing policy at the exact name being changed. If one already exists, reconcile the needed authorisation into that policy rather than creating a second SPF policy there. Place the authorising mechanism before the terminating all mechanism, and ensure the resulting evaluation remains valid and within the DNS-dependent lookup limit.
Treat DMARC as the domain owner's policy decision. Preserve an existing suitable policy and reporting configuration. A marketing setup should not reset controls for unrelated mail.
Check how DNS publishes the values
Identify the active authoritative host rather than relying on a registrar's name. Compare the full resulting owner names and values after publication.
HubSpot specifically calls out Cloudflare proxy and domain-wide CNAME-flattening settings. Follow the current supported requirements for the authentication records, and assess any wider DNS change separately. Do not change unrelated website behaviour simply to clear an email setup warning.
For an automatic connection, review the changes and record what was actually written. For a manual connection, check suffix handling and record-type conflicts. Both paths need observable public answers.
Verify the actual marketing message
Complete HubSpot's authentication checks, then send an appropriate controlled campaign test through the intended route. Keep the original received message, account context and sending time.
Inspect the visible From, envelope identity, DKIM signing domain and trusted receiver results. Record the alignment path that supports DMARC. A passing signature for an unrelated service domain is not enough by itself.
In a synthetic case, the DNS team successfully connects a marketing subdomain, but the campaign still uses the old root-domain From address. The configuration and the message describe different identities. Correct the intended sender configuration, then repeat the campaign-route test rather than adding records to every plausible name.
Do not generalise one test to every connected mailbox, transactional route or integrated service. Test the workflows that matter to the scope of this change.
Preserve a useful completion record
The handover should identify the account, selected sending domain, generated records, DNS change owner and verified message. Include the reason for choosing the domain and any other account using it.
Review the configuration when campaign ownership changes or a new subdomain is introduced. Keep old dependencies until retirement has been verified rather than deleting them as soon as a new campaign succeeds.
Use sender inventory to connect marketing ownership with the wider mail programme. Authentication establishes an identity path; permission to contact recipients, list quality and inbox placement remain separate matters.
Separate sender correction from a policy change
Written case HS-01 assumes the marketing account has news.example.com connected, while the planned campaign From is updates@example.com. A hypothetical trusted message result is DKIM pass with d=news.example.com, s=demo1. That signature can align under ordinary relaxed organizational-domain alignment but does not exactly align with the root under adkim=s. SPF and all other signatures remain unknown, so do not report an overall strict-mode DMARC failure. The marketing owner must confirm the intended From and matching product connection, then obtain an authorized campaign sample; changing domain-wide policy is not the repair proposed here. The normal staff mailbox MX at example.com remains outside this change. No HubSpot account, mailbox or DNS was tested.
Use the generated record owners and values, rather than turning troubleshooting examples into universal selectors. HubSpot currently documents paired DKIM CNAMEs and an SPF merge when a policy exists. Its status labels describe setup checks; even a fully authenticated label does not prove that this planned campaign selected the correct From identity.
Preserve the enforcement boundary
RFC 9989 Section 7.4 requires valid DKIM, not SPF alone, for domains publishing p=reject, and warns about indirect-mail and mailing-list interoperability. A single successful direct-message test is not proof that every legitimate route is ready for stronger policy. Keep existing approved protection while diagnosing the actual gap; any policy change needs its own decision.