all mails going to gmail SPAM (sendmail on centos) 127.0.0.1 problem?

Question

UPDATE ON SPF CHECK http://www.openspf.org/Why:

The SPF check gives me this: An SPF-enabled mail server rejected a message that claimed an envelope sender address of [email protected]. An SPF-enabled mail server received a message from ourdomain.com (x.x.x.X) that claimed an envelope sender address of [email protected]. The domain ourdomain.com has authorized ourdomain.com (x.x.x.x) to send mail on its behalf, so the message should have been accepted. It is impossible for us to say why it was rejected

UPDDATE: I am using Google Apps to send email from and receive email from. Maybe this helps in researching our problem. We only have MX records for gmail set up and are now thinking this might be an issue? If a mailserver receives an email from www.ourdomain.com and cannot find an MX record for that IP, that might be bad or not?

all our mails are going to the gmail spam folder. Mails are not spammy or bulky, just registration confirmation emails from our web app.

The SPF headers give me the following

Received-SPF: pass (google.com: best guess record for domain of [email protected] designates x.x.x.x as permitted sender) client-ip=x.x.x.x;
Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of [email protected] designates x.x.x.x as permitted sender) [email protected]
Received: from www.ourdomain.com (localhost [127.0.0.1])

where x.x.x.x is our full IP address

UPDATE my complete mail and headers are now:

Delivered-To: [email protected]
Received: by 10.216.183.13 with SMTP id p13cs84787wem;
        Sat, 13 Nov 2010 09:00:00 -0800 (PST)
Received: by 10.229.214.139 with SMTP id ha11mr3256460qcb.235.1289667599435;
        Sat, 13 Nov 2010 08:59:59 -0800 (PST)
Return-Path: <[email protected]>
Received: from www.ourdomain.com (www.ourdomain.com [x.x.x.x])
        by mx.google.com with ESMTP id u7si11134289qco.191.2010.11.13.08.59.58;
        Sat, 13 Nov 2010 08:59:59 -0800 (PST)
Received-SPF: pass (google.com: domain of [email protected] designates x.x.x.x as permitted sender) client-ip=x.x.x.x;
Authentication-Results: mx.google.com; spf=pass (google.com: domain of [email protected] designates x.x.x.x as permitted sender) [email protected]
Received: by www.ourdomain.com (Postfix, from userid 48)
    id 5AB8F1C881; Sat, 13 Nov 2010 11:59:58 -0500 (EST)
To: [email protected]
Subject: Signup confirmation needed
From: Ourdomain.com <[email protected]>
Reply-To: Ourdomain.com <[email protected]>
MIME-Version: 1.0
Content-type: text/html;charset=UTF-8
Date: Sat, 13 Nov 2010 16:59:58 +0000
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Message-Id: <[email protected]>

Hi! We're thrilled to have you on board!<br /><br />You are now just 1 t=
iny step away from securing your shiny new beta-account.<br /=
>Please click the following link to confirm.<br /><br /><br /><br /><a h=
ref=3D"http://www.ourdomain.com/default/beta/regconfirm/guid/7a8344e1ae=
04062c9c2495429255b5a0/id/76">Confirm your beta subscription</a><br /><b=
r /><br /><br />Have a good day!<br /><a href=3D'http://www.ourdomain.com.com'>ourdomain.com.com</a>

ps: I have set a correct SPF record that allows our x.x.x.x ip to send emails

UPDATE:

how can we make sure that google doesn't see us as spam. I've read that gmail will get an email from @ourdomain.com and it will run an nslookup or something to see if we actually have a receiving MX server set up?

Can someone confirm this and give me the nslookup command that I can test with. I'm confused as nslookup on ourdomain.com gives the correct MX records, but mxrecord on WWW.ourdomain.com doesnt.

The hostname of the machine we are sending with is www.ourdomain.com. May that be a problem?

Solution 1

Have you changed your hostname? If the hostname of the server is localhost, localhost.localdomain, contains an IP address or doesn't resolve to your server you'll get this issue. Change it with:
hostname yourdomain.com and also in /etc/sysconfig/network.

Restart sendmail and then telnet to your server on port 25, it should say something like: 220 yourdomain.com ESMTP Sendmail, if not you may need to edit a sendmail config file as well.

In general, I find you will get spammed for one of the following reasons:

• Bad hostname (as above)
• No reverse DNS
• No SPF record
• You're blacklisted (Google for blacklist checker)
• You're sending spam.

Good luck.

Solution 2

Google has a support channel for this: http://mail.google.com/support/bin/request.py?contact_type=bulk_send

Also, try running your mail through SpamAssassin and see if it flags anything surprising.

Solution 3

1- You are not providing full information. For example there are more Received: lines in your header and not just one.

2- The 127.0.0.1 line is OK. From the information that you have provided in comments, the sendmail daemon accepts mail on 127.0.0.1. Your php script submits email there, or forks the sendmail executable which in turn submits email there (check your submit.mc / submit.cf to verify this)

3- The fact that even with postfix you get the same results makes it more probable that the problem is elsewhere, like

4- You state that you have an identical setup with a different domain / ip that is working fine. Even identical setups are never identical. Have you documented the process of deploying the "good" setup? Repeat it on the problematic one (with changes where appropriate). Do the results persist?

5- Add the IP address from the "good" setup to the SPF record. Send an email from this address. Is it delivered OK? If yes, then send an email that has the exact content with the ones that get labeled as spam. Is it deivered OK?

6- Check whether your domain name and/or IP in question are included in any DNSBL.

7- Finally, post the domain name. It may help.

Solution 4

Regarding your Update #2: Greylisting is not the problem here.

Solution 5

Long story short: it is impossible to guarantee that a remote site will treat all email from you as non-spam. Why? For one, because many sites have their own local block-lists and it is not always possible to know if you're in it.

All the other things mentioned here can help you out and make it more likely that your mail will be accepted and delivered to the inbox. By this I'm talking about:

• Matching forward and reverse dns entries on the host sending mail
• Implementing SPF/DKIM for your domain
• Configuring a proper helo
• being able to receive email at the [email protected]

You have one really big thing going against you; you are probably trying to send email from "generic" IP space (hard to know since you are not giving us the IP). In general, many people block outright any mail that originates from "the cloud," providers like Google and Amazon make it easy to sign up and get a server instance but the IP address is not really "yours." Hence, there is no way to assure that the mail is legit. Take a look at the r-whois for your IP address to see about this. For example, if I use the gnu jwhois client and do whois 74.125.83.198 (to check the sending address of a Google notification email) I get output that shows Google owns the IP, postal address, etc... Generic space will show information about an ISP, or worse...

To sum up, you will have better results by setting up your own IP space to send outgoing mail.

View more solutions

Comments

[Admin]

Does this happen with other large email services (ie: yahoo)?

[Admin]

yes it does, with hotmail, gmail, yahoo and even outlook, but I may need to say that I'm using Google Apps in the mx records. check my last update

[Admin]

What happens if you try it without the HTML in the main body of the message? And also without ourdomain.com.com which seems odd. And also the 3D is another thing spammers often do.

[Admin]

Without knowing your sending IP address it will be tough to help

[Admin]

It might help if you shared your actual domain name w/ us? (I assume it's not really ourdomain.com, which has no SPF record).

[Admin]

Agreed, you won't get anywhere on this without revealing the IP/Domain. I'm guessing you have SPF setup wrong, Google is very particular about SPF if you have it enabled.

[solsol]

thanks, my hostname is indeed set to my domainname and reverse dns is resolving like it should... any other ideas?

[James L]

have you tried the telnet check? It's possibly sendmail is storing a default hostname somewhere. If not, and you're not blacklisted or sending spam, you need to check Google's FAQs (see @dfrankes answer)

[solsol]

telenet gives me:

[solsol]

220 www.ourdomain.com ESMTP Sendmail 8.13.8/8.13.8;

[solsol]

any idea on where that localhost / 127.0.0.1 is coming from ?

[solsol]

sendmail.mc file has the following line, is that ok? DAEMON_OPTIONS(`Port=smtp,Addr=127.0.0.1, Name=MTA')dnl

[solsol]

I just contacted them... strange thing is, an identical setup on another domain/ip is delivering just fine...

[solsol]

switched to postfix, no improvements...

[adamo]

The DAEMON_OPTIONS line is OK

[adamo]

Could it be possible that the IP in question is in some DNSBL? Have you checked that?

[solsol]

yup, i checked, but we are not blacklisted

[solsol]

1. check my update with full mail & headers above

[solsol]

4. the other machine is in spam as well (I must have clicked "this is not spam" before on that mail and thought the machine was ok). Tests on new email addresses from both machines go to spam in hotmail/gmail

[solsol]

5. the ip is already in the SPF: v=spf1 mx a a:www.ourdomain.com ip4:x.x.x.x include:_spf.google.com -all

[solsol]

6. nothing is blacklisted in the tools I've checked

[adamo]

If you send normal mail from these IP addresses to Google, what happens to these messages? Do they get into the Spam folder too?

[solsol]

thanks, but this didn't resolve the issue...

[solsol]

except for DKIM, all settings are ok

[Artem Fedotov]

May I have your domain name? That would help to check SPF Record.

[solsol]

Do you need our SPF record details?

[solsol]

should the hostname be "ourdomain.com" or "mail.ourdomain.com" ? Does that make a difference?

[Artem Fedotov]

I would like to test your SPF record. You can test your records at and check openspf.org/Why

[adamo]

As is evident by the long version of the headers given, the suggestion for editing the PHP.ini will not resolve the issue. As a sidenote, localhost is perfectly valid in accepting local email, which will then forward to wherever it must.

[solsol]

what do you mean by "normal email"? It gets in spam when sending from php with mail() and when sending through telnet

[solsol]

@maniargaurav, check my update above for results from the SPF check

[adamo]

"Normal" email was supposed to mean email sent to the Google hosted domain from a mail client on the machine (like mutt, pine, etc) and not php.

[solsol]

sorry about keeping the real domain name off this page, is there a way to PM the domain name?

[Artem Fedotov]

@solsol I am not able to send you PM. Please send me details about domain name.