How to Add an SPF Record for Business Email

If your business sends email from Google Workspace, Microsoft 365, HubSpot, Mailchimp, a CRM, or an outbound platform, your domain needs an SPF record. SPF is one of the DNS controls mailbox providers use to decide whether an email claiming to come from your domain is legitimate. Set it up incorrectly and real emails may land in spam. Skip it entirely and attackers can impersonate your domain more easily. The good news: adding an SPF record is usually straightforward once you know every system that sends mail on your behalf.

SPF stands for Sender Policy Framework. It is a TXT record in your domain’s DNS settings that lists the mail servers and platforms authorized to send email using your domain. When Gmail, Outlook, or another receiving server gets a message from your company, it can check that record and compare the sending server against your approved list.

Think of SPF as a guest list for your domain’s sending infrastructure. If Google Workspace is on the list, Google can send mail as yourdomain.com. If your outbound platform is on the list, its sending servers can send as yourdomain.com. If an unknown server tries to send as yourdomain.com, SPF gives the receiving mailbox a reason to distrust it.

SPF does not encrypt email, prevent every phishing attack, or guarantee inbox placement. It is one part of email authentication alongside DKIM and DMARC. But it is foundational. Without it, you are asking inbox providers to trust messages from a domain that has not clearly identified its approved senders.

Email delivery is a revenue operations issue, not merely a DNS task. Sales follow-ups, product notifications, invoices, nurture sequences, recruiting messages, customer support, and founder outreach all depend on recipients receiving your email. A poorly configured sender domain can quietly reduce response rates before your team sees the problem in a dashboard.

SPF also helps protect brand trust. If someone sends a fake invoice, payment request, or executive impersonation email from a domain that resembles yours, customers may not distinguish the fraudulent message from a real one. Proper authentication makes impersonation harder and gives mailbox providers clearer evidence when a message is not authorized.

For marketing leaders, the operational issue is usually fragmentation. One team uses Microsoft 365, another sends campaigns through HubSpot, sales has an outbound tool, finance uses an invoicing platform, and support sends transactional updates through a separate provider. SPF is where all of those tools must be reconciled into one accurate authorization policy.

Do not begin by copying the first SPF example you find online. First, make an inventory of every platform that sends email using your domain or a subdomain. The list should include employee inboxes, marketing automation, CRM workflows, outbound platforms, help desk tools, ecommerce systems, form tools, billing software, and transactional email services.

Ask a practical question for each platform: does it send with an address ending in your primary domain, such as hello@yourdomain.com, or does it send from a dedicated subdomain, such as updates@news.yourdomain.com? The answer determines where the SPF authorization belongs. A platform using its own sending domain does not need to appear in your SPF record.

Build a simple working sheet with four columns: tool name, sending address or domain, vendor SPF include value, and owner. The owner column matters more than it sounds. Six months from now, someone may add a new automation or cancel an old vendor. Without a record of who owns the sender, your DNS configuration becomes guesswork.

Common senders businesses forget

The obvious providers are Google Workspace and Microsoft 365. The less obvious ones are often responsible for authentication failures. Examples include applicant tracking systems, appointment reminders, customer review platforms, website form notifications, project management tools, accounting software, ecommerce order updates, and embedded chat tools.

Outbound deserves special attention. If sales is sending cold email through dedicated infrastructure, do not casually add every vendor to the corporate domain’s SPF record. Many teams protect their primary domain by sending outreach from purpose-built secondary domains. That approach can limit risk, but it still requires proper SPF, DKIM, and DMARC alignment on each domain used.

Also separate “sending through a platform” from “using a platform’s reply-to address.” A tool may display a reply-to address at your company while messages actually originate from the vendor’s authenticated domain. Check the vendor documentation and inspect a delivered email’s headers if the setup is unclear.

Before publishing anything, inspect your existing DNS records. Search for TXT records on the root domain that begin with v=spf1. You may find one existing SPF record, which is normal. You may find none, which means you need to create one. You should not find multiple SPF records for the same domain.

Multiple SPF records are a common mistake. SPF permits one policy record per domain. If you publish two separate records because two vendors gave you two separate instructions, receiving servers can return a permanent SPF error. The fix is not to delete authorization blindly; it is to combine the approved mechanisms into one record.

You can view DNS records in your registrar, DNS host, or infrastructure provider. That might be Cloudflare, GoDaddy, Namecheap, Squarespace, AWS Route 53, or another platform. If your domain and website are managed in different places, make changes where the authoritative DNS nameservers are hosted, not necessarily where you bought the domain.

An SPF record is published as a TXT record. It starts with the version identifier v=spf1, followed by mechanisms that authorize senders, and ends with a policy qualifier. A basic Google Workspace example looks like this: v=spf1 include:_spf.google.com ~all.

The include mechanism tells receiving servers to consult another domain’s published SPF policy. This is how most SaaS vendors provide authorization instructions. Microsoft 365, HubSpot, Mailchimp, and other providers each publish their own include value or recommended syntax. Use the documentation for your exact plan and sending configuration rather than assuming one vendor’s pattern applies to another.

The ending matters. A soft fail, written as ~all, says servers not listed are probably unauthorized. A hard fail, written as -all, says servers not listed are unauthorized. Neither setting should be chosen in isolation: your decision should follow a complete sender inventory, active DKIM setup, and a sensible DMARC policy.

SPF mechanisms you will see most often

include: authorizes a vendor’s SPF policy. ip4: authorizes a specific IPv4 address, and ip6: does the same for IPv6. a and mx can authorize servers associated with the domain’s A record or mail exchange records, though they are not always the cleanest choice for modern SaaS-based setups.

A combined record might look like this: v=spf1 include:_spf.google.com include:servers.mcsv.net ~all. This is only an illustrative pattern. The actual values depend on your providers, and a vendor may change its recommended configuration. Copying an old forum answer into DNS can create a delivery problem that takes weeks to diagnose.

SPF evaluation has a limit of 10 DNS lookups. Each include can trigger lookups, and nested vendor records can consume more than you expect. If you operate a large stack, monitor this limit. Exceeding it can cause SPF permerrors, which means your record exists but cannot be evaluated reliably.

Once you have the sender inventory and know whether an SPF record already exists, log in to the DNS provider for your domain. Open the DNS zone, locate TXT records, and search for a record beginning with v=spf1. Do not confuse SPF with a DKIM selector record or a DMARC record, which uses the hostname _dmarc.

If no SPF record exists, create a new TXT record at the root host. Depending on your DNS provider, the host field may be shown as @, left blank, or populated with your domain name. Paste the complete record into the value field. For example, if Google Workspace is your only authorized sender, use the current Google-recommended value from its documentation.

If an SPF record already exists, edit that single record and append the new provider’s approved mechanism before the final ~all or -all. Keep one version tag at the start and one all mechanism at the end. Save the changes, then allow DNS propagation time. Many updates appear quickly, but cached DNS responses can make changes seem inconsistent for several hours.

If your company only uses Google Workspace for employee email, the SPF configuration is usually simple. Google publishes the required include value, and your record authorizes its mail servers. The important operational step is confirming that no other tool is sending as your root domain before you use a restrictive ending.

Microsoft 365 environments follow the same logic but use Microsoft’s published SPF include value. If your business uses both Microsoft 365 and a marketing platform, you combine the authorized mechanisms into one record. Do not publish one Microsoft TXT record and one marketing-platform TXT record at the root domain.

Marketing automation and CRM tools vary. Some send through their own shared or dedicated infrastructure; others ask you to authenticate a dedicated sending subdomain. A subdomain approach can keep marketing activity separate from employee email. For example, your team may use yourdomain.com for people-to-people mail and mail.yourdomain.com for campaign delivery. That separation can make governance and troubleshooting cleaner.

SPF checks the envelope sender, also called the return-path or MAIL FROM domain. The visible From address that a recipient sees may be different. That gap is why DKIM and DMARC are essential. DKIM adds a cryptographic signature to messages, while DMARC tells receiving providers how to evaluate alignment between SPF, DKIM, and the visible From domain.

For most businesses, the practical sequence is clear: inventory senders, publish accurate SPF, enable DKIM for every material sending platform, then publish a DMARC record in monitoring mode. Review the reports, find legitimate senders that are not aligned, and tighten the policy only when the evidence supports it.

Reputation still matters. A technically valid SPF record will not rescue an outbound program with poor targeting, weak list quality, high complaint rates, or sudden high-volume sending. Authentication proves identity; it does not make unwanted email welcome. Delivery improves when technical controls and sending behavior agree.

Email authentication should have an owner and a change process. Marketing may own campaign platforms, sales may own outbound, IT may control DNS, and finance may add a billing tool without informing either group. The result is often an untracked sender that fails authentication or causes a legitimate record to be overwritten.

A useful operating rhythm is to review authorized senders quarterly and during every major vendor change. Remove tools that no longer send mail, confirm DKIM keys remain active, inspect DMARC reports, and check whether a vendor has changed its documentation. Treat DNS changes as production changes: document them, verify them, and make sure someone can roll them back.

This is also where a senior operator model can be more useful than disconnected specialists. Anton Chisliuk · AI Marketing Ops connects growth systems across SEO, CRM, outbound, automation, and measurement rather than treating each channel as a separate project. In one B2B SaaS engagement, Cleverence grew from 0 to 80K organic visits per month and 0 to 2K inbound leads per month; the underlying lesson is that growth channels need dependable operational foundations, including the systems that carry customer communication. Learn more about the operator-led marketing ops model.

Do not stop at “the DNS record saved.” Use an SPF lookup tool to confirm that the published record is visible and syntactically valid. Check for duplicate records, invalid mechanisms, excessive DNS lookups, and unexpected redirects. If you made the change recently, test more than once because DNS caching can delay what different resolvers see.

Then send a real test email from each important platform to a Gmail or Outlook inbox. Open the message details or headers and look for authentication results. You want to see SPF pass, DKIM pass where configured, and DMARC pass once your alignment is correct. Test employee email, automated marketing email, and transactional messages separately.

If SPF fails, inspect the return-path domain and sending IP in the message headers. The problem may be that the platform is sending from a different domain than expected, that the vendor include is missing, or that the sender is not actually using your custom domain. Avoid changing several variables at once. Make one documented correction, wait for DNS to propagate, and retest.

The biggest mistake is creating multiple root-domain SPF records. It often happens when vendors provide one-line instructions without asking whether a record already exists. The correct approach is to merge authorized mechanisms into a single policy and keep the final all statement only once.

The second mistake is authorizing every tool “just in case.” An SPF record should be a controlled list, not a graveyard of vendors your business tried three years ago. Old authorizations expand the set of infrastructure that can claim to send for your domain. Remove obsolete entries after confirming the platform is no longer active.

The third mistake is moving immediately to -all without a full inventory and DMARC visibility. A hard fail may be appropriate once your setup is mature, but it can disrupt legitimate mail if a forgotten system is still sending. Start from evidence, not from a desire to make the record look strict.

A single-domain company using one inbox provider can normally handle SPF internally in under an hour. The task becomes more involved when you have multiple domains, a new CRM, outbound infrastructure, transactional email, a website migration, or a history of deliverability issues. At that point, the challenge is not typing a TXT record; it is controlling a connected system.

Bring in IT when DNS access, security policy, identity management, or network infrastructure is involved. Bring in RevOps or marketing operations when the question is which platforms are active, who owns each sender, how CRM workflows route messages, and whether data is being captured correctly after a recipient clicks or replies.

If you are rebuilding the wider revenue stack, email authentication is one item in a larger implementation checklist. A properly configured CRM, documented lifecycle stages, reliable automations, and clean sending domains prevent small technical gaps from becoming pipeline leaks. Teams that need that connection can review a CRM implementation approach built around operational ownership rather than software setup alone.

Confirm the exact domain you are editing and identify the authoritative DNS provider. List every service that sends using that domain or a relevant subdomain. Check for an existing SPF TXT record before adding anything. These steps prevent the two most frequent issues: editing the wrong DNS zone and creating duplicate SPF records.

For each authorized sender, get the current SPF guidance from the provider’s official documentation. Combine the mechanisms into one record, place the policy qualifier at the end, and review the total DNS lookup count. If a service has moved to a dedicated sending subdomain, make sure you are editing that subdomain’s DNS policy rather than the root domain by accident.

After publishing, run a lookup, send real-world test messages, and record the final configuration in your internal documentation. Assign an owner for future updates. This small discipline saves time when a new campaign tool is introduced or a deliverability problem appears during an important launch.

Adding an SPF record is a small DNS change with outsized operational consequences. It tells mailbox providers which systems can speak for your domain, reduces avoidable authentication failures, and supports a more trustworthy email program. The hard part is not the syntax. It is knowing every system that sends on your behalf and keeping that list current.

Do not rush to add every vendor, and do not publish a second SPF record because a tool gave you a new line of text. Audit the senders, use one valid policy, test the result, and pair SPF with DKIM and DMARC. That process protects both day-to-day communication and the pipeline work attached to it.

If email authentication is only one symptom of a scattered CRM, outbound, automation, or measurement setup, start with a Growth Audit to identify the operational gaps before they affect the next campaign.

Article by Anton Chisliuk, founder of Anton Chisliuk · AI Marketing Ops.

- Can I have more than one SPF record for my domain?

No. You should publish only one SPF TXT record for a domain. If multiple providers need authorization, combine their mechanisms into one record before the final ~all or -all policy.

- How long does an SPF record take to work?

Many DNS changes appear within minutes, but propagation and resolver caching can take several hours. Test from more than one lookup service and send actual messages after publishing.

- Should I use ~all or -all in my SPF record?

Use the policy that matches your confidence in the sender inventory. Many teams begin with ~all while validating their email ecosystem. Consider -all only after confirming authorized senders, DKIM configuration, and DMARC alignment.

- Does SPF stop phishing emails?

SPF helps mailbox providers identify unauthorized sending servers, but it does not stop every phishing attack. Attackers can use lookalike domains or other methods. DKIM, DMARC, monitoring, and user awareness complete the protection model.

- Do HubSpot, Mailchimp, and Google Workspace all need to be in SPF?

Only if each platform sends email using your domain or relevant subdomain. Review each vendor’s sending configuration and official authentication instructions. If a provider sends exclusively from its own domain, it may not need to be included in your domain’s SPF policy.

- What happens if I exceed the SPF DNS lookup limit?

SPF evaluation can fail with a permanent error when it requires more than 10 DNS lookups. Reduce unnecessary includes, remove inactive vendors, use vendor-supported alternatives where available, and validate the revised record with an SPF checker.