SPF is a bolt-on technology designed to try to limit the ability to spoof so as such it is not mandatory anywhere. The latter point could be argued, particularly with the large players increasingly using it but that is the position from an RFC perspective.

Mail servers will always (okay in 99% of cases) attempt local delivery if the domain is defined as it determines it is authoritative for that domain by virtue of it being defined. Historically this made sense, why go to the 'expense' of DNS lookups if you know you host the domain by definition. 

To resolve your immediate issue setup the domain the user wants to send from in SM but configure the 'Inbound Message Delivery' as 'External (Use MX)'. This will let the user authenticate, you can lock down so they can only send from the domain or the specific address within the domain. Importantly, if they send an email n to their own domain (or someone else on the same SM box does) then it will be delivered to their real MX. 

Addressing your question as to why a mail server does not check if it is allowed to send by checking SPF that is a good question. As already mentioned it is not part of the standard so is not inherently there. Also, the SM mail server that hosts your mailboxes does not necessarily have to be present in the SPF record - assuming you are routing outbound email via a gateway, in which case that Internet facing gateway would need to be listed. So, with this quick example you can see it could be problematic in certain scenarios.

However, we implement such a feature on our Exim mail gateways in tandem with having to specifically authorise the domain. The reason for doing this is not so much as an ACL but simply to ensure clients have setup and maintained the correct SPF record as a lack of SPF or invalid SPF can damage the reputation of a sending IP with the big players.

So I would +1 it as a feature within SM but it may be something that is configurable, i.e. perhaps have the option of validating the IP(s) of the SM server against the SPF record and/or the presence of a specific 'include' which would infer the same valid nature in your environment.

I host about 130 domains on my main MX, and don't want to have to add those to my bulk email server, too.

Yes, a setting that could say 'look at the SPF' or something just as simple.

You need to add your originating server to the server whitelist on the bulk messaging server.  (System admin... Gear [icon]... Security... [Whitelist] tab... [New] button.   This will allow messages coming from the originating server, and destined for the Internet, to pass through without authentication.

Historically, open relays have been a huge problem.   Server A (domain A) finds Server B (domain B) on the Internet.  Then Server A sends a message to Server B addressed for domain C.   Server B sees that the message is not for domain B, so it sends it on its way to the server for domain C.    Of course, the message is malicious, which is why Server A wants Server B to take the blame.

The solution is closed relays -  by default, systems only accept unauthenticated SMTP messages from remote servers for locally hosted domains.    Authenticated users are allowed to send messages to both locally hosted domains and remote domains.  

Whitelisting an IP address is an alternative form of authentication.   Your second server is functioning as an outgoing gateway for these messages, so whitelisting the source server makes the most sense.   Conceptually, the second server is relying on the first server to have performed authentication before forwarding the message, so the second server does not need to repeat the authentication process.

SPF would apply if the messages were addressed to a domain on your second server.   Since this is not the case, it does not apply.

Hope this clarifies things,

Doug

Hi Doug. I think you may misunderstand my situation. The bulk email server is used by my webserver for SMTP duties. The issue is in attempting to send From: a domain that is not present on the bulk server, but *is* present on my main email server (ie; this is a customer sending a bulk email from their website who wants to use their domain as the From). I have an SPF record for every domain I host, indicating the bulk email server is authorized to send emails on that domain's behalf.

My problem comes in because the bulk email server fails to see the domain locally. The domain is present on the main email server, but not on the bulk email server. I'd prefer not to duplicate the domains on the bulk server as that's a pain and a potential licensing issue.

My ask is if a new y/n setting could be added to instruct the bulk email server to do a quick SPF lookup if the domain isn't local before failing it for relaying.

Over the weekend I noticed an issue where SM failed an outgoing email because the sending server (my web server) didn't have a PTR record. So.... SM *does* check DNS? But doesn't look at SPF?

It checks incoming which from your web server to SM box is correct. However, it only checks to reject not as a means of deciding whether to send or or not which was your original question.

This was an email my web server was trying to send out through my bulk email server. The bulk email server was checking whether the IP number of the issuing entity (my web server) had a valid PTR. It didn't, so it refused to send.

This would be the same instant in which checking if the email domain is valid to send as well, by also looking at the DNS for an SPF record.

Just a thought. Could be a switch. Could be an industry changer. People will make t-shirts in commemoration of this sea change in how mail servers work.

[ahem... best movie promo narrator voice...]   IN A WORLD, where email servers refuse to send emails for domains they don't have the authority to send for...

in a world, where spammers don’t just install an older version of software to get around said fix. In a world where people upgrade their mail server software to incorporate new said features.

Those with spf are already protected on incoming mail. For example, PayPal has spf records, so even if I start pumping out email from our server as paypal.com, most email won’t make it to the destination or will be flagged as junk. 

I stand by my original comment, because you said you are getting a relay error, and that is a term with very specific meaning.

Then these rules apply

SMTP AUTH can be satisfied with login credentials or IP whitelist.  Login credentials are appropriate when the source system is a client device submitting a message to its local mail server.   Whitelisting is appropriate when the source system is a mail server forwarding a message through an outbound gateway.