Scanning a mails content is a very processor intensive process.  It can take 2-15 seconds to scan a mail for virus, banned attachments and spam text.  If mail is being received at a fast rate the mail can begin to build up in the queues.  This is where the Front-line tests come in to play.

The Front-line tests are very efficient tests carried out by SpamTitan's mail server.  These tests are not reliant on checking the content of a mail in order to reject it, they examine the envelope settings such as IP address, To/From addresses, message size, etc.  The tests include RBL (Realtime Blackhole Lists), SPF (Sender Policy Framework), Recipient Verification, Greylisting and SMTP Controls.  The majority of these tests are performed via DNS and only take a fraction of a second to perform.  As such, they can very quickly determine if a mail is spam.  To get the most from your SpamTitan server you will want to configure it to drop as much mail as possible using the front-line tests so only a small portion of the overall mail flow has to be passed to the processor intensive spam, virus and attachment scans.

You can find the SpamTitan Admin and Install guides here:


NOTE: Each of the front-line tests described below has a bypass list to which you can add server IP addresses.


RBL servers contain lists of IP addresses of know spammers and compromised machines.  You enable RBL in System Setup->Mail Relay->IP Controls.  You add RBL servers like zen.spamhaus.org or bl.spamcop.net and then the IP addresses of every incoming connection are checked against the RBL servers.  If the IP address is listed the connection is dropped before the mail is fully delivered on to SpamTitan.  This tests required one DNS query per RBL server that is added.  If the first RBL server returns a hit none of the others will be checked.  There is an RBL Bypass List where you can add IP addresses that will be exempt from RBL testing.  RBL can block up to 90% of all incoming mail making them a "must have" test.  You can find a good comparison chart of various RBL here:


RBL can be configured to be performed before or after recipient verification.  The "After recipient verification" option only works if ALL of your domains are using either Dynamic Recipient Verification or no verification.  If you are using any other form of Recipient Verification the RBL test has to be configured to be performed before the recipient verification test.

Recipient Verification

Recipient Verification allows SpamTitan to check every recipient address to ensure it is valid (exists on the mail server).  Mail addressed to invalid email addresses is dropped before being accepted by SpamTitan.  SpamTitan supports 4 methods of Recipient Verification, Dynamic, LDAP, List and Regular Expression.  Dynamic Recipient Verification is the most efficient and easiest to manage and maintain.  You can read more about Dynamic Recipient Verification here:



SPF is a method for publishing a list of servers authorized to send mail for a particular domain.  This allows SPF enabled mail servers to check for an SPF record and verify if the server sending mail is listed on the SPF record.  You do not need an SPF record for your own domain to use SPF.  SPF will have no effect on mail from domains with no SPF record.  SPF is enabled in System Setup > Mail Relay > Sender Controls.  When enabled there is an exemption list where you can IP addresses of mail servers which you want to be exempt from the SPF test.  

Note:  The only caveat to using SPF is that it can block mail from domains with an incorrectly configured SPF record.  Use at your discretion.


DomainKeys Identified Mail (DKIM) is an email authentication method designed to detect forged sender addresses in emails (email spoofing), a technique often used in phishing and email spam.

DKIM 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.[1] It achieves this by affixing a digital signature, linked to a domain name, to each outgoing email message. The recipient system can verify this by looking up the sender's public key published in the DNS. A valid signature also 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 the message's authors and recipients.

You can enable DKIM Verification for inbound mail in System SEtup > Mail Authentication > DKIM.

SpamTitan can also DKIM sign your outbound mail.  We have a guide to enabling DKIM signing on SpamTitan here.


DMARC (Domain-based Message Authentication, Reporting and Conformance) is an email authentication protocol. It is designed to give email domain owners the ability to protect their domain from unauthorized use, commonly known as email spoofing. The purpose and primary outcome of implementing DMARC is to protect a domain from being used in business email compromise attacks, phishing emails, email scams and other cyber threat activities.

Once the DMARC DNS entry is published, any receiving email server can authenticate the incoming email based on the instructions published by the domain owner within the DNS entry. If the email passes the authentication it will be delivered and can be trusted. If the email fails the check, depending on the instructions held within the DMARC record the email could be delivered, quarantined or rejected.

DMARC extends two existing mechanisms, Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM). It allows the administrative owner of a domain to publish a policy in their DNS records to specify which mechanism (DKIM, SPF or both) is employed when sending email from that domain; how to check the From: field presented to end users; how the receiver should deal with failures - and a reporting mechanism for actions performed under those policies.

DMARC verification can be enabled in SpamTitan in System Setup > Mail authentication > DMARC.  When enabled SpamTitan will check to see if a DMARC record exists for each sending domain, and if a record exists it will be used to verify whether the mail is legitimate.

You can read more about DMARC verification on spamTitan here.

NOTE:  If you are using DMARC, both SPF and DKIM checking MUST be enabled.

You can also add a DMARC record for your domains to both improve deliverability of your mail and prevent abuse of your domains.  The creation of a DMARC record does not involve your SpamTitan server and as such is outside the scope of this article.

SMTP Controls

These tests perform a variety of functions.  The first set of tests are based around the HELO name provided by a server sending mail to SpamTitan.  You can require that the server use the HELO command, use a Fully Qualified Hostname or a Resolvable Hostname.  There is also an exception list for these tests.

Activate the Require Fully Qualified Domain Names setting to reject connections if the address in the client MAIL FROM command is not in fully-qualified domain form or if the address in the client RCPT TO command is not in fully-qualified domain form.

Activate the Reject Unknown Sender Domain to reject the request when the sender mail address has no DNS A or MX record.  For example, you receive a mail from user@xyz.com.  If the xyz.com domain has no MX or A record the mail is rejected.


When enabled Greylisting will reject all mail temporarily.  All SMTP compliant mail servers will defer the mail and resend it after a set period of time, usually around 5 minutes. On the other hand spam sending servers are rarely SMTP compliant, it is very likely that they will not resend the rejected mail so straight away spam will be blocked.  If a spam server does resend the mail it is likely that the spam server IP address or the content of the mail will be blacklisted when the mail is received a second time and a different test will block it.  The simple act of delaying the mail greatly increases the probability that it will be blocked.  

Greylisting comes with an auto-whitelist feature. Mail servers that send you mail regularly will be whitelisted after the whitelist settings are met.  By default a server will need to successfully deliver at least 1 mail per hour over the course of 5 hours to become whitelisted.  You can also manually exempt mail server IP addresses and recipient email addresses or domains.

Greylisting is enabled and configured in System Setup > Mail Relay > Greylisting.


Bounce Mails

SpamTitan has a specific module to handle unwanted bounce mails.  In order for this module to work you must list the host names of your mail servers in System Setup->Mail Relay->Outbound->Hostname of Outbound Relays.  This will allow SpamTitan to drop bounce mails that do not reference your mail servers.  

The importance of DNS

Accurate DNS responses are vital to SpamTitan maintaining a good spam catch rate.  SpamTitan queries multiple internet based spam blocking tools using DNS.  Due to the very high volume of DNS requests that originate from free/open DNS servers (e.g,,, etc)  the test providers will not respond to DNS requests from these servers.  Do not configure SpamTitan to use free/open DNS servers, or if you are using your own DNS server do not configure it to use free/open DNS servers as a forwarder.

One of the test providers supplies a test you can use to determine if your DNS server is able to access their services.  If you are unable to access this service then it is very likely you will have issues accessing other DNS based services and your spam catch rate will be affected.  You can very easily test to see if you are being blocked.

If you go to the Reporting > System Information tab under Tools you will see a text box beside DIG.  You can test any DNS server here by adding the following: (replace with the IP of the DNS server)


@ TXT test.uribl.com.multi.uribl.com


If it comes back with the following it has failed the test:

test.uribl.com.multi.uribl.com.	2099 IN	TXT	" -> Query Refused. See http://uribl.com/refused.shtml for more information [Your DNS IP:]"


It the following is returned that indicated that your DNS query was accepted:

test.uribl.com.multi.uribl.com.	55 IN	TXT	"permanent testpoint"

SpamTitan Admin Guide

The SpamTitan Admin guide contains detailed descriptions and configuration tip for all the above features.  You can find the SpamTitan Admin and Install guides here: