Check DNS MX records' configuration and the corresponding mail servers.

Tests are based on the following standards:

• RFC 2821
• RFC 821
• RFC 5321
• RFC 2142

List domain's MX records.

Mail exchanger (MX) records of a domain name specify how emails should be routed with the Simple Mail Transfer Protocol (SMTP). It's a type of resource record in the Domain Name System which specifies the mail servers responsible for accepting email messages on behalf of the recipient's domain.

The purpose of multiple MX records:

• Provide a backup MX that can be used if the primary one is unavailable
• Provide some load balancing by using multiple MX records with the same preference

Check MX records and the corresponding Mail Server's configurations.

Check if A records are configured for all the mail servers. This is required to be reachable via IPv4.

Check if AAAA records are configured for all the mail servers. This is required to be reachable via IPv6.

Retrieve CNAME records and check if they don't contain mail servers.

RFC 2181, section 10.3: host name should be mapped directly to one or more address records (A or AAAA) and should not point to any CNAME records.

RFC 1034, section 3.6.2: if a name appears in the right-hand side of RR (Resource Record) it should not appear in the left-hand name of CNAME RR, thus CNAME records should not be used with NS and MX records.

Syntax check Exchange fields: should contain valid domain names. Mail servers with bad Exchange fields are unreachable.

Mail servers should have public IPs to be reachable over the Internet. If a mail server has a private IP address, it can't be reached outside it's subnet.

MX records's Exchange fields should contain valid domain names, IP addresses are not allowed.

An IP address could not be used as it would be interpreted as an unqualified domain name, which cannot be resolved (RFC 1035).

Request all the domain's Name Servers in order to compare the MX records returned. All the name servers should return identical MX records.

All the mail servers should be defined only once.

It's recommended that mail servers point to different IPs. When an unreachable IP hosts multiple mail servers, multiple mail servers will be down. This rule is not applicable to Google's mail servers.

Compare domain's TXT records against the SPF record pattern and check if SPF is configured.

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.

RFC 7208 defines Sender Policy Framework as a "proposed standard".

Compare domain's TXT records against the DMARC record pattern and check if DMARC is configured.

Domain-based Message Authentication, Reporting and Conformance (DMARC) is an email validation system designed to detect and prevent email spoofing. It's intended to combat certain techniques often used in phishing and email spam, such as emails with forged sender address. 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.

Check that SPF and DMARC TXT records are identical on all the name servers.

If Google mail servers are used, check that settings meet the recommendations:

• ASPMX.L.GOOGLE.COM is the top priority mail server
• Any Time to Live values should be set to 24 hours (TLL = 86400)

Compare mail server's IPs received though reverse DNS and the ones provided in the initial A records:

• Mail server: get the mail server's domain name from the Exchange field
• IP resolution: get mail server's IP from the corresponding DNS A record
• Reverse DNS domain: run reverse DNS query for IP resolution
• Reverse IP resolution: get reverse DNS domain's IP from the corresponding DNS A record
• Check if IP resolution and Reverse IP resolution match

Check all the mail servers against RBLs.

When a mail server is blacklisted, the list of those who returned positive answer is provided. Please refer to the RBL's websites for more information.

Our full database includes 106 RBLs. Basic subscription plans are limited to validation in 10 RBLs only:

• b.barracudacentral.org
• cbl.abuseat.org
• http.dnsbl.sorbs.net
• misc.dnsbl.sorbs.net
• socks.dnsbl.sorbs.net
• web.dnsbl.sorbs.net
• dnsbl-1.uceprotect.net
• dnsbl-3.uceprotect.net
• sbl.spamhaus.org
• zen.spamhaus.org

Check mail server's SMTP connection response.

Check if SMTP connection could be established to all the mail servers.

Check if the mail server's domain name is present in the mail greeting.

After SMTP client establishes connection to SMTP server, the session is opened with a greeting by the server, usually containing it's Fully qualified domain name (FQDN).

SMTP server should accept postmaster@<domain_name> address as a recipient (RFC 5321).

SMTP server should accept abuse@<domain_name> address as a recipient (RFC 2142).