4

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?

6
  • Does this happen with other large email services (ie: yahoo)?
    – d-_-b
    Nov 17, 2010 at 8:27
  • 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
    – solsol
    Nov 17, 2010 at 23:00
  • 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.
    – user47584
    Nov 18, 2010 at 18:47
  • Without knowing your sending IP address it will be tough to help
    – JGurtz
    Nov 18, 2010 at 18:54
  • 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).
    – user47584
    Nov 18, 2010 at 18:55

7 Answers 7

6

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.

9
  • thanks, my hostname is indeed set to my domainname and reverse dns is resolving like it should... any other ideas?
    – solsol
    Nov 10, 2010 at 16:25
  • 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)
    – James L
    Nov 10, 2010 at 16:44
  • telenet gives me:
    – solsol
    Nov 10, 2010 at 17:59
  • 220 www.ourdomain.com ESMTP Sendmail 8.13.8/8.13.8;
    – solsol
    Nov 10, 2010 at 17:59
  • any idea on where that localhost / 127.0.0.1 is coming from ?
    – solsol
    Nov 10, 2010 at 18:00
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.

3
  • I just contacted them... strange thing is, an identical setup on another domain/ip is delivering just fine...
    – solsol
    Nov 10, 2010 at 19:03
  • Could it be possible that the IP in question is in some DNSBL? Have you checked that?
    – adamo
    Nov 13, 2010 at 19:51
  • yup, i checked, but we are not blacklisted
    – solsol
    Nov 13, 2010 at 20:33
1

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.

7
  • 1. check my update with full mail & headers above
    – solsol
    Nov 14, 2010 at 0:07
  • 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
    Nov 14, 2010 at 0:07
  • 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
    Nov 14, 2010 at 0:09
  • 6. nothing is blacklisted in the tools I've checked
    – solsol
    Nov 14, 2010 at 0:09
  • If you send normal mail from these IP addresses to Google, what happens to these messages? Do they get into the Spam folder too?
    – adamo
    Nov 17, 2010 at 9:11
1

Try this Email Server Test and see if you get any recommendations useful for your setup.

1
  • except for DKIM, all settings are ok
    – solsol
    Nov 18, 2010 at 9:49
1

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

1

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.

0

In PHP.ini file please change localhost to your mail server name like mail.domainname.com. This would resolve the issue.

9
  • thanks, but this didn't resolve the issue...
    – solsol
    Nov 18, 2010 at 9:48
  • May I have your domain name? That would help to check SPF Record. Nov 18, 2010 at 11:26
  • We'd rather not put the domain out there right now, but the SPF records says in google: Received-SPF: pass
    – solsol
    Nov 18, 2010 at 11:38
  • Do you need our SPF record details?
    – solsol
    Nov 18, 2010 at 11:39
  • I would like to test your SPF record. You can test your records at and check openspf.org/Why Nov 18, 2010 at 12:23

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .