SPF (Sender Policy Framework) records operate at the DNS level to specify authorized mail servers for a domain. A common misconception is that parent domain SPF records automatically propagate to subdomains - this is only partially true.
By default, subdomains do not inherit the SPF policy of their parent domain. If you have:
example.com. IN TXT "v=spf1 include:_spf.google.com ~all"
This record only protects emails from @example.com addresses, not @subdomain.example.com.
For any subdomain sending email, you must create a dedicated SPF record. For example:
marketing.example.com. IN TXT "v=spf1 ip4:192.0.2.0/24 ~all"
support.example.com. IN TXT "v=spf1 include:servers.mailprovider.com ~all"
You can force inheritance by adding this to your subdomain's DNS:
subdomain.example.com. IN TXT "v=spf1 redirect=example.com"
This tells mail receivers to check example.com's SPF record for authorization.
- Multiple SPF records for the same domain (DNS only allows one)
- Exceeding the 10-lookup limit when using many 'include' mechanisms
- Forgetting to update SPF records when changing email providers
Always test your configuration using:
dig TXT example.com +short
dig TXT subdomain.example.com +short
Or use online validators like MXToolbox or Google Admin Toolbox.
When configuring email authentication, a common point of confusion arises around SPF (Sender Policy Framework) record inheritance between primary domains and their subdomains. The fundamental rule is:
; SPF records DO NOT automatically inherit from parent domains ; Each subdomain needs explicit SPF configuration if sending email
According to RFC 7208 (SPF specification), section 3.4 clearly states that subdomains must define their own SPF policies. Here's what happens in different scenarios:
; Scenario 1: No SPF for subdomain subdomain.example.com IN TXT "v=spf1 -all" ; Defaults to rejecting all mail ; Scenario 2: Explicit SPF for subdomain mail.example.com IN TXT "v=spf1 ip4:192.0.2.1 -all" ; Scenario 3: Inheriting mechanism (not recommended) example.com IN TXT "v=spf1 include:mailers.example.com ?all"
For a web application sending transactional emails from multiple subdomains:
; DNS Zone File Example @ IN TXT "v=spf1 include:_spf.google.com -all" mail IN TXT "v=spf1 ip4:203.0.113.5 -all" api IN TXT "v=spf1 include:amazonses.com -all" notifications IN TXT "v=spf1 include:spf.protection.outlook.com -all"
Many email delivery issues stem from incorrect SPF inheritance assumptions. Consider these cases:
; Problem Case: ; Parent domain has SPF but subdomain has none ; Email from support@sub.example.com fails SPF check ; Solution: sub IN TXT "v=spf1 include:example.com -all" ; OR sub IN TXT "v=spf1 redirect=example.com"
For complex email infrastructures, these patterns prove useful:
; Using redirect for centralized management marketing IN TXT "v=spf1 redirect=_spf.example.com" ; Combining multiple mechanisms support IN TXT "v=spf1 include:example.com include:zendesk.com -all" ; Temporary testing configuration staging IN TXT "v=spf1 ip4:198.51.100.0/24 ~all"
Always validate your SPF records using these CLI tools:
dig +short TXT example.com | grep "v=spf1" nslookup -type=TXT subdomain.example.com