Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

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

I have postfix and dovecot installed on a Centos 6.4 production ( machine. The intent is to send all system and transactional messages and collect bounces. The email id's that resulted in a bounce are then flagged to prevent site from sending further messages to these id's.

I have the necessary SPF records setup on the DNS and PTR records setup on my hosting providers end. My MX records point to a different mail server where our staff sends and receives email.

My issue is though I have been able to send mail from the production machine I am unable to read bounces using my php snippet. Actually I do not even know if the bounces are reaching the machine!

I have a similar setup on my test ( machine with the same hosting provider the MX, SPF and PTR records are setup in a similar fashion i.e. the MX records point to another mail server where the staff sends and receives mail. On the test machine I am able to read the bounces using the PHP program.

The postfix logs /var/log/maillog on the production machine indicates a single bounce which was not initiated by the php program that send out the transactional messages Mar 3 03:15:03 bw postfix/smtp[22338]: 09420120CA3: to=,[999.999.999.999]:25, delay=0.9, delays=0.05/0.02/0.43/0.41, dsn=4.7.1, status=deferred (host[999.999.999.999] said: 451 4.7.1 Please try again later (in reply to DATA command))

Any idea what could be wrong?

share|improve this question
Your mail was tried for delivery and kept in deferred queue since the remote MTA told to retry sending later. So postfix will try to deliver the mail until maximal_queue_lifetime expires. More info here – clement Mar 3 '14 at 3:39
up vote 2 down vote accepted

Bounces will be returned to the relay system. You must arrange for it to forward the bounces back to your system for processing. It may be simpler to process the bounces on it than getting the bounces forwarded back to your system.

Do use a specific sending email address of the form "". It should be in an appropriate domain or sub-domain for your application.

In normal processing, you can expect some email to remain queued for a long time before being bounced. Normally, this will be in the range of 4 to 7 days.

Some systems will accept the mail before deciding whether to deliver it or not. If they are well behaved you will not see bounces from them as they would risk generating backscatter spam if they did send a bounce message.

EDIT: I would expect your email to be sent using the MX server which appears to be a different server than your web server. (Email sent from www. domains is unusual, and in my experience likely spam.) Using a second domain on the same server to send mail might be more appropriate. Neither of the domains you describe appear to be valid, so I can't verify your configuration.

If you want the bounces to remain on your web server, use it as the MX for itself, or just omit the MX record. Configure a postmaster address that can be used to send information back about configuration issues. Likewise an abuse address is recommended so that abuse reports can be sent to you. Both of these can be forward to users on the MX domain you refer to.

share|improve this answer
I do not use a separate relay system. Postfix is installed on the same server as the saas app and the domain points to the same machine. FYI : " If they are well behaved you will not see bounce.." I have a set of id's that I use that result in a bounce. I am able to see bounces from these addresses almost immediately on the test machine. "In normal processing, you can expect some email to remain queued for a long time before being bounced" - Waited for over a week! – sridhar pandurangiah Mar 3 '14 at 5:30
We're currently using a subdomain (mail.)that points to the same ip as the www to send out emails. We'll plan to move it to a smarthost in due course. I thought mentioning the domains on the post was inappropriate so had to abbreviate them. Nevertheless here you go - and (live servers), and (test servers). I have configured an abuse address will configure a postmaster address rightaway. – sridhar pandurangiah Mar 4 '14 at 6:12
Created the postmaster account. The bounced mails do not get delivered to the postmaster. – sridhar pandurangiah Mar 5 '14 at 7:44
Postmaster account is to enable administrators of other domains to contact your mail administrators. It should not be receiving bounce messages. Bounce messages will be sent back to the sending userid. – BillThor Mar 6 '14 at 1:30

Bill is right about the MX record causing the non returned mail. Basically, although SPF allows you to send mail, and the PTR record confirms it, the MX record pointing to another server means bounces will be sent back there.

When the remote mail server has to bounce the email, it will do an MX lookup on your domain, and it will send the email to that record. So, all your bounces will be headed back to that server.

You could create a subdomain on your server, then create an alias on the machine with the MX record, => That way you will receive all the bounces.

share|improve this answer
I have a similar setup on my test servers. I don't have this issue on the test machine. – sridhar pandurangiah Mar 5 '14 at 17:05
Just to drive home my point I have pasted the DNS entries here – sridhar pandurangiah Mar 5 '14 at 17:18
Why not read the RFCs? If the server that has to generate the bounce record (which is NOT a must) it will reply to the sender, if the domain of the sender has an MX record, the bounce record will be sent there! If the bounces are arriving on your test server, you need to find out what about your test server with the MX record is relaying them back, or if they are actually generated by your test server's postfix instance (for example, sending to remote destination timed out, or remote server replied with a 550). – NickW Mar 5 '14 at 17:22
I am doing just that. Will post back in a few hours – sridhar pandurangiah Mar 5 '14 at 17:27
Just an FYI, I may reply tomorrow ;) – NickW Mar 5 '14 at 17:30

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.