Does SPF need an update so subdomains can inherit the policy of its organizational domain? I say yes

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 (I've removed the reporting addresses): | "v=DMARC1; p=reject; pct=100"

There's no subdomain policy, which means that the following domain which has no DMARC record: | 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 could be protected and had to set p=none. I could still protect the subdomains by specifying its policy: | "v=DMARC1; p=none; pct=100; sp=reject"

So, a phisher could spoof, but not,, 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 * 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 | "v=spf1 ip4: -all"

(Let's pretend, for now, that the IP range is not an internal range). Anyone who spoofs from an IP outside that range will hard fail SPF and will experience problems delivering.

But what if a spammer sends from

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, already has a DMARC record, so you're all set.

Except that's not true. Many times phishers spoof in the header.from address, or a subdomain in the header.from address; those are protected by DMARC. But often times, they spoof * 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 * 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: | None

... would be treated as this: | "v=spf1 ip4: -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 (using SPF record for

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.

Comments (5)
  1. Great idea!
    Let’s do that, starting today.

  2. Ben says:

    So what do you need from us?! Sounds ideal to me!

  3. Bart says:

    Sounds really good! Have you informed Scott Kittermann (the author of RFC7208) and/or the SPF mailing list ( ) for feedback?

    Publishing SPF on all subdomains is indeed not going to scale. It is not only impossible to maintain, it also dramatically increases the size of a DNS zone.

    Currently non-exisiting subdomains could already be covered with a wildcard ( ).
    But what if someone will send an email from something.* (with * as label, not as wildcard)? Should we therefore also created an *.* record, and keep on adding wildcard labels until we reach the maximum dns label length..?

    On the SPF website I found this FAQ:
    It shows the need to have the option to exempt subdomains from inheriting the policy of the organizational domain.

  4. Jesse Thompson says:

    What about the idea of extending DMARC to allow a domain owner to publish a policy that says “All email using my domain in the SMTP Mail From must be aligned to the From: header domain.” DMARC already has the subdomain policy capability, and alignment could be achieved using DKIM or SPF for legitimate uses of the subdomain.

  5. Jason says:

    This could be a good solution to a big problem we are facing.
    Let’s say our corporate domain is , and we have 250 MTA’s running (we are an ESP).
    Each NDR is send back from (where XXX is a number).

    All these NDR messages are failing DMARC because 1. they are not DKIM signed (NDR messages) and 2. they don’t have an SPF record validating them.

    If we elevate our DMARC policy to reject, and a customer uses for example Google Apps for his domain, then all his NDR messages would be rejected by Google, because is not DMARC compliant.

Comments are closed.

Skip to main content