Do subdomains need their own SPF records?

SummaryPublish or configure SPF for the identity your provider actually uses. A separate sending identity can have its own lookup budget; adding another include to the original policy cannot.

SPF does not automatically inherit from the parent

If a service uses bounce.studio.example as its envelope-sender domain, the policy at studio.example does not automatically cover it. Configure the exact sending identity according to the provider’s instructions. Google’s SPF setup guidance calls out separate subdomain configuration.

This does not mean every hostname used for a website needs to authorise email. Start with the names actually used as sending identities. A hostname such as www.studio.example may host a website without ever appearing as a MAIL FROM domain.

SPF can also evaluate a server’s HELO identity; this matters particularly for messages with an empty reverse-path, such as some bounces. If you operate an SMTP server directly, include that identity in your review rather than applying only a mailbox-provider example.

Find the domain your provider actually uses

Send a message from the service to an external mailbox you control. Compare the visible From address with the Return-Path and the smtp.mailfrom reported by the receiving system. Then compare those observations with the service’s authentication setup screen.

If the service uses its own provider-owned domain, you may have no SPF record to publish for that identity. If it offers a custom return path, follow its full setup process. Some services use TXT and MX records; others delegate a name with a CNAME. Do not add a TXT record alongside a CNAME at the same name or invent an alternative to the provider’s instructions.

Amazon SES is one documented example: its custom MAIL FROM configuration requires the relevant SPF and bounce-handling records. This is an illustration of provider-specific behaviour, not an Emailmetry compatibility listing.

A separate policy for a separate sending identity

Suppose a studio’s mailbox and campaign service use different envelope-sender domains. These fictional policies show the separation:

Mailbox messages using studio.example are evaluated against the first policy. Campaign messages using campaigns.studio.example are evaluated against the second. Neither policy needs the other provider solely because both belong to the same business.

The sending service must actually use the intended identity. Publishing a campaigns policy while the service continues using the root domain as MAIL FROM will not move its SPF evaluation.

When a subdomain gives you a separate lookup budget

A new SPF evaluation for a different envelope-sender domain has its own ten-term budget. This can keep independent sending workflows from sharing an unnecessarily complex root policy.

For example, imagine two fictional workflows each need six evaluated terms. If both are combined into one policy and a sender must traverse all twelve, that path is too long. If each workflow uses its own envelope-sender domain with an independent six-term policy, the evaluations can fit separately. The result depends on real routing and policy paths, not on the names chosen for the TXT records.

Microsoft discusses using subdomains for separately operated email services. Our lookup-limit guide explains how nested terms are counted.

Check DMARC alignment alongside SPF

Moving the envelope sender to a subdomain changes the SPF identity. Compare it with the visible From domain under your DMARC alignment settings. In a straightforward studio.example example, a passing SPF result for bounce.studio.example aligns with the root under relaxed alignment, but not strict alignment.

A passing DKIM signature with an aligned domain may provide the DMARC pass instead. Publishing a separate SPF record does not by itself configure DKIM, establish DMARC alignment or create an independent DMARC policy. Read why SPF can pass while DMARC fails before changing production identities.

Do unused subdomains need SPF?

Do not copy a broad authorisation to a hostname simply because it exists. For a known domain that must never be used as a sending identity, a policy such as v=spf1 -all expresses that intent. Confirm it is not used by a bounce path, device or application before applying that policy.

One record does not automatically establish protection for every possible subdomain. Review DMARC domain coverage separately and avoid relying on wildcard DNS behaviour without understanding the existing names in the zone.

Test a subdomain rollout

1. Record the current and proposed envelope-sender domains and who owns the sending service.
2. Save the DNS baseline and publish the exact records supplied by the provider at the intended names.
3. Complete any provider verification and confirm that outgoing messages now use the new return path.
4. Inspect SPF, DKIM and DMARC at an external receiving mailbox, including alignment.
5. Check the service’s documented bounce handling with a controlled test where appropriate.
6. Retire old authorisations only after queues, scheduled workflows and the transition have been checked.

Use the SPF checker on the actual envelope-sender domain. Keep the results with the provider-change checklist so the next person knows which identity was tested.