Advance Your Skills:
Sign Up for a Free Email Course
Get the Latest News:
Subscribe to the LISTSERV at Work Newsletter
Advance Your Skills:
Sign Up for a Free Email Course
Get the Latest News:
Subscribe to the LISTSERV at Work Newsletter
LISTSERV Tech Tip |
By Jacob Haller
Senior Support Engineer, L-Soft
Almost since the beginning, email service providers have been concerned about abuse, spam and forgery. This has led them to become increasingly strict about what types of emails to accept and what messages to classify as possible spam or reject altogether.
There are many best practices that can help prevent your email from being blocked or flagged as spam. In this tech tip, we'll address some DNS-related protocols that have been developed to help mail servers determine that LISTSERV has permission to deliver the mail that it sends. Specifically, we will discuss SPF, DKIM and DMARC policies and how to set them up for your LISTSERV site and to verify that they are working.
All of these will require your DNS administrator to create or update DNS entries for the LISTSERV domain. DKIM will also require special configuration of LISTSERV itself (SPF and DMARC do not require this).
Before we talk about how to implement SPF, DKIM and DMARC, let's describe their purpose and what they do.
SPF (Sender Policy Framework)
An SPF policy is published as a DNS "TXT" record, which provides a mechanism to allow receiving mail exchangers to verify that incoming mail from a domain comes from an IP address authorized by that domain's administrators. The SPF protocol is designed to detect and block email "spoofing".
DKIM (DomainKeys Identified Mail)
DKIM allows LISTSERV (or any other mail service) to sign a message in a way that will allow recipient mail servers to verify that the message was sent by LISTSERV, and that it has not been modified in any important way since leaving LISTSERV. Setting this up will require both a special configuration in LISTSERV, and a special DNS "TXT" record that the recipients' mail servers can use to verify that the DKIM signatures were generated by LISTSERV.
DMARC (Domain Message Authentication Reporting & Conformance)
DMARC is an email authentication, policy and reporting protocol that builds on existing SPF and DKIM records. Like SPF and DKIM, DMARC is becoming another must-have tool for email reputation and successful delivery to many major ISPs. Moreover, federal agencies in the United States are now required to comply with the US DHS Binding Operational Directive (BOD) 18-01, which mandates the implementation of DMARC for all federal agencies.
For most of this tech tip, we will be assuming that your organization accesses and edits their DNS entries via an online web application such as cPanel. If you host your own DNS service, then see the appendix at the end of this tech tip.
In online domain managers, adding new records is usually as simple as clicking on a link to add new records. For instance, in one major ISP's cPanel domain manager, clicking "Add" presents the following:
To create any of the DNS entries described, you would pick the record type (generally TXT for these types of records) and continue from there.
In most cases, when creating a new DNS record, you should be aware that your ISP has already accounted for your base domain name (e.g., "example.com") and you should not include the base domain name in the "Host" fields of the DNS webgui editor. For instance, in the SPF record example in the next section, if you were to enter "listserv.example.com" in the Host field, the created DNS record would be for "listserv.example.com.example.com", which is not what you want. The same caveat applies to all of the various records being created below. Assuming that the LISTSERV server's name is listserv.example.com, you would use:
This type of address is known as an "unqualified" address since it is not "qualified" with your domain name. The DNS system in most, if not all, cases has already been set up to qualify your hostnames, and it is rarely, if ever, necessary to type in the entire fully qualified address (also known as an FQDN, or "fully qualified domain name").
The SPF TXT Record
To begin creating the TXT record you need for SPF, choose the "TXT" type in the drop-down box.
Using the example provided above, this form will be filled out as follows:
The TXT value can in theory be quite complicated, but in practice, when used for a LISTSERV server's domain, it is usually relatively simple. If LISTSERV has its own small set of servers that it uses to send its mail, then you can just list the IP addresses of those servers:
|
v=spf1 ip4:1.2.3.4 ip4:2.3.4.5 -all |
'v=spf1' indicates that this is an SPF policy and must be at the beginning of all SPF records. 'ip4:' indicates that this is an IP address (specifically, an ipv4 address) and is followed by an IP address that external mail servers will be getting LISTSERV's mail from. You can have as many 'ip4:' parts of an SPF record as you like. The '-all' at the end indicates that messages from this domain that fail SPF should be rejected.
Alternatively, if LISTSERV is using your organization's normal mail system to send its mail, and your organization already has published an SPF record, then the LISTSERV domain can just piggyback off that:
|
v=spf1 include:example.com -all |
Here, 'include:example.com' tells external mail servers to look at the example.com domain's SPF record.
As previously noted, more complicated policies are possible, so if you are in a situation where neither of the above types of records will quite meet your needs, then you can find more information at: http://www.open-spf.org/SPF_Record_Syntax/
After creating the record, your DNS portal may prompt you to take further action to update your zone file. If so, follow those instructions.
Once the record is created, you can check to see that it looks good using the 'nslookup' command, which should be available from a command line on Windows, Unix or Mac OS. To check the SPF record for listserv.example.com, for instance, you would type:
|
nslookup -type=txt listserv.example.com |
And you should see the SPF record in the response:
|
> set type=txt |
Setting up DKIM involves creating a key, configuring LISTSERV to use it and setting up a DKIM TXT selector record in DNS. This is documented in the LISTSERV Advanced Topics Manual, and most of what you will do is described there. However, I do want to specifically talk about setting up the DKIM TXT selector.
This works similarly to adding the SPF TXT record, except that the text that you will be adding is a lot longer. When you generate the keypair as described in the Advanced Topics Manual, the public key will look something like:
Note that this is all supposed to be one single line that doesn't break.
To create the DKIM TXT selector record, start another blank TXT record in the domain manager, and fill it out. Because the unqualified name of the example host is "LISTSERV", the "Host:" field will contain the special value "default._domainkey.listserv". If the unqualified name of your host is something else, like "LISTS", that value would be "default._domainkey.lists".
Again, the TXT value is all one line without breaks. So it will look like this in the editor:
You can see that the values have overrun the visible text box limits; that's OK, the information is all there. Save, and you'll see something like this:
Again, if you are prompted to take further action to update your zone file, do so.
As with SPF, you can use nslookup to check the record after it's created:
|
nslookup -type=txt default._domainkey.listserv.example.com |
Which should return the record that you created:
|
Server: google-public-dns-a.google.com |
As noted, the key above is only an example, and you would use the key that you created as described in the Advanced Topics Manual.
In most cases, for the LISTSERV domain, a very simple DMARC policy should work fine. Using the sample domain given previously, the entry would look like:
The "Host:" field is similar to that of the DKIM policy record, but uses "_dmarc" instead of "_domainkey". Note that the underscore before "dmarc" is required.
The "TXT Value:" field contains the DMARC protocol version and the policy to be applied to DMARC lookups. The value that we've provided above means that the protocol is in "monitoring" mode without any reporting. If a more stringent policy is desired, please refer to the DMARC Website for details.
Save this record:
As with SPF and DKIM, you can use nslookup to check the policy. The command would be along the lines of:
|
nslookup -type=txt _dmarc.listserv.example.com |
And should return the policy that you set up:
|
Server: google-public-dns-a.google.com |
In addition to the nslookup commands given above, LISTSERV has its own deliverability assessment page, which will tell you whether various DNS-related entries are set up correctly, including SPF and DKIM. To access this, click on "Server Administration > Deliverability Assessment" in the main menu. Enter this information:
MXToolBox.com also has tools that can be used to check the SPF and DMARC records for a domain and verify that they don't have any syntactical problems.
Some freemail sites (gmail.com and outlook.com are two that I use) will record what they're seeing in DNS for messages they receive in the message's full headers, and this can be useful to verify that SPF, DKIM and DMARC are set up correctly and to track down problems if they aren't. Information on how to view the full headers in different email programs and services can be found at: https://mxtoolbox.com/public/content/emailheaders/
If you run your own BIND DNS and prefer to add the records to your zone file manually, that will look like this (again, using our sample host listserv.example.com as above, and adding records to your example.com zone file):
|
; A record |
We've used a one-hour (3600 second) TTL in our examples. The actual value to use for TTL is up to you. Additionally, if you prefer to use a different format for your zone file records, then that is also fine.
LISTSERV is a registered trademark licensed to L-Soft international, Inc.
See Guidelines for Proper Usage of the LISTSERV Trademark for more details.
All other trademarks, both marked and unmarked, are the property of their respective owners.
