0

Firstly, i'm not a mail expert! My workplace owns the domain example.com, until recently we had an application hosted on the LAN that worked fine and sent emails from [email protected] to various internal and external recipients using smtp configuration on the application.

Recently we moved this application to an externally hosted AWS at remote.com. Now the emails aren't being received (bounce backs mostly). Presumably this is because remote.com isn't authorised to send emails on behalf of our domain?

The AWS remote host advised that we needed to update our example.com SPF record to include the remote host IP and everything should work as expected.

The remote AWS is one single fixed IP, and one server.

The issue is, our internal mail team has advised us that adding a single IP to our example.com SPF record isn't something they want to do as it's a security vulnerability. The explanation they provided was;

Setting up a SPF record that permits a third party, over which we have no control, can send as ‘us’ is the antithesis of Cyber Security. It is not what SPF is intended for. There is a trend for software suppliers to say "Just set up a SPF record" so that they don’t have to bother setting up email properly.

As far as they concerned, no other server / IP should be mentioned in a SPF record for our example.com domain.

I'm not sure how accurate / reliable this is but it's the response we got. I'm not a mail or cyber security expert but, looks like we can't use SPF?

What other options do we have if we want to send mail from remote.com, with a from mail address of [email protected]? Preferably a solution that doesn't impact our security, and will be trusted by recipients (not end up in spam / junk etc.)

Improve this question
0

3 Answers 3

Reset to default
4

Setting up a SPF record that permits a third party, over which we have no control, can send as ‘us’ is the antithesis of Cyber Security.

This opinion is not held by the general cybersecurity community. And it is not "the antithesis of Cyber Security". Cybersecurity is about risk management, not binary yes/no pronouncements.

It is not what SPF is intended for.

Actually, it is. SPF's design intent is to allow mail-emitting hosts to identify as a sender. It's not about protecting a single domain and a single, in-house set of email servers. The defining document for SPF even has a section just for allowing 3rd party mailing services.

It is normal and expected to add IPs of authorised email servers to a domain's SPF record. Adding the IPs of bulk mailing services, ISPs, marketing services, or even partners happens all the time.

Yes, there is a slightly increased risk that the 3rd party sender might do something malicious, but that's not an increased risk over any other activity.

Improve this answer
6
  • 2
    +1. To add to what @schroeder said WRT Setting up a SPF record that permits a third party, over which we have no control, can send as ‘us’ is the antithesis of Cyber Security... - if this was taken literally, then no company would outsource their mail to hosted mail services like gmail, outlook, amazon ses, etc. I just did an SPF lookup for NSA.gov, and I see that the NSA includes amazonses.com in their SPF. Somebody better notify the NSA ASAP about this 'antithesis of Cyber Security' that they are committing!
    – mti2935
    Aug 27, 2021 at 12:23
  • 2
    I would have respected the security team so much more if they had simply said, "we've assessed the risks and allowing any 3rd party to send under our identity is beyond the company's risk tolerance". I might not understand their decision, but I could respect it. What they did respond with was just nonsense.
    – schroeder ♦
    Aug 27, 2021 at 12:41
  • 2
    I agree, that would have been a much more reasonable response. To make a blanket statement stating that an SPF record pointing to a third-party mail provider is the 'antithesis of cybersecurity' is laughable, and this calls into question the credibility of whoever said this. I just did SPF lookups of a half-dozen or so large tech companies, and almost all have SPF records that point to third-party mail services. Crowdstrike and Checkpoint are among them.
    – mti2935
    Aug 27, 2021 at 12:49
  • These are all really useful comments, thanks so much for taking the time to post and do the SPF lookups - I didn't think to so this! Everyone's comments make a lot of sense and are very logical, unlike the people I am trying to convince! I'll go back with some more evidence that it's not a security issue and SPF is in fact supposed to work like this.
    – TheOrdinaryGeek
    Aug 27, 2021 at 14:08
  • As an expert in the email security space specializing in anti-spam, phish detection, and spoofing technologies, I have to say that I agree with the sentiment that there is risk in using SPF for shared servers because if one is compromised, an attacker can send mail as you. That's why DKIM is preferable—at least it's less likely to be DMARC-aligned. I wouldn't go as far as to say that it's an "antithesis of Cyber Security" though.
    – Adam Katz
    Aug 27, 2021 at 19:18
4

One solution to your issue is to send your mail through your main mail host (the one that is listed in your SPF record) instead of using the local SMTP relay on your server.

You will have to get credentials for an account that can send mail on behalf of your sender address, configure your software to work as an SMPT client (instead of as a server) and use these credentials to do that but that will most likely solve your SPF issue (it might also help you with DKIM at the same time).

Edit Just to make clear: this is a way to solve your problem. @schroeder is 180% right about the way the answer from your security team is incorrect and shouldn't be accepted

Improve this answer
1
  • 2
    This question is a tough one, because the security part of the answer is just a pure /*head-desk/* but the "what are my options" part is actually just a simple server config answer. So, you are also 180% correct that this is an option to accomplish the goal.
    – schroeder ♦
    Aug 27, 2021 at 12:39
1

Setting up a SPF record that permits a third party, over which we have no control, can send as ‘us’ is the antithesis of Cyber Security. It is not what SPF is intended for.

Oh dear. More security idiots. That is exactly the type of situation SPF is designed to address.

If they are allowing the application to be hosted on elsewhere but not sending email they are failing in their role.

If it is the security policy to restrict mail sending to a specific zone - then that is something different from what you have said here. If that is the case and they have not provided a mechanism or at least a design framework to support routing of the mail via that zone, they are failing in their role.

But knowing they are incompetent does not resolve your issue.

We can spend all day criticizing them and coming up with other solutions. But that's a waste of our time and yours. You need to ask them to propose a solution.

Improve this answer

You must log in to answer this question.

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