You'd have to ask the developer of SPF. Years ago, when it was first released I spent a few hours in a seminar where the developer told us why we should use it. I never saw it as a an anti-spam solution, because many spammers can and do create spf records. While it could be an anti-spam solution now, since spammers tend to use bots for whom they really can't create spf records, it's still not.
Why? Let's continue ...
It's better at identity assurance. Why? Because you can use it to see if the email was actually sent by an authorized server.
However...
Let's look at your question as to why you can't just use a or mx to indicate an approved sender.
Well, for several reasons:
First of all, let's look at what an mx record points to. An mx record points to a server authorized to receive email for a domain. Which isn't necessarily a server authorized to send email for that same domain. For example, large businesses, educational institutions, and ISPs all use completely separate servers, at different IP#s, for mail receiving and sending. So mx records often do not point to servers authorized to send email. I'd argue that a majority of the mx records on the Internet point to servers not authorized to send email. A records? Perhaps a bit better, though we'd all admit that a lot of A records don't point to servers authorized to send email (or in fact to have anything to do with email at all).
And then there are those of us who send email, even email with return addresses at our own domain, through our ISPs. We can never reasonably indicate in an SPF record which servers and only which servers, are authorized to send email for our domains. We could include MX records, but don't forget that for most ISPs those are NOT servers authorized to send email. Or we could include A records, knowing that only a small percentage of the A records used by our ISPs to point to servers authorized to send email.
You'd have to ask the developer of SPF. Years ago, when it was first released I spent a few hours in a seminar where the developer told us why we should use it. I never saw it as a an anti-spam solution, because many spammers can and do create spf records. While it could be an anti-spam solution now, since spammers tend to use bots for whom they really can't create spf records, it's still not.
Why? Let's continue ...
It's better at identity assurance. Why? Because you can use it to see if the email was actually sent by an authorized server.
However...
Let's look at your question as to why you can't just use a or mx to indicate an approved sender.
Well, for several reasons:
First of all, let's look at what an mx record points to. An mx record points to a server authorized to receive email for a domain. Which isn't necessarily a server authorized to send email for that same domain. For example, large businesses, educational institutions, and ISPs all use completely separate servers, at different IP#s, for mail receiving and sending. So mx records often do not point to servers authorized to send email. I'd argue that a majority of the mx records on the Internet point to servers not authorized to send email. A records? Perhaps a bit better, though we'd all admit that a lot of A records don't point to servers authorized to send email (or in fact to have anything to do with email at all).
And then there are those of us who send email, even email with return addresses at our own domain, through our ISPs. We can never reasonably indicate in an SPF record which servers and only which servers, are authorized to send email for our domains. We could include MX records, but don't forget that for most ISPs those are NOT servers authorized to send email. Or we could include A records, knowing that only a small percentage of the A records used by our ISPs to point to servers authorized to send email.
Of course you could argue that you could include only the A records of your ISP's actual mailservers authorized to send email, but then if your ISP changes the name of it's mailserver you're still out of luck.
If you've read the above carefully, and stopped for even a moment to analyze what I've written, then you realize why SPF records can't even guarantee authenticity of the sender with any real authority.
Maybe at some point in the future, with a new record type in DNS, and universal acceptance (ha!), but certainly not now.
I've never loved SPF. I worked with DirectAdmin staff to get it working because it's important (only because a lot of recipients do use it) but I've never implmented scoring based on SPF in SpamBlocker (you're free to do it yourself) because I don't believe it'll do enough to make it worthwhile.
Jeff
Of course you could argue that you could include only the A records of your ISP's actual mailservers authorized to send email, but then if your ISP changes the name of it's mailserver you're still out of luck.
If you've read the above carefully, and stopped for even a moment to analyze what I've written, then you realize why SPF records can't even guarantee authenticity of the sender with any real authority.
Maybe at some point in the future, with a new record type in DNS, and universal acceptance (ha!), but certainly not now.
I've never loved SPF. I worked with DirectAdmin staff to get it working because it's important (only because a lot of recipients do use it) but I've never implmented scoring based on SPF in SpamBlocker (you're free to do it yourself) because I don't believe it'll do enough to make it worthwhile.
Jeff
