11

Why do administrators mostly use +a alongside +mx in SPF records? This is the example:

@              10800 IN TXT     "v=spf1 +a +mx -all"

Isn't it enough to only use +mx parameter e.g.:

@              10800 IN TXT     "v=spf1 +mx -all"

I thought MX record's task is to send email and not A record's. Can anyone explain the scenario why would anyone use +a then?

71GA
  • 363
  • 1
  • 3
  • 10
  • 6
    Actually, an MX **receives** mail. Often the same server is used to also send mail, but there's absolutely no requirement for that, and there are many setups where it isn't the case at all. – jcaron Dec 29 '20 at 00:15
  • 3
    Let's also remember the oft-discounted fact that web servers send e-mail, and depending on the setup, they may do so directly rather than going through another server. Including the web server's address allows this (provided the server has a single IP), and using `a` means you don't need to update your SPF record if you change your web server's address. How prevalent this could be, and how accurate it is is anyone's guess. – jcaron Dec 29 '20 at 00:19
  • @jcaron Could you add that as an answer? I didn't see it mentioned in any of the existing ones. – wjandrea Dec 30 '20 at 19:33

4 Answers4

23

Frankly because they have copied the configuration from some tutorial or example configuration without knowing the basic principles of SPF. Sometimes it's desired that e.g. both a web server in a and incoming mail exchanges mx are also used for sending mail, but not nearly always.

It's better to favor mechanisms with less additional DNS queries: ip4/ip6 over a and a over mx (RFC 7208, 10.1.1) And even if, for easier administration (10.1.2), a mechanism is chosen, it's not always a mx or a, but e.g. a:relay.example.com.

Community
  • 1
Esa Jokinen
  • 46,944
  • 3
  • 83
  • 129
  • When you say *"It's better to favor mechanisms with less additional DNS queries"* what did you mean? Did you mean that usage of symbolic names i.e. `mx` is performance wise worse than using IP's directly which don't have to be resolved? So if `+a` doesn't have to be used I will only use `+mx` or as you pointed out `ip4:` or `ip4:`. – 71GA Dec 28 '20 at 09:47
  • 3
    @71GA There is performance hit for the recipient from having to look up additional records. Indirectly specified IP addresses from `a`, `mx` (in two steps!), `include` (possibly multiple steps!), etc require looking up these other records in order to get at the IP addresses actually needed for SPF validation. This is also why there is a maximum number of lookups (10) after which recipient will simply refuse to process your full policy. `ip4:x` and `ip6:x` are the ideal forms of policy, indirections are relevant if they serve a purpose. – Håkan Lindqvist Dec 28 '20 at 09:55
  • 1
    Yep. Sometimes `include`s are necessary if someone else is controlling the system sending email, like Microsoft, Google or some newsletter system; you don't want to monitor if they change the IP ranges in use. But if you use multiple and they don't use the `ip4`/`ip6` mechanisms, you are shortly out of the 10 lookups limit. So better not waste it with `mx` and `a`, when possible. – Esa Jokinen Dec 28 '20 at 11:15
  • 3
    On the other hand, `mx` and `a` are more ergonomic to use as they are symbolic and you don’t have to list possibly changing IP addresses. A mail server usually already has made and cached the relevant DNS queries, I would be surprised if use of `a` or `mx` turned out to be a measurable performance concern in actual practice … – glts Dec 28 '20 at 11:54
  • @glts: The email is validated against the SPF records when **receiving** mail. The receiving MTA hasn't contacted the sending MTA, as it's the other way around. Therefore, it probably hasn't cached those `A` or `MX` records. – Esa Jokinen Dec 28 '20 at 20:28
  • @EsaJokinen Maybe – it’s worth a thought. For example, the Postfix mail server may perform various checks such as whether a sender’s mail domain can be found in DNS, whether reverse DNS matches etc. With a local caching resolver at least some of these records may therefore be available locally. – glts Dec 28 '20 at 20:53
  • @glts: That might be correct for `a`, but certainly not for `mx`. Also, `a` isn't necessarily always the hostname itself, but could also be e.g. `a:sub.example.com` or even `a:example.net`. But this has been a good discussion! – Esa Jokinen Dec 28 '20 at 21:01
  • Yes, of course. And thank you too! – glts Dec 28 '20 at 21:05
20

The task of the hosts listed in MX records is to receive email, not necessarily to deliver email.
It's entirely valid (and quite common, particularly for larger operations) to have an asymmetric setup where the hosts handling inbound and outbound email are not the same.

That is, there is no guarantee that either mx (aka +mx) or a (aka +a) in SPF is a relevant for specifying which hosts are expected to deliver email.
As an example, if you don't run your own mail servers, maybe something like v=spf1 include:spf.majoremailserviceprovider.example -all would be more relevant.

To directly address the question about why the a mx combination in particular appears to be overrepresented in SPF records, my guess is that this situation boils down to all too many administrators adding SPF records without understanding the SPF concepts well enough to judge what to put in their policy, instead just copy-pasting some arbitrarily constructed examples.

Håkan Lindqvist
  • 35,011
  • 5
  • 69
  • 94
  • The other argument for the `a mx` combination being so prevalent is that it _works_ no matter what your infrastructure looks like, provided you handle DNS for your own mailservers. Even if it’s too generic to be properly secure, it’s still better than nothing and requires zero effort from the network administrator to set up. – Austin Hemmelgarn Dec 31 '20 at 16:43
  • @AustinHemmelgarn That is just not true. It may *often* (?) work in simple environments, but regardless if you run your own mail servers or not, it's by no means a universally safe bet that the address records at the apex or the `MX` hosts will match the hosts that are expected to deliver mail. – Håkan Lindqvist Dec 31 '20 at 17:07
4

I agree with the other answers that +a +mx is probably a cargo-culted anti-idiom.

Regarding when you would use +a, the RFC document answers this in section 10.1.2:

Publishing SPF records for individual hosts is also best practice. The host name is generally the identity used in the 5321.HELO/.EHLO command. In the case of messages with a null 5321.MailFrom, this is used as the domain for 5321.MailFrom SPF checks, in addition to being used in 5321.HELO/.EHLO-based SPF checks. The standard SPF record for an individual host that is involved in mail processing is:

relay.example.com.   IN TXT  "v=spf1 a -all"

For example, I publish such a record for my mail server mail.mydomain.org, for the benefit of verifiers that verify the HELO identity first. (Of course, I also publish the customary v=spf1 mx -all record at the mail domain mydomain.org itself.)

glts
  • 897
  • 5
  • 17
  • 1
    Furthermore, if there's any subdomain (`A`) that shouldn't be used for sending email it should have a corresponding `TXT "v=spf1 -all"` to tell that neither should anyone else. SPF doesn't have inheritance: the SPF record at the domain apex won't protect any subdomains. – Esa Jokinen Dec 28 '20 at 14:11
0

Could be an advantage in length - though this is very unlikely to be the real motivation.

Consider that the TXT record can blow out in size to where a single UDP packet is too small. So the request is sent again in TCP and the reply is multiple TCP packets and the associated handshake setup time.

By careful use of the A and MX requests, one could get two ~1500 byte UDP replies for the SPF record, one for the A and one for the MX, as well as the remaining ~1400 bytes for all the TXT records.

This assumes you have enough authorised "things" in your SPF record to exceed 3000 bytes. Includes can also work around length restrictions but I'm hazy if they would each be a separate UDP request or a single TCP request session.

Criggie
  • 2,379
  • 14
  • 25