The good thing about DMARC
One of the great things about DMARC is that subdomains can inherit the policy of its organizational domain. For example, here's the DMARC record of microsoft.com (I've removed the reporting addresses):
microsoft.com | "v=DMARC1; p=reject; pct=100"
There's no subdomain policy, which means that the following domain which has no DMARC record:
foo.microsoft.com | No DMARC record
... inherits the organizational domain policy, which in this case is p=reject. This is great because suppose I wasn't entirely sure if microsoft.com could be protected and had to set p=none. I could still protect the subdomains by specifying its policy:
microsoft.com | "v=DMARC1; p=none; pct=100; sp=reject"
So, a phisher could spoof microsoft.com, but not foo.microsoft.com, bar.microsoft.com, and so forth. It's one of the best things about DMARC. I can't possibly set up DNS records for every possible combination of *.microsoft.com but I don't have to because they all inherit from the organizational domain by default. Or, I can specify the subdomain policy and make it different than the organizational domain's policy. Or, for certain subdomains, I can explicitly specify the policy by publishing a DMARC record.
.
The drawback of SPF
But whereas DMARC has inheritance, SPF does not. Suppose that this is the SPF record for microsoft.com:
microsoft.com | "v=spf1 ip4:10.0.0.0/24 -all"
(Let's pretend, for now, that the IP range is not an internal range). Anyone who spoofs microsoft.com from an IP outside that range will hard fail SPF and will experience problems delivering.
But what if a spammer sends from @foo.microsoft.com?
There's no SPF record for that domain, and I can't possibly set them all up. Rather than getting an SPF hard fail, it will get SPF None. That's usually not nearly enough to give a domain delivery trouble.
You may ask "Why does this matter?" After all, microsoft.com already has a DMARC record, so you're all set.
Except that's not true. Many times phishers spoof microsoft.com in the header.from address, or a subdomain in the header.from address; those are protected by DMARC. But often times, they spoof *.microsoft.com in the SMTP Mail From domain, and then have a completely different header.From domain (a domain we do not control).
This is problematic because we don't want spammers or phishers squatting on our domains or subdomains in any capacity, neither the SMTP Mail From, nor the From: domain (nor the Sender: header, but that's another problem). When the SMTP Mail From and From: domains are different, DMARC doesn't help if it's not our brand since we can't publish a DMARC record. And also, SPF isn't helping either because the SPF record does not exist and therefore can't help in refudiating [1] the message.
And that leads to "cosmetic" problems. Many of us understand the complexities of different sender addresses, the limits of SPF and DMARC, and the challenge of authentication. But even more of us (i.e., not me, of course) don't. And when someone gets an email and starts going through the headers and doesn't have that background and then they see *.microsoft.com being spoofed, it leads to all sorts of noise. "Why are you sending spam?" "Why haven't you locked down your domain?" And on it goes.
Email authentication is hard to explain.
.
Extending SPF to include inheritance
It'd be great to cut down on that noise.
And that's why I think SPF needs an update. It needs a mechanism to specify that a subdomain inherits from its organizational domain, or not. That way, I can sleep easy knowing that the entire domain is protected since I can't possibly publish SPF records for everything.
I think the default should be just like DMARC - if the SPF record doesn't exist, fallback to the organizational domain. We'd have to define a new syntax to say that the subdomain should not inherit from the organizational domain; and that syntax should also be able to specify a default fallback (hard fail, soft fail, neutral) for subdomains. I don't know for certain that's necessary because it's rare that unpublished subdomains should have a different fallback policy than the organizational domain. If it's that big a concern, explicitly set one up.
So, this SPF record:
foo.microsoft.com | None
... would be treated as this:
microsoft.com | "v=spf1 ip4:10.0.0.0/24 -all"
The correct way to do this would be to propose an extension to RFC 7208, get sign-off from the industry and publish an updated RFC. I think that's the long-term path.
The short-term path would be to start doing it, and then in the Authentication-Results header, add some comment that says that's what you're doing, e.g.,
Authentication-Results: spf=fail (sending IP is 192.168.1.2) smtp.mailfrom=foo.microsoft.com (using SPF record for microsoft.com)
That makes it clear to anyone who asks what is being done. There's probably a better way to specify this (e.g., with a new result, like spf=inheritFail). In parallel, work on updating the standard.
And that's my idea about how we can make SPF great again.
[1] "Refudiate" is a word. Look it up.