Before You Start
- Access to your domain registrar or DNS hosting provider
- A list of all services that send email on behalf of your domain
- Basic understanding of DNS record types (TXT, MX)
Inventory all authorized email senders
Before writing a single line of DNS, you need to know every server and service that legitimately sends email using your domain. Start with your primary mail provider such as Microsoft 365 or Google Workspace. Then check for transactional email services like SendGrid, Mailgun, or Amazon SES. Do not forget marketing platforms such as Mailchimp or HubSpot, CRM systems that send on your behalf, helpdesk tools, and any on-premise mail servers. Interview department heads to uncover shadow IT email services. Document each sender with its IP address or include mechanism so nothing is missed when you build the record.
Construct your SPF record syntax
An SPF record is a DNS TXT record that starts with v=spf1 followed by mechanisms that define authorized senders. Use the include mechanism for cloud services, for example include:_spf.google.com for Google Workspace or include:spf.protection.outlook.com for Microsoft 365. Use ip4 and ip6 mechanisms for specific server addresses. Keep the record under ten DNS lookups total, as exceeding this limit causes a permanent error and SPF will fail. End the record with -all for a hard fail, ~all for a soft fail, or ?all for neutral. For initial deployment, start with ~all and move to -all once you have confirmed all senders are listed.
Publish the SPF record in DNS
Log in to your DNS hosting provider or domain registrar. Navigate to the DNS management section for your domain. Create a new TXT record with the host field set to @ or your bare domain name. Paste your SPF string into the value field. Set the TTL to 3600 seconds or one hour initially so changes propagate quickly during testing. Make sure you have only one SPF record for the domain because multiple SPF records cause authentication failures. If an existing SPF record is present, merge the mechanisms into a single record rather than creating a second one. Save the record and wait for DNS propagation.
Validate the SPF record
After publishing, verify the record is correct and reachable. Use a command-line tool like dig or nslookup to query your domain for TXT records and confirm the SPF entry appears. Then use an online SPF validator such as MXToolbox or dmarcian to check for syntax errors, duplicate records, and lookup count. The validator will flag common issues like exceeding the ten-lookup limit, using deprecated ptr mechanisms, or having multiple SPF records. Fix any errors before proceeding. Send a test email from each authorized service and check the email headers for spf=pass in the Authentication-Results header.
Flatten the record if you exceed the lookup limit
Each include, a, mx, and redirect mechanism triggers a DNS lookup, and SPF allows a maximum of ten. If your record exceeds this limit, you need to flatten it by replacing include mechanisms with the actual IP addresses they resolve to. Tools like SPF Flattener or autospf can automate this process. Be aware that flattened records must be updated whenever a provider changes their IP ranges, so set a calendar reminder to review monthly or use a dynamic flattening service. An alternative approach is to delegate a subdomain for specific services and create separate SPF records for each subdomain, keeping each under the limit.
Monitor SPF results with DMARC reports
Once SPF is live, set up a DMARC record in monitor mode with p=none and a rua reporting address. DMARC aggregate reports will show you which senders are passing and failing SPF checks. Review these reports weekly for the first month to catch any legitimate senders you missed. Look for spf=fail entries from IP addresses you do not recognize and investigate whether they are legitimate services or spoofing attempts. Use a DMARC report analyzer tool to parse the XML reports into readable dashboards. This monitoring phase is critical before tightening your SPF policy to hard fail.
Common Mistakes to Avoid
Creating multiple SPF records for the same domain instead of merging them into one
Exceeding the ten DNS lookup limit, which causes SPF to return a permanent error
Forgetting to include third-party services like CRM or helpdesk tools that send email on your behalf
Starting with -all (hard fail) before confirming all legitimate senders are listed
Get your Cyber Defense Score™ in 60 seconds.
100 tools. No installation. No credit card.
Get My Cyber Defense Score™ →