Assume that the domain name is “foofoo.com”, with the mail server on “mail.foofoo.com”, and an e-mail account for “email@example.com“ is expected to work.
MX record is for receiving mail, so this is not a solid requirement for an out-bounding server, set up only in case of some spam-filters check this.
A MX Record of domain name “foofoo.com” should be set pointing to “mail.foofoo.com”. Multiple MX records with different priorities can be set for fail-over. An A record of “mail.foofoo.com” is also required with the IP of the inbound mail server. After configuring this all mails send to “firstname.lastname@example.org“ will be handled by the pointed mail server.
The Sender Policy Framework (SPF) is an open standard specifying a technical method to prevent sender address forgery. More precisely, the current version of SPF — called SPFv1 or SPF Classic — protects the envelope sender address, which is used for the delivery of messages. SPFv1 allows the owner of a domain to specify their mail sending policy, e.g. which mail servers they use to send mail from their domain. The technology requires two sides to play together: (1) the domain owner publishes this information in an SPF record in the domain’s DNS zone, and when someone else’s mail server receives a message claiming to come from that domain, then (2) the receiving server can check whether the message complies with the domain’s stated policy. If, e.g., the message comes from an unknown server, it can be considered a fake.
Add this string as TXT record of domain “foofoo.com”
This allows all IPs of foofoo.com’s A record and MX record to send emails, and consider all mails send from the other IPs fake.
You can also specific the mail server IP manually by following adding this string.
For detailed SPF syntax please consult Official document.
DKIM attaches a new domain name identifier to a message and uses cryptographic techniques to validate authorization for its presence. The identifier is independent of any other identifier in the message, such in the author’s From: field.
The DKIM uses RSA key to sign the mail, to generate the key pair, openssl is recommended.
For better compatibility, please convert your private key from traditional format to PKCS#8 form as the following command shows.
Then extract the RSA public key from the private key.
Deploy the DKIM public key to the DNS, TXT record of domain “default._domainkey.foofoo.com”. Note that the “default” sub-domain is called the domain selector in DKIM, it can be replaced by any string as long as it is chosen correctly the signing process.
It is recommend to have this in one TXT record. However if the DNS provider has a limit of text length for each TXT record, you can split it in two or more TXT records in syntax “(“First part” “Second Part”)”
For more information, please see DKIM specifications.
DMARC, which stands for “Domain-based Message Authentication, Reporting & Conformance”, is an email authentication, policy, and reporting protocol. It builds on the widely deployed SPF and DKIM protocols, adding linkage to the author (“From:”) domain name, published policies for recipient handling of authentication failures, and reporting from receivers to senders, to improve and monitor protection of the domain from fraudulent email.
Add DNS TXT record of domain “_dmarc.foofoo.com”
For an official document of DMARC Click here.
In computer networks, a reverse DNS lookup or reverse DNS resolution (rDNS) is the querying of the Domain Name System (DNS) to determine the domain name associated with an IP address – the reverse of the usual “forward” DNS lookup of an IP address from a domain name. The process of reverse resolving an IP address uses PTR records. The reverse DNS database of the Internet is rooted in the arpa top-level domain.
The receiver or spam-filter will try to check the rDNS hostname of the sender’s IP to see whether it is same as the sender claims. The default rDNS is often set to something like “271.828.182.846.vultr.com”, which is not correspond to the domain. You should change the rDNS to “foofoo.com”. The rDNS configuration different according to your host provider. Please contact them for support. Note that the configuration may take several hours to valid.
Haraka is a highly scalable node.js email server with a modular plugin architecture. Haraka can serve thousands of concurrent connections and deliver thousands of messages per second. Haraka and plugins are written in asynchronous JS and are very fast.
node.js and npm are dependencies of haraka and should be install first.
Make configuration directory:
Run haraka for test:
The haraka may leave orphan process after shutdown and block the port, you can kill it manually:
Change the listening port to
haraka should then listen on these three ports on both IPv4 and IPv6. haraka will automatically assign the port 25 to handle insecure connection, port 465 for TLS and port 587 for STARTTLS. Opening listening port below 1024 requires root privilege.
To enable TLS and authentication, configure the config/plugins file
Edit the “config/auth_flat_file.ini” and add the SMTP users.
The “methods” specify the allowed login method.
Users filed syntax is username=password
An example as:
In default condition the TLS cert and key file is “config/tls_cert.pem” and “config/tls_key.pem”
This can be override by “config/tls.ini”
For more information about TLS plugin configuration see this document.
If you want to use the certificate which is issued by CA instead of self signed, you will need to concatenate the cert with the cert chain and the CA in order.
You can test the TLS settings using openssl:
Please note, in the actual situation, concatenating CA certificate might cause the TLS broken(no certificate provided by host). In such case, using the full chain instead may be help.
In case you want to debug, change the debug level by adding log level text to file “config/loglevel”
The valid log levels are:
SPF, DKIM, DMARC and rDNS must be at No.1 priority.
In pursuit of higher mail delivery rate, here is a list of dos and don’ts.