In my experience not having a PTR (reverse DNS) record set for the IP address of a server is the number one way email gets flagged as SPAM on services like Gmail and even AOL.
Related but if you don’t have an SPF (Sender Policy Framework) record set for the domain name, that won’t help anything at all so you should have that set as well.
But in the end, the PTR is really the most important thing followed by the SPF.
Past both of those is the concept of DKIM (DomainKeys Identified Mail) and it’s use to validate mails. But in my experience, most server setups just need to get a PTR record set coupled with an SPF for SPAM flagging to disappear.
You should only deal with DKIM stuff if you have no other choice; not because it’s hard to setup but it’s not going to mean much of anything without valid PTR and SPF records in place.
Though, it seems like Google Gmail servers have been flagging my
emails as “Junk” for a very long time but other providers, such as
Yahoo Mail, don’t. Creating more email accounts didn’t help. I have
also used email accounts that belonged to different domains.
How can avoid Gmail servers from flagging my emails as “unwanted?”
The issue is most likely you don’t have a proper PTR record or SPF record setup for the server. Remember: Any server in the world can send emails and SPAM protection is a scoring system and not an exact science.
What is a PTR (reverse DNS) record?
Simply put a PTR record is a reverse DNS record that connects an IP address to a hostname. Might sound like a standard hostname lookup, but it’s not at all. It’s the opposite: A PTR record is a record of what hostname an IP address is assigned to from the point of view of the hosting service that assigned that server an IP.
So if your server’s IP address is
123.456.789.0 then a PTR record lookup for that IP address would have to match your server’s hostname. But that value would be set not in a DNS entry as you might know it, but within the DNS servers that are connected to the hosting service itself.
This is a cross-reference check against SPAMmers since the reality is anyone can setup an actual basic mail server on most any PC in the world. But just because a server can send mail doesn’t mean what it sends is valid. What a PTR record does is basically “vouch” for any mail coming off of a server at that IP address and says, “Okay, you got an email from
example.com off of one of our servers? Let me check and see if that server is associated with
example.com?” The answer to that question would either be, yes that server is allowed to send emails for
example.com or no, we have no clue what that is… Do what you wish with that mail.
As for how to set a PTR record, it depends on your server’s hosting service and policies. Some service will allow you to independently set the PTR record via a control panel. Others will make you contact them—either by email, phone or mail—to have a record set.
For example I know Amazon’s EC2 setup allows you to make a request via a web form for getting a PTR record set and there is no guarantee they would approve a PTR record change; although most of the time they do. But places like Rackspace just let you set those values on your own without the need to ask for permission.
To check your server’s PTR record, you can use a tool like this MXToolbox “Reverse IP Lookup” tool. Or if you are comfortable with the command line in Linux/Unix just run a command like this:
dig -x 123.456.789.0
What is an SPF (Sender Policy Framework) record?
Another piece of the basic puzzle of getting mail to not be flagged as SPAM is to ensure a proper SPF record is set. A deep explanation of what an SPF record is can be found on the official SPF website. But this MXToolbox “Sender Policy Framework (SPF) Record Lookup” tool explains it quite nicely:
Sender Policy Framework (SPF) records allow domain owners to publish a
list of IP addresses or subnets that are authorized to send email on
their behalf. The goal is to reduce the amount of spam and fraud by
making it much harder for malicious senders to disguise their
To set an SPF record, you would need to set a TXT record in the DNS record for your domain name that would look something like this:
v=spf1 mx a ptr ip4:123.456.789.0 a:example.com include:example.com ~all
That basically says that any hostname or IP address listed in that SPF is allowed to send emails on the behalf of
example.com. This example is pretty simple, but the benefit of an SPF record is let’s say you have 1/2 a dozen servers connected to your hostname and they all have different IP addresses. An SPF record that would include the IP addresses of those 1/2 a dozen servers would basically “vouch” for the validity of mails being sent from that IP address on behalf of that hostname.