Configuring SMTP Relay

Email has never been as simple as most people think it is. But if you need to connect a cloud application or an office photocopier to your organization email, SMTP relay can be pretty easy to set up--if you know how!
EXTRA CREDIT:
- SPF is only one of the two ways used to validate an email's source. The other method is DKIM. That's typically set up on the central mail server, so relaying through your organization's server allows the correct signature to be added.
- SPF and DKIM together are used as part of DMARC, which allows your organization to tell others how to deal with any email that claims to be from your organization but doesn't pass the validation checks.

[@TheWhiteRose-JunaidButt]

you have a wonderful personality you should make more videos teaching

[@NextDoorNetAdmin]

Thank you! I definitely plan to keep going. :)

[@JavierDiaz-zh2jo]

Hi,
Comcast and some other ISPs are blocking port 25, and the SMTP authenticators will be removed from Office 365. Do you know how to get around this port 25 issue?

[@NextDoorNetAdmin]

I do! Use a business connection. :)
Not to be glib about it, but residential connections often have port 25 blocked in order to combat spam being sent from unaware customers infected with malware. Customers accessing their remote email accounts will usually use a different port--sending directly to port 25 (with or without STARTTLS) is indicative of a server-to-server (relay) connection.
Conversely, since a business connection is expected to be running business applications (including email servers), all ports are generally left unblocked. Since you would need a static IP to add into the SPF record to permit the relay, that's also something typically available on a business connection.

[@JavierDiaz-zh2jo]

@@NextDoorNetAdmin Sorry to say, Comcast in Florida is blocking port 25, even for businesses (which is why I asked). Many companies are dealing with this. To get around it, I set up an SMTP relay server with postfix. It connects to Office 365 using TLS and an account with SMTP authentication enabled.

[@NextDoorNetAdmin]

@@JavierDiaz-zh2jo Ouch! That boggles my mind, honestly. Business connections should be unfiltered, in my mind--it's one of the main reasons to even get a business connection in the first place!
I'm going to guess that switching ISPs is likewise not a feasible option. If so, then I would honestly next look at ways of proxying the connection. First thing I would try is probably setting up an SSH tunnel to another endpoint where port 25 isn't blocked. If you had a way to SOCKSify the outbound connection, so much the better--you could use dynamic port forwarding instead of local port forwarding. But I'm afraid that I don't have a ready-made solution at hand for that problem... just ideas that would need more work.

[@TheTF01]

If there are multiple public ip that need to be added, because of multiple locations, would you just add all of them to the spf record? Also, does that not create some other security concerns public the companies public ip on the spf record?

[@NextDoorNetAdmin]

@TheTF01 Every IP address that needs to be allowed to send mail does need to be added... but there's different ways of doing that, depending on the exact circumstances. If they're just single IPs that aren't connected to each other, you can use multiple ip4: entries. If the IPs can be summarized into a CIDR range, you can also enter that. (Example: "ip4:192.168.2.36/30")
Does it create a security concern? I don't think it does. For one thing, there's nothing saying that these IP addresses belong to your company. Let's say you have a rule sending all outbound email to a third-party service that adds a signature. (My company does this!) You need to add the third-party service to your SPF record, and they'll typically have documentation telling you what you can put in (it's usually an "include:service.com" entry). But you could just as easily put in the actual IP addresses if you wanted, and it would work the same way.
The actual SMTP headers on the email message also include a record of all the machines the email has passed through (using SMTP), including their IP addresses, from start to finish. This not only reveals the sender's IP address (if they used SMTP), but all servers along the mail path. This is standard because it helps to diagnose mail flow issues, as well as allowing things such as SPF to function correctly. And it's been that way since the very beginning of email!
As a general security rule, you never want to rely on "security through obscurity"--keeping things safe by keeping them secret. You definitely want to make sure you have a firewall to protect the network, whether you publish the external IPs in an SPF record or not. And if you do have a firewall in place, I think any additional security risk created by an SPF record is minimal, if not negligible.