7

I have 2 web apps running on the same server. The first is www.nimikri.com and the other is www.hourjar.com. Both apps share the same IP address (75.127.100.175). My server is through a shared hosting company.

I've been testing my apps, and at first all my emails were being delivered to me just fine. Then a few days ago every email from both apps got dumped into my spam box (in gmail and google apps). So far the apps have just been sending emails to me and nobody else, so I know people aren't manually flagging them as spam.

I did a reverse DNS lookup for my IP and the results I got were these:

100.127.75.in-addr.arpa NS DNS2.GNAX.NET.

100.127.75.in-addr.arpa NS DNS1.GNAX.NET.

Should the reverse DNS lookup point to nimikri.com and hourjar.com, or are they set up fine the way they are?

I noticed in the email header these 2 lines:

Received: from nimikri.nimikri.com

From: Hour Jar <invite@hourjar.com>

Would the different domain names be causing gmail to think this is spam?

Here is the header from one of the emails. Please let me know if any of this looks like a red flag for spam. Thanks.

Delivered-To: bapublic@gmail.com
Received: by 10.231.157.85 with SMTP id a21cs54749ibx;
        Sun, 25 Apr 2010 10:03:14 -0700 (PDT)
Received: by 10.151.130.18 with SMTP id h18mr3056714ybn.186.1272214992196;
        Sun, 25 Apr 2010 10:03:12 -0700 (PDT)
Return-Path: <invite@hourjar.com>
Received: from nimikri.nimikri.com ([75.127.100.175])
        by mx.google.com with ESMTP id 28si4358025gxk.44.2010.04.25.10.03.11;
        Sun, 25 Apr 2010 10:03:11 -0700 (PDT)
Received-SPF: neutral (google.com: 75.127.100.175 is neither permitted nor denied by best guess record for domain of invite@hourjar.com) client-ip=75.127.100.175;
Authentication-Results: mx.google.com; spf=neutral (google.com: 75.127.100.175 is neither permitted nor denied by best guess record for domain of invite@hourjar.com) smtp.mail=invite@hourjar.com
Received: from nimikri.nimikri.com (localhost.localdomain [127.0.0.1])
 by nimikri.nimikri.com (8.14.3/8.14.3) with ESMTP id o3PH3A7a029986
 for <bapublic@gmail.com>; Sun, 25 Apr 2010 12:03:11 -0500
Date: Sun, 25 Apr 2010 12:03:10 -0500
From: Hour Jar <invite@hourjar.com>
To: bapublic@gmail.com
Message-ID: <8441961.01272214990893.JavaMail.mailer@nimikri.com>
Subject: brian@hourjar.com has invited you to New Event
MIME-Version: 1.0
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

ChrisF, here is the body of the message:

<h1>Hour Jar</h1><h3>New Event</h3><p>To view the event, please go to hourjar.com/event?event.id=2&guest.id=2</p>

Chaitanya, yes every single message from my server is going to spam.

BillThor, thank you for answering my question about rDNS. I will fix the issues you pointed out and see if they help.

Sam Cogan
  • 38,158
  • 6
  • 77
  • 113
  • 2
    The body of the e-mail might have a bearing on this as well - can you post that (or is it confidential). – ChrisF Jun 05 '10 at 22:37
  • +1. I am interested to see what the community has to say too. I don't know much about spam detection. – Nate Jun 05 '10 at 22:38
  • 1
    Shouldn't this be on Serverfault or Meta? It's not really a programming question ... – Jan K. Jun 05 '10 at 22:40
  • 1
    I don't know why it would go on Meta, but I agree that it belongs on Server Fault because it seems more like a DNS/server question. – Sasha Chedygov Jun 05 '10 at 22:45
  • Every mail sent to gmail from the app is going into the spam? I once had a similar problem, I had 10-15 mails sent at a time and few ended up in spam. –  Jun 05 '10 at 22:46

5 Answers5

3

Jeff recently had a post on his blog titled So You'd Like to Send Some Email (Through Code) which details a number of techniques you should use to ensure that your email gets delivered. In short:

  • check your reverse PTR DNS record
  • configure DomainKeys to sign your outgoing email
  • set up SenderID
  • test what you've done
Greg Hewgill
  • 6,749
  • 3
  • 29
  • 26
1

Ensure your system is not on a blacklist: http://www.mxtoolbox.com/blacklists.aspx

Publish SPF records for your domain name, as well as DomainKeys if you can (these likely won't help in most cases, but why not).

Yann Ramin
  • 191
  • 3
1

SPF and domainkeys don't actually work for making your messages look less like spam - spammers quite often have them too.

The main things to ensure are:

  • You have a correctly configured reverse DNS for your mail relay
  • Your message IS NOT SPAM
  • You are not sharing a mail relay with anyone who is really sending spam (this is a key point)
  • You do not forge or invent unroutable sender (especially envelope sender) address(es). This sounds obvious but it's surprising how many people try to send mail from webserver@localhost and wonder why it never arrives. Set the envelope sender to a domain you control; ensure that if you happen to have SPF set up, it is allowed to send. Don't send messages generated by one of your users with their address as an envelope sender (by all means set reply-to if you like)

Normally the reason your messages don't arrive is that you're on blacklists or are considered to have a bad reputation. This mostly happens because you share a relay with a spammer, or are one yourself.

If you have a reputation problem, but cannot shake it off, it may be easier to allocate a new IP address (but make sure in future you don't send spam from it - not even accidentally)

We have also seen problems where some misguided sys admins decide that IP blocks allocated by certain IP registries aren't "good enough" to send mail to them. These misguided individuals often work for major US corporations, and decide that all non-ARIN IP addresses are used by spammers. Sadly, there is no way to work around this except for using ARIN-registered IP space for your relays to relay messages to these losers.

Disclaimer: I work for a security company who filter spam.

MarkR
  • 2,898
  • 16
  • 13
0
  • Avoid any string that looks like spam.

Most Spam checking these days is Bayesian, which means that that your message is checked using a fuzzy algorithm that tries to guess if resembles known Spam or Ham (good) messages (mainly by checking the frequency of common spam words and phrases).

  • Send individual messages to each recipient instead of copies.

It is better to send an individual message to each recipient, rather than using multiple addresses in the BCC field because many spam filters (and many ISP's) automatically flag multiple recipients as spam.

  • If possible send via your ISP's mail server rather than using a local SMTP Server.

Messages sent from a mail server running on your computer may be flagged as spam because some mail servers will try to contact the source IP of the sending server (which will fail with a local IP address).

  • Try with smaller batches of e-mails.

It would appear that some of the big mail hosts such as Hotmail will recognize when an identical message is sent to a large number of subscribers at one time so you should stagger the delivery of your messages [...] to send your messages in small batches.

  • Minimize your use of attachments.
  • Make sure the computer sending the email has a Reverse PTR record.

What's a reverse PTR record? It's something your ISP has to configure for you -- a way of verifying that the email you send from a particular IP address actually belongs to the domain it is purportedly from.

  • Configure DomainKeys Identified Mail in your DNS and code.

What's DomainKeys Identified Mail? With DKIM, you "sign" every email you send with your private key, a key only you could possibly know. And this can be verified by attempting to decrypt the email using the public key stored in your public DNS records.

  • Set up a SenderID record in your DNS.

To be honest, SenderID is a bit of a "nice to have" compared to the above two. But if you've gone this far, you might as well go the distance. SenderID, while a little antiquated and kind of.. Microsoft/Hotmail centric.. doesn't take much additional effort.

SenderID isn't complicated. It's another TXT DNS record at the root of, say, example.com, which contains a specially formatted string documenting all the allowed IP addresses that mail can be expected to come from.

Sources and additional information:

Matthieu
  • 117
  • 7
-1

You are missing an rDNS mapping. This indicates your email server is not correctly configured and start you on the way to being flagged as SPAM. Missing SPF record in DNS won't help, but won't hinder much either.

Non-standard formatting of the body of the mail will also create problem. Unix default is to use line-feed line termination. The standard requires carriage-return line-feed termination. Also you need to ensure lines are less than 80 characters in length.

Being standards compliant will go a long way to resolving your issues. Don't be discouraged, I see a lot of large corporations whose mailings get high spam rating because they are non-compliant.

BillThor
  • 27,354
  • 3
  • 35
  • 69