Does Your CRM Need an SPF Record?

A sales reply and a marketing campaign can leave the same CRM through different email providers. That determines whether your existing authentication covers them or another setup is needed.

Connecting an Outlook inbox to HubSpot does not also authenticate HubSpot marketing email. The connected inbox uses the mailbox provider's sending network; marketing campaigns use HubSpot's network. HubSpot documents the distinction.

Both messages can show the same business email address. To the receiving service, however, they have come from different systems. A successful sales reply therefore tells you little about how a campaign is authenticated.

The sending service determines the setup

If the CRM sends through your existing mailbox, that mailbox provider can continue handling authentication. Connecting the CRM may require no additional SPF entry.

A separate campaign service needs authentication for its own messages. That might involve SPF, DKIM or both, depending on how the service sends and the options enabled for your account. The records supplied by that service matter more than the fact that the software is called a CRM.

HubSpot's authentication settings provide the DNS records for the account being configured. Records copied from another company's setup can be inappropriate even when both companies use HubSpot.

The visible sender address does not tell the whole story

SPF checks whether the sending server's IP address is authorised for the domain used in the message's return address. That domain can differ from the address a customer sees in the From field.

For example, a campaign showing sales@example.com might use the campaign provider's domain for SPF. Adding that provider to the SPF record for example.com would not change a check made against the provider's domain.

DKIM provides another way to authenticate the message: a digital signature tied to a domain. A campaign service may supply DNS records that let it sign messages using your business's domain. Microsoft explains these authentication methods.

Read the domains on one campaign message

In this fictional example, a campaign has these identities:

Adding an include to example.com's SPF would not change this SPF result. The email header analyser helps read these fields from a received message. Use the receiver's authentication results and the CRM's account settings together; the displayed From address alone cannot establish the required DNS change.

When another CRM sender adds to the SPF lookup count

When a service does require an include in an SPF record you control, that addition uses some of its lookup allowance. SPF permits only ten terms that trigger DNS queries during a check, including references nested inside a provider's record. One new include can therefore consume more than one of the ten. The SPF standard defines this limit.

For a crowded SPF record, automatic flattening can reduce that lookup use. It replaces supported references with IPv4 and IPv6 sending ranges and keeps those ranges updated as providers change them.

Flattening becomes relevant when the SPF record actually needs those senders and is running short of lookups. If the CRM sends through your existing mailbox, or uses its own domain for SPF, adding it to your main SPF record can create unnecessary complexity without helping its messages authenticate.