I have configured Postfix to be responsible for subdomain.example.com (google apps is responsible for example.com so I didn't want to mix the two).

As I mentioned in question title, SPF and DKIM always pass when I send mail locally from that host ($ mail xyz@gmail.com), but mails still end up in Spam folder.

The only thing missing is reverse DNS setup for subdomain.example.com and IP it's sending from, but I figured it won't matter, since SPF includes a:ip.add.re.ss, and since SPF passes...

Any ideas what else could I do to get them into inbox?

UPDATE: problem was instantly resolved as soon as Amazon removed my IP from Spamhaus PBL (see answer below).

  • dkim is not made for spam prevention/filtering, it just ensures that the messages is not tampered with along the way to the recipient. iirc Jun 17, 2011 at 8:00
  • I figured that much, but since email itself doesn't contain anything even remotely suspicious (lorem ipsum text as copy, hello as subject?) I really have no idea what could be triggering their spam flags...
    – mr.b
    Jun 17, 2011 at 8:05
  • is there no way to get the reason it is marked as spam from the spam filter? there could be lots of reasons. Jun 17, 2011 at 8:07
  • the lack of a reverse DNS record triggers most MTAs, while SPF does not. Checking for a PTR record is probably the oldest trick in the book, and even the laziest admins have this implemented. Whether or not SPF can provide the same is not a question here, since the receiving MTA looking for a PTR will not look for it in SPF
    – dyasny
    Jun 17, 2011 at 8:10
  • @dynasty: I am fully aware of that, however, I don't own the IP block, so it's not up to me to configure my PTR. I'm still waiting for my provider to configure PTR for my IP.. I'll see if problem goes away after they do that.
    – mr.b
    Jun 17, 2011 at 8:15

1 Answer 1


I think I found two possible reasons why mails are listed as spam.

First, as someone previously suggested (and as I was already aware of), missing PTR for sending server could be main cause.

Second, since this server is hosted in AWS cloud, and Amazon has worked with Spamhaus to add all their IP ranges to PBL by default, it could also be the reason... From what I know, PBL has certain weight in deciding if email will be marked as spam or not. Also, Amazon has blocked requests for removal of their IP's from Spamhaus PBL list directly - requests have to go through Amazon. Luckily, they offer a way to remove Elastic IP from this list, and to setup a PTR record, while you're at it.

So I'll see what happens after this process is complete.

UPDATE: Amazon added correct PTR record, and it didn't resolve the problem. However, after they removed IP from Spamhaus PBL, mails stopped being sent to spam. Meanwhile, many SMTP servers stopped accepting mails from my SMTP because of this PBL list, which was also resolved when PBL record was removed.

  • The PTR record not matching the From: domain is an incredibly stupid way of blocking spam. As you've pointed out, there are plenty of entirely legitimate reasons why the PTR can not and will never match. Anyone blocking incoming messages (or even weighting their scoring system for it) needs a good slap. Jun 17, 2011 at 12:28
  • I should add that I don't think many people do this sort of blocking, so you shouldn't worry too much about it. You may find more people scoring for the SMTP EHLO domain not matching the From: domain. There are still legitimate reasons why these don't match; but the cases are nowhere near as common. Jun 17, 2011 at 12:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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