根据这篇 ArsTechnica 文章，在邮件服务器上使用自签名证书是一个坏主意：
当我们在上一个系列中设置 Web 服务器时，建议使用 SSL/TLS 工作，但这是可选步骤。但是，对于本指南，它绝对不是可选的：您的邮件服务器必须有一个有效的 SSL/TLS 证书。这里的“有效”是指“由公认的证书颁发机构 (CA) 颁发”，而不是自签名的东西。 使用自签名证书向其他邮件服务器识别您的邮件服务器是让其他邮件服务器拒绝传递您的邮件的好方法。然后你的邮件服务器会很孤单，因为没有其他服务器愿意与它交谈，这将是可悲的。你不希望你的服务器伤心，是吗？
这是真的吗？其他邮件服务器真的会拒绝与使用自签名 SSL 证书的邮件服务器交互吗？如果有，有哪些？还是几乎所有常见的邮件服务器都是如此？
您可以使用自签名证书。
根据我多年的经验，我的邮件服务器上的自签名证书从未遇到任何问题。我最终切换到一个由StartSSL签名的版本，并且在互操作性方面没有明显差异。
另请参阅ServerFault 上的这篇文章。
底线是，STARTTLS 是关于加密，而不是身份验证。虽然它可以被锁定以执行身份验证，但大多数（如果不是全部）SMTP 服务器的默认设置是机会加密。SMTP默认是明文的，需要加密多于认证，因此重点突出。
可以锁定连接 - 例如，我看到 Ironport 配置为需要由它喜欢的已知 CA 签名的有效证书（在这种情况下，它喜欢 Entrust 但不喜欢 Comodo，所以我们最终更改了证书，因为这比调试别人的 Ironport 更容易）。但这是为了锁定希望确保合作加密的特定域，我从未见过有人使用机会加密来做到这一点。
使用 SSL 加密包括以下步骤：
您通常使用加密，因为您认为任何人都可能会监听连接。这种被动侦听的一小步是主动操纵 SSL 也可以检测到的连接。但是为此它需要正确识别您的对等方，否则中间的任何人都可以声称是正确的服务器。
使用自签名证书是不可能进行正确识别的，因为任何人都可以使用与您相同的凭据创建这样的证书。这意味着没有人应该单独信任自签名证书。如果它可以使用另一种方式验证它，它应该只信任自签名证书。这种其他方式可以是服务器端的手动配置（通常不是这种情况，除非发件人直接知道收件人）或通过DANE验证证书，其中域的所有者在受信任的 DNS 记录中提供他们的证书或指纹（需要DNSSec）。
服务器在检测到不受信任的证书时实际执行的操作有所不同：有些会接受证书并写入verify=NO邮件的 Received 标头，而另一些可能会拒绝使用 SSL 连接，因为他们认为连接不安全并降级为纯文本或根本不连接. 这取决于发送服务器的设置。
目前，大多数邮件服务器可能会成功连接到其他服务器，即使它们无法验证其证书。但是，越来越多的人使用“真实的”（可验证的）证书。如果您比较 Facebook 从2014 年5 月到2014 年8 月的报告，您会发现可验证证书的使用率在短短 4 个月内从 30% 上升到 95%。这意味着，在不久的将来，更多服务器可能需要使用真实证书。
这意味着，使用由知名 CA 签名的证书肯定比使用自签名证书更好。但即使这样也可能无法提供您想要实现的安全性。操作系统信任的第 100 个 CA 中的任何一个都可以颁发这样的证书，因此攻击者也可能会尝试为您的域获取证书。但这至少比创建另一个自签名证书要困难得多，因为攻击者需要破解 CA 或以某种方式控制您的邮件域，以捕获 CA 在识别过程中使用的邮件。
主动中间人的另一种攻击是通过攻击 DNS 重新路由邮件：要将邮件从发送邮件服务器路由到负责您的域的服务器，发送服务器需要进行 DNS 查找对于您的域的 MX 记录，其中包含您的邮件服务器的名称。发送服务器附近的主动攻击者可以攻击此 DNS 查找并提供指向其自己服务器的虚假 MX 记录。TLS 在这里不再有帮助。相反，您必须使用 DNSSec 来保护您的 DNS 记录，并且发件人必须验证此记录。
除此之外，TLS 不为邮件提供端到端的安全性，只是逐跳。介于两者之间的任何邮件服务器都可以访问普通邮件，因此需要完全信任。要获得端到端加密，您需要使用 S/MIME 或 PGP。正因为如此，一些服务器管理员根本不关心正确的 TLS，因为即使正确实施，TLS 也不会为邮件提供真正的（端到端）安全性。
使用受信任方的公钥验证证书的真实性。证书欺骗者可以在他们制作的任何证书中输入他们想要的任何数据，但不能使用受信任方的私有（签名）密钥对证书进行签名，因为他们没有它。当受信任方的 pub 或您喜欢的验证密钥用于错误的私有（签名）密钥时，签名将被视为伪造。
到目前为止，这对于 CA 签名或自签名证书没有什么不同。
然而，在公钥的分配中出现了问题。这就是证书“权威”擅长的地方，因为他们似乎可以更安全地将其公钥分发给更多人，只需将其安全地发送给愿意在其应用程序中安装它的相对少数关键应用程序提供商，例如： '浏览器供应商'，邮件服务器提供商等。确定是他们发送它。因此，他们用来验证他们自己签名的公钥“肯定”是他们的，并且可以安全地用于检查他们是否真的签署了某些东西。即证书。
如果自签名者可以安全地分发他们的公钥，也就是说，以用户确定它是他们的方式分发它，那么他们的签名，因此他们的自签名证书，即使不是更好，也同样好，考虑到他们的身份更好与任何 CA 一样，通过密钥分发而不是 CA 证书请求者身份验证来保证。
在这种情况下，问题变成了如何安全和成本（或时间）有效地将您的 pub 密钥分发和安装到其他邮件服务器上，如果有什么驱使您这样做，无论是更好的安全性、CA $upport 厌恶还是其他一些是值得的。
这不再是真的了。一些电子邮件服务器开始验证所提供证书的信任链，如果不通过则拒绝连接。这可以防止发送和接收电子邮件。
在我们的例子中，我们使用的是 mailgun，并且在他们的配置界面中有一个小开关，默认情况下需要接收服务器具有正确的证书。