Guide To Mail Server Configuration

TXT (TYPE 16) or SPF (TYPE 99) Records types in DNS

Please note: SPF (TYPE 99) is now obsolete

When the standard was introduced, your SPF record was stored as a TXT record (TYPE 16). In 2005, a new standard was introduced, SPF (TYPE 99). Originally SPF was created to supersede the original TXT record. However, mail servers reverted to the original TXT record and SPF (TYPE 99) became obsolete.

Now, even though SPF (TYPE 99) is obsolete, it’s still recommended to have the records present. If your Authentication String contains both TYPE 99 and TYPE 16, you’ll be considered “SPF-Compliant”. If you only have TYPE 16, you’ll be considered “Compliant”.

DomainKeys (DKIM)

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

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

How do DomainKeys work?

{
  "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 to the 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

SPF Unaligned Email Identifier Alignment Example

Below is a sample header from an email. Pay attention to the domain highlighted in blue.

Return-path: <mailtest@"example.com">
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
      d=zerobounce.net; s=secure;
      h=from;
      bh=o3fu6xyRMvsfFmwnP6/SlW7vJ99RrE0ChDczpE+HayQ=;
      b=ODihl0g56Upldz3ETsFkFlY5EyPNJecpftbJxQHaBzHVOOzqpr0NaJTEBZ3aOLOR0
      piHemvHGHtVtEM0jH0RUJ2MG22gEuUnXA8No6mqgJEs47P/9APKG45SVy7O1XNpK7
      2dzD8iGgb4aguGwvYMO1lrsv+I7Wtj0J+Ev98b4Xg=
Received: from [168.144.32.46] (VPS9517.ad3.softcom.biz [168.144.32.46])
      by mail.zerobounce.net with SMTP;
      Sun, 8 Jul 2020 23:53:06 -0400
Subject: Your Email Authentication Results
Date: Sun, 08 Jul 2020 23:53:06 -0400
From: "ZeroBounce" <mailtest@"zerobounce.net">

If the two sections highlighted in blue domains don't match, this is considered to be SPF Unaligned Compliance.

DKIM Unaligned Email Identifier Alignment Example

Below is a sample header from an email. Pay attention to the domain highlighted in blue.

Return-path:
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
      d="example.com"; s=secure;
      h=from;
      bh=o3fu6xyRMvsfFmwnP6/SlW7vJ99RrE0ChDczpE+HayQ=;
      b=ODihl0g56Upldz3ETsFkFlY5EyPNJecpftbJxQHaBzHVOOzqpr0NaJTEBZ3aOLOR0
      piHemvHGHtVtEM0jH0RUJ2MG22gEuUnXA8No6mqgJEs47P/9APKG45SVy7O1XNpK7
      2dzD8iGgb4aguGwvYMO1lrsv+I7Wtj0J+Ev98b4Xg=
Received: from [168.144.32.46] (VPS9517.ad3.softcom.biz [168.144.32.46])
      by mail.zerobounce.net with SMTP;
      Sun, 8 Jul 2020 23:53:06 -0400
Subject: Your Email Authentication Results
Date: Sun, 08 Jul 2020 23:53:06 -0400
From: "ZeroBounce" <mailtest@"zerobounce.net">

If the two sections highlighted in blue match exactly, it's considered to be DKIM Unaligned Compliance.

Is DMARC Needed?

So why are we mentioning DMARC?

DMARC (Domain-based Message Authentication, Reporting and Conformance) includes optional tags, which will help mail servers validate your messages to a higher standard. ADKIM and ASPF are the tags which represent the alignment mode for DKIM and SPF. They can have two values: "r" for relaxed and "s" for strict. Please see the tables below for Pass/Fail scenarios:

Relaxed Alignment

Strict Alignment

How to Set Up Your Abuse Contacts

The Network Abuse Clearing House (http://www.abuse.net runs and maintains an abuse contact database. Here, an owner of a domain can register their abuse email contact info. If a person receives abusive, harassing, or SPAM emails, they can access the database and find the appropriate address of the offending domain’s abuse contacts.

How do I add my domain to the database so people can alert me of any abuse?

Email "update@abuse.net" with the subject line of "Please Add My Contacts", then in the body of the email include the following information.

Then send it off. Check the website for updated abuse contact info within a few hours of sending the email.

How do I look up the abuse contact for a domain I'm experiencing abuse from?

Feel free to use the Abuse.net lookup tool: Abuse.net Contact Lookup

How to Set Up Your Author Domain Signing Practices (HISTORIC)

What is ADSP?

Author Domain Signing practices (ADSP), is an optional extension used in DKIM authentication. ADSP was developed to prevent a 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 server could treat the email as suspicious, and assign a higher spam score. If the record is marked "discardable", the receiving email 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".

PTR Records (Reverse DNS Lookups)

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 by the 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, and why is it important?

Last Sending IP Address (LSIP) refers to the last IP address to “handle” and send your email towards it’s intended recipient. It’s important that you set up an rDNS record for this domain, and that this IP is the same IP used in Sender ID checking 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 need to initiate the request. Secondly, if your server’s domain is something similar to mail.exampledomain.com, then you’ll need to 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.

DKIM Signatures (DomainKeys Identified Mail)

DomainKeys Identified Mail (DKIM) is an authentication method created to detect email spoofing. It allows for the Receiving Mail Server to check that the email it received has been sent by the domain’s owner. It does this by attaching a digital signature to each outgoing email, that is linked to a specific domain name. This is checked by the receiving system against the public key in DNS.

Example of a DKIM Signature

DKIM-Signature: v=1; a=rsa-sha256; d=example.net; s=secure;
c=relaxed/simple; q=dns/txt; t=1117574938; x=1118006938;
h=from:to:subject:date:keywords:keywords;
bh=MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=;
b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ
          VoG4ZHRNiYzR

The table below parses out the DKIM-signature presented above.

How do I set up my DKIM Signature?

Once you’ve set up your DomainKeys, you’ll be setting up your DKIM signature in your email server software. Most, if not all, of modern email software will allow you to enable DKIM signatures and establish basic configs.

If your email software does not include DKIM capabilities, we recommend switching to a more modern software package. This’ll ensure you have access to all of the modern email standards.

Sender ID (SIDF) Historical

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.

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.

Diagram of How Sender ID Works

DMARC Record Example

What is a DMARC Record, and how important is it?

Domain-based Message Authentication, Reporting & Conformance (DMARC) is an email authentication protocol that aims to stop or reduce email spam and phishing attacks. The DMARC specification essentially extends existing email authentication using SPF or DKIM. So email receivers who have applied DMARC, will experience more constant authentication.

Much like SPF, DMARC allows the domain owner to publish their policy and the receiving server can then check the validity of the record. However, unlike SPF, DMARC also includes instructions on what to do with any messages that fail authentication.

DMARC essentially extends the functionality of SPF and DomainKeys Identified Mail (DKIM). It allows the admin of a domain to publish a policy in their DNS records. Then, they can specify which authentication protocol (SPF, DKIM or both) is used when sending emails from that domain. Also, the admin can specify a reporting procedure, Authentication Failure Reporting Format (AFRF), for actions performed under those policies.

DMARC Record Example

Here's an example of a DMARC record we use at www.zerobounce.net:

"v=DMARC1;p=none;pct=100;rua=mailto:email@domain.com;ruf=mailto:email@domain.com;"

The code above in detail

Now you’re more likely asking, "How do I set my _DMARC Record up?" That's the easy part. You can just utilize our free DMARC record generator tool.

Generate and test your DMARC Record

Navigate over to our DMARC Generator and begin by filling out the questionnaire. After your DMARC record is created, you’ll receive instructions on how to add it to your DNS.