The emails I send are going to junk folders

Email
When an email recipient reports that emails which they are receiving are being diverted to a SPAM folder, there are many possible causes. Emails go through several checks to verify legitimacy before they are delivered. The following list will help in identifying the most common factors.

SPF Record

The SPF record (Sender Policy Framework) is a DNS record that lists valid email-sending servers for a given domain. Common issues with SPF records are:
  • No SPF record exists for the sending domain
  • An SPF record does not include the sending source of the failing email
  • An SPF record lists sources by IP rather than domain, helpful if the IP changes or can vary
  • An SPF record is too strict and excludes other sources with a recommendation for hard fail
You can check the SPF record for a domain with this tool: https://mxtoolbox.com/spf.aspx
 
This KB article guides you through creating an SPF record: https://support.managed.com/kb/a2262/creating-an-spf-record.aspx

PTR (Reverse DNS) Record

Please note: Customers are unable to modify their own PTR records. If you believe that your PTR record needs to be looked at, please contact the Managed.com Support team.
 
The PTR record, also known as Reverse DNS, maps an IP address back to a hostname. Email servers verify that this record exists and matches the hostname provided in the email header. Hostnames in a long format (example: static-ip-208-88-75-164.net-208-88-75-0.rdns.managed.com.) likely have not been set as the hostname of the mail server. Common issues with PTR records are:
  • No PTR record exists for the sending IP address
  • A PTR record exists but does not match the hostname provided in the header of an email
You can check the a PTR record of an IP address with this tool: https://mxtoolbox.com/ReverseLookup.aspx
 
You can verify if the PTR record matches the hostname provided in the email header by viewing the hostname in SmarterMail. The hostname can be found by logging into SmarterMail as admin then going to Settings > General Settings to see Hostname.
 
 
You can also see the hostname in the header of the email. Each Received entry details a server through which the message has traveled in its route from the sender to the recipient descending from most recent to first. The final Received entry is the focus as it provides the hostname of the sending server (highlighted in yellow).
Received: from BN6PR10MB1299.namprd10.prod.outlook.com (2603:10b6:405:29::38)
 by DM5PR10MB1306.namprd10.prod.outlook.com with HTTPS via
 BN6PR1301CA0025.NAMPRD13.PROD.OUTLOOK.COM; Tue, 6 Mar 2018 19:30:58 +0000
Received: from DM5PR10CA0019.namprd10.prod.outlook.com (10.172.33.29) by
 BN6PR10MB1299.namprd10.prod.outlook.com (10.173.29.137) with Microsoft SMTP
 Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id
 15.20.548.13; Tue, 6 Mar 2018 19:30:57 +0000
Received: from BL2NAM02FT056.eop-nam02.prod.protection.outlook.com
 (2a01:111:f400:7e46::202) by DM5PR10CA0019.outlook.office365.com
 (2603:10b6:4:2::29) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.548.13 via Frontend
 Transport; Tue, 6 Mar 2018 19:30:57 +0000
Authentication-Results: spf=none (sender IP is 208.88.74.248)
 smtp.mailfrom=sendingdomain.com; managed.com; dkim=none (message not
 signed) header.d=none;managed.com; dmarc=none action=none
 header.from=sendingdomain.com;
Received-SPF: None (protection.outlook.com: sendingdomain.com does not
 designate permitted sender hosts)
Received: from generic252.mxout.managed.com (208.88.74.248) by
 BL2NAM02FT056.mail.protection.outlook.com (10.152.77.221) with Microsoft SMTP
 Server id 15.20.527.18 via Frontend Transport; Tue, 6 Mar 2018 19:30:56 +0000
Received: by generic252.mxout.managed.com via HTTP;
PTR records do not exist inside of the DNS zone of a domain and have a special procedure. This KB article guides you through adding/updating a PTR record: https://support.managed.com/kb/a485/how-to-set-up-a-ptr-reverse-dns.aspx

Blacklists

Emails originating from a sending IP address which has recently been the known source of SPAM or may be actively sending SPAM may be blocked due to being listed on one or more blacklists. You can verify if the domain or IP is appearing on blacklists by visiting the following blacklist checker: https://mxtoolbox.com/blacklists.aspx
 
If you have a dedicated sever, you can verify if the server is actively sending SPAM and then clean up that activity by following the instructions in the following KB article: https://support.managed.com/kb/a1965/an-ip-has-been-blacklisted_-how-to-identify-the-source-and-remove-the-spam.aspx For shared hosting customers, contact Support for assistance.
 
Aside from the blacklist services which may be listed in the blacklist checker above, an ISP, network or email service provider can maintain their own private blacklist based on the activity which they have observed. This is especially common with large providers who have strict policies to protect their users. You may need to search deeper than the public blacklists to discover if the provider is restricting email. The following are links to Postmaster areas of common providers:
Both public and private blacklists always have a TTL (time to live) setting on their blacklist entries, which means that the listing will only last a certain set time until it is naturally removed. Some blacklists offer the opportunities to request de-listing which would bypass the normal expiry of the listing. You should investigate the options for each situation.

Sender Reputation

Similar to a blacklist, there are organizations that track sender reputation over time and maintain these lists for use by ISPs and email providers. These sender reputation reports are essentially a consolidation of many blacklists and other information into one reputation rating. You can verify the standing of a particular IP by viewing it using this link: https://talosintelligence.com/
 
These providers do not provide any de-listing option since they are a consolidation of information from other sources.

DKIM

DKIM (DomainKeys Identified Mail) attaches a new domain name identifier to a message and uses cryptographic techniques to validate authorization. While DKIM is not required by a receiving mail server, its presence provides an additional layer of assurance that the sender is valid making it unlikely to be rejected.
 

Local SPAM Filters

The local SPAM settings on a domain or server level provide the last wall of protection for an email. While the majority of these checks are of the settings already listed in this article (SPF, PTR, subscribed blacklists, DKIM) there are additional checks which can occur on the message itself. These checks can occur on the receiving server and also can occur in an email client such as Outlook which has its own SPAM filtering. While there are many possible SPAM filtering add-ons that may be in use, the most common filtering technique is Bayesian filtering.
 
Bayesian filtering looks at the content of a message and analyzes the individual words and combinations of words in use and assigns point values based on how commonly they are observed in known SPAM. For example, 'money' may be worth .75 points and 'Nigerian prince' may be worth 2 points. The total points scored by a message will then fall into a threshold which clears the message or marks it as a high probability of SPAM.
 
The overall results of this type of filtering as well as the results of other SPAM checks are often recorded into the header of a message so it is recommended to analyze the header for further information. Server delivery logs will also contain information of the results of SPAM checks.

Add Feedback