SPF (Sender Policy Framework) records use qualifiers to specify how receiving mail servers should handle emails that don't match the defined policies. The two most important qualifiers are:
v=spf1 a mx ~all # Soft fail (non-matching emails still accepted but marked)
v=spf1 a mx -all # Hard fail (non-matching emails rejected)
~all (SoftFail) indicates that hosts not listed in the SPF record may still send mail, but such messages should be treated with suspicion. Receiving servers may accept the message but mark it as potential spam.
-all (Fail) is a definitive statement that only the specified hosts are authorized to send mail. Any other source should be rejected outright.
For a domain using Google Workspace with additional mail servers:
# Strict policy example
v=spf1 include:_spf.google.com ip4:192.0.2.0/24 -all
# Lenient policy example (during migration)
v=spf1 include:_spf.google.com ip4:192.0.2.0/24 ~all
Use -all when:
- You're certain about all legitimate mail sources
- You want maximum protection against spoofing
- Your email infrastructure is stable
Use ~all when:
- You're testing or migrating SPF records
- You might have unknown legitimate senders
- You want to monitor non-compliant messages first
For most production environments, we recommend:
# Recommended production SPF record
v=spf1 include:spf.protection.outlook.com include:_spf.salesforce.com ip4:203.0.113.5 -all
During testing phase:
# Testing SPF record
v=spf1 include:spf.protection.outlook.com include:_spf.salesforce.com ip4:203.0.113.5 ~all
1. Using both qualifiers in the same record (invalid syntax)
2. Having more than one SPF record per domain
3. Exceeding the 10 DNS lookup limit
4. Forgetting to update SPF when adding new services
Always test your SPF records using tools like:
nslookup -type=txt yourdomain.com
dig txt yourdomain.com
SPF (Sender Policy Framework) records use qualifiers to define how receiving mail servers should handle emails from unauthorized sources. The two most debated modifiers are:
v=spf1 a mx ~all # Soft fail (accept but mark suspicious) v=spf1 a mx -all # Hard fail (reject unauthorized emails)
The tilde (~) and dash (-) prefixes create fundamentally different handling scenarios:
| Modifier | RFC Name | Server Action | Typical Use Case |
|---|---|---|---|
| ~all | SoftFail | Accept but mark as suspicious | Transition periods, testing |
| -all | Fail | Reject the message | Production environments |
For a domain example.com with Google Workspace:
# Transitional/testing configuration: "v=spf1 include:_spf.google.com ~all" # Production configuration: "v=spf1 include:_spf.google.com -all"
- Always test with
~allbefore switching to-all - Monitor email headers using tools like MXToolbox
- Combine SPF with DKIM and DMARC for comprehensive protection
- Keep the SPF record under 10 DNS lookups to avoid processing limits
When debugging SPF failures, check:
- DNS propagation status
- Correct modifier syntax (no spaces between modifier and mechanism)
- Mail server IP changes not reflected in SPF
- Third-party services not included in the record