Direct Delivery is when spammers send their junk mail to your mailbox by ignoring your MX records. The MX records for a domain tell email servers where to send your mail, real servers follow the rules.
We are seeing an increase in the number of spam groups that are ignoring MX records in an attempt to bypass spam protection systems.
How Do They Do it?
Spammers can attempt to bypass your MX records by attempting direct delivery to your server. They try things like delivering to mail.example.com or by sending mail to the same IP address that your website is running on.
In order to prevent direct delivery attacks, you must control who can connect to your server to deliver mail. When using MX Guarddog you ideally only want MX Guarddog servers connecting to your server to deliver mail.
Your available options for stopping direct delivery attacks are determined by your email setup, with so many different email systems there are lots of possible options.
With any of the above options in place, spammers will not be able to bypass spam protection for your domain - resulting in a cleaner inbox.
If none of the above are options in your environment, you can also implement filtering rules directly in your email client. Email client filtering is less efficient as you must add the rules on every email client. We have some guides available for Thunderbird, Outlook 2013 and MacMail.
In order to check if you are suffering from spam reaching you via direct delivery, you need to check the headers of the mail you have received.
Here are the headers of a message that passed through the MX Guarddog network, you can tell this because there are several references from servers in the IK2.COM network. So this message did pass through MX Guarddog.
Envelope-to: user@example.com
Delivery-date: Mon, 15 Jun 2015 09:39:21 -0400
Received: from s480f.ik2.com ([64.38.239.86]:26047)
by s047.boxmanager.com with esmtps (TLSv1:DHE-RSA-AES256-SHA:256)
(Exim 4.85)
(envelope-from <bounce+7576f4.010a37@work.com>)
for user@example.com; Mon, 15 Jun 2015 09:39:20 -0400
Received: from s480k.ik2.com ([192.168.48.81] helo=s480g.ik2.com)
by s480f.ik2.com with esmtps (TLSv1:DHE-RSA-AES256-SHA:256)
id 1Z4Ubf-0003qs-57
for user@example.com; Mon, 15 Jun 2015 13:39:19 +0000
Received: from 192.237.158.66 by s480g.ik2.com (IK2 SMTP Server); Mon, 15 Jun 2015 13:39:17 +0000
Date: Mon, 15 Jun 2015 13:38:17 +0000
Received: by luna.mailgun.net with HTTP; Mon, 15 Jun 2015 13:38:15 +0000
Content-Type: multipart/alternative;
boundary="----------=_1434375495-12243-167"
Content-Transfer-Encoding: binary
MIME-Version: 1.0
From: Work Notification <room@work.com>
Subject: Rahul, Robert
To: <user@example.com>
X-SF-RX-Return-Path: <bounce+7576f4.010a37@work.com>
X-SF-HELO-Domain: do158-66.mailgun.net
X-SF-Originating-IP: 192.237.158.66
Now here are headers of a message that was delivered direct to a server via a direct delivery attack, you can see the message never passed through any server in the IK2.COM network, so MX Guarddog had no chance to stop the message.
(192.168.0.12) with Microsoft SMTP Server (TLS) id 14.3.224.2; Tue, 16 Jun
2015 15:58:33 -0400
Received: from AP-EXCHANGE.action.local ([fe80::b8e8:b862:1c98:c374]) by
AP-Exchange.action.local ([fe80::b8e8:b862:1c98:c374%13]) with mapi id
14.03.0224.002; Tue, 16 Jun 2015 15:58:32 -0400
From: Carrie <Carrie@actionplumbing24.com>
To: "brandon@rcstoremaintenance.com" <brandon@rcstoremaintenance.com>
Subject: Confirmation of payment
Date: Tue, 16 Jun 2015 19:58:31 +0000
Message-ID: <1942B1A9CA8B5843BC8D02DE047242DE9A068F67@AP-Exchange.action.local>
Content-Type: multipart/mixed;
boundary="_004_1942B1A9CA8B5843BC8D02DE047242DE9A068F67APExchangeactio_"
Return-Path: Carrie@actionplumbing24.com
MIME-Version: 1.0
If you are receiving messages with headers like the above sample, with no reference to servers from IK2.COM you would need to implement some type of hardening at your server to ensure all mail that reaches your server can only reach your inbox if it has passed through MX Guarddog.