Mail Server Blocked? Help?

I have a mail server. I host it at Rackspace. When I send mail to the users of  my website, it is going to spam. I checked my gmail account for testing and it is in the spam folder and they direct me here for reasons:
https://support.google.com/mail/answer/81126?hl=en#authentication

On Rackspace, I have setup a ReverseDNS Record to the IP address of the server that hosts my mail server.
I have added the name of the mail server, like: mail.blah.com

I send the mail from: support@this.com and the mail server is mail.blah.com; but even though it's not the same domain, it is in the same mail server, so that should be okay, right?

Can someone help me with why it is flagging it as spam?

I send mail with this code. I really don't know what all that stuff is, it was in an example, so I could very well be doing something wrong.

Set NewMailer = CreateObject("CDO.Message")
'Send the message using the network (SMTP over the network).
NewMailer.Configuration.Fields.Item ("http://schemas.microsoft.com/cdo/configuration/sendusing") = 2

NewMailer.Configuration.Fields.Item ("http://schemas.microsoft.com/cdo/configuration/smtpserver") =smtpServer
NewMailer.Configuration.Fields.Item ("http://schemas.microsoft.com/cdo/configuration/smtpserverport") = 25

'Use SSL for the connection (True or False)
NewMailer.Configuration.Fields.Item ("http://schemas.microsoft.com/cdo/configuration/smtpusessl") = False

NewMailer.Configuration.Fields.Item ("http://schemas.microsoft.com/cdo/configuration/smtpconnectiontimeout") = 60

'If your server requires outgoing authentication, uncomment the lines below and use a valid email address and password.
'Basic (clear-text) authentication
NewMailer.Configuration.Fields.Item ("http://schemas.microsoft.com/cdo/configuration/smtpauthenticate") = 1
'Your UserID on the SMTP server
NewMailer.Configuration.Fields.Item ("http://schemas.microsoft.com/cdo/configuration/sendusername") =serverEmail
NewMailer.Configuration.Fields.Item ("http://schemas.microsoft.com/cdo/configuration/sendpassword") =serverPassword

NewMailer.Configuration.Fields.Update
NewMailer.Subject=Subject
NewMailer.From=FromAddress
NewMailer.To=ToAddress
NewMailer.TextBody=Body
NewMailer.Send


Any ideas how to be in compliance with mail requirements?

thanks!
(this happens to be in asp classic, but I imagine that has nothing to do with it)
LVL 2
Starr DuskkASP.NET VB.NET DeveloperAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Jason CrawfordExchange / Office 365 Premier Field EngineerCommented:
One possibility is the SPF record is misconfigured.  Any domain you use to send email should either have a correct SPF record or no SPF record at all.  In your example let's take this.com and query the SPF record using nslookup from a command prompt:

nslookup
server 8.8.8.8
set type=txt
this.com

That should return something similar to "v=spf1 ip4:27.108.92.250 -all" (or whatever the sending IP actually is).  There are many different configuration options with SPF records, especially when you start to use the recursive capability so it probably won't be exactly what I provided.  I've used Kitterman for years to validate my SPF syntax if you need help - http://www.kitterman.com/spf/validate.html.

Another possibility is one or more of Rackspace's outbound IPs was blacklisted which happens all the time and the situation has already corrected itself.  You can generally roll off a blacklist within a day or so (except with SORBS...man I hate those guys).  

I think the reverse DNS record you referred to is a PTR record which maps an IP back to a host which is basically opposite how an SPF record works.  You can query PTR with nslookup just like TXT:

nslookup
server 8.8.8.8
set type=ptr
27.108.92.250

Again though, it's better to not have a PTR record than to have a misconfigured one.  PM me if you'd like to walk through your specific example.

Take care
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Starr DuskkASP.NET VB.NET DeveloperAuthor Commented:
You say it's better to not have them than to have them.

Where do I check whether they were setup at all? Is it something done through the registrar like Godaddy or Name.com, etc? Because typically I do nothing there, but I could easily check.

So at Rackspace, it doesn't use  my IP for the outbound? So if I put my server IP in to check if it's been blacklisted, it won't matter, because it's using something else?

When I checked my gmail, it was routing it to the spam folder, but I've had clients say that it's not even in the spam folder, which makes no sense.

I will try those things you suggested and see what I see.

thanks!
0
Jason CrawfordExchange / Office 365 Premier Field EngineerCommented:
No I said it's better to not have SPF and PTR records than to misconfigure them.  Reverse DNS isn't a requirement for email, it's just an option to help combat spam.  

PTR records have to be setup by the ISP that owns the WAN IP.  Just open a ticket with your ISP's support department and they should know exactly what you're referring to.  I apologize, I meant to include that in my initial post.  SPF records are created in the form of a TXT DNS record in your domain's public zone file.  If you need to know who the DNS host is for your domain just use our handy little friend, nslookup.  Open a command prompt and type exactly this:

nslookup
server 8.8.8.8
set type=ns
yourdomain.com

The nameserver is generally the DNS host except in rare occasions.

You're correct about including your WAN IP in the SPF record.  It would be pointless since the email is being routed outbound through servers owned by Rackspace.  Here's a Rackspace KB documenting the process:

https://www.rackspace.com/knowledge_center/article/create-an-spf-txt-record

Gmail is a free email service lacking advanced spam filters so if an inbound message looks spammy there's really no other option but to just receive it in your spam folder.  This is not the case for 3rd party spam filters like Barracuda, MXLogic, Postini, etc.  With these services you can configure a Deny action that prevents spam from being delivered to the recipient which would explain how your clients never saw the email land in their spam folder.
0
Cloud Class® Course: Ruby Fundamentals

This course will introduce you to Ruby, as well as teach you about classes, methods, variables, data structures, loops, enumerable methods, and finishing touches.

Starr DuskkASP.NET VB.NET DeveloperAuthor Commented:
Okay, I'll give this a shot sometime this week! I'm sure I'll get flagged as abandoned before I get to it though. sigh. They never consider us weekend warriors.

thanks!
0
Starr DuskkASP.NET VB.NET DeveloperAuthor Commented:
ok, it shows it is hosted by name.com which I suspected since that's where I have my dns records.

If I go to the panel for the domain which has the mail server, it has an MX record to mail.right.com, but there is no TXT record.

I don't understand what I would really need for the TXT record even after reading the Rackspace article you referenced. Here's what I want to do:
I want to send and receive mail from Outlook.
I want my website to send mail. It uses the email address of support@left.com and the mail server at mail.right.com

At name.com, I go to right.com and it has the mx record for mail.right.com, but no TXT.

What would I need in that TXT record to allow me to send from my websites?

also PTR: ISP - is name.com my ISP (where the DNS is) or is it Rackspace (where the mail server is hosted).

thanks!
0
Jason CrawfordExchange / Office 365 Premier Field EngineerCommented:
First - a PTR record has to be put in place by your Internet Service Provider (ISP).  It's not something you can configure yourself, so if your ISP is Time Warner you'd have to call TW tech support and make the request.

To properly configure an SPF record you have to first gather the list of outbound WAN IPs used by your email and web servers.  For this example let's use 1.1.1.1 and 2.2.2.2.  Here's what the SPF record would look like:

Type: TXT
Value: "v=spf1 ip4:1.1.1.1 ip4:2.2.2.2 -all"

You would need to configure this for any domain you're sending email from.  Because you use Rackspace you'll need to work with them to determine what the record should include, and it will most likely be a recursive query to another record, ie a:rackspace.com (for example).  Once you have the Rackspace requirements and the WAN IP for your web server, feel free to message me through EE and I'll let you know what you should add.

Keep in mind also that reverse DNS was just one possible cause of your email being flagged as spam as you described in the original post.  Another possibility is that one of Rackspace's outbound servers was put on a blacklist.  This is a temporary situation as Rackspace uses many servers to send email and blacklists don't list an IP indefinitely.  Try sending email now and see if it's still flagged as spam.  This issue may have resolved itself, and I don't want you to put in a lot of unnecessary leg work.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
ASP

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.