Publishing SPF for example.com does not automatically authorise mail using bounce.example.com as its envelope domain. SPF looks up policy for the identity being evaluated under RFC 7208 §4.4. There is no general parent-domain fallback that turns the root policy into an inherited policy for every child.
That matters when a new application introduces a custom return-path domain. The visible From address may stay unchanged while the domain relevant to SPF changes underneath it.
Start from a received message
Obtain a message received by a system you trust. Identify the SMTP MAIL FROM domain from trusted receiver evidence and distinguish it from the visible From field. For a null reverse path, HELO-related evaluation needs separate attention. Do not assume the root domain is the target just because it appears in the marketing copy or user interface.
Query TXT at the exact domain being evaluated. Record the owner name, response and authoritative servers. If the subdomain is delegated to another DNS zone or service, work with its actual operator rather than editing an unrelated parent-zone entry.
Choose explicit independence or shared policy
A child can have its own SPF policy tailored to its senders. This is often useful when billing, marketing and operational mail use different services. The authorisations can then be reviewed independently.
Where several identities genuinely need the same complete policy, SPF's redirect modifier in RFC 7208 §6.1 can centralise it. For example, the synthetic policy v=spf1 redirect=_spf.example.com at a child directs evaluation to an explicitly maintained policy target. The target must publish valid SPF. Redirect is used when no mechanism matches; an all mechanism in the original record prevents redirect from being used.
An include has different semantics under RFC 7208 §5.2: a pass from the included policy makes that include match, while other outcomes are processed according to the include rules. Do not swap include and redirect merely because both reference another name. Choose based on whether you are incorporating a sender set or delegating the final policy decision.
Do not use a wildcard as a substitute for inventory
DNS wildcard behaviour is more limited than “apply this to every subdomain”. Existing names and DNS tree structure affect whether wildcard synthesis occurs. RFC 7208 §3.5 discourages wildcard SPF publication and explains why extra records may be needed where names already exist.
For an important sending identity, publish an explicit, managed policy or supported delegation and test that exact name. A wildcard that appears to work for an unused test name does not prove that an established application subdomain gets the same answer.
Test the boundary with a concrete example
Illustrative example: example.com authorises documentation address 192.0.2.10, while bounce.example.com has no SPF policy. A connection from 192.0.2.10 using the root identity can pass; use of the child identity does not inherit that pass and normally yields none when there is no applicable record and no other lookup error.
If the child instead authorises only 198.51.100.20 with a final -all, a connection from 192.0.2.10 can fail for the child even while passing for the parent. This independence is useful: a marketing service need not acquire the same sender permissions as employee mail.
Manage the full lifecycle
Before adding a subdomain, assign a business owner, DNS operator and expected sender set. Preserve the approved policy and recovery instructions. After publication, test fresh messages using that exact envelope domain and record both the SPF result and any separate alignment assessment required by your wider authentication design.
At retirement, check whether the subdomain still serves delayed jobs or bounce processing. Do not remove a shared redirect target until all dependants have been reviewed. The child-domain inventory is complete when each used SMTP identity has an intentional policy and a named owner, rather than an assumption that the parent covers it.
Use the evidence for a decision
For a hypothetical billing rollout, record the actual child MAIL FROM name, its DNS operator, exact policy and test identity. If parent mail passes but child mail returns none, check the child lookup rather than adding more ranges to the parent. For shared redirect targets, retain a list of dependent identities and test negative cases as well as expected senders. No DNS delegation or policy was changed.