Hosting affect email being marked as spam?

[AuctionHugh]

I use very inexpensive shared hosting for our main website, and the email through this hosting is what I use for my main email address, which is quite important as you can imagine.

Quite a few folks I email say they find my emails in their spam folders. These are normal emails where they are the only recipient, their email address is not in the subject line, etc etc, so these should not be caught under normal rules.

Is it possible that having a small shared host is causing my email to be marked as spam?

If I went with hosting from one of the big boyz, like one and one or godaddy or even (shudder) registrar.com that a much larger percentage of my emails might get through?

Your thoughts please?

[speed]

The host themselves shouldn't matter providing their IP addresses are not flag in one the spam databases and DNS etc is configured properly for the mail server.

You can possibly improve delivery rates by adding an SPF record for your domain. Once you add an SPF record you must always make sure you send via a permitted server. You can also enable domainkeys on your domain. We create new accounts with the SPF record set so only mail from the server hosting the account is flagged as valid.

If your host is using cPanel then you can set this up within it, if not you may have to talk to them if there's not an option in the control panel.

[deepsand]

Without knowing the content of the missives in question, we cannot say that "these should not be caught under normal rules."

I frequently see certain e-mails from WPW itself, along with those from other known legitimate senders, flagged as spam by BrightMail.

[villageloop]

You can always run your mail through google's mail servers (if you dont mind their privacy policy).
They have some of the most robust and reliable servers out there right now and all you have to do is sign up for a free google apps account (google.com/a/) - you will have to dig for the free version, but trust me, it is there.
Then just edit your MX records to point to google's mail servers instead of your hosts.

We offer website hosting, yet the majority of our support involves email problems beyond our control.
Once it is setup, google's mail servers are much more reliable and accepted than any small (and even some major) web hosts can provide.

[sharonjackson]

I wonder what you are putting in your subject line? I make rules from spam emails all the time..anyone who sends me something with free, or dear friend, or Ghana, inheritance or lottery ...stuff like that in the body or subject line, all gets slammed into my deleted folder.

Perhaps you might give some thought to the kinds of wording you are using?

[jawn_tech]

Hosting has nothing to do with it. Spam filters work by way of blocking addresses and / or domains. (Or individual filters / preferences). It's that simple.

No matter what host you're on, you'll always find a percentage of intended recipients finding their message in the spam folder. Small businesses and mega corps run into the same thing, hence their pleas for everyone to check to make sure everyone adjusts their settings to allow their newsletters and correspondence.

Most of the time it's user error, recipients who inadvertently flagged a message as spam instead of archiving it, with the click of a wrong button. (Or as sharonjackson said, it could also be to individuals' filter settings)

[spiderbait]

Contrary to some of the views expressed here, I believe your webhosting can make a difference in your email deliverability.

All of the other advice is useful and relevant, but may not solve the problem.

This is because a poorly configured mailserver can fail to provide information considered necessary by incoming mailservers. The absence of certain headers, or the wrong information in certain headers can cause mailservers to mark incoming mail as spam.

Similarly, a cheaper host may keep costs low by not providing you with the ability to edit DNS zones by adding a SPF record. And they may not install or maintain other authentication protocols such as DomainKeys.

Without knowing more about your host, I can't say that this is definitely a problem for you. But a more professional host will definitely provide you with the tools you need to manage your email reputation.

Hope this helps.

[jawn_tech]

This is because a poorly configured mailserver can fail to provide information considered necessary by incoming mailservers.

I can agree with that. If that's the case, it's a level of amateur email-hosting that should definitely be avoided, and definitely not the status-quo. Imo, it's more of a technical issue than a flagging issue, even though the message could be filtered as spam. In his case it is being delivered, it's just being delivered to the spam folder. Now my curiosity is piqued as to who the host is, but that's fine not divulging it. Aside from that, my advice would be to look at the percentage of emails being marked as spam, and also the email services of the recipients and see if there's anything in common.

[Terry Van Horne]

Hosting has nothing to do with it. Spam filters work by way of blocking addresses and / or domains. (Or individual filters / preferences). It's that simple.Not always... I use a spam program that stops mail from any domain on black listed server or a server that has a misconfigured DNS entry for the specified mail server. A single mail server can host several domains and users. For instance the clients I'm hosting says the mail comes from IWB**** although the sender etc is the client domain. Most spam filters are useless for the chronic abusers because they change domains and users with every mailing so the only way you stop them is with blocking all mail from that server. I often add email adresses to the Global Allow list to enable a domain to send email from the black listed server.

[AuctionHugh]

It is interesting how many ways there are to look at things like this, many opinions, many conflicting. I am sending normal business correspondence from outlook email through an SMTP ATT server (dynamic IP not fixed), with the sending domain being my own domain, to other fairly good sized organizations, with no spammy stuff in them except an image attached (in my signature).

I did pose a more specific question on dslreports.com related to a problem with one particular set of correspondence, and likewise got 10 different answers from 10 people including that one of the ATT (SBC) server IPs had been mistakenly on a blacklist for a while.

Email Bouncing - 503 Valid RCPT command must precede DATA - dslreports.com (http://www.dslreports.com/forum/r21451339-Email-Bouncing-503-Valid-RCPT-command-must-precede-DATA)

On another occasion, from another address, from a different host, some said the mailserver was misconfigured but others disagreed:

Email to certain address is bouncing! (Fixed - Thanks All!) - dslreports.com (http://www.dslreports.com/forum/r21350916-Email-to-certain-address-is-bouncing-Fixed-Thanks-All)

Due to the variety of opinions there and here I think I will probably never get this figured out, but I do still have a gut feeling that if my domain and/or email was hosted by one of the big guys I'd have less trouble with my recipient's mail systems marking it as spam.

[AuctionHugh]

You can always run your mail through google's mail servers (if you dont mind their privacy policy).
They have some of the most robust and reliable servers out there right now and all you have to do is sign up for a free google apps account (google.com/a/) - you will have to dig for the free version, but trust me, it is there.
Then just edit your MX records to point to google's mail servers instead of your hosts.

We offer website hosting, yet the majority of our support involves email problems beyond our control.
Once it is setup, google's mail servers are much more reliable and accepted than any small (and even some major) web hosts can provide.

Is there something online with a step by step on this? I think this might help a lot of people if it turns out to be as effective as you indicate.

[southplatte]

I believe hosting can have quite a bit to do with it. I recently moved my dedicated server to a different facility, different ISP, different static IP address. Interestingly, the static IP address I was assigned was listed in two rather obscure blacklists, but they were just enough that a certain percentage of recipients were not getting their emails. As soon as I requested removal of the IP from the blacklists email started going through normal. Many times a hosting platform has a large block of IP address and they do get recycled, so it is hard to say what was done with the IP in the past.

I also agree with adding the SPF record to the DNS to ensure deliver, as well as ensuring that the MTA (mail transport agent) on the server has been properly configured to send email properly and that it is not configured as an open-relay, aka a user must authenticate with the mail server before being allowed to send mail as many ISPs will block or mark as spam any mail coming from one that is an open relay.

[jonisolis]

Is there something online with a step by step on this? I think this might help a lot of people if it turns out to be as effective as you indicate.

I too would like to learn more about using google's mail servers. Is there a webpage with more info somewhere? Thanks!

[jonisolis]

Google mail info:

I found this:

Google Mail Servers Enable Backscatter Spam

Slashdot | Google Mail Servers Enable Backscatter Spam (http://tech.slashdot.org/article.pl?sid=08/04/08/2258246)

and this...

Configuring MX records

Configuring MX records - Google Apps for Administrators (http://www.google.com/support/a/bin/answer.py?hl=en&answer=33352)

[wige]

The thing that gets tricky when troubleshooting e-mail is that there are so many different systems involved to get a message through, and sometimes error messages don't come back correctly making it even harder to isolate the problem. I have seen and heard about so many various issues that tracking down a problem from the technical side can be virtually impossible, and then when you add in counter-spam issues it becomes even more complex.

For example, I have seen some hosts that would add a header to all outgoing e-mail generated by hosted sites containing "[spam]" so that they would get filtered, unless the party registered for the ability to send server-generated e-mails ahead of time. I know certain common e-mail software is configured to automatically add similar headers until the header is turned off by an administrator.

Because the problem you are encountering is a filtering issue and not a deliverability issue, I would try running the e-mails through a few checkers, such as SpamCheck (http://spamcheck.sitesell.com/) which will give an idea of problems that might get filtered. For an idea of some of the factors used to rate e-mails, check out the list here: SpamAssassin: Tests Performed: v3.0.x (http://spamassassin.apache.org/tests_3_0_x.html). This list contains all of the tests used by SpamAssassin in determining the spamminess of an e-mail.

Also, this blog posting: http://www.realfreewebsites.com/blog/dropped-emails-yahoos-gain/ goes in depth to issues related to sending e-mails to Yahoo after they implemented a new anti-spam system, and can give some additional insight into potential issues, including an issue based on your hosting company acknowledged by Yahoo.

[jawn_tech]

Great discussion. Another way to look at this is to rephrase the question, "will I get arrested for shoplifting because I'm wearing a blue parka?" No. But an exception to the rule is the rare circumstance of mistaken identity. So it can happen, but it's an issue with an officer or a witness who needs better glasses.

If someone's emails are being filtered as spam, and the recipient is on the same service as someone else receiving the emails without any problems, it's not an issue with the host. Likewise, if the sender on that host generally has recipients receiving his emails, then there's two sides to the coin. Is the issue with the host or is it with the filter.

However, if there's an issue with a shoddy host in which most messages aren't getting through, because it doesn't meet criteria, then yes of course it's possible. I see it as the exception rather than the standard.


In fact one user was told by Yahoo that: “…all shared hosting IPs are instantly flagged as suspect by them.”
Imho, hmm, not sure about that. (quote from the blog article) Imagine the millions of small businesses with shared hosting sites/email services not getting through to their customers. Plenty of yahoo users receive new emails all the time from shared hosts. I'd want to see Yahoo's public statement on that, considering they sell shared hosting themselves.

:)

[villageloop]

Is there something online with a step by step on this? I think this might help a lot of people if it turns out to be as effective as you indicate.

Here is the direct link to gettting started with google apps standard edition Google Apps for business – edition comparison (http://www.google.com/apps/intl/en/business/editions.html)
(it is kind of difficult to find a link to the standard without looking at the comparison)

There is link already posted to the google page on settingup your MX records, so I wont repost that.
(i am not sure about the backscatter spam link, so I cant comment on that)

And here is a link to thier general gettting started guide:
Getting Started - Google Apps for Administrators (http://www.google.com/support/a/bin/topic.py?topic=9192)

Again, please remember that google has thier own privacy policy and will most likely read your email and analyze it for what ever "non-evil" purposes it feels fit.
But if you are OK with this, I say go for it.

[spiderbait]

I am sending normal business correspondence from outlook email through an SMTP ATT server (dynamic IP not fixed), with the sending domain being my own domain, to other fairly good sized organizations, with no spammy stuff in them except an image attached (in my signature).

Hi again,

I thought I'd just jump back in with an observation/question.

I visited the dslreports.com forum and read the thread. And when I take that in context with your message I've quoted above, I get the sneaking suspicion that you're using AT&T as your outgoing server BUT, you've set up your Outlook to appear as though the email is coming from your own domain.

Is this the case?

If so, that can look like forged headers to some incoming servers and can lead to complete blocking (as in the thread on dslreports.com) or at the very least, spam scoring which could account for user level filtering you initially posted aboout (with email going into the spam folder).

A properly configured SPF record can probably solve this problem and is a good idea even if this isn't the cause of your difficulties.

You can see a thread I started some time ago which addresses SPF and other authentication methods: http://www.webproworld.com/webmaster-resources-discussion-forum/71035-protect-your-domains-email-reputation.html

Hope this helps.

[AuctionHugh]

My email address is firstname.m.lastname _aatt_ kallenweb.com.

I read and send this email through outlook 2007, usually through my at&t (formerly SBC) dsl connection.

My incoming pop server is mail.myhostname.net where myhostname is the name of my shared hosting company.

SBC/ATT will only allow you to send outgoing email on their ISP connection if you go through their smtp server. Thus my outgoing smtp server is smtpauth.sbcglobal.net and requires authentication, where I use the username and password equal to the one I use on my router to log into my dsl connection.

This is all I can set, really. My godaddy nameservers are set for ns1.myhostingname.net and ns2.myhostingname.net. On my control panel for kallenweb com, my mx records are set for
kallenweb.com MX 5 mail.myhostname.net

Beyond all this, I don't think I have a lot of control or choice about how my email is set up.

[speed]

I would say that is probably your issue. If AT&T have blocked port 25 then ask your hosting company for the alternate port, you should then be able to send through their server.

As you are sending via AT&T it doesn't matter which host you use, you will have exactly the same issue as you are only using the host for incoming not outgoing email.

Your SPF record should be adjusted as well, made tighter if you can use your host to send through or change to list your host +AT&T as valid senders only, at the moment it's all neutral.

[spiderbait]

I would say that is probably your issue. If AT&T have blocked port 25 then ask your hosting company for the alternate port, you should then be able to send through their server.

As you are sending via AT&T it doesn't matter which host you use, you will have exactly the same issue as you are only using the host for incoming not outgoing email.

Your SPF record should be adjusted as well, made tighter if you can use your host to send through or change to list your host +AT&T as valid senders only, at the moment it's all neutral.

I agree. This is exactly what I suspected.

Speed is right that you may be able to solve this if your host has an alternate port open to receive SMTP traffic. However, and this is important, since you're having to use your host's domain in the incoming server (mail.myhostname.net) you would probably have to use the same server for SMTP, which wouldn't really solve the problem by itself. Your mail would still be claiming to come from your domain, but the server name doesn't match your domain.

As I and Speed (and others) suggested, an SPF record is your best protection.

If you also upgraded hosting you would be able to use your own domain name in the POP and SMTP servers which would be the best long term solution (assuming you can find a way around AT&T's port blocking). I've got a handful of clients with similar restrictions from their ISPs and we're always able to get their host to provide an alternative port for SMTP.

Seriously, check out that post regarding SPF and email authentication. I'm almost certain that's your problem.

Good luck.

[spiderbait]

Hi again,

A further update. I just did a DNS report for your domain and learned that you do have an SPF record.

Unfortunately, it's poorly formed and is almost certainly responsible for some if not all of your current email troubles.

Your record is "v=spf1 ?all"

Which basically tells other mailservers to "soft fail" any mail claiming to come from your domain that doesn't originate from a server at your domain. Since you're not using your own domain to send mail, that's the source of the problem.

Soft fail means it's up to the server how it handles it. Some will automatically reject it, others will mark it as spam and still deliver it. Still others, may choose to deliver it normally.

Even though you're not sending mail through your host your SPF record should at the very least specify your host's mailserver domain (since your host is requiring you to use their domain's mailserver rather than your own). This is a perfect example of the misconfiguration risk I mentioned earlier since your host must have set up your SPF record in the first place.

But to work properly with your current email setup (using AT&T's SMTP server) your SPF record must contain sbcglobal.net as a permitted sender (and probably prodigy.net too since I noticed on the other forum that you seem to be using that server).

On the link I provided earlier you can find a link to a tool to help you generate the correct SPF for your situation. Then you can provide that SPF record to your host and hopefully they can update the record for you.

If they can do that, I think your problem will be solved.

Edited for correction: Sorry, I misquoted the SPF syntax. Here's the actual syntax for SPF records:
"+" Pass
"-" Fail
"~" SoftFail
"?" Neutral

[AuctionHugh]

For some reason prodigy.net servers carry sbcglobal.net email. Don't ask me why.

The whole SPF thing is confusing to me. I may end up screwing it up.

[spiderbait]

For some reason prodigy.net servers carry sbcglobal.net email. Don't ask me why.

The whole SPF thing is confusing to me. I may end up screwing it up.

Why don't you give it a shot creating your own SPF using the tools I suggested? Then you can post it here and you can get some feedback before you submit it to your host.

[ronchalice]

Hosting has nothing to do with it. Spam filters work by way of blocking addresses and / or domains. (Or individual filters / preferences). It's that simple.

I do a lot of blocking specifically based on hosting and IP addresses. If the content falls into certain categories, I will use one of the regional who-is servers to determine and block the entire range of IPs owned by the organization who owns the offending IP address.

[AuctionHugh]

Why don't you give it a shot creating your own SPF using the tools I suggested? Then you can post it here and you can get some feedback before you submit it to your host.

Ok, sure. Using the tool in the top right corner here SPF: Project Overview (http://www.openspf.org/)


I get "v=spf1 include:sbcglobal.net include:prodigy.net ~all"

Except I hand edited to also include prodigy.net since I could not find a way to include more than one sending isp. That syntax may be incorrect.

[jawn_tech]

I do a lot of blocking specifically based on hosting and IP addresses. If the content falls into certain categories, I will use one of the regional who-is servers to determine and block the entire range of IPs owned by the organization who owns the offending IP address.

Good for you, Ron. Like I said, individual filters / preferences. Check out the rest of the thread too.

[speed]

I get "v=spf1 include:sbcglobal.net include:prodigy.net ~all"
Don't use that as it will make things worse, neither sbcglobal.net or prodigy.net have valid SPF records that I can see therefore as there's no record you will get a permanent failure.

You would have to build the record from the mail server IPs so my advice either send through the host and use a tight SPF record which just specifies your host as valid or delete the SPF record completely.

[speed]

"v=spf1 a mx mx:sbcglobal.net mx:prodigy.net -all"
Rethink, the above should be right, the motto here is don't try thinking about SPF on new years day ;)

If you set it with a very low TTL then you can test it and tweak if it doesn't work.

p.s. why doesn't preview post work :(

[spiderbait]

I would use the one Speed provided, with one change:


"v=spf1 a mx mx:sbcglobal.net mx:prodigy.net ~all"

I modified the "fail all" -all to be "soft fail" ~all

The fail all is probably too restrictive to start with. If you find this has improved your email delivery after a few weeks or a month, then you could switch it to fail all. But until then, better safe than sorry.

[AuctionHugh]

I've had an interesting exchange with my hosting support folks who by the way are completely fantastic folks who I can hardly compliment enough. I don't know if I am getting far with this particular issue though:

Support -|- 2009-02-02 19:35:35"v=spf1 ?all" basically means there is no record, all is possible.
"-all" means hard failure, if the sender host is not in the permitted list, drop it.
"~all" means soft failure, if the sender host is not in the permitted list, it fails the test, but what to do with the email is up to the recipient host.

Having a valid SPF record can improve your mail score, but in some cases, it can be a double edged sword. If the recipient is using a forwarding address, when the email hits the final destination host, it will fail the SPF test because the forwarding(relay) host is not listed as permitted sender. Please do keep this in mind. -|-

ME 2009-02-02 23:39:11I understand. My point is this. I don't understand. I really don't know how all this works, and I don't really want to have to know. Can you just help me to know how this should be set up right so I don't have my emails marked as spam?

Support -|- 2009-02-03 00:21:39I have added the SPF record for you. FYI, you can also do so yourself in the DNS section.
You should now try and send some test emails to your own free mailboxes and see if they pass the SPF test. Feel free to send me one too if you wish.

Because you have been sending emails via smtpauth.sbcglobal.net, while claiming to be from kallenweb.com, which was a typical sign of spoofed emails. Once configured correctly, SPF should take care of this.

The next step is to monitor the emails and see if the delivery improves. If yes, problem solved. In case not, you will need to look into the issue further, such as trying to alter the structure of the emails, the sending pattern, or contact the service provider of those users who mark your emails as spam for information.

There is no way to guarantee the emails won’t be marked as spam. There are many many reasons an email can end up in the junkbox, and you have to figure out the real cause through trial and error. For example some people with a particular ISP can flag your emails as spam for whatever reason or simply by mistake, and your emails will end up as spam for all their users. Such things happen.

I always do my best to make sure our servers come up clean on all public spam databases, but it’s irrelevant in this case, since you’re not using our mail servers to send emails anyway.

ME 2009-02-03 01:04:01Is this what I should be seeing with that spf record?

---------------
mta594.mail.mud.yahoo.com from=kallenweb.com; domainkeys=neutral (no sig)
Received: from 67.15.64.87 (EHLO mail.e-rice.net) (67.15.64.87) by mta594.mail.mud.yahoo.com with SMTP; Mon, 02 Feb 2009 16:56:32 -0800
Received: from mail.e-rice.net (localhost [127.0.0.1]) by mail.e-rice.net (Postfix) with ESMTP id A42B118B1F for <zzzzzzzzzzzzzzzzzzzz@yahoo.com>; Tue, 3 Feb 2009 00:56:05 +0000 (GMT)
Received-SPF: softfail (mail.e-rice.net: transitioning domain of zzzzzzzzzzzzz@kallenweb.com does not designate 207.115.36.82 as permitted sender)
Received: from nlpi053.prodigy.net (nlpi053.sbcis.sbc.com [207.115.36.82]) by mail.e-rice.net (Postfix) with ESMTP id 7988317BA6 for <zzzzzzzzzzzz@rendergreen.com>; Tue, 3 Feb 2009 00:56:05 +0000 (GMT)
Received: from HughDell1735 (adsl-75-40-250-159.dsl.klmzmi.sbcglobal.net [75.40.250.159]) (authenticated bits=0) by nlpi053.prodigy.net (8.13.8 smtpauth/dk/map_regex/8.13.8) with ESMTP id n130uSiG000440; Mon, 2 Feb 2009 18:56:29 -0600
From:
"Hugh Kallen" <zzzzzzzzzzzzzzz@kallenweb.com>
--------------------
Funny that is is soft failing because "does not designate 207.115.36.82 as permitted sender" even though the spf record designates prodigy.net. On the other hand I may have no idea what is going on.

Support -|- 2009-02-03 01:16:51No, it doesn't look good.
It's because nlpi053.prodigy.net (nlpi053.sbcis.sbc.com [207.115.36.82]) is not listed as MX record for prodigy.net.

Support -|- 2009-02-03 01:21:01What I'd suggest is to call your ISP, ask for the subnet IP range of their SMTP servers that you have access to. So you can use the IPs for SPF.

Support -|- 2009-02-03 02:02:04I have just checked both sbcglobal.net and prodigy.net, there is no SPF for either of them, otherwise you could simply copy theirs. Hopefully you can get the subnet range from their support line, or there will be some guess work to do.

How to guess the IP range:
Send a lot of test emails, and note down the relay host IP for each of them. Compare the IP addresses, pick out those vary in the first 3 parts, add them to SPF..

To keep it simple (don’t worry about the technical stuff), just change the last part of the IP to '0', and use ‘/24’, so "207.115.36.82" becomes "ip4:207.115.36.0/24"

The final format should look like this:
v=spf1 a mx ip4:207.115.36.0/24 ip4:123.123.123.0/24 ~all

Support -|- 2009-02-03 02:09:03I have updated the SPF to "v=spf1 a mx ip4:207.115.36.0/24 ~all"
You should be able to start from here, just add more ip ranges to the list.