If you have configured MailCleaner as an Outgoing Relay, it is important that you set MailCleaner and your domain up to meet modern best practices in order to ensure that your mails actually get delivered to the recipient. Here are some recommendations which are increasingly required by some of the largest email hosting providers, such as Office 365 or Gmail, before they will allow the mail to be delivered.

Set up a valid SSL certificate¶

By default, MailCleaner ships with a self-signed certificate which is insecure by nature, not least because it is visible in our GitHub repository. It is provided because historically a lot of servers would reject mail that is not encrypted at all, so a bad certificate was better than none at all. Now, however, some hosting providers are either requiring a valid certificate, or even preferring no certificate over a self-signed or invalid one.

See this guide for configuration instructions.

There are many tools such as this to confirm that your machine is correctly negotiating a TLS connection and that it has a valid certificate.

Set up a strict SPF record¶

Sender Policy Framework (SPF) is a mechanism for allowing recipient machines to determine if mail being send on behalf of your domain is originating from a domain which is allowed to send mail on your behalf. It is the simplest and best mechanism for reducing the ability of spammers and other malicious actors from being able to trick recipients into thinking that their email actually came from your domain.

An SPF record is a public TXT record for your domain which should be hosted by the DNS provider for your domain.

There are many tools such as this to help you understand and generate an SPF record.

It is now common for some hosting providers to reject messages from domains with a 'none' policy for SPF failures (ie. one ending with ?all). If you are confident that your SPF record is comprehensive, you should make all failures result in a hard fail (ie. ending with -all). If you are still uncertain, you should stick with a softfail (ie. ending with ~all), which could result in messages being quaratined if it turns out that the record was not comprehensive, but should ensure that more strict email hosts at least allow the message to be allowed to be processed in the first place.

As with DKIM and DMARC to follow, note that DNS records have a Time To Live (TTL) value which is usually between 1 hour and 24 hours. If you have a mistake in any DNS record, recipient machines could take up to that duration before they check again to see your changes.

If your are using MailCleaner Cloud as an outgoing relay, your SPF record will need to contain at least:

v=spf1 include:spf.mailcleaner.net

followed by any other sources that you wish to allow and your preferred ~all or -all policy.

Configure DKIM signing¶

Domain Key Identified Mail (DKIM) is a method for verifying that the contents of the message have not changed since it was sent. This is done with a public/private key pair. The public key is, again, published as a TXT record. This time, it is a record for a specific subdomain like selector._domainkey (unlike SPF which is for the exact hostname that matches the sender's domain). The sending machine will use the private and public key to generate a cryptographic signature for the protect parts of the message and add it as a new header to all outgoing messages. The recipient machine will be able to use the public key to determine that the signature matches the content of the message, but that public key is insufficient to actual generate the signature on it's own. If the signature does not match the public key, the sender will know that the content must have changed, or it was not signed using a legitimate key pair.

If you are relaying outgoing mail with MailCleaner, you should configure your domain to perform DKIM signing of outgoing messages.

If you are the administrator of your own MailCleaner machine and would like to configure a single default private key for all domains on your instance, you can configure this from Configuration->SMTP->DKIM. Continue reading since this will NOT enable DKIM for any domain.

If you are the administrator of a single domain on someone else's MailCleaner instance, including MailCleaner Cloud (these administrators are called 'manager' accounts in MailCleaner parlance), you can either use the default key that the global administrator set up for you, or you can configure your own for that domain or a custom domain.

Regardless of your administrator type, you need to enable DKIM signing from Configuration->Domains->[select domain]->Outgoing relay. Select which key you would like to use, generate or paste in your own private key for any option of the than the default key, then submit. After the page reloads, it will present you with a public DKIM key that you can add to your DNS.

MailCleaner will not begin trying to sign message until it can find your public DNS record. You will may need to verify that the nameservers which are configured for MailCleaner (Configuration->Base system->DNS Settings) can correctly resolve these records. Once it is able to resolve this record, it will immediately start signing.

Configuring DMARC¶

DMARC is an enforcement policy for when DKIM or SPF fail which tells the recipient machine how to handle those conditions. That is done completely with a DMARC TXT record. Likewise, the only settings in MailCleaner related to DMARC are how handle to handle DKIM. Implementing this is done entirely using that DNS record; there is nothing to set up in MailCleaner (other than actually enabling relaying and setting up DKIM signing, as discussed in the previous step).

There are many tools such as this to help you understand and generate a DMARC record.

It is recommended that you first use 'p=none' to ensure that the DKIM signing and SPF results are working as expected. At this time it is very uncommon for recipient machines to be upset by a 'none' policy, but this could become more common in the future. So, once you have confirmed that both SPF and DKIM pass, you can change this to 'p=quarantine' to ensure that the recipient actually knows to block failed messages. This lends more credibility to your domain's legitimacy as an email source.

Note that we rarely recommend that ordinary domains enforce a 'p=reject' policy. This policy is intended to leave no recoverable messages in the event of a failure. Since DKIM or SPF can fairly easily be broken accidentally, having no recovery mechanism for these messages is generally more hassle than it is worth for regular business and personal email. The exception would be for domains which operate at an extremely high level of trust such as banks or governments. In these cases, a rejected message probably does cause fewer problems than a malicious message being allowed into a quarantine while spoofing that trusted domain.

Protect the reputation of your MailCleaner relay¶

Even if your server checks all of the above boxes, it is still possible that it, or your domain more generally, could be blocked as a source of spam by a Real-Time Blocklist (RBL). These are DNS servers which will aggregate lists of IPs/Domains based on user reports, public information (eg. WHOIS records), or automated detection of low quality traffic. Recipient machines will query for the domain or IP as a subdomain for that RBL service (eg. your-domain.com.urirbl.mailcleaner.net or 1.1.1.1.iprbl.mailcleaner.net) and if your domain has been listed, they can decide to quarantine or reject the message outright. You can see more about RBLs and how we treat listings here.

Different RBL sources will have different policies for what criteria will result in a list and different policies for de-listing. Which RBL sources to use and how strictly to treat a listing is up to the recipient's mail filter/firewall, so it is best to ensure that you never get listed by any.

To avoid getting your MailCleaner listed by an RBL you can follow a few best practices:

• Ensure that outgoing relaying is as restricted as possible, as discussed in the configuration instructions
• Block authenticated relaying on port 25 (Configuration->SMTP->SMTP Checks->Block authenticated relaying on port 25)
• Mask the IP of the relaying source (Configuration->SMTP-SMTP Checks->Mask IP address of relayed host on port 587). This will prevent blocks in the event that your back-end server gets listed, since many mail filters will also check the IPs of the upstream machines in the "Received" headers. Some RBLs have even been know to list IPs in the private IP spaces (eg. 192.168.0.0/16, and 10.0.0.0/8), so even an IP on your LAN could result in the mail being blocked.
• Use different nodes for incoming and outgoing mail. There are sometimes consequences from misconfigurations for your incoming mail filtering (eg. bounces generated by MailCleaner because you don't have working Recipient Verification which rejects invalid addresses during the Incoming MTA stage) which result in nuisance mail being sent out from your incoming mail node(s). This could result in regular outgoing mail being blocked, not because you are sending out malicious mail, but because outgoing mail shares a hostname/IP with that nuisance mail.
• Set reasonable rate-limits in Configuration->SMTP->Connection control. These limits apply to both incoming and outgoing mail (with separate limits for a trusted list), and can ensure that individual addresses are not allow to send out large blast of mail too quickly. This can happen if an account is compromised, or if a regular user simply tries to send out bulk mail for any reason.
• Be careful with bulk mail. Following from the previous point, you should be careful when sending bulk mail from the same server that sends your regular outbound mail. If you have a mailing list or newsletter, you should consider configuring each on a dedicated server (using MailCleaner, or not). Otherwise, you should consider using a third party that specializes in sending bulk mail. If you do send your own newsletter, be sure that you follow CANSPAM rules. Always include the necessary headers and unsubscribe links so that the recipient can identify it as bulk mail. It is better to end up being (justifiably) filtered into a 'promotional' folder or quarantine than to have your marketing material damage the reputation of the IP/domain as a whole. Most RBL providers will ignore reports for messages that are clearly identified as promotional or will specifically list them in a dedicated list (eg. niprbl.mailcleaner.net is used for newsletters while iprbl.mailcleaner.net is used for spam/phishing).