How to Create an SPF Record for Subdomain in 2026

Do not index

Emails can land in spam even when the root domain already has a valid SPF record. The usual cause is a mistaken assumption: SPF authorization flows from example.com to mail.example.com or get.example.com. It doesn't. Receivers evaluate the exact Return-Path domain, so every active sending subdomain needs deliberate authentication and testing.

Table of Contents

Why Your Subdomain SPF Record Is Not Inherited SPF checks the envelope identity Why this damages deliverability How to Create and Publish a Subdomain SPF Record Step 1, map the real sending paths Step 2, publish one record at the exact hostname Step 3, consolidate rather than duplicate How Subdomain SPF Secures DMARC Alignment Relaxed and strict alignment behave differently DMARC can inherit policy, SPF cannot Dedicated sending subdomains need deliberate design Common Mistakes That Invalidate Subdomain SPF Mistake one, assuming a wildcard covers every subdomain Mistake two, exceeding the lookup budget Mistake three, publishing multiple SPF records How to Verify Your Subdomain SPF Record Is Working Frequently Asked Questions Does a subdomain inherit SPF from the root domain?Should every sending subdomain have its own SPF record?Does a visible From subdomain determine the SPF record location?Can one wildcard SPF record authorize all subdomains?What happens when a subdomain SPF record exceeds the lookup limit?

Why Your Subdomain SPF Record Is Not Inherited

The popular advice that “the domain already has SPF” is incomplete. A record published at example.com authorizes senders for example.com. It doesn't automatically authorize mail that uses mail.example.com, get.example.com, or another hostname as its SPF identity.

RFC 7208 defines SPF as a policy attached to a specific DNS owner name. The receiver evaluates the domain in the SMTP MAIL FROM command, also called the envelope-from or Return-Path domain. If the reverse path is empty, the receiver evaluates the HELO or EHLO domain instead. The standard's exact-name model is summarized in the RFC 7208 SPF specification.

SPF checks the envelope identity

Consider a message with these identities:

Visible From: sales@example.com

Return-Path: bounce@mail.example.com

Root SPF record: published at example.com

Subdomain SPF record: missing at mail.example.com

The recipient doesn't use the visible From address to perform the SPF lookup. It checks mail.example.com, because that's the domain presented in MAIL FROM. The root record can be perfectly formatted and still be irrelevant to that SPF evaluation.

That distinction explains many cold outbound failures. A team may configure example.com, then route outbound mail through mail.example.com or get.example.com, assuming the organizational domain covers both. The envelope identity remains unauthenticated, and the message may fail DMARC if DKIM alignment doesn't provide an independent pass.

A useful technical primer on sender authorization is B2B email SPF explained, particularly for teams separating visible sender addresses from envelope identities.

Why this damages deliverability

Mailbox providers use authentication results as part of filtering and reputation decisions. A missing subdomain record can produce an SPF result of none, while an invalid or overextended record can produce a failure or permanent error. Those outcomes don't automatically mean every message will be rejected, but they remove an important signal that helps receivers assess legitimacy.

The commercial impact is straightforward. Messages that miss the inbox receive less attention, generate fewer replies and conversions, and can weaken trust in the sending brand. Authentication failure also makes troubleshooting harder because teams may keep editing the apex record while the receiver is checking a different hostname.

SPF's non-inheritance is intentional. It gives an organization precise control over each sending identity, which is valuable when marketing, transactional, and outbound programs have different owners and risk profiles. The control only works when the DNS records mirror the actual sending architecture.

How to Create and Publish a Subdomain SPF Record

The correct setup starts with the sending identity, not with a copy of the root record. A subdomain SPF policy should reflect every legitimate system that uses that subdomain as its envelope-from or HELO identity.

Step 1, map the real sending paths

Create an inventory for each sending subdomain. For example, mail.example.com might handle outbound messages, while get.example.com might handle product or campaign mail.

Record:

Sending service: Identify every email service, application, CRM, or internal system that sends through the subdomain.

Envelope identity: Confirm the actual Return-Path domain shown in message headers.

Authorization method: Collect the provider's required include: hostname or the approved direct IP ranges.

Ownership: Assign one person to approve additions and remove abandoned services.

This inventory matters because an incomplete record authorizes some traffic while failing other traffic. An unauthorized system may generate SPF failures, which can affect inbox placement, reply rates, and revenue from the program using that identity.

Step 2, publish one record at the exact hostname

In a DNS provider's TXT record form, the hostname should be the sending subdomain label. For mail.example.com, the host field is commonly mail, while the value begins with v=spf1.

A single-service example looks like this:

mail TXT "v=spf1 include:provider.example ~all"

A subdomain using two authorized services needs one consolidated record:

get TXT "v=spf1 include:provider-a.example include:provider-b.example ~all"

A system authorized by direct addresses may use mechanisms such as:

mail TXT "v=spf1 ip4:192.0.2.10 ip6:2001:db8::10 ~all"

The addresses above are documentation examples, not production authorization values. A real record must contain only the mechanisms supplied and approved for the organization's infrastructure.

The important rule is one SPF TXT record per evaluated domain. Multiple TXT records beginning with v=spf1 don't combine safely. Receivers can treat the result as invalid, causing authentication failures and making legitimate mail look indistinguishable from spoofed traffic.

Step 3, consolidate rather than duplicate

A root record such as:

example.com TXT "v=spf1 include:corporate.example ~all"

doesn't authorize mail.example.com. The subdomain requires its own record:

mail.example.com TXT "v=spf1 include:provider.example ~all"

Use redirect= only when evaluation should intentionally be delegated to another hostname. It isn't a shortcut for inheritance, and it adds lookup complexity that must be accounted for.

Avoid adding a provider's record without checking what already exists. Two departments can independently publish records for the same subdomain, creating a conflict that may be invisible in a basic DNS editor but obvious in receiver headers.

How Subdomain SPF Secures DMARC Alignment

SPF passing and SPF alignment are different outcomes. SPF asks whether the sending IP or service is authorized by the Return-Path domain. DMARC then checks whether an authenticated domain aligns with the visible From domain.

Suppose a message uses:

From: sales.example.com

Return-Path: bounces.example.com

The SPF record must be published at bounces.example.com. If SPF passes there, DMARC compares that authenticated domain with sales.example.com under the organization's alignment mode.

Relaxed and strict alignment behave differently

DMARC's default SPF alignment mode is relaxed. Under relaxed alignment, a parent domain and its subdomain can align because they share the same organizational domain. Thus, bounces.example.com can align with sales.example.com if SPF passes for the Return-Path domain.

Strict alignment requires an exact domain match. In that case, bounces.example.com and sales.example.com aren't equivalent, even though both belong to the same organization. A strict configuration therefore requires the SPF-authenticated domain to match the visible From domain exactly, or it must rely on aligned DKIM instead.

The subdomain misconception can incur substantial costs. A team may believe the root SPF record covers the message, but the receiver checks the Return-Path subdomain, finds no applicable policy, and receives no aligned SPF pass. If DKIM isn't aligned either, DMARC can fail. The result may include spam placement, filtering, or rejection depending on the receiver's policy and other signals.

DMARC can inherit policy, SPF cannot

DMARC policy discovery works differently from SPF. When no usable record is found for the exact From domain, receivers can query the organizational domain, as described in the policy discovery rules summarized by RFC 7489 subdomain guidance. A parent domain can also use the sp tag to define a policy for subdomains without changing the parent domain's own policy.

That difference creates a dangerous mental shortcut. A subdomain may receive a DMARC policy through parent-domain discovery, but it still needs an SPF record at the exact Return-Path hostname for SPF to pass.

The SPF, DKIM and DMARC explained guide helps teams evaluate the three controls together rather than treating SPF as a standalone DNS task.

Dedicated sending subdomains need deliberate design

Outbound teams often use a dedicated subdomain such as get.example.com, while an ESP configuration might use mail.example.com or a designated bounce hostname. Segmentation can make ownership and troubleshooting clearer, but every additional identity creates another SPF policy to maintain.

That separation protects operational clarity only when records, DKIM selectors, DMARC policy, and Return-Path behavior are documented together. If a campaign uses a visible From subdomain but the ESP uses a different envelope domain in the background, the team may validate the wrong DNS name and misread the authentication results.

Common Mistakes That Invalidate Subdomain SPF

Subdomain SPF failures are rarely caused by advanced cryptography. They usually come from inaccurate inventories, duplicated records, and lookup-heavy vendor configurations. These errors directly affect authentication signals, reputation, and the commercial performance of every affected email stream.

Mistake one, assuming a wildcard covers every subdomain

A wildcard DNS record doesn't create the SPF inheritance model teams often expect. It may be bypassed when an exact name has another record, and it doesn't turn a parent policy into a reliable authorization plan for every sending identity.

The safer approach is explicit publication at each active sending hostname. This makes ownership visible and prevents a newly introduced mail path from depending on an assumption that receivers won't apply.

Mistake two, exceeding the lookup budget

SPF evaluation has a hard limit of 10 DNS-querying mechanisms or modifiers per check, including nested lookups triggered by include, a, mx, ptr, exists, and redirect; ip4, ip6, and all don't consume that lookup budget, as reflected in RFC 7208 lookup guidance.

If a record exceeds the limit, receivers can return PermError and treat SPF as failing. The SPF lookup limit guidance also highlights the operational consequence for segmented programs: each sending subdomain has its own evaluation budget, but each record still needs to remain compact.

Reduce unnecessary includes, remove inactive vendors, and consider approved direct IP mechanisms where appropriate. Flattening can reduce lookups, but it creates a maintenance obligation because changed provider infrastructure can make the flattened addresses stale.

Mistake three, publishing multiple SPF records

Two records such as these are not a valid way to split ownership:

mail TXT "v=spf1 include:provider-a.example ~all"

mail TXT "v=spf1 include:provider-b.example ~all"

The mechanisms need to be consolidated into one record. A duplicate policy can cause a permanent error before reputation is even considered, so teams should treat DNS change control as part of deliverability governance, not as an informal marketing task.

How to Verify Your Subdomain SPF Record Is Working

Publication isn't proof. Verification should confirm the exact hostname, syntax, lookup behavior, and live message result.

Query the exact Return-Path domain. Check mail.example.com, not only example.com.

Validate the record. Use the spf checker to confirm that the record exists and identify syntax or lookup issues.

Send a controlled message. Deliver mail to monitored accounts and inspect the received headers for an authentication result such as spf=pass.

Confirm alignment. Compare the authenticated SPF domain with the visible From domain and check whether the configured DMARC mode allows the relationship.

Repeat after infrastructure changes. Adding a vendor or changing the Return-Path can invalidate a previously correct policy.

A diagnostic result is only one part of the answer. Headers reveal what the receiver evaluated, which is why a DNS record that looks correct can still fail when the sending platform uses a different envelope domain.

Frequently Asked Questions

Does a subdomain inherit SPF from the root domain?

No. SPF is published and evaluated at the exact DNS name used as the MAIL FROM or HELO identity. A sending subdomain needs its own applicable record.

Should every sending subdomain have its own SPF record?

Yes, when that subdomain is used as the SPF identity. Each record should consolidate all legitimate senders for that hostname into one policy.

Does a visible From subdomain determine the SPF record location?

No. SPF normally follows the Return-Path or envelope-from domain. The visible From address is used for DMARC alignment, not as the sole SPF lookup target.

Can one wildcard SPF record authorize all subdomains?

No. A wildcard isn't a dependable substitute for explicit SPF records at active sending hostnames. Exact-name publication is easier to audit and troubleshoot.

What happens when a subdomain SPF record exceeds the lookup limit?

Receivers can return PermError, causing SPF to fail. Nested include and redirect chains deserve particular scrutiny because they consume lookups beyond the visible record.

A correct SPF record for a subdomain is a small DNS change with broad deliverability consequences. The essential discipline is to map the active Return-Path, publish one policy at that exact hostname, keep lookup usage controlled, and verify alignment through live headers. Teams that send through multiple subdomains should treat these records as managed infrastructure because authentication failures cost inbox access, conversions, and brand trust.

MailAdept provides subscription-based email deliverability consulting that combines AI agents with human experts to review SPF, DKIM, DMARC, Return-Path behavior, and subdomain configuration. Teams facing repeated authentication failures can visit Mailadept to discuss a focused review of their sending infrastructure.