The SPF a and mx mechanisms authorise addresses discovered through DNS. They can reduce manual address maintenance, but they also couple outbound permission to records maintained for other jobs. A website migration or inbound-mail change can therefore alter SPF without anyone editing the SPF record itself.
The right question is not whether these mechanisms are valid. It is whether the DNS dependency expresses your intended sending policy.
What a actually evaluates
The a mechanism resolves the selected target name to addresses appropriate to the SMTP connection family. It uses A for an IPv4 connection and AAAA for native IPv6; IPv4-mapped IPv6 is treated as IPv4 under RFC 7208 §5. Despite its name, a is not limited to IPv4. If a target is omitted, the current SPF evaluation domain is used.
With a:mail.example.com, a matching address can pass under the default + qualifier. With bare a at example.com, the addresses of example.com become relevant. If that name points to a website host or CDN, ask why those addresses should be authorised to send mail for the evaluated identity. The semantics appear in RFC 7208 section 5.3.
What mx actually evaluates
The mx mechanism retrieves MX hosts for its target domain and then their addresses. It compares the connecting IP with those resolved addresses. MX records ordinarily describe inbound routing, but inbound servers are not necessarily the same systems that send outbound mail.
SPF mx does not use SMTP's implicit-MX fallback. If the target has no MX record, SPF must not treat its A or AAAA records as fallback MX hosts. That distinction is explicit in RFC 7208 section 5.4.
Worked example: two dependencies, different permissions
Assuming a valid single SPF policy, successful DNS answers, default host prefixes and no earlier evaluation error, this synthetic policy is v=spf1 a:out.example.com mx:example.com -all. Assume out.example.com resolves to A 192.0.2.40. The MX of example.com is inbound.example.com, whose A record is 198.51.100.12.
A connection from 192.0.2.40 matches a. A connection from 198.51.100.12 misses a, then matches mx. A connection from 203.0.113.18 misses both and reaches fail. If the inbound MX host changes, the second permission can change even though the SPF TXT record remains identical.
For an IPv6 connection, inspect the relevant AAAA answers instead of reusing the IPv4 trace. If a target is absent or returns no applicable address, distinguish that no-match condition from a DNS error; a timeout is not proof that the intended host is unauthorised.
Review lookup work and secondary limits
Both mechanisms contribute to the ten DNS-query-causing-term limit when evaluated. MX expansion also has additional address-query limits defined in RFC 7208 §4.6.4. A policy can fail those limits even when a superficial count of top-level terms looks acceptable.
Capture the MX answer set and subsequent address lookups in the test evidence. Do not treat ten as a guarantee that every record with ten visible words is safe. Recursive dependencies, expansion and void lookups need their own evaluation.
Decide whether to keep the dependency
Keep a or mx when the domain owner intentionally wants that DNS record to govern sending permission and the operational teams understand the coupling. Consider explicit ip4/ip6 mechanisms for stable dedicated egress, or a provider-supported include when the provider maintains the outbound infrastructure.
Before removing a dependency, identify which legitimate addresses currently match it. A seemingly unnecessary mx may be the only authorisation for a rarely used relay. Build the replacement, compare the permission sets and verify representative messages before deleting the old term.
The practical takeaway
An a or mx mechanism turns another DNS change into an SPF permission change. Make that relationship intentional, visible to the relevant owners and covered by tests.
Record the decision and its limits
Keep a dependency row for out.example.com and another for each MX host: DNS owner, address family, observed answer and legitimate service using it. An inbound-provider migration should trigger review of the MX row even if TXT is unchanged. The sample results are analytical; real evidence must include answer timestamps and terminal errors as well as matches.