4

Does a SPF record apply only on the domain it’s setup for or also for all it’s subdomains?

For example an SPF record that is configured for the domain example.com will set the policy for mails ending with @example.com.

So if that is the only SPF record, does it also apply on mails send from mail addresses ending with @www.example.com? Or should a second SPF record for the www subdomain be configured (and so for all other subdomains)?

Bob Ortiz
  • 6,234
  • 8
  • 43
  • 90

3 Answers3

7

I cannot see anything in the SPF standard which would imply that a SPF record covers all subdomains too. Given that subdomains are sometimes managed by different parties (especially in larger organisations like universities) it would also not make much sense to implicitly cover the subdomains. And the standard says in section 4.4:

4.4. Record Lookup
In accordance with how the records are published (see Section 3 above), a DNS query needs to be made for the <domain> name, querying for type TXT only.

"<domain> name" is here the domain from the email, not an upper domain.

Community
  • 1
Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • Does this mean that subdomains such as (www) always need their own SPF record in order to set their policy? For example: `example.com` has it's own SPF record for `@example.com` mail addresses. But shouldn't `www.example.com` have an SPF record to restrict (in this scenario) mailing, by rejecting all e-mails sent using `@www.example.com` email addresses? Since the SPF record on `example.com` does not apply on `www.example.com`. – Bob Ortiz Feb 12 '18 at 11:28
  • @KevinMorssink: non-existence of a SPF record does not mean that mails in the name of the domain can be send from everywhere. Often MTA check that a MX record exists for the senders domain and reject mails which claim to be send from domains which based on the non-existent MX record do not accept any mails. – Steffen Ullrich Feb 12 '18 at 12:16
  • I understand, but that requires the client to perform such MTA / MX-record existence check. But if we theoretically only look at the SPF mechanism. Does that mean that every subdomain needs their own SPF record since one SPF record on the domain itself does not apply on its subdomains? – Bob Ortiz Feb 12 '18 at 12:21
  • 1
    @KevinMorssink: an MTA which is configured to care about spam and therefore checks the SPF record but then treats a non-existent SPF record as "allow from everywhere" without checking MX does not properly care about spam. It is not the task of a domain owner to create rejecting SPF records for every possible sub-domain and sub-subdomain just because of misconfigured MTA. – Steffen Ullrich Feb 12 '18 at 12:30
  • @SteffenUllrich – Missing SPF is treated as "NEUTRAL". This differs from "allow from everywhere", in which SPF containing `+all` would get an SPF "PASS" verdict. – Adam Katz Feb 16 '18 at 16:53
  • @AdamKatz: Correct. It is actually not "allow from everywhere" (`+all`) but "not disallow from everywhere" (`?all`). I just wanted to highlight that one does not have to explicitly add `-all` for every subdomain in order to limit spam from this domain. And, while a missing SPF record is just treated as `?all` and thus does not forbid the MTA to accept mails for this domain from this source IP, the non-existence of an MX record for the claimed sender domain should hopefully cause the rejection of the mail by the MTA. – Steffen Ullrich Feb 16 '18 at 17:34
3

SPF does not "roll up" to the organizational domain (this is DMARC's term for thing you register, immediately under the TLD/public suffix). When SPF refers to a "domain", it means the fully qualified domain name (FQDN, "host").

You can make this roll up with a wildcard DNS record, so if you control example.com with BIND:

*         IN  TXT     v=spf1 a 192.0.2.0/24 -all
@         IN  TXT     v=spf1 a mx 192.0.2.0/24 ~all

I've chosen to make @ (the top level) allow the mail exchange and be more forgiving about missing may relays (they'll SOFTFAIL) while any other host will trigger the wildcard and either sends mail themselves (the A record, which also affects IPv6's AAAA), plus the allowed network CIDR, with a more final FAIL for items that do not pass. This isn't authoritative without DMARC, which could also be set up with a wildcard if desired.

Adam Katz
  • 9,718
  • 2
  • 22
  • 44
1

As Adam mentioned, SPF policy discovery works differently than DMARC when it comes to subdomains: if no SPF record is found on a subdomain, no attempt is made to use the SPF record on the organizational domain; SPF will return none as the check result.

A subdomain typically represents a separate department within an organization, e.g., sales.company.com for the sales department, it.company.com for the IT department, support.company.com for customer support, etc.

As different departments have different functions, so do the services they use to deliver emails. For example, sales might use Outreach, and support might use Zendesk, etc.

Therefore, unlike DMARC, it's probably not a good idea to fall back to using the root domain's SPF record if no SPF record is found on a subdomain, as the subdomain should use very different services.

To rectify this, one should publish an SPF record on every subdomain that sends outbound emails.

Learn more here: https://dmarcly.com/blog/how-spf-works-with-subdomains

lgc_ustc
  • 111
  • 1