Domain Search
AI Domain Search
Domain Transfer
TLD List with Prices
SSL Certificates
Create a Website
Google Workspace
News
Podcast
Promos
About Us
Contact
Microsoft 365 SPF helps receiving servers recognize mail sent from your domain. Before adding a TXT record in NicNames, find the active DNS provider and any existing SPF value. This checklist shows what to compare with Microsoft's current guidance, why a second SPF record causes problems, and how to verify the public answer.
1. Confirm the sending domain and DNS provider
List every service that sends mail using your domain, including Microsoft 365, a website form, a newsletter platform or an on-premises server. SPF identifies authorized sending sources; it does not route incoming mail. If you are moving incoming mail, use our Microsoft 365 MX cutover guide separately.
In NicNames, open Domains → ClassicDNS, select the domain, and inspect Name-Servers. Continue in the NicNames DNS editor only when Free Name-Servers are active. If the domain uses Custom Name-Servers, inspect and edit the zone at the provider serving those nameservers. Changing nameservers merely to add SPF can disrupt existing website and mail records.
2. Find the existing SPF TXT record
For a domain on NicNames Free Name-Servers, open DNS Records → Manage and review the TXT records. For the root sending domain, find a TXT value beginning v=spf1. Other TXT records, including Microsoft ownership verification strings, are separate; do not remove them. Also check each subdomain that sends mail because the parent domain's SPF record does not automatically cover it.
Compare the active DNS list with a public TXT lookup for the exact sending name, such as example.com. If no SPF value appears publicly, first confirm the authoritative nameservers and the name you queried. Our DNS change troubleshooting guide explains how to distinguish the active zone from cached answers.
3. Compare the value with your real senders
Microsoft says most standard Microsoft 365 organizations need include:spf.protection.outlook.com in the SPF TXT record. Its Microsoft 365-only example is v=spf1 include:spf.protection.outlook.com -all. That is an example for a domain whose only sender is Microsoft 365, not a value to paste over a working multi-service record. GCC High, DoD and 21Vianet environments use different includes, so use Microsoft's current guidance for your organization.
There must be one SPF TXT record per domain or subdomain. If one already exists, add authorized sources to that same record through a coordinated mail-administrator change; a second v=spf1 TXT record at the same name can cause a permanent SPF error. Keep the legitimate sending services and review the SPF DNS lookup limit before saving. Do not tighten ~all to -all without confirming all real senders and reviewing authentication results.
4. Verify before and after a planned change
If your mail administrator has approved a correction and NicNames serves the zone, + Add record → TXT exposes Name, TTL and Value for a new record. For an existing SPF value, edit that record rather than creating another SPF entry at the same name. Compare the exact host and value with your mail plan before saving. Do not change the MX record as part of an SPF check.
After a planned update, query the public TXT answer at the sending name. Confirm that it contains exactly one v=spf1 record and the intended sources, allowing for the previous TTL while caches refresh. Send test mail from each authorized service and inspect the receiving message's authentication results; a public TXT answer alone does not prove every sender passes SPF. SPF is one layer: our Microsoft 365 DKIM guide and DMARC check guide cover related checks. If the active zone or record value remains unclear, contact NicNames Support with the domain and record details, without sharing passwords or private tokens.
