At OnlineGroups.net, we help people to collaborate using email. That makes it pretty important that people actually receive email that is sent by their groups. Unfortunately, a lot of spam and phishing email is sent to those same people. Their email providers have to sort out the helpful collaborative email from the unhelpful email. Sometimes they get it wrong and people do not receive email from their online groups.
Listserv (aka email discussion list or mailing list) providers like ourselves send a lot of email. It is not surprising that email providers like Gmail and Outlook.com treat us with caution. It is therefore a good idea to take steps to demonstrate that our email is legitimate.
Here are six important steps that a listserv provider should take to demonstrate that it is legitimately sending email to group members.
- Make sure people opt in
- Make it easy to opt out
- Be easy to contact
- Support Reverse DNS
- Support SPF
- Support DKIM
The first three are fairly simple. The last three are a bit technical. I’ll explain each of them in turn.
1. Make sure people opt in
All spam is email people did not ask to receive. The most important thing a listserv provider can do is to make sure the people receiving the email have asked receive the email. At OnlineGroups.net, we do this by encouraging site administrators to invite people to join groups, rather than just adding them. When administrators do just-add people, we ask them to make absolutely sure that they have those people’s consent.
2. Make it easy to opt out
Even when people have opted in, sometimes they just want to get out of a listserv. A listserv provider should make it really easy to do this. At OnlineGroups.net we put an subscribe link at the bottom of every email. It is a
mailto link that allows you to send an email to the group address with the subject line
unsubscribe. If you do this, OnlineGroups.net will unsubscribe you instantly and silently. You simply will not hear from that group again.
Unfortunately, it can be hard for people to find the bottom of an email. There is often a lot of text from previous messages to scroll past. Sometimes, people email everyone in the group with the subject line
unsubscrib. If it is one of our own groups, we unsubscribe those people ourselves.
We also put an unsubscribe link such as
List-Unsubscribe:<mailto:firstname.lastname@example.org?Subject=Unsubscribe> in the email header. Some email clients, such as Gmail, use this to provide an unsubscribe link in their UI.
Ideally, we would provide a one-click unsubscribe link. Sadly, that is going to take a bit of work. You can unsubscribe from an OnlineGroups.net group from the group page, but you need to log in first.
3. Be easy to contact
Sometimes, people want to contact you. They may want to ask you to stop sending them email, or they may wish to report someone who is abusing your email system. Here are some ways to make it easy for people to contact you.
- The DNS record for your domain should contain a contact email address.
- Provide an email address such as
email@example.com your domain, specifically for complaints about abuse of your system.
- Provide a contact address in the header of all listserv emails. At OnlineGroups.net, we use a
List-Ownerheader that contains the support address for the site, like the following.
List-Owner: <mailto:firstname.lastname@example.org> (OnlineGroups.Net Support).
- Provide a support email address on the web interface for your groups.
4. Support reverse DNS
If you are sending bad email, you should try to hide your server. If you are sending good email, you should make it easy to find your server, and to confirm that you have found it. Reverse DNS helps to confirm that your email server is what it says it is.
All email servers have a URI (Uniform Resource Identifier) and an IP address. Most people prefer to type in a URI such as
smtp-1.onlinegroups.net than an IP address such as
22.214.171.124. Computers called Domain Name Servers (DNS) make sure that the URI
smtp-1.onlinegroups.net points to the server at
126.96.36.199. Reverse DNS works the other way around. It makes sure that the server at
188.8.131.52 points to the URI
Together, the DNS and reverse DNS show that there is a valid relationship between the owner of the domain name and the owner of the server using the IP address.
If your server uses multiple domains to send email, you only need to create a valid reverse DNS using one of those domains. A receiving server determines the IP address of the sending server, checks its reverse DNS and then checks the forward DNS on the domain returned.
Reverse DNS examples
An email may be relayed by a series of servers before it reaches you. Each time this happens, the server adds a
Received header to let you know what it did. The
Received header begins by identifying the server that received the email. This part looks like the following.
Received: from smtp-1.onlinegroups.net (smtp-1.onlinegroups.net [184.108.40.206])
Received: from smtp-1.onlinegroups.net ([2607:f0d0:2101:b9::2])
If your server uses both IPv4 and IPv6, its reverse DNS record must therefore include both addresses.
You can check the reverse DNS using tools such as Web DNS tools and from the command line as follows.
$ host 220.127.116.11 243.204.97.50.in-addr.arpa domain name pointer smtp-1.onlinegroups.net. $ host 2607:f0d0:2101:b9::2 18.104.22.168.0.0.0.0.0.0.0.0.0.0.0.0.9. b.0.0.1.0.1.2.0.d.0.f.22.214.171.124.ip6.arpa domain name pointer smtp-1.onlinegroups.net
5. Support SPF
If you are sending bad email, you should try to pretend that you are sending it from someone else’s domain. If you are sending good email, you should make it easy to check whether or not an email has come from one of your servers. Sender Policy Framework (SPF) is a way to specify the mail servers that are authorised to send email from your domain.
An SPF record is part of the DNS record for a domain. It contains a list of the IP addresses of servers that are authorised to send email from that domain.
An email server connects to another email server using its IP address and receives an email with a MAIL FROM address in the message envelope (this address can be referred to as the HELO address and appears in the message header as the RETURN-PATH). The receiving email server can check the SPF record of the domain in the envelope MAIL FROM address. If that SPF record contains the IP address of the server it is connected to, then the receiving server can be confident that the sending server is authorised by the owner of the domain.
If your email server uses both IPv4 and IPv6, then your SPF record must contain both addresses.
On a regular OnlineGroups.net site, all group email addresses end in
@onlinegroups.net (even if the site uses a subdomain for its web address). This means that the SPF record for the domain
onlinegroups.net will be valid for all the groups on these sites. OnlineGroups.net customers can add a custom domain to their site. Groups on sites with custom domains all use the custom domain in their email address. This means that sites with a custom domain (or subdomain) must add an SPF record containing the IPv4 and IPv6 addresses of our mail server.
You can check the presence and validity of an SPF record with this SPF record testing tool or by requesting the
TXT DNS record as follows.
$ host -tTXT onlinegroups.net onlinegroups.net descriptive text "v=spf1 ip4:126.96.36.199 ip4:188.8.131.52 ip4:184.108.40.206 ip4:220.127.116.11 ip4:18.104.22.168 ip4:22.214.171.124 ip6:2607:f0d0:2101:b9::2 ?all"
Here is an example of the header field in an email that shows that the SPF test passed for an email sent from the group with the address
email@example.com to the address
Authentication-Results: mx.google.com; spf=pass (google.com: domain of firstname.lastname@example.org designates 126.96.36.199 as permitted sender) email@example.com
6. Support DKIM
DKIM is a further means of proving that an email comes from where it says it comes from. It proves that an email has not been interfered with since it was sent, and allows a listserv provider to claim responsibility for the email it sends. DKIM is the email equivalent of the air travel security question “did you pack your own bags”?
A mail server that supports DKIM adds a signature to outgoing email. That signature is made by processing the contents and some headers of the email with a private key. The signing server publishes a public key that can be used to check whether the email really was signed by that server. The server receiving the email uses the public key to check that the signature matches the applicable parts of the email. If it is valid, the receiving server knows that the email has not been altered since it was signed.
The signing server does not have to use the same domain that the email uses.
As almost all listservs change one or more headers as it processes the email, the DKIM signatures on incoming email will all be invalid. It is OK to leave them intact as they will be counted as non-existent as long as there is one valid signature in the header.
Here is a DKIM signature from the header of an email signed by onlinegroups.net.
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=onlinegroups.net; s=mail; t=1407461250; bh=ILHLaEmedNNmU1d9XaPRACcqhmR6GB/KLlRLkcDlxek=; h=In-Reply-To:References:Date:Subject:From:To: Reply-To:List-Id:List-Post:List-Subscribe:List-Unsubscribe: List-Help:List-Archive:List-Owner; b=ErZpfCcgiahOJwdiHx2Nwz+zrsQ0ZudJ99hKfeUtW9Mn8Ntzh6S38e2DFd 6gZdexqOLE/Ilc6W0ZnFbszra0HusgJ6rC4mJCjlrBJN/On0Ct3JqfFjsx FlDjiA7K/ynSkZ86Xhv77LVCsM8aIx02zBAoujd4UiQvbSDnfh+p3GQ=
Here is an excerpt from the
Authentication-Results header field that shows that the DKIM signature was passed as valid.
Authentication-Results: mx.google.com; [...] dkim=pass firstname.lastname@example.org