death2spam

Configuration Check-List

Use the following check list to configure your organization's use of Death2Spam.

  1. Accept our Terms of Service and Privacy Policy
  2. Verify the "priority" mail server record in Domain Admin screen
  3. Optionally configure POP server for web-UI login authentication
  4. Configure downstream mail server to reject invalid email addresses
  5. Verify the number of user licenses in the Customer Admin screen
  6. White-list D2S for multiple inbound connections to your mail server
  7. Check connectivity using the "Test" button in the Domain Admin screen
  8. Update your domain's Aliases Table
  9. Validate DNS configuration via the "DNS Report" link on Domain Admin screen
  10. Verify that all MX records point to the correct D2S server(s)
  11. Configure your firewall to only accept SMTP connections from D2S

1. Accept our Terms of Service and Privacy Policy

Protecting the privacy of your confidential email traffic is extremely important to us at Death2Spam. Our Privacy Policy applies to all of the services and websites provided by Death2Spam LLC, and its subsidiaries, agencies or affiliated companies. You can find our Terms of Service and Privacy policies here:

Login with a domain administrator ID to your Customer Admin screen and click on the "Accept Terms of Service" checkbox to indicate that you have read and approved the Death2Spam ToS agreement. Once this form has been submitted, the "Accept Terms" checkbox option will disappear.


2. Verify your "priority" mail server record in Domain Admin Screen

Login with a domain administrator ID to your Domain Admin screen, to verify that the Priority Mail Exchanger hostname or IP address is directed at your domain's email server. NB: this is Death2Spam's internal routing data used for relaying your inbound email, not to be confused with your domain's public Mail Exchanger (MX) records in the Domain Name Service (DNS).

In the event that your main email server fails or goes offline, you can optionally designate a Failover Mail Exchanger target, thereby directing inbound messages to a failover (secondary) server. If your organization doesn't have a backup mail server, leave this field blank.

After making any changes to your domain's destination (downstream) mail host, we strongly recommend clicking on the "Test" button to verify that the designated mail server is 100% operational and is accepting inbound messages from Death2Spam.


3. Optionally configure POP server for web-UI login authentication

By default, Death2Spam will use a combination of trap-door algorithms and encryption to store a one-way hash of your login password on our servers for authentication. Alternatively, you can configure D2S with the hostname of a POP server to which Death2Spam can attempt a connection using the authentication credentials (user name and password) submitted to Death2Spam by the user.

Under these circumstances, Death2Spam will establish a connection to the designated POP server on port 110, and your server will authenticate (accept or reject) the user's credentials. Death2spam will then allow (or deny) access based upon this query. This is useful where an organization's internal security policies require users to change their login passwords for various services (e.g. email) on a regular basis.


4. Configure downstream mail server to reject invalid email addresses

To fine-tune the way D2S handles automatic account creation for your users, we recommend that your domain's mail server be configured to reject bogus recipient addresses during the RCPT_TO phase of the SMTP transaction. This also allows D2S to detect Directory Harvesting Attacks as they happen, and to defeat blitzkrieg, brute-force or dictionary attacks.

If your mail server is configured to accept any recipient address, per your IT policy, you will need to manually create D2S user accounts (if they're required). From your domain administration screen, click on the [+] Add User button to create a new user account. Alternatively, when a D2S alias is registered for a user's email address, e.g. somebody@your.domain.com --> somebody@your.domain.com, an account is created for that user in Death2Spam's Access Control List (ACL). The user is then able to login to the D2S web interface, and can inspect and re-classify their email messages as necessary.


5. Verify the number of user licenses in the Customer Admin screen

Per our Terms of Service, administrators are required to ensure they have declared the correct number of user licenses for their organization, and to keep this data current. NB: the D2S licensing agreement defines each person receiving filtered email as a "user", i.e. this is not the number of mailboxes supported at a domain (since each person may have a number of email addresses).

We rely on your honesty in correctly entering, and updating, the number of user licences which are being billed for. Please don't be tempted to cheat. Death2Spam automatically audits the volume of email traffic passing through our filtering servers, and is able to detect statistically-anomalous levels of traffic per user. The penalty for abusing our trust is double your SPAM back!


6. White-list D2S for multiple inbound connections to your mail server

Some mail servers and/or firewalls do not permit multiple concurrent SMTP connections into a domain. Since your organization will be receiving all its inbound SMTP traffic from the Death2Spam interceptor server, you will need to ensure that D2S can open multiple connections simultaneously to your mail server.


7. Check connectivity using the "Test" button in the Domain Admin Screen

This "Test" button verifies SMTP connectivity between the Death2Spam server and your downstream mail host. If the connection fails, there is most likely a problem with your domain's mail server, and/or it may be mis-configured. Check that you have the correct priority mail exchanger data in the Domain Administration screen. By default, the test button initiates a "partial SMTP transaction" to the postmaster mailbox at your domain, but you can designate any legitimate recipient address. A test email will only be sent to the recipient when the "Send Message" option is checked.

Please ensure that your mail server is RFC-compliant by configuring your mail server to accept messages for the <postmaster> recipient address, which is used by D2S for communicating certain system-generated messages. Check that messages to <postmaster> at your domain are being correctly accepted via the Test SMTP Transaction screen. Click the DNS Report button for a thorough analysis.


8. Update your domain's Aliases Table

The Aliases Table determines which Death2Spam user account will be used to store "ghosted" emails for purposes of re-classification, training and message archiving. Aliases do not change the email's recipient (unlike forwarding rules), i.e. whom the message is sent to, only which Death2Spam account it will appear in for re-classification, etc.

Aliases are configured using two text columns:

  • Column 1 = The recipient's email address
  • Column 2 = A Death2Spam account ID

Recipient Email AddressD2S Account ID (Email)
accounts@example.commarge@example.com
bart@example.combart@example.com
lisa@example.commarge@example.com
sales@example.comhomer@example.com
xyzzy@example.compostmaster@example.com
*@example.compostmaster@example.com

In the sample Aliases Table shown above, all emails to sales@example.com will appear in the user account for homer@example.com for system training purposes. Likewise, messages sent to lisa@example.com and accounts@example.com will be "ghosted" into the marge@example.com user account (along with her own emails). The entry for bart@example.com is somewhat redundant, since if this D2S account exists, all incoming email for the user is ghosted there by default.

Any inbound email to a recipient without a specific Death2Spam user account will be ghosted under the postmaster@example.com login. This "fall-through" or default account can be specified using the asterisk wild-card character, e.g. *@your.domain.com could be aliased to administrator@your.domain.com. This configures D2S to ghost any email for recipients not explicitly declared in the aliases table, nor having a D2S account, into the administrator's D2S account. Note that email filtered by D2S is always delivered to the intended recipient, irrespective of Death2Spam's aliasing rules.


9. Validate DNS configuration via the "DNS Report" link on Domain Admin page

It is good practice to validate your DNS configuration, e.g. at www.pingability.com, after making any changes to your Name Server records. Pingability.com provides a comprehensive report to ensure that your DNS data comply with the Internet RFC requirements. Mis-configuration of your DNS data can prevent the Death2Spam service from working correctly.


10. Verify that all MX records point to the correct Death2Spam server(s)

Your domain's primary MX record should be configured (DNS) to point at mx0.death2spam.net. This can be verified via the www.pingability.com utility.

If your DNS provider's admin interface forces the use of MX records which are a zone (sub-domain), e.g. [mail.yourdomain.com], instead of mx0.death2spam.net, we strongly suggest you use a more professional Domain Name Service provider, e.g. easyDNS.com, dnsMadeEasy.com or ZoneEdit.com. Creating an Address (A) record pointing to a Death2Spam server's IP address is not recommended, since serious delays in email delivery can occur if/when the IP address of a Death2Spam server is changed.

We recommend adding the D2S failover servers mx1.death2spam.net and mx2.death2spam.net to your domain's mail exchanger (MX) records. Check how to do this with your ISP or DNS provider, or contact support@death2spam.net. In the (unlikely) event of your domain's primary Death2Spam Sentinel server going down, it is vital that your domains have a failover server configured in the Domain Name system. If not, email delivery to your domain may be disrupted while the primary D2S system is being brought back online.

FYI, technical information on the configuration of your domain's inbound mail stream via Death2Spam can be viewed at death2spam.net/enterprise/mx.html, and answers to many frequently-asked questions can be found at death2spam.net/enterprise/faq.html.

If you are unsure what changes to your MX records are required, please contact Death2Spam.

Third-party Internet Service Providers:  D2S customers who have their email service hosted with third-parties such as Internet Service Providers (ISPs) or Mail Hosting Providers should verify that your mail server host will still accept incoming email from Death2Spam if all MX records point to a D2S interception server.

Some ISPs use MX records to identify that they are the destination mail host. ISPs and Mail Hosting Providers who use such methods will not recognise that they are the target mail host for a domain if all its MX records point at Death2Spam. Under these circumstances, the mail server will attempt to send inbound messages back to D2S, which will eventually create a "Looping Error" causing the emails to be bounced as non-deliverable.

A technically-competent ISP will be able to correct this problem by configuring an internal routing policy that permits Death2Spam to successfully deliver messages to your mail server, irrespective of the domain's MX records. However, if your ISP is unable to resolve such looping errors, we can recommend a number of reliable and economical email hosting providers which are compatible with Death2Spam.


11. Configure your firewall to only accept SMTP connections from Death2Spam

If possible, firewall your mail server so that it only accepts inbound TCP/IP connections (port 25) from our cluster's SMTP tier servers, namely 75.101.133.30, 75.101.128.14 and 75.101.155.29, to prevent spam and malware sneaking through the "back door". Note that even after you have removed all references to your mail server's hostname from DNS, spammers are likely to have cached its IP address, and will continue trying to send junk into it indefinitely...

NB: Do not change firewall settings until your MX records point at Death2Spam, and these changes have fully propagated through the DNS (nominally 24 hours).