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 the SSL certificate 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).

I'm already blacklisted! What do I do?

Determine the cause

The first thing to check is for an unusual amount of activity from a specific sender. The easiest way to search the logs is using Management->Tracing where all relayed messages will appear with that as the Arrival Status.

However, this has a couple of limitations. First of all, it does not provide an very brief count, so it could require going through several pages before you find the unusual behavior. Second, it is only searchable for one domain at a time and for domains that you have actually configured. If you allow relaying from other domains with Configuration->SMTP->Connection Control->Allow relaying from unknown domains, then messages from these other domains will be unsearchable in the web. Finally, you cannot restrict the results to just relayed messages.

Alternatively, a tool exists at /usr/mailcleaner/tools/relay_summary.pl which can be used to get simple counts for relayed messages.

Running the script without options will provide counts for each unique outbound sender. You can use the --help option to get more options for additional output or filtering.

You should make sure the behavior you see is all as expected wanted. If it is not, please change the password for the concerned user or remove the sending IP from the Configuration->SMTP->Connection Control->Allow external relaying for these hosts since their account or an authorized IP is probably compormised.

If the relaying is being allowed by IP, but that IP is used by other senders, you can temporarily block the offending sender with Configuration->SMTP->Connection Control->Reject these senders addresses. This should be temporary until you are able to secure the account.

If the relaying is authenticated, you can temporarily block the sender with Configuration->SMTP->Connection Control->Reject these authenticated users.

In either case, it is likely that the user's credentials will need to be reset from the authentication server if the account is compromised.

If the source wasn't a domain that you control, be check that Configuration->SMTP->Connection control->Allow relaying from unknown domains is disabled.

Also verify if all domains currently using Configuration->Domains->select domain->Outgoing relay->Allow users to use SMTP authentication actually require access to relay via MailCleaner. Usually a domain will be relayed by its own mail server (the one usually used as destination server for the domain), so directly relaying via MailCleaner should not be required for the majority of senders.

Resolving an RBL listing

First, identify which list you are blacklisted on. Generally this will be shown in a bounce message that you have received. Often this will even included a link to the URL where you can request de-listing.

If the bounce does not make it clear where you are listed, you can try using a service like MulitRBL or MXToolbox to search a wide variety of commonly used RBLs. You can then search that organizations website to see if there are de-listing instructions. If you are listed by our RBLs, you can request de-listing here.

In many cases, listing and de-listing is automated based on user reports and there will be nobody to handle a remove request; you'll simply have to wait for a period of usually one to a few days with no further user reports to get de-listed.

In the meantime, you can work around a blacklist if you have access to an additional IP which you could migrate that node to, or by directing relay traffic to a different set of MailCleaner nodes in a cluster. However, make sure that any problem is resolved before doing this, or you risk getting other IPs blacklisted.

Finally, MailCleaner does very minimal filtering on outgoing mail, so you may be better off using a better controlled outbound relay such as our sister product SerenaMail.