~ dig _dmarc.google.com txt +short
"v=DMARC1; p=reject; rua=mailto:mailauth-reports@google.com"Yes, SPF (the original design) is horribly broken and trivially bypassed. The most prominent design flaw is that the inbound SMTP service uses the SMTP (rfc5321) MailFrom address for SPF validation, which is not the same sender address shown to the recipient, they can only see the the message (rfc5321) 'From' header address. SPF originally didn't require the domains in the MailFrom and From addresses to match, so an attacker would simply use a domain they control in the MailFrom address, and the 'spoofed' domain in the From header.
That was in 10 years ago though. DMARC fixed this by adding the alignment requirement, meaning that the domains in the MailFrom and From address must match. By default the alignment policy is 'relaxed', meaning that the MailFrom and From domains can differ in subdomain, as long as they share the same organizational domain. Setting the SPF alignment to strict (aspf=s) like you mention in your post requires the domains to match exactly, with no subdomain differences allowed.
So, it doesn't matter that Google doesn't use strict SPF alignment in the DMARC policy, the fact that they have DMARC already adds the requirement to SPF validation that the domains must match.
Yes, google.com and gmail.com use the same IP ranges in the respective SPF policies, but Gmail will never allow you to send email addresses from a domain that you do not own. This is why domain validation is required when you set up Gmail with a custom domain.
The only scenario where your explanation would hold up, is if the attacker was able to gain control of the DNS of a subdomain of the google.com domain, and successfully validated it as a custom domain in Gmail, then send emails from that subdomain in rfc5321.MailFrom address and the google.com domain itself as the rfc5322.From domain.
Deprecating SPF would do everyone a favour though. Especially for reasons like these.
Google owns and manages all of this, so they can send emails with a google.com MAIL FROM, a google.com header, and signed with a google.com DKIM key. And they could do likewise with gmail.com emails.
I'm not clear on why this isn't practical, perhaps there is something I'm missing though? I would appreciate your viewpoint.
Edit: I see you added a point about forwarding.
Your MTA can still check alignment for both HELO and SMTP From as specified by SPF's RFC(s) though and spam filters often do for extra information/signal.
DMARC's adkim/aspf aren't basically supported in practice. Nor they should be. For reasons already mentioned, as you already read.