An open mail relay is a Simple Mail Transfer Protocol (SMTP) server configured in such a way that it allows anyone on the Internet to send e-mail through it, not just mail destined to or originating from known users. This used to be the default configuration in many mail servers; indeed, it was the way the Internet was initially set up, but open mail relays have become unpopular because of their exploitation by spammers and worms. Many relays were closed, or were placed on blacklists by other servers.

Until the 1990s, mail servers were commonly intentionally configured as open relays; in fact, this was frequently the installation default setting. The traditional store and forward method of relaying e-mail to its destination required that it was passed from computer to computer (through and beyond the Internet) via modems on telephone lines. For many early networks, such as UUCPNET, FidoNet and BITNET, lists of machines that were open relays were a core part of those networks. Filtering and speed of e-mail delivery were not priorities at that time and in any case the government and educational servers that were initially on the Internet were covered by a federal edict forbidding the transfer of commercial messages.

In the mid-1990s, with the rise of spamming, spammers resorted to re-routing their e-mail through third party e-mail servers to avoid detection and to exploit the additional resources of these open relay servers. Spammers would send one e-mail to the open relay and (effectively) include a large blind carbon copy list, then the open relay would relay that spam to the entire list. While this greatly reduced the bandwidth requirements for spammers at a time when Internet connections were limited, it forced each spam to be an exact copy and thus easier to detect. After abuse by spammers became widespread, operating an open relay came to be frowned upon among the majority of Internet server administrators and other prominent users. Open relays are recommended against in RFC 2505 and RFC 5321 (which defines SMTP). The exact copy nature of spam using open relays made it easy to create bulk e-mail detection systems such as Vipul's Razor and the Distributed Checksum Clearinghouse. To counter this, spammers were forced to switch to using hash busters to make them less effective and the advantage of using open relays was removed since every copy of spam was "unique" and had to be sent individually.

Since open mail relays make no effort to authenticate the sender of an e-mail, open mail relays are vulnerable to address spoofing.

Many Internet service providers use Domain Name System-based Blackhole Lists (DNSBL) to disallow mail from open relays. Once a mail server is detected or reported that allows third parties to send mail through them, they will be added to one or more such lists, and other e-mail servers using those lists will reject any mail coming from those sites. The relay need not actually be used for sending spam to be blacklisted; instead, it may be blacklisted after a simple test that just confirms open access.^{[better source needed]}

This trend reduced the percentage of mail senders that were open relays from over 90% down to well under 1% over several years. This led spammers to adopt other techniques, such as the use of botnets of zombie computers to send spam.

One consequence of the new unacceptability of open relays was an inconvenience for some end users and certain Internet service providers. To allow customers to use their e-mail addresses at Internet locations other than the company's systems (such as at school or work), many mail sites explicitly allowed open relaying so that customers could send e-mail via the ISP from any location. Once open relay became unacceptable because of abuse (and unusable because of blocking of open relays), ISPs and other sites had to adopt new protocols to allow remote users to send mail. These include smart hosts, SMTP-AUTH, POP before SMTP, and the use of virtual private networks (VPNs). The Internet Engineering Task Force (IETF) has written a best current practices covering Email Submission Operations in RFC 5068.

Note that the above only becomes an issue if the user wishes to (or has to) continue to send e-mail remotely, using the same SMTP server which they were previously accessing locally. If they have valid access to some other SMTP server from their new, remote location, then they will typically be able to use that new server to send e-mails as if from their old address, even when this server is properly secured. (Although this may involve some reconfiguration of the user's email client which may not be entirely straightforward.)