The short and simple answer is no. An SPF record on your main domain does not automatically apply to your subdomains. This is a common point of confusion, and getting it wrong can have a significant impact on your email deliverability. Each subdomain that sends email needs its own separate SPF record.
Unlike DMARC, which has mechanisms for inheritance, SPF is very specific. The check is performed against the exact domain used in the email's Return-Path (also known as the MAIL FROM or envelope sender address). So, if you send an email from “updates@news.yourdomain.com”, the receiving server will check for an SPF record on “news.yourdomain.com”, not “yourdomain.com”.
The design of SPF is intentionally explicit. It was created to authorize specific servers to send mail on behalf of a specific domain name. Since subdomains can be, and often are, used for entirely different purposes and managed by different teams or vendors, inheriting the parent domain's policy could create security holes and operational conflicts.
For example, your primary domain might send corporate emails through Google Workspace, while a subdomain like marketing.yourdomain.com sends campaigns through a third-party platform. Each requires a different SPF record authorizing different sending IPs. As spf-record.com notes, the advice is clear: “You should add an SPF record for each subdomain or hostname with an A or MX record.” This ensures that each sending source is properly authenticated without granting overly broad permissions.
Creating an SPF record for a subdomain is exactly like creating one for a root domain. You just need to add a new TXT record to your DNS settings, but instead of leaving the host/name field as "@" or blank, you specify the subdomain.
This is where things get interesting. While SPF policies are not inherited, DMARC policies on a parent domain do apply to its subdomains by default. If you have a DMARC policy of p=reject on yourdomain.com, any email sent from an unauthenticated subdomain (one without a proper SPF record) will be rejected.
This default behavior is a safety net, but it highlights the critical need to configure SPF for every single subdomain you use to send email. If you don't, your legitimate emails could be blocked. For more granular control, DMARC includes an sp (subdomain policy) tag. This allows you to set a different policy for subdomains than for the main domain, for instance, setting sp=reject while your primary domain's policy is p=quarantine.
To wrap it up, always remember that SPF does not apply to subdomains by default. It's a fundamental rule of email authentication. Every subdomain that sends email must have its own correctly configured SPF record in its DNS settings. Failing to do this can lead to your emails failing DMARC checks, which hurts your deliverability and could get your domain flagged or even added to a blacklist (or blocklist).
By managing each subdomain's SPF record carefully and aligning it with your overall DMARC strategy, you ensure that all of your email, regardless of its origin within your domain hierarchy, is properly authenticated and has the best chance of reaching the inbox.
Does a DMARC policy apply to emails from subdomains by default?
Does SPF apply to the 'Return-Path' address?
What SPF mechanism includes the A records of a domain?
What SPF mechanism includes the MX records of a domain?
What SPF mechanism refers to another domain's SPF record?
What SPF mechanism includes the IP addresses of the sending domain?