Are sites without wildcard SPF records vulnerable to subdomain spoofing attacks?

Question

The thought occurred to me that if SPF records are not recursive, domain names may be vulnerable to email spoofing from subdomains. My research reveals this:

The Demon Question: What about subdomains?

If I get mail from pielovers.demon.co.uk, and there's no SPF data for pielovers, should I go back one level and test SPF for demon.co.uk? No. Each subdomain at Demon is a different customer, and each customer might have their own policy. It wouldn't make sense for Demon's policy to apply to all its customers by default; if Demon wants to do that, it can set up SPF records for each subdomain.

So the advice to SPF publishers is this: you should add an SPF record for each subdomain or hostname that has an A or MX record.

Sites with wildcard A or MX records should also have a wildcard SPF record, of the form: * IN TXT "v=spf1 -all"

(Thanks to Stuart Cheshire.)

^{(emphasis mine)}

Q1: Why don't you need to add a SPF record if the subdomain doesn't have a A/MX record?

As an example, I investigated support.google.com:

dig google.com txt:

google.com. 3599 IN TXT "v=spf1 include:_spf.google.com ip4:216.73.93.70/31 ip4:216.73.93.72/31 ~all"

dig support.google.com txt:

support.google.com. 21599 IN CNAME www3.l.google.com.

dig www3.l.google.com txt:

www3.l.google.com. IN TXT

So..., no SPF record for support.google.com.

Q2: Wy don't Google (and many other sites) follow this advice?

Q3 (bonus): If this is a problem, and I'm not just being stupid, why is this not more documented?

^{The only related SE question I can find is this, but it doesn't say much more than the openspf.org FAQ above.}

Answer 1

This is actually not terribly relevant advice in 2015, as the email landscape has evolved substantially since that post was made.

In practice SPF is an authentication protocol, not a policy enforcement mechanism. What I mean by that is that a particular message can pass, fail, or not check SPF based on the EHLO name or Return Path domain. But how a receiver should handle any SPF result is up to the receiver.

The email policy enforcement mechanism is DMARC, which specifies how a message that does not pass SPF or DKIM authentication should be handled by a receiver. Should it be rejected entirely? Quarantined (typically meaning directed to a spam folder)? Or treated as 'normal'?

DMARC, unlike SPF, does have subdomain inheritance. So, provided an explicit DMARC policy isn't defined on the subdomain, the policy defined on the organizational domain is used. So in the specific case you mention, the policy will be read from _dmarc.google.com. Which is:

v=DMARC1; p=quarantine; rua=mailto:[email protected]

So your hypothetical email sent on support.google.com will be treated as spam, even without an explicit SPF policy defined on support.google.com

So if you want to ensure against subdomain spoofing for a domain you manage, add a DMARC policy.