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)?

Improve this question
4
  • do your subdomains have differernt ips? remember that its a DNS record
    – schroeder ♦
    Commented Feb 6, 2018 at 23:45
  • @schroeder is it relevant? Because, if so, I also wonder what difference that would make.
    – Bob Ortiz
    Commented Feb 6, 2018 at 23:49
  • because it is a DNS record
    – schroeder ♦
    Commented Feb 6, 2018 at 23:50
  • SPF records are normally applied to MX records, so you need 1 per different MX record.
    – LvB
    Commented Feb 8, 2018 at 23:47

3 Answers 3

Reset to default
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.

Improve this answer
6
  • 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
    Commented Feb 12, 2018 at 11:28
  • 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
    Commented Feb 12, 2018 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
    Commented Feb 12, 2018 at 12:21
  • 1
    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
    Commented Feb 12, 2018 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
    Commented Feb 16, 2018 at 16:53
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.

Improve this answer
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

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .