How to Set Up an SPF TXT Record for BROSH Email
Authorize BROSH to send email for your domain without losing your existing mail setup. Follow the DNS steps below, preserve your current SPF policy, and test before your next customer follow-up.
Updated October 15, 2026
Quick answer: edit your existing SPF TXT record and add include:_spf.brosh.io before its final all term. Keep the current ending. Create a record only if none exists.
Find your DNS host and existing SPF record
Your DNS host is the provider running your domain’s authoritative nameservers. It may differ from the company where you bought the domain. For example, a domain registered at GoDaddy may use Cloudflare DNS.
Open that provider’s DNS records and find the TXT value beginning v=spf1 at the sending domain. Copy it before editing. Keep other TXT records, such as verification records, intact.
Publish one SPF record per hostname. A separate sending subdomain needs its own policy; do not assume it inherits the root domain’s SPF.
SPF TXT values: with and without the optional Google example
These examples retain the a mx mechanisms in the BROSH setup supplied for this guide. Select the ending appropriate to your existing policy; do not publish both alternatives.
| Situation | Single TXT value |
|---|---|
| BROSH plus Google Workspace; existing neutral policy | |
| BROSH plus Google Workspace; existing softfail policy | |
| Without Google; existing neutral policy | |
| Without Google; existing softfail policy | |
Google is optional. Include include:_spf.google.com only when Google Workspace sends mail for your domain. Receiving mail from Gmail customers is not a reason to add it. Google’s SPF setup guide explains its sending configuration.
If you use another mail service, retain that service’s authorized mechanisms. These sample values are not replacements for an existing record containing other legitimate senders. Enter v=spf1 exactly, with no comma after SPF and no quotation marks unless your provider requires them.
SPF settings for Microsoft 365 / Outlook
If your custom domain sends through Microsoft 365 / Exchange Online, include include:spf.protection.outlook.com. Using the Outlook app with another email provider does not, by itself, require this include.
At your authoritative DNS host, edit the existing SPF TXT record. Keep Microsoft’s include and add include:_spf.brosh.io before the final all term. Preserve every other legitimate sender and the existing ending.
| Existing policy ending | Microsoft 365 + BROSH example |
|---|---|
| Keep an existing -all | |
| Keep an existing ~all | |
| Keep an existing ?all | |
Microsoft’s standard Microsoft 365-only example ends in -all. Do not weaken that ending when adding BROSH. These examples omit a mx; retain those mechanisms if your existing setup needs them. Add Google’s include only if Google also sends for the domain.
Save one SPF record, then test both Microsoft 365 and BROSH messages. Personal @outlook.com mailboxes use Microsoft-managed DNS. Sovereign-cloud or gateway configurations may need different entries; follow your tenant’s setup guidance and Microsoft’s official SPF instructions.
What each part of the record does
| Part | Meaning | What to check |
|---|---|---|
v=spf1 | Identifies the policy as SPF version 1. | Use once, at the beginning. |
a | Authorizes sending IPs matching the domain’s A or AAAA records. | Include only if those hosts are intended to send email. |
mx | Authorizes sending IPs of hosts listed in the domain’s MX records. | Inbound mail hosts are not always outbound senders. |
include:_spf.google.com | Checks the Google SPF policy for an authorized sender. | Optional; only for domains sending through Google Workspace. |
include:_spf.brosh.io | Checks the BROSH SPF policy for an authorized sender. | Add once, before the final all mechanism. |
~all or ?all | Sets the result when earlier mechanisms do not match. | Preserve your existing ending during this addition. |
The a and mx terms authorize hosts; they are not mandatory boilerplate for every domain. Keep this guide’s examples only where those permissions fit your setup. If your existing policy omits them, adding BROSH does not require adding them.
What is the difference between ~all and ?all?
| Ending | SPF result for an unmatched sender | Practical interpretation |
|---|---|---|
~all | Softfail | The domain considers the sender probably unauthorized. A receiver may treat this as a negative signal; it is not an automatic instruction to reject or send to spam. |
?all | Neutral | The domain makes no assertion about authorization for that sender. Neutral is not SPF pass and does not authorize every sender. |
-all | Fail | The domain explicitly identifies unmatched senders as unauthorized. Receiver handling depends on its policies. |
Keep the ending as it is if one already exists. If your record ends in ?all, keep ?all. If it ends in ~all, keep ~all. Preserve an existing -all as well. Adding BROSH is separate from changing your enforcement policy.
If no SPF record exists, have your mail administrator confirm all senders and choose the policy. A new ~all policy can support a staged rollout; ?all offers weaker assertions. Review strictness separately after testing.
See RFC 7208: SPF results and receiver handling and NCSC guidance on building and testing an SPF policy. Neither softfail nor neutral counts as SPF pass for DMARC.
Add BROSH without replacing your other senders
For an existing Google-only record, insert the BROSH include before ~all. Preserve the rest of the value:
Before: v=spf1 include:_spf.google.com ~all
After: v=spf1 include:_spf.google.com include:_spf.brosh.io ~allUse the same approach for an existing ?all or -all ending. Do not add a second v=spf1, a second SPF TXT record, or an include after all.
If your policy uses redirect=, ask its administrator to merge BROSH correctly; adding an all term would override that redirect.
DNS fields to enter
| Field | Value or action |
|---|---|
| Type | TXT, not the legacy SPF record type. |
| Name / Host | Usually @ for the root domain; Wix uses a blank host instead. Use the specified subdomain label when configuring a sending subdomain. |
| Value / Content / Text | Your complete merged v=spf1 ... value as one record. |
| TTL | Keep the existing TTL when editing, or use the provider’s default/Auto for a new record. |
| Save | Reopen the saved record and check the value and hostname. |
Use the domain specified by your sending setup. SPF checks the envelope sender / Return-Path domain, which may differ from the visible From address. A correct root-domain record alone cannot fix an unrelated Return-Path configuration.
How to add or update SPF at GoDaddy
Use these steps when GoDaddy hosts your DNS. Sign in through the official GoDaddy SPF guide or open your domain’s DNS settings in your account.
| Step | Action |
|---|---|
| 1. Select the domain | Open your Domain Portfolio, choose the domain, then open DNS. |
| 2. Inspect records | Find the existing TXT record starting v=spf1. Select its edit action. Choose Add New Record only if no SPF policy exists at that hostname. |
| 3. Fill the form | For a new record choose TXT, set Name to @ for the root domain, and enter your full merged SPF value. |
| 4. Preserve the policy | Keep existing sender permissions and the final ?all, ~all, or -all. Use the current/default TTL. |
| 5. Save and check | Save, complete any account verification, and confirm that only one SPF TXT record exists for the hostname. |
GoDaddy can already have an SPF record for an email product. Do not replace it with the BROSH-only example. Add BROSH to the existing policy so the mailbox service remains authorized.
Google DNS and other popular providers: setup instructions
For every provider below, edit an existing SPF TXT record first. The “add” action applies only when the target hostname has no SPF record. Labels can change; the linked official guides provide the current provider instructions.
| DNS provider | Where to edit or add | Root hostname and value |
|---|---|---|
| Google Cloud DNS — add or update TXT records | Open Google Cloud Console → Cloud DNS → Zones. Select the authoritative public managed zone. Edit its existing TXT record set; if none exists at that name, choose Add standard and select TXT. Enter the merged SPF text, keep the current/default TTL, then save or create the record set. | For the zone apex, leave DNS name blank; @ does not create an apex record here. For a subdomain, enter its label. Preserve unrelated TXT values in the same record set and keep only one value beginning v=spf1. Keep the existing SPF ending. |
| Cloudflare — manage DNS records | Select the domain → DNS → Records. Edit the SPF TXT row, or choose Add record → TXT. Save. | Name: @. Content: complete merged SPF value. TTL: current or Auto. TXT records do not use the web proxy toggle. |
| Namecheap — TXT/SPF setup | Choose Domain List → Manage → Advanced DNS. Edit the TXT row under Host Records or use Add New Record → TXT Record. Save changes. | Host: @. Value: merged SPF string. Applies to BasicDNS, PremiumDNS or FreeDNS; hosting DNS may require cPanel instead. |
| Squarespace — add TXT records | Open the domains dashboard, select the domain → DNS → DNS Settings → Custom Records. Edit the policy or select Add record → TXT. Save. | Name: @. Text: merged SPF string. Complete account reauthentication if prompted. |
| Wix — add or update SPF | Open Domains → Domain Actions → Manage DNS Records. Edit the SPF TXT row or choose + Add Record in TXT. Save. | Host Name: leave blank for the root domain. Value: merged SPF string. Do not enter @ in Wix’s root Host Name field. |
Former Google Domains customers: Google Domains registrations moved to Squarespace. Follow the Squarespace instructions above if it hosts your DNS, or use your current authoritative DNS host. See the official Google Domains migration guide.
Google Public DNS (8.8.8.8) is a resolver: you cannot publish your domain’s TXT records there. Google Workspace is an email service; its optional SPF include does not mean Google hosts your DNS.
Buying a domain from one of these companies does not necessarily mean it hosts your DNS. If the domain uses external nameservers, make the change at that DNS host.
Verify DNS and send a test message
After saving, look up the sending domain’s public TXT records and confirm that the merged SPF value appears once. Cached answers can remain until their TTL expires; some providers advise allowing up to 48 hours.
Send a test from BROSH to a mailbox you control and inspect its full headers. Check Authentication-Results for spf=pass and confirm the tested smtp.mailfrom domain. Also test your regular mailbox service.
Before resuming customer follow-up, assign one owner to record the DNS change, test results, and any bounces. SPF is one part of email deliverability.
Troubleshooting before your next campaign
| Problem | Likely cause | Next step |
|---|---|---|
| More than one v=spf1 TXT record | Separate SPF policies were added for different tools. | Combine authorized senders into one valid policy at that hostname; retain unrelated TXT records. |
| BROSH test is not passing | Wrong hostname, an omitted include, cached DNS, or a different Return-Path. | Compare the saved policy with the actual envelope sender and test headers. |
| SPF permerror | Syntax problem, duplicate policies, or excessive DNS-dependent terms. | Validate the full policy, including nested includes. SPF limits DNS-lookup-causing terms to 10 during evaluation. |
| Regular mailbox stops passing | An existing mail service was replaced by a BROSH-only example. | Restore the missing authorized sender from your saved original and retest both routes. |
| SPF passes but mail reaches spam | Authentication alone does not determine inbox placement. | Check DKIM, DMARC alignment, recipient consent, reputation, complaints and message quality. |
Google’s SPF troubleshooting guide covers the lookup limit and header checks. Count nested lookups as well as the mechanisms visible in your top-level record; ten includes is not a safe universal rule.
Once authentication is verified, connect campaign ownership and follow-up to your CRM marketing automation workflow. Monitor authentication failures and bounces after each sender configuration change.
Questions and Answers
Do I need Google in my BROSH SPF record?
Only if Google Workspace sends email for your domain. The Google include is an optional example. Keep the entries for the services you actually use.
Should I change ?all to ~all when adding BROSH?
Keep the existing ending for this change. Add the BROSH include before it. Review a policy change separately with your mail administrator after checking every authorized sender.
Can I add a second SPF TXT record for BROSH?
No. Merge BROSH into the existing SPF policy at that hostname. Other TXT records used for verification or other purposes can remain.
Should I copy a mx into an existing record?
Not automatically. Those mechanisms authorize the domain’s address and mail-exchanger hosts. Add them only if those hosts should send mail; BROSH’s include can be added without changing those permissions.
Does SPF guarantee my quotes and follow-up emails reach the inbox?
No. Check DKIM, DMARC alignment, reputation and recipient consent as well. SPF pass confirms an authorized sending path for the tested envelope domain, not guaranteed inbox delivery.
Who should manage the change for a B2B team?
Assign your domain or email administrator to update DNS and test all sending services. Keep the original value, the change date and test evidence accessible to the person who owns customer communications.
A safe SPF update keeps your existing email working
Use one SPF TXT record, retain existing senders, add include:_spf.brosh.io, and preserve the current ending. Verify both BROSH and regular mailbox traffic before relying on the change for customer communications.
Technical references: RFC 7208; NCSC SPF rollout guidance; Google Workspace SPF setup. Provider instructions are linked beside each walkthrough above.
Make customer follow-up easier to manage
Bring your customer records, communication ownership and next steps together with BROSH CRM.
Talk to a CRM Expert