In an SPF record, include: does not copy another record into yours. It tells a receiving mail system to evaluate another domain’s SPF policy as part of checking whether a sender is authorized. It is the normal way a business lets an email provider, marketing platform, or CRM send mail using its domain—but it also creates DNS lookup costs and should be used deliberately.
What an include does
A record such as v=spf1 include:_spf.google.com ~all asks the receiver to evaluate Google’s published SPF policy. If the sender matches that included policy, the include mechanism can pass. The provider controls the included record, which is why the exact value should come from its current documentation rather than an old blog example.
Why providers use includes
Email providers operate many sending IPs that can change over time. An include lets the provider update its own SPF policy without requiring every customer to edit their DNS record. Your domain references the provider’s maintained authorization list, while your record remains short and focused on the services you have actually approved.
Combine providers in one record
A business can use a mailbox provider, CRM, marketing platform, and transactional service. Their approved includes belong in one SPF record, not separate SPF records. A conceptual pattern is v=spf1 include:provider-one.example include:provider-two.example ~all. The example domains are not live configuration values; use the entries supplied by each service.
Keep the final all mechanism
The end of an SPF record usually contains ~all or -all, which states how unauthorised senders should be treated. Do not place a new include after the all mechanism, because evaluation stops there. Preserve the intended ending when adding a provider and avoid changing enforcement solely to solve an unrelated delivery problem.
Understand lookup cost
Each include can trigger DNS lookups, and included records can reference further records. SPF allows a maximum of ten DNS-based lookups during evaluation. A record may look short while still exceeding the limit because of the provider chains behind it. See the SPF lookup-limit guide before adding another service.
Check the complete sender inventory
Before editing SPF, list every system that sends using your domain: employee mailboxes, CRM, newsletters, billing, support, website forms, and agencies. An include should correspond to a real approved sender. Keep the provider, account owner, purpose, and test date in a simple inventory so an old authorization can be removed safely after a service is retired.
Test with a fresh message
After a DNS change, wait for the public value to be visible, then send a new message from the platform you added. Inspect headers for spf=pass. Test existing streams too, because replacing an old record can silently remove authorization for another sender. Use the SPF check guide and SPF record examples for the wider process.
SPF includes are not enough alone
Enable DKIM for each provider that supports it and use DMARC to evaluate aligned identity. SPF can fail through forwarding, and an SPF pass may not align with the visible From domain. Read SPF versus DKIM versus DMARC before treating an include as the whole security setup.
Run Beacon’s free domain check to review the public SPF, DKIM, and DMARC records before or after adding an include.
Document every include with its owner and purpose.