I am working in a small programming company and administrated the mail-servers for quite a while.
Now we moved our web site and the MTA to a company that we considered to be more professional. But I realized, that none of my emails arrived my colleagues — sometimes I got an error mail, sometimes not. The error indictated, that my SMTP server was faulty and that it need to be fixed.

Having this problem for the first time in many years, I contacted the others company's admin for some explanations:
He told me, that I send the mails with SMTP-server, that has another server name than my email address' domain name. I answered that that is absolutely legal, as I don't have SMTP-Server declared for all my accounts, but all my SMTP-server are authenticated servers, so that should be absolutely ok.
The admin responded, that this is not true, that it is absolutely common to block email, if they are send via another SMTP-server to prevent spam.
Again me: that is not common, as in many networks you have to use their SMTP-server, i.e. I know several university networks and in several countries people, citizen and foreigners, are forced by the internet providers to use special servers,...
The admin told me, that he can't understand my examples and that in my mentioned cases people are always forced to either use other mail addresses or web mailers. Additionally he wrote a mail to the person he thought of as my boss (actually we are partners), that I am telling terrible lies and would propagate securities flaws and should be fired.
Now we started to search for another company to run our servers, but I really wonder, who is right?

Should a Mailserver reject a mail, if it is send via another — but authenticated — SMTP server, or would that lead to many problems?


You should certainly look for another MSP as this admin is potentially blocking business critical emails. Sending an email for a domain that is not the mailservers domain is called Relaying. Open relays (by which anyone can send email from regardless of source) are blacklisted pretty quickly as they are often used by spammers. Nowadays relaying occurs by verifying the source IP. This allows admins to set up servers as needed (typically send only mail relays that forward to the main corporate mailserver to get mail past the firewall). The admin has some of his facts straight in that relayed mail is, in general, more likely to be suspect. A more typical response is to weight the spam headers or use greylisting. Simply blocking the mail, in my opinion, is a denial of service.

| improve this answer | |

If by 'server name' you mean HELO name or its hostname (which both should be same) then it is perfectly legal to send it through server which has it different from e-mail address domain.

For example, there is very common situation when one server (eg. mail.hoster.com) sends emails for multiple different domains (companyone.com, companytwo.com etc).

It is completely up to owner of e-mail domain to decide which servers are allowed to send emails with this domain in From: address by setting SPF records for domain. And if there are no such SPF records or if they are neutral and not restrictive then you could legally send e-mail from any SMTP server which allows it to come through.

| improve this answer | |

You're correct that there are many perfectly legitimate reasons why a mail server's reverse DNS won't match the domain of the sender. Automatically blocking all mail that doesn't match is going to generate a lot of false positives.

(I posted a longer answer to a similar question here)

| improve this answer | |

The biggest reason for blocked mail is when the PTR record (reverse dns) of the mail server's IP address doesn't match its EHLO response. (Telnet to your SMTP server, then say "EHLO localhost". The hostname in that response should match that server's reverse dns)

Whether the email's from address's host name matches is much less of an issue.

You can whitelist the mailserver for each domain by including its IP address in the SPF record of the domain.

| improve this answer | |

You ask "Should a Mailserver reject a mail, if it is send via another — but authenticated — SMTP server".

Consider this: Mailserver B wants to send mail to Mailserver A. In this context, B acts like a client. Every information given could be faked. How should A know that B did a lot of good work to prevent spammers, like authentication, virus checking? Should it trust the mail headers? Or the information it get's during smtp conversation? Not very safe.

One important verification is double-checking IP-addresses and name resolutions. A perfect match (even in the EHLO/HELO context, as others noted) is very important if you want best acceptance.

But that said this is different from the requirement of your admin that a mail addresses domain should match the hostname of the sending server. This is overdone, at least as SPF and other methods are not used by a majority. He might add some SPAM weight headers or flag otherwise but not totally reject it.

| improve this answer | |

The domain of the SMTP server does not need to match the domain of the server. If fact this is common. In fact it is rare that there is an exact match. Most mail servers domain names are at least third level domains (mail.example.com) while most email addresses are second level domains (example.net).

If you use SPF (which I do recommend), then the SMTP server should be listed as as sender for the email domain. I also recommend setting up an SPF record for the mail servers domain as well.

It is important the mail servers identity not look like it is being forged. This is done by setting up rDNS records for the IP address, and using the FQDN (fully qualified domain name) from the rDNS setup in the HELO commands issued by the SMTP server. See my article on Detecting Mail Server Forgery for more information on checking your servers setup.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.