0

I have been reviewing my company's SPF record with a number of our SAAS providers. One service advised me to use 'include:amazonses.com' in my record to allow emails to be validated.

I am rather hesitant in allowing Amazon's service API to be allowed in the record. Is this not delegitimizing the purpose of SPF or am I arguing an authentication technology that was never prepared for Cloud driven services?

If they gave me companyx.amazonses.com I would be a tad more interested in including this.

What prevents a spam bot (minus the cost factor) from utilising these services with any one company's domain, effectively invalidating any SPF records?

wildshane
  • 1

2 Answers2

1

... or am I arguing an authentication technology that was never prepared for Cloud driven services?

SPF is not really an authentication technology. It does not authenticate who is sending the mail but only limits from which IP addresses the mail can be sent from and thus tries to limit misuse of your domain as the claimed sender of spam and phishing.

If they gave me companyx.amazonses.com I would be a tad more interested in including this.

There is no reason to believe that this would be more safe just because the company name is included in the domain name. The real question is which IP addresses are covered by the SPF (i.e. allowed to send mail for this domain) and one might simply set this "company record" to be the same as the global amazonaws record.

If you use the cloud to send mail you are usually doing this to profit from its advantages, i.e. flexibility, scalability, fault tolerance, low latency due to geographic routing etc. But, to implement these advantages it might be necessary to have lots of IP addresses and be flexible in which tasks are assigned to which IP address.

This means that the IP address might be an overly broad trust anchor when using cloud infrastructure. Instead or additionally you should rely on system specific instead IP specific restrictions. This can be done using DKIM where the outgoing mail system signs the mail and the recipient can check that it was actually signed by the mail system belonging to the sender. Both of DKIM and SPF can be combined with DMARC for even better protection against misusing your domain name for spamming and phishing.

In short: don't complain that SPF is insufficient and not designed for the cloud. Instead use DKIM and DMARC in addition to SPF.

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • Thanks for the details Steffen. I'm sorry you got the wrong context for my question. It is not that I find SPF something to complain about. It is quite the contrary, I endeavour to utilise SPF as efficiently as possible and my understanding of its purpose had me 'disgruntled' with a vendors response. Not being an expert on the matter I am seeking further details regarding this. Your information indeed helped with that. – wildshane Aug 16 '17 at 06:16
  • You are right in saying that the subdomain is somewhat superfluous. I get that the same underlying IP could be utilised, hence my previous comment of a technology (albeit simply an approval sheet) not fit for cloud delivered services. My grievance with this is typically a vendors lack of alternative email validation methods (DKIM and DMARC). – wildshane Aug 16 '17 at 06:24
  • 1
    @wildshane: *My grievance with this is typically a vendors lack of alternative email validation methods (DKIM and DMARC).* - that's actually the real problem. But, if you need SPF don't rely on services where everybody can setup their own mail server on the same IP address or use an existing mail server to send mails with a faked sender. It does not matter if there are lots of IP addresses. What matters instead is that lots of others could use the same IP as origin of their mails and that they are able to fake the sender. – Steffen Ullrich Aug 16 '17 at 06:24
0

I agree with you. An overly broad SPF record is a much bigger risk than, as you say, companyx.amazonses.com

This email service company appears to be putting all their clients at risk by recommending this. I would look for another service provider.

Sas3
  • 2,638
  • 9
  • 20
  • Ok so it isn't that I was missing something. I just wanted to validate that what I was considering insecure was in deed that. Now I will go back and demand a better-resolved name. :) – wildshane Aug 16 '17 at 03:31