Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top


The SPF check gives me this: An SPF-enabled mail server rejected a message that claimed an envelope sender address of An SPF-enabled mail server received a message from (x.x.x.X) that claimed an envelope sender address of The domain has authorized (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 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 ( best guess record for domain of designates x.x.x.x as permitted sender) client-ip=x.x.x.x;
Authentication-Results:; spf=pass ( best guess record for domain of designates x.x.x.x as permitted sender)
Received: from (localhost [])

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

UPDATE my complete mail and headers are now:

Received: by with SMTP id p13cs84787wem;
        Sat, 13 Nov 2010 09:00:00 -0800 (PST)
Received: by with SMTP id ha11mr3256460qcb.235.1289667599435;
        Sat, 13 Nov 2010 08:59:59 -0800 (PST)
Return-Path: <>
Received: from ( [x.x.x.x])
        by with ESMTP id u7si11134289qco.191.2010.;
        Sat, 13 Nov 2010 08:59:59 -0800 (PST)
Received-SPF: pass ( domain of designates x.x.x.x as permitted sender) client-ip=x.x.x.x;
Authentication-Results:; spf=pass ( domain of designates x.x.x.x as permitted sender)
Received: by (Postfix, from userid 48)
    id 5AB8F1C881; Sat, 13 Nov 2010 11:59:58 -0500 (EST)
Subject: Signup confirmation needed
From: <>
Reply-To: <>
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: <>

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=
04062c9c2495429255b5a0/id/76">Confirm your beta subscription</a><br /><b=
r /><br /><br />Have a good day!<br /><a href=3D''></a>

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


how can we make sure that google doesn't see us as spam. I've read that gmail will get an email from 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 gives the correct MX records, but mxrecord on doesnt.

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

share|improve this question
Does this happen with other large email services (ie: yahoo)? – d-_-b Nov 17 '10 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 '10 at 23:00
What happens if you try it without the HTML in the main body of the message? And also without which seems odd. And also the 3D is another thing spammers often do. – barrycarter Nov 18 '10 at 18:47
Without knowing your sending IP address it will be tough to help – JGurtz Nov 18 '10 at 18:54
It might help if you shared your actual domain name w/ us? (I assume it's not really, which has no SPF record). – barrycarter Nov 18 '10 at 18:55

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 and also in /etc/sysconfig/network.

Restart sendmail and then telnet to your server on port 25, it should say something like: 220 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.

share|improve this answer
thanks, my hostname is indeed set to my domainname and reverse dns is resolving like it should... any other ideas? – solsol Nov 10 '10 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 '10 at 16:44
telenet gives me: – solsol Nov 10 '10 at 17:59
220 ESMTP Sendmail 8.13.8/8.13.8; – solsol Nov 10 '10 at 17:59
any idea on where that localhost / is coming from ? – solsol Nov 10 '10 at 18:00

Google has a support channel for this:

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

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

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

2- The line is OK. From the information that you have provided in comments, the sendmail daemon accepts mail on Your php script submits email there, or forks the sendmail executable which in turn submits email there (check your / 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.

share|improve this answer
1. check my update with full mail & headers above – solsol Nov 14 '10 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 '10 at 0:07
5. the ip is already in the SPF: v=spf1 mx a ip4:x.x.x.x -all – solsol Nov 14 '10 at 0:09
6. nothing is blacklisted in the tools I've checked – solsol Nov 14 '10 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 '10 at 9:11

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

share|improve this answer
except for DKIM, all settings are ok – solsol Nov 18 '10 at 9:49

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

share|improve this answer

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

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 (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.

share|improve this answer

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

share|improve this answer
thanks, but this didn't resolve the issue... – solsol Nov 18 '10 at 9:48
May I have your domain name? That would help to check SPF Record. – maniargaurav Nov 18 '10 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 '10 at 11:38
Do you need our SPF record details? – solsol Nov 18 '10 at 11:39
I would like to test your SPF record. You can test your records at and check – maniargaurav Nov 18 '10 at 12:23

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.