Web Applications Stack Exchange is a question and answer site for power users of web applications. It only takes a minute to sign up.
Sign up to join this community
Whenever I send a mail from [email protected] to a Gmail account, Gmail treats it as spam.
I'm talking about the one e-mail I send to a prospect after I've met him (it is surely non-spam mail). It's happened several times already:
"Hey!, you never sent that e-mail you promised me" the prospect says.
"How come...? I did send it. Check the spam e-mail" I answer.
"Oh, there it is..."
I think it has to do with example.com not being a well-known domain.
How/Where should I complaint about this?
Jeff Atwood had a really good post on things to do to help your email get through. This made a huge difference for the company I work for. Some highlights:
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.
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
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 identity.
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.
A small update for anyone finding this in 2018. This could be considered as an addition to @JakeGould's excellent answer (which leaves out DMARC).
Google applied some heavier spam and phishing filter rules with the new version of Gmail. If your e-mails end up in someone's spam, make sure you've configured SPF, DKIM & DMARC properly. You can use various tools to check your domain's MX rules. For instance - MXToolbox or Google's Toolbox.
You might also want to verify your site with Postmaster to see the reputation of your e-mail domain & ip ranges.
Here's a great resource from Google on how to configure DMARC via GSuite - https://support.google.com/a/answer/2466580?hl=en
If you found all these terms new like I did - here's a great 3 post series explaining all three terms by returnpath.com
Free e-mail services like Gmail, Hotmail, Yahoo and similars get tons of spam mails per day. That's why they hardened incoming e-mail policies and they apply very concrete and strict rules so they make sure any incoming mail is unlikely to be spam, otherwise send it to the Junk folder.
First off, you should have a valid SPF policy. You don't mention what e-mail MTA are you running, but configuring a SPF policy is pretty straight-forward and is MTA-agnostic. It is basically a DNS record which says from what IPs/domains are your domain allowed to send e-mail. If an e-mail is received from within a different IP address than the ones announced in your DNS record, it will quite probably end up in the Junk folder. There are some links that might help you:
Next, DKIM is getting more and more important. This basically signs your e-mail with a private key (generated by you), and you generate a DNS record with the public key so any recipient domain can verify if the mail content has been or not forged.
There's another way to allow others verify your e-mails, DMARC. It is basically the combination of the two above and you decide what should others do with an e-mail that doesn't pass the DMARC restrictions, relaying on them the final decision. DMARC allows you to receive reports as well (from other domains running DMARC checking).
Next (and unfortunately there's not much you can do about it, at least at the beggining), there's a term called IP reputation. Many mail services use some services which will tell them if an IP address has good or bad reputation. If your IP has been used previously to send spam, even before you owned it, it will most likely have a bad reputation. If your IP address is unknown, it will be untrusted as well. You'll have to gain reputation by telling your recipients to "whitelist" your emails. If many people do it, the free e-mail provider will know you are not harmful and will apply a softer policy towards you.
There are more concepts about it but these are the most important. Just configure what you can configure and be patient.
This page might be helpful to you:
https://mail.google.com/support/bin/answer.py?answer=81126
While it applies to bulk-mail messages, there is quite a bit of information about why messages can be marked as spam. I don't know anything about your specific information, but hopefully you'll be able to see something that will be helpful.
