Guide to Mail Server Configuration

Getting started with DomainKeys

DomainKeys is a deprecated email authentication protocol developed by Yahoo. It was created to verify the message integrityfrom any given sender’s domain name.

DomainKeys was superseded by the DomainKeys Identified Mail (DKIM) email authentication method. Even though this standard is obsolete, many mail servers (old and new) still use it, and if you have the option, you should implement it.

Published Standard: RFC 4870

https://www.ietf.org/rfc/rfc4870.txt to find more details about Published Standard: RFC 4870

How does DomainKeys work?

To better understand how DomainKeys works, take a look at this example of a DomainKey below:

{
  "Status": 0,
  "TC": false,
  "RD": true,
  "RA": true,
  "AD": true,
  "CD": false,
  "Question": [
    {
      "name": "zb._domainkey.zerobounce.net.",
      "type": 16
    }
  ],
  "Answer": [
    {
      "name": "zb._domainkey.zerobounce.net.",
      "type": 16,
      "TTL": 299,
      "data": "\"v=DKIM1"; "k=rsa";
      "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAjxHiM+LhOfpCTgqZCnmZgX8S0766oDeOx2XkVJqqxMQgCp4CNqzGBLMk/wc2wwWYAsSI5tSW6vSTigkYwA2Y73Ufhc4c1GGpp8oN/d+OJqTNHIqJO4fk7RvTryJbfG8IxFNKefTMMVdcVZcElqGNiflpC5PgbJmk9cNMVcAxiBgYNmg8ofmjIHX8MvbMr3tN/A2XRacZtpvlukrHwJYnRzb1gK7W0l/7QEh/Ad8uIQa/fSaf9oWWnEk7caA7aKRMln/heayxP42XfXMfsBGXGN8ZkrPtevXkmECl21LYKwP+rlEtxS55vK5cgJjtFPI2ooAxRfkQlh1W9CediWXEzwIDAQAB"
    }
  ],
  "Comment": "Response from 162.159.0.218."
}     

As you can see in our record, the public key starts with “p=” and our encryption method is denoted by “k=”. Assuming that your email software is DomainKey enabled, your private key is used to generate a digital signature. This is embedded in the headers of your emails. In order for your email to be delivered tothe recipient’s inbox, the public key and digital signature must match.

What’s a DomainKeys Policy Record?

When you use DomainKeys, you can publish policy statements in DNS that help email receivers understand how they should treat your email. There are three main statements that can be published:

"t=y" - Which means that your email DomainKeys are in test mode.
"o=-" - All email from your domain is digitally signed.
"o=~" - Some email from your domain is digitally signed.
"n=*" - n stands for notes. Replace the * symbol, with any note you like

How to set up a DomainKeys policy record

To set your DomainKey, you’ll have to enable this through your email software. This feature is usually built-in, but in order to enable it as described above, you’ll have to do the legwork. Please note: if your email software lacks this functionality, it may be time to switch over to a new one.

If your email software requires that the RSA Keys be generated separately, add the private key to itself and the public key to your DNS.

How do I look up my DomainKeys records?

You can check your DNS, for free, by using the Google DNS Tool: Google Public DNS Tool: https://dns.google.com/ to find more details about Google Public DNS Tool

Mail servers use two different methods when determining SPF and DKIM: strict and relaxed. In the example below, you’ll see that the FROM address uses zerobounce.net as the domain. This is compared to "return-path (enveloped-sender)" for SPF or the "d=" tag in the domain signature for DKIM.

What are Author Domain Signing Practices (ADSP)? (HISTORIC)

What is ADSP?

Author Domain Signing Practices (ADSP), is an optional extension used in DKIM authentication. ADSP was developed to preventa malicious sender from misrepresenting themselves as the legitimate author of an email.

ADSP was approved as a standard RFC 5617 in August 2009, but declared "Historic" in November 2013.

Currently, there are three possible outbound signing practices:

If the record is set up with "all" or "discardable", then the FROM field is meant to be originating from your mail servers. If you use something like Gmail or Outlook to send mail, then your ADSP DKIM policy will be set to "unknown"

So, what’s the difference between "all" and "discardable"? If the policy is marked as "all", then the receiving mail servercould treat the email as suspicious, and assign a higher spam score. If the record is marked "discardable", the receivingemail server will discard the message if it’s not signed properly by the domain.

How to set up an ADSP Policy

1. Set up your DKIM How to set up your DKIM Signature.
2. Publish a DNS TXT resource record type for your domain in the following format:

_adsp._domainkey.{subdomain}.domain.example If your domain email has sub-domain emails, you will simply replace the {subdomain}.

• For example "user@blogs.domain.com" would have a key that looks like this: _adsp._domainkey.blogs.domain.com
• But, most commonly, most domain owners have emails like "users@domain.com" and that will look like this: _adsp._domainkey.domain.com

Depending on the policy you wish to enforce, you can set the record to "dkim=all", "dkim=discardable", or"dkim=unknown".

What are PTR records?

Reverse DNS lookup, or reverse DNS resolution (rDNS) are more commonly known as PTR records. Essentially, they map an IP address to a domain/host. It’s the reverse of the A record in IPv4 and the AAAA record in IPv6.

So, if they’re like A records (but in reverse) why are they important? PTR records are used by SPAM filters. Usually, spammers send out emails with spoofed domain names. However, they may not have the correct PTR record set up in DNS. If this is the case, the emails are blocked from being received by the intended recipient.

Why you should avoid using generic PTR records

Generic PTR are records used by most hosting companies. They use what appears to be a random string, alpha-numeric sequence, or a repeating pattern. Something along the lines of 123-123-123-123.your.isp.com.

Many spam filters will look up your PTR record to determine if it matches one of many known generic strings. If you have not set your PTR record and you instead rely on the one provided by your hosting company, you run the risk of being flagged bythe spam filter. To prevent this, your PTR record should be unique and usually take on the form of "mail.domain.com".

Keep in mind, only your outgoing mail servers or last sending IP address (LSIP) need to have a rDNS PTR record.However, we recommend setting up a PTR record for all MX records and IP’s you have.

What is LSIP

Last Sending IP Address (LSIP) refers to the last IP address to “handle” and send your email towards it’s intendedrecipient. It’s important that you set up an rDNS record for this domain, and that this IP is the same IP used in Sender IDchecking and SPF.

How do I set my unique PTR record?

Firstly, you’ll need to contact your ISP to set up your PTR record. This is something they’ll do for free, but you’ll needto initiate the request. Secondly, if your server’s domain is something similar to mail.exampledomain.com, then you’ll needto request your ISP to set up the rPTR record. To do this you’ll need to provide them with the IP address of your server.

PTR Record Checker

You can check to see if your mail server has a PTR Record set up by using our lookup tool: PTR Record Lookup Tool

How to add a Sender ID (HISTORIC)

Sender ID, also known as SPF2.0 (Historical), was originally built to expand on the original SPF protocol. The intent was to provide superior protection against phishing and domain spoofing by verifying the email senders. Currently Microsoft holds patents to several components within Sender ID, and still utilizes it within their Exchange Server.

Sender ID Standard: RFC 4406 and RFC 4407

https://www.ietf.org/rfc/rfc4406.txt find more details about Sender ID Standard: RFC 4406 and RFC 4407
https://www.ietf.org/rfc/rfc4407.txt find more details about Sender ID Standard: RFC 4406 and RFC 4407

The majority of unwanted or malicious emails contain headers that were modified to hide their identity/point of origin. SPF and Sender ID are almost identical in syntax. Where they do differ is in how the receiving mail server looks up the message’s authentication record. The authentication record is a line of code implanted in your DNS, that appears in your email message headers.

SPF examines the domain from the envelope’s return-path address (5321-FROM), typically called the bounce address. Sender ID examines the Purported Responsible Address (PRA), known as 5322-FROM, that is, the visible sender address in the message. Thus, Sender ID provides better protection against those phishing scams and domain spoofing we mentioned earlier.

Sender ID is almost identical to SPF, except that v=spf1 is replaced with one of the following:

How does Sender ID work?

• You send an email message.
• The recipient email server receives your message.
• The recipient email server checks the SPF Record of the sending domain and determines that it's a match.
• If the IP address and SPF record of the sending server matches the mail is delivered.