The email server is a central communication hub for your company. It needs to be protected and secured against spam, but also you must be sure that your emails are correctly delivered to your recipients and not rejected or tagged as spam by other platforms like Google Apps, Outlook 365, etc.

Around an Email Server, you have always methods to verify the emails are not sent by a spam host, like SPF, DKIM, DMARC, rDNS: This is what we will talk. In all probability if you do not configure properly all of these authentication methods your email will be refused. For the impatient, they can check now and see what they have to configure: go to https://www.mail-tester.com and send an email to the address given (only three free tests per day). Think to remove your smarthost sender if you have one configured.

It is easy to install and create a mail server with nethserver, but you must configure the DNS zone of your domain name in the settings of your public DNS provider, we want to detail all the mandatory DNS records. This settings are really important it is likely the phone number of your server. As a side note, the DNS is not relevant of the email server, it is used by all services which need to be reachable on internet.

The first step of an SMTP session is the exchange of HELO command (or EHLO). This command takes a valid server name as required parameter (RFC 1123).

NethServer and other mail servers try to reduce spam by not accepting HELO domains that are not registered on a public DNS.

When talking to another mail server, NethServer uses its full host name (FQDN) as the value for the HELO command. If the FQDN is not registered in public DNS, the HELO can be fixed by setting a special prop. For instance, assuming myhelo.example.com is the publicly registered DNS record, type the following commands:

config setprop postfix HeloHost myhelo.example.com
signal-event nethserver-mail-common-save

This configuration is also valuable if the mail server is using a free dynamic DNS service.

DNS or Domain Name System is a system that points a domain name to physical IP address. For example, when a user types in www.domain.com in their browser and hits enter, the DNS servers resolve it to the IP address where the website is hosted.

The purpose of DNS is to use easy to remember domain names for websites instead of their numeric IP addresses. It also enables website owners to change their web hosts without changing domain names. Website owners can simply change the DNS entry for their domain name and point to their new web host’s name servers.

All settings must propagated to all DNS server of the world, it needs time to be known by all. So be patient and wait 24 hours after you have changed your records. By experience we know that the google DNS are really quick to be updated, then you can check after them what are the saved records (wait some minutes)

An A record matches up a domain (or subdomain) to an IP address. In other words, it points your domain name to your nethserver’s IP address, which allows web traffic to reach your Nethserver. This is the core functionality of DNS. A typical A record looks like the following:

domain.com     A       12.34.56.78

You must create a 'A' record of 'domain.com' directed to the Internet IP of your server.

This is an example at 1&1

ask to google

set A record YourDnsProvider

The domain must be tested

• Web tools

https://mxtoolbox.com/DNSLookup.aspx

• In the terminal

Google is used, else remove @8.8.4.4

# dig +short A sub.domain.com @8.8.4.4
164.132.xxx.xxx

Nethserver creates several sub domain by default to be reached from outside or internally (check /etc/hosts), you have to declare them to your (external) public DNS provider and creates for each one a 'A' record with the internet IP of your server. This is not relevant to your email server, but generally for all services running on your server and needing to be reachable on the internet.

At minimal you must create these sub.domains and set the 'A' records to the internet IP of your server

serverName.domain.com
smtp.domain.com
mail.domain.com
www.domain.com     #nothing related to a mail server, but for a web server

Optionaly you can also create and assign, but they are less used

imap.domain.com
pop.domain.com
pop3.domain.com

For example :

prometheus.domain.com       A       12.34.56.78
smtp.domain.com             A       12.34.56.78
mail.domain.com             A       12.34.56.78

ask to google

set A record YourDnsProvider

Each subdomain must be tested

• Web tools

https://mxtoolbox.com/DNSLookup.aspx

• In the terminal

Google is used, else remove @8.8.4.4

# dig +short A sub.domain.com @8.8.4.4
164.132.xxx.xxx

MX record is abbreviation for Mail Exchanger record. It is a type of DNS resource record that defines a mail server to handle email for a particular domain name. For example, by adding an MX recorded to mail.domain.com for your domain.com, any email received by your domain.com will be handled through your mail servers.

The MX record is checked if there is a mail server (MX Record) behind your domain name, often spam sender do not have it properly configured. The MX record(s) must be added to your public DNS provider.

Create a MX record for domain.com :

A typical MX record looks like the following:

domain.com         MX      10  mail.domain.com.
mail.domain.com    A           12.34.56.78

This is an example at 1&1

ask to google

set MX record YourDnsProvider

• Web tools

https://mxtoolbox.com/

• In the terminal

Google is used, else remove @8.8.4.4

# dig +short MX  domain.com @8.8.4.4
    10 mail.domain.com.

One part of the spam hunt is mostly based on the IP/domain reputation, but also on the check of specific DNS records. If you plan to send your email by a smarthost, like the smtp of your internet service provider, you do not need to follow the below section. This section is if you want to send your email by your server directly.

The domain you use for sending your emails, like domain.com in toto@domain.com, has its reputation. The reputation depends on many factors.

For instance, it’s important how old is the domain. In fact, for the first 5 days after a new domain was registered, it is by default considered as suspicious. After all, reputation is something you can only earn over time. So it’s good to warm up all the emails on such a fresh domain by sending just a few emails per day during the first 2-3 weeks after the registration.

Good reputation of your domain increases the deliverability of your emails. That’s why it’s important to have it checked through blacklists and fix all the DNS records you will read below, then test your domain score by http://mail-tester.com/ (3 free tests per day)

How to interpret the score you get?

• Obviously, the closer you get to 10, the better. 10 should be the goal you pursue and fight for.
• 9-8 is a good score, but take all the hints Mail-Tester gives you into consideration to improve that.
• 7-6 is acceptable, but some strictest providers may block some of your emails.
• You should never go with 5 or below.

There’s a reputation of your email server IP. Sometimes, the IPs you get from your your server provider have already some reputation – good or poor. That’s why it’s crucial to check your email server IP before you start sending.

If your mail server has been blacklisted, some email you send may not be delivered. Email blacklists are a common way of reducing spam. Blacklists are Commonly called Realtime blacklist, DNSBL or RBL and save a list of spammer sender used to blacklist domain. You should test your IP/domain name time to time.

• Web tools

https://mxtoolbox.com/blacklists.aspx
http://multirbl.valli.org/lookup/

The reverse DNS (rDNS) resolution is a determination of the domain name that is associated to an IP. Some email companies will reject any email that doesn’t have a valid rDNS. The process of reverse resolving an IP address uses PTR records.

serverName.domain.com ==> 98.25.65.23
conventional DNS resolution

serverName.domain.com <== 98.25.65.23
reverse DNS resolution

In the Public DNS of the ISP provider or in the setting of your server hosting provider. It is different for each case. A tip, it is close where you bought the IP. You need to create a PTR record and to assign the valid FQDN of your server

This is what it looks at soyoustart

Ask to google

set PTR record YourIpProvider

• Web tools

You can check if your reverse DNS is well configured with the https://mxtoolbox.com/ReverseLookup.aspx by filling the IP of your server.

• In the terminal

Google is used, else remove @8.8.4.4

# dig +noall +answer -x 164.132.xxx.xxx @8.8.4.4
216.77.xxx.xxx.in-addr.arpa. 21599 IN	PTR	serverName.domain.com.

You can check also by comparing this two commands in the terminal

/usr/bin/dig @1.1.1.1 +short +tries=1 +retry=0 +time=2 -x publicIP
reverseIP.
/usr/bin/dig @1.1.1.1 +short +tries=1 +retry=0 +time=2 reverseIP.
publicIP.

the reverseIP. found must match the publiIP retrieved in the second command line.

Sender Policy Framework (SPF) is a simple email-validation system designed to detect email spoofing by providing a mechanism to allow receiving mail exchangers to check that incoming mail from a domain comes from a host authorized by that domain's administrators.

The list of authorized sending hosts for a domain is published in the Domain Name System (DNS) records for that domain in the form of a specially formatted TXT record.

Email spam and phishing often use forged “from” addresses, so publishing and checking SPF records can be considered anti-spam techniques.

All you have to do is in the DNS zone of your domain name. This is a list of examples following your DNS provider.

add a record 'TXT' to the DNS zone of your domain name with

"v=spf1 a:serverName.domain.com mx:mail.domain.com ip4:164.92.21.18/32 ~all"

serverName.domain.com and mail.domain.com must be valid sub domains

this is what it looks at 1&1

SPF can be configured in different ways, since neutral to hard fail. Almost 98% of domains are using the ~all (softfail) that means even if something of the SPF entry is wrong against the source Mailserver, mark the mail only like softfail. Here, the complete table to understand the feature all in the SPF

Parameter     Result 	 Means
+all 	      pass 	 Permits all the email, like have nothing configured.
-all 	      fail 	 Will only mark the email like pass if the source Email Server fits exactly, IP, MX, etc. with the SPF entry.
~all 	      softfail   Allows to send the email, and if something is wrong will mark it like softfail.
?all 	      neutral    Without policy

If your domain is under an SPAM attack trying to spoofing your domain, try to change the SPF to -all for a while, and reset to ~all when the attack ends. Keep selected the -all if you want to be strict with the SPF entry and you are sure that your DNS entry is correct.

• mail-tester.com
• smtp2go.com

• Web tools

https://mxtoolbox.com/spf.aspx

• In the terminal

Google is used, else remove @8.8.4.4

# dig +short TXT  domain.com @8.8.4.4
"v=spf1 a:serverName.domain.com mx:mail.domain.com ip4:158.145.89.254/32 ~all"

Domain Keys Identified Mail (DKIM) is an email authentication method designed to detect email spoofing. It allows the receiver to check that an email claimed to have come from a specific domain was indeed authorized by the owner of that domain. It is intended to prevent forged sender addresses in emails, a technique often used in phishing and email spam.

In technical terms, DKIM lets a domain associate its name with an email message by affixing a digital signature to it. Verification is carried out using the signer's public key published in the DNS. A valid signature guarantees that some parts of the email (possibly including attachments) have not been modified since the signature was affixed. Usually, DKIM signatures are not visible to end-users, and are affixed or verified by the infrastructure rather than message's authors and recipients. In that respect, DKIM differs from end-to-end digital signatures.

Dkim is really simple with NethServer, go to the email panel and allow DKIM in the setting of your domain, then retrieve the digital key of this domain. Then this key must be saved in a TXT record in your (external) public DNS provider.

DKIM needs to be configured in the public DNS. You must create a TXT record 'default._domainkey' or 'default._domainkey.domain.com' in the DNS zone of your provider. Your DKIM selector is default

default._domainkey.domain.com  3600	IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxmWXIuDlgrSvnEIDetpSJC/pyt/Ru9xHv2cpjXnrTyxXuiuebkVyapwwh+mY1+I++g7vjBQ/3eWtr0iYJNE6QnH7B4sSdOqoMd+qDLSQlfiUEaQUDTZfLfGC+51CH8Ic72CxfqQeks/TM/iEbAMqIZGXyGNWI1GaCj5fb8Id5teLWMbxEdTnWxv0Fi+PtEcEevDBZDUuJk1/dQ1VTH04rQVy5If5XlPq91ACqyXomdqDGBcmC5B9mLcm/adfqIZB/vR5y4hW761cwYJCBIdO2njd1pRN4b/sRi9khAEyBhjJAHSbuocLw+ha2YJiCb0R2gOHHSjEBQuqgGu7fkr5+wIDAQAB;"

This is an example at 1&1

• smtp2go.com

• Web tools

https://mxtoolbox.com/dkim.aspx

keep in mind that your selector is default

• In the terminal

Google is used, else remove @8.8.4.4

# dig +short TXT  default._domainkey.domain.com @8.8.4.4
"v=DKIM1\; k=rsa\; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnDHXY9axEEi2mNiPJarErUkCdnuCIo3pLidherVt+6z6NHrB/Fwc2BWwK97qH9APzbo4cBhm/wtbXAiRnNlcTBMkG4P4lm09a/dR6spVsJ72QMrr+V5M04sLQ+76Ru4K6Pj4iyHJmBlAvORS3v4tpoZgXipi4o9qmbPvcT7JzXucICZ6q5gSKuyQRrKlZKL55" "TR7GWTCJ6VVLhbis74HlMNWfwjhJmcz3z1zMnNKHsDSaQfLplDBi5c3gZFG8hJ7mBVA1fGZHD4SeDv5mSYQrBgFT5Hgij67eSmYtZ5GcMPyn7q3aobCDXHvWVTFQD1x5SNIJohYTBuPQ7SfRNs17QIDAQAB\;"

Domain-based Message Authentication, Reporting and Conformance (DMARC) is an email-validation system designed to detect and prevent email spoofing. It is intended to combat certain techniques often used in phishing and email spam, such as emails with forged sender addresses that appear to originate from legitimate organizations. Specified in RFC 7489, DMARC counters the illegitimate usage of the exact domain name in the From: field of email message headers.

DMARC is built on top of two existing mechanisms, Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM). It allows the administrative owner of a domain to publish a policy on which mechanism (DKIM, SPF or both) is employed when sending email from that domain and how the receiver should deal with failures. Additionally, it provides a reporting mechanism of actions performed under those policies. It thus coordinates the results of DKIM and SPF and specifies under which circumstances the From: header field, which is often visible to end users, should be considered legitimate.

see an example of configuration : https://www.dmarcanalyzer.com/how-to-create-a-dmarc-record/

Add a TXT record to your domain _dmarc.domain.com with the following value:

v=DMARC1; p=none

Only the v (version) and p (policy) tags are required. Three possible policy settings, or message dispositions, are available:

    none – Take no action. Log affected messages on the daily report only.
    quarantine – Mark affected messages as spam.
    reject – Cancel the message at the SMTP layer.

Here's a more complex DMARC entry for the test domain DMARC site:

v=DMARC1; p=quarantine; rua=mailto:reports@dmarc.site; ruf=mailto:reports@dmarc.site; adkim=r; aspf=r; rf=afrf

• The “p” option has three options: none, quarantine, or reject, for how email that violates policies should be handled
• The adkim and aspf options define how strictly DKIM and SPF policy should be applied, with 's' indicating strict and 'r' indicating relaxed
• The RUA provides an address for aggregate data reports, while the RUF provides an address for forensic reports

• Web tools

https://mxtoolbox.com/dmarc.aspx

• In the terminal

Google is used, else remove @8.8.4.4

# dig +short TXT  _dmarc.domain.com @8.8.4.4
"v=DMARC1\; p=none\;"

(Here for consideration, the project is quite new)

Authenticated Received Chain (ARC) is an email-authentication system designed to allow an intermediate mail server like a mailing list or forwarding service to sign an email's original authentication results. This allows a receiving service to validate an email when the email's SPF and DKIM records are rendered invalid by an intermediate server's processing.

DMARC allows a sender's domain to indicate that their emails are protected by SPF and/or DKIM, and tells a receiving service what to do if neither of those authentication methods passes - such as to reject the message. However, a strict DMARC policy may block legitimate emails sent through a mailing list or forwarder, as the SPF check will fail due to the unapproved sender and the DKIM signature will be invalidated if the message is modified, such as by adding a subject tag or footer.

ARC helps to solve the problem of the SPF and DKIM signatures being invalidated by giving the intermediate server a way to sign the original message's validation results. Even if the SPF and DKIM validation fail, the receiving service can choose to validate the ARC. If the ARC indicates that the original message passed the SPF and DKIM checks and the only modifications were made by intermediaries trusted by that receiving service, the receiving service may choose to ignore the failed SPF, DKIM, or DMARC validation and accept the email anyway. It's up to each receiving service to decide which intermediaries to trust.

ARC is currently a draft standard with the IETF

https://dmarc.org/presentations/ARC-Overview-2016Q3-v01.pdf

https://dmarc.org/presentations/ARC-Status-March-2017.pdf