0

We're selling a web application that customers install on-premise or in different cloud environments. The default email setup sends email via a web service we created 15 years ago to one of our servers. The web service on our central server create emails in the IIS SMTP pickup directory for delivery. We have always warned our users that this web service is just for testing and development, but many are using it in production.

A few years ago we started getting delivery problems, so we adviced all our customers using the service to setup SPF. That helped a lot, but lately we have started to have some delivery issues again. I think the main problem now is that we're not using TLS, so Gmail for example has a question mark beside all the email from our server. I have started to look into setting up TLS, but I'm not sure how to do it correctly. If we only sent emails for one domain, it would have been easy, but we're sending emails for around 30 domains.

In tutorials I see they specify a FQDN when configuring TLS setup. But how do we do this when so many domains are sending through our server? Can I just setup a sertificate for mail.mycompany.com, and that will be used for all domains?

1

Yes, your mail server should have one canonical name e.g. mail.example.com. Ideally you'd use that name everywhere:

  • in HELO hostname & SMTP banner
  • in reverse DNS PTR record (with a matching A)
  • as the common name of the certificate.

This domain doesn't have to (and technically can't) match every domain the server is used to send email from. Such match between HELO hostname and the envelope sender or the From header simply isn't required by anyone. It's exactly the same with TLS. Not a problem!

Simply enable TLS on the part of your MTA that works as a client towards other MTAs.

With email, sending MTAs won't check the authenticity of the certificate of the receiving MTA, unless it's configured e.g. to respect DANE (RFC 6698) TLSA records; delivering the mail is typically considered more important. Furthermore, receiving MTAs doesn't check the certificate of a sending MTA at all i.e. there's no mutual authentication with client certificates. For both these reasons a self-signed certificate would be just fine, but as Let's Encrypt provides free and easy certificates for anyone, there's also no reason not to use them, instead.

Additionally, configuring the full trinity of SPF + DKIM + DMARC could increase the delivery rates even more.

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.