Q:

Using multiple A-records within one SPF a:name

Let's say my SPF record looks like this:
v=spf1 a:spf.example.com -all
And the records for spf.example.com look like this:
spf.example.com A 12.12.12.12
spf.example.com A 12.42.66.12
spf.example.com A 12.16.48.12
spf.example.com A 12.73.23.12
spf.example.com AAAA 2001:0db8:85a3:0000:0000:8a2e:0370:1001
spf.example.com AAAA 2001:0db8:85a3:0000:0000:5a1e:1288:1001
spf.example.com AAAA 2001:0db8:85a3:0000:0000:3b2e:5241:1001
spf.example.com AAAA 2001:0db8:85a3:0000:0000:2f2e:8361:1001

Would all of these IP addresses be validated by the SPF? If so, are there any limits to the amount of A-records for one name? It seems to me that none of the bigger providers like Google or Outlook use this method. Is that because it is bad practice?
Why I ask this question: I would assume that this method is better than using multiple includes because of the 10 DNS lookup limit for SPF records. With this method only 1 DNS lookup would be required so I guess it would speed things up AND you will never hit the 255 character limit in the TXT-record for the SPF.

A:

When you use the a mechanism in SPF, that means that all the addresses found by a lookup corresponding to the address family used by the client will be matched. Ie, if the client connected via IPv4 an A lookup is done, if the client connected via IPv6 an AAAA lookup is done.
Just from a general DNS perspective, the limit for how many records you can have for a single name is not a set number but rather a limit in terms of the overall message size when sending a response. You can't really stretch this all that far.
There may well be some middle ground where what you describe could serve as a useful trick, but if you look at the big providers they often have big pools of addresses that they use for their services. Them specifying address prefixes (possible with the SPF ip4 and ip6 mechanisms) rather than doing anything that involves listing individual addresses (as with A or AAAA records, which is what the a mechanism will lead to) quickly becomes a MUCH bigger saving.
If we look at one of your mentioned examples, namely Google, we would at this time see:
_spf.google.com.        300     IN      TXT     "v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all"

_netblocks.google.com.  3600    IN      TXT     "v=spf1 ip4:35.190.247.0/24 ip4:64.233.160.0/19 ip4:66.102.0.0/20 ip4:66.249.80.0/20 ip4:72.14.192.0/18 ip4:74.125.0.0/16 ip4:108.177.8.0/21 ip4:173.194.0.0/16 ip4:209.85.128.0/17 ip4:216.58.192.0/19 ip4:216.239.32.0/19 ~all"

_netblocks2.google.com. 3600    IN      TXT     "v=spf1 ip6:2001:4860:4000::/36 ip6:2404:6800:4000::/36 ip6:2607:f8b0:4000::/36 ip6:2800:3f0:4000::/36 ip6:2a00:1450:4000::/36 ip6:2c0f:fb50:4000::/36 ~all"

_netblocks3.google.com. 3600    IN      TXT     "v=spf1 ip4:172.217.0.0/19 ip4:172.217.32.0/20 ip4:172.217.128.0/19 ip4:172.217.160.0/20 ip4:172.217.192.0/19 ip4:108.177.96.0/19 ip4:35.191.0.0/16 ip4:130.211.0.0/22 ~all"

That means, for the typical user domain that it costs four lookups to specify:

256 + 8192 + 4096 + 4096 + 16384 + 65536 + 2048 + 65536 + 32768 + 8192 + 8192 + 4096 + 8192 + 4096 + 8192 + 8192 + 65536 + 1024 = 314624  IPv4 addresses
4951760157141521099596496896 + 4951760157141521099596496896 + 4951760157141521099596496896 + 4951760157141521099596496896 + 4951760157141521099596496896 + 4951760157141521099596496896 = 29710560942849126597578981376 IPv6 addresses

