The pre-flight DNS checklist: Authenticating HubSpot and Salesforce

Before dispatching your first campaign from HubSpot or Salesforce, you must configure four distinct DNS resource records—MX, DKIM, SPF, and DMARC—so receiving mail servers authenticate outbound messages without dropping them into spam. AutoSPF recommends a strict pre-flight operational sequence: audit existing lookup limits against the RFC 7208 specification, establish dual CNAME keys for DomainKeys Identified Mail, append vendor includes to your single Sender Policy Framework record, and monitor traffic under an unrestrictive DMARC policy. Skipping these steps triggers an SPF PermError or cryptographic failure, damaging domain reputation before your marketing operations launch.

Audit your existing SPF infrastructure

Every third-party SaaS integration adds weight to your domain's DNS records. Most marketing operations teams treat the addition of HubSpot or Salesforce as a simple copy-paste exercise. Systems administrators know that DNS is an unforgiving protocol governed by strict operational limits.

Before touching your zone file, you must run an inventory of every active sending service authorized on your root domain and subdomains. Most organizations discover dozens of uncataloged transactional platforms, billing engines, and support desks already publishing mechanisms to their records. The revenue impact of breaking these existing streams is documented in The Hidden Cost of Email Deliverability Failures for Enterprises.

The 10-lookup threshold

The primary technical constraint in email authentication is the 10-DNS-lookup limit defined in RFC 7208 section 4.6.4. To prevent denial-of-service amplification attacks on nameservers, receiving Mail Transfer Agents (MTAs) count every mechanism that requires an additional DNS query during SPF evaluation.

These specific mechanisms consume lookups:

• The include: mechanism triggers a query to fetch the target domain's SPF record.
• The a and mx mechanisms require address record resolution for hostnames.
• The ptr mechanism executes reverse DNS resolution (and should never be used).
• The exists: mechanism triggers a custom DNS query per evaluation.
• The redirect= modifier performs a full lookup for a replacement SPF record.

Mechanisms like ip4, ip6, and all evaluate locally against the sending IP address and do not count toward this limit. If an evaluation hits lookup number 11, the receiving server aborts the check immediately and returns an SPF PermError. For any domain already sitting at 8 or 9 lookups, adding a single new enterprise tool pushes the record over the edge.

Hidden nested mechanisms

The 10-lookup counter does not just evaluate your visible DNS record. It recurses through every nested layer of your vendor includes.

When you add a single include statement for a platform like Salesforce, that record references sub-records maintained on the vendor's nameservers. Those sub-records often reference further includes or exists statements. What looks like one mechanism in your DNS dashboard can consume four or five lookups behind the scenes.

yourdomain.com TXT -> include:_spf.salesforce.com (1)
  _spf.salesforce.com TXT -> include:_spf-a.salesforce.com (2)
  _spf.salesforce.com TXT -> include:_spf-b.salesforce.com (3)

AutoSPF specializes in solving this recursive expansion problem for global organizations. Because third-party vendors update their underlying network routes without notifying clients, static records that sit at 9 lookups today can drift to 11 lookups tomorrow without your knowledge. Resolving this constraint requires continuous tracking of nested mechanisms across your entire sending stack.

Configure provider-specific DKIM records

DomainKeys Identified Mail (DKIM) provides the cryptographic signature that proves an email originated from an authorized server and arrived without tampering. Unlike SPF, which verifies the envelope sender IP address, DKIM signs the actual body and selected headers of the email using an asymmetric key pair.

Major receiving providers like Google and Yahoo prioritize DKIM validation when evaluating inbound bulk marketing traffic. According to HubSpot email authentication requirements, attempting to send marketing emails without establishing custom DKIM will cause HubSpot to fall back to a shared variable domain (such as user=yourcompany.com@hs-domain.com). This alters your visible branding and harms recipient engagement.

HubSpot CNAME architecture

HubSpot automates key management through DNS CNAME delegation. When you connect a sending domain inside HubSpot's Marketing Hub, the system generates two separate CNAME records pointing to HubSpot-managed nameservers.

This architecture delegates key rotation to the vendor. Instead of requiring you to manually publish new 2048-bit RSA public keys in TXT records every six months, HubSpot rotates keys on their backend servers without modifying your zone file.

When adding these records, check whether your DNS hosting provider automatically appends your root domain. Entering hs1-123456._domainkey.yourdomain.com into a registrar interface that automatically adds the root domain will create an invalid record at hs1-123456._domainkey.yourdomain.com.yourdomain.com. Verify the final fully qualified domain name (FQDN) using command-line query tools before initiating validation.

Salesforce primary and alternate selectors

Salesforce uses a dual-selector model to prevent delivery interruptions during cryptographic key rotation. In Salesforce Setup under DKIM Keys, generating a new 2048-bit key produces both a primary selector and an alternate selector.

As outlined in Salesforce's DNS guide for email deliverability, administrators must publish both CNAME records in their DNS provider before activating the key in the Salesforce console:

example-sf-a._domainkey.yourdomain.com CNAME example-sf-a.xxxxxx.custdkim.salesforce.com
example-sf-b._domainkey.yourdomain.com CNAME example-sf-b.yyyyyy.custdkim.salesforce.com

Leaving the alternate selector unconfigured means that when Salesforce initiates a scheduled security rotation to the secondary key, outbound application traffic will immediately fail cryptographic verification. Publish both CNAME entries, wait for DNS propagation across public resolvers, and click activate inside the Salesforce interface.

Alignment mode rules

DMARC requires DKIM to align with the domain displayed in the email's visible "From" header. The authentication protocol recognizes two alignment modes:

• Relaxed alignment (adkim=r) accepts signatures where the signing domain (d=) shares the same organizational domain as the visible From header. A message sent from marketing.yourdomain.com signed with d=yourdomain.com passes authentication.
• Strict alignment (adkim=s) requires an exact match between the From header domain and the signing domain. The same subdomain message will fail DMARC under strict mode unless signed specifically by d=marketing.yourdomain.com.

For multi-vendor SaaS stacks, AutoSPF recommends maintaining relaxed alignment for both DKIM and SPF. Relaxed mode provides the operational flexibility needed when routing transactional messages and bulk marketing blasts through distinct external cloud platforms.

Append the new include statements without breaking DNS

Once DKIM is configured, you must authorize the sending servers to pass SPF checks. An SPF record is published as a single TXT string at the apex of your domain or at a specific sending subdomain.

Adding new email tools requires modifying the existing string cleanly. For a detailed breakdown of syntax rules, review The DNS and SPF configuration guide for HubSpot and Salesforce integrations.

Handling multiple SPF entries

The most destructive error an IT administrator can make during SaaS onboarding is creating a second SPF TXT record.

RFC 7208 permits exactly one SPF record per hostname. If a domain zone contains multiple TXT records starting with v=spf1, receiving MTAs will not merge them. They throw an automatic PermError, reject SPF validation across all records, and subject all outbound traffic to potential delivery failure.

; INVALID: Never publish two SPF records on one domain
yourdomain.com. IN TXT "v=spf1 include:_spf.google.com ~all"
yourdomain.com. IN TXT "v=spf1 include:123456.spf03.hubspotemail.net ~all"

; VALID: Merge all includes into a single record
yourdomain.com. IN TXT "v=spf1 include:_spf.google.com include:123456.spf03.hubspotemail.net ~all"

To integrate HubSpot correctly, insert their unique include mechanism directly before your closing policy flag (such as ~all or -all), separated by a single space. If you need step-by-step guidance on remediating merged records, see Why HubSpot and Salesforce integrations break your SPF record (and how to fix it).

Why hardcoding IPs fails

When teams discover they have exceeded the 10-lookup limit, some attempt a manual workaround: resolving the vendor's include statement into IP blocks and hardcoding those addresses into their record using ip4 mechanisms.

; DANGEROUS WORKAROUND: Hardcoding third-party ranges
v=spf1 ip4:54.174.52.0/24 ip4:158.247.16.0/20 ~all

This workaround is fundamentally flawed. Cloud software providers regularly acquire new IP ranges, decommission older subnets, and shift customer routing across server pools without warning. The moment HubSpot or Salesforce routes a batch of emails through a newly assigned subnet not listed in your static record, your messages will fail SPF validation.

Hardcoding IP addresses creates brittle infrastructure that requires constant monitoring. Automated SPF flattening platforms replace this manual burden by dynamically resolving vendor includes every 15 minutes, updating your authorized IP lists automatically while presenting a single managed entry to the public DNS. Learn more about maintaining clean records in Common SPF Record Problems And How You Can Fix Them Today.

Publish DMARC in monitoring mode

Domain-based Message Authentication, Reporting, and Conformance (DMARC) ties SPF and DKIM together. It tells receiving mailbox providers how to handle messages that fail authentication checks, while providing a reporting channel back to the domain owner.

Publishing DMARC is not optional. Major email providers reject unauthenticated bulk senders outright. However, setting an aggressive policy right away is an operational hazard.

The monitoring policy

When deploying HubSpot or Salesforce, publish your DMARC record in monitoring mode (p=none). This instructs receiving MTAs to deliver all messages normally, regardless of authentication outcomes, while collecting forensic and aggregate telemetry.

A baseline pre-flight DMARC record looks like this:

Host: _dmarc.yourdomain.com
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; aspf=r; adkim=r;

This configuration achieves three objectives:

• It satisfies provider requirements for bulk senders without risking rejected messages during the rollout.
• The rua= tag directs daily aggregate XML reports to your monitoring mailbox, giving you total visibility into which servers send mail on your behalf.
• The relaxed alignment flags (aspf=r; adkim=r) grant enough leeway for cloud marketing platforms to validate against root domain policies.

Leaving a domain unmonitored invites spoofing and leaves you blind to authentication drops. Adding an initial p=none record provides the visibility required to diagnose errors before changing your policy to p=quarantine or p=reject.

The pre-flight verification workflow

Never send a marketing blast or live campaign without verifying your DNS architecture using synthetic test sends and command-line diagnostics. Run through this pre-flight matrix before authorizing sending permissions in HubSpot or Salesforce.

Step-by-step diagnostic verification

1. Query your public SPF record using terminal commands:

   dig TXT yourdomain.com +short
   

   Confirm that only one record beginning with v=spf1 returns. Count every include, a, and mx mechanism recursively down the tree. If the total number of DNS lookups reaches 10 or more, stop immediately.

2. Query both DKIM CNAME selectors:

   dig CNAME hs1-123456._domainkey.yourdomain.com +short
   

   Verify that the record resolves to the vendor's target hostname. If the terminal returns an empty response, verify your registrar settings to confirm the domain suffix was not duplicated.

3. Confirm DMARC record syntax:

   dig TXT _dmarc.yourdomain.com +short
   

   Confirm that the p= tag is set to none during the initial launch phase, and check that the rua= reporting address is formatted correctly.

4. Send a test message from HubSpot and Salesforce to an external test inbox. Open the raw email headers and inspect the Authentication-Results block. You must see spf=pass, dkim=pass, and dmarc=pass before enabling production email workflows.

Authentication-Results: mx.google.com;
       dkim=pass header.i=@yourdomain.com header.s=hs1-123456 header.b=...;
       spf=pass (google.com: domain of 123456@hubspotemail.net designates 158.247.16.10 as permitted sender) smtp.mailfrom=123456@hubspotemail.net;
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=yourdomain.com

Large organizations operating multi-domain environments frequently manage dozens of marketing platforms alongside enterprise business systems. Our team supports hundreds of organizations through dedicated enterprise email authentication management, preventing syntax errors and resolving lookup limits across complex infrastructure.

Before pushing your next marketing campaign live, verify your current SPF lookup count. If adding HubSpot or Salesforce pushes your domain over the 10-lookup limit, implement automated SPF flattening before modifying your DNS zone. Learn more at AutoSPF's website to keep your email authentication reliable, compliant, and always functional.