Comcast rejecteing emails

[retronaut]

Can anyone confirm if this fixes the issue with Comcast?

[retronaut]

Originally Posted by soky

Thanks for the help guys... in the CP, there are a few questions.
Name TTL Class Type Data
Name = spf
TTL = ?? (use default value 86400 ??)
Class = N
Type = txt
data = v=spf1 a mx include:hsphere.cc ~all
Is that right?

That looks fine.

[soky]

Sweet... thanks!! Edited! Crossed fingers.

[retronaut]

In the name field - I think you can leave it blank.

Go to http://www.dnsreport.com/ and test your domain.

[soky]

Thanks for the link... it still doesn't see the SPF record but I'm going to give it overnight and test it again. It may need time to "propagate"

Adding the SPF in the name field created the spf.soky.net DNS record. I'll test tomorrow and if I still get a warning, I'll edit it out.

Thanks for the help.

[soky]

Unrelated, I did get the NS warnings... anyone now if there is anything I can do about that?

FAIL: You have one or more missing (stealth) nameservers. The following nameserver(s) are listed (at your nameservers) as nameservers for your domain, but are not listed at the parent nameservers (therefore, they may or may not get used, depending on whether your DNS servers return them in the authority section for other requests, per RFC2181 5.4.1). You need to make sure that these stealth nameservers are working; if they are not responding, you may have serious problems! The DNS Report will not query these servers, so you need to be very careful that they are working properly.

ns.hsphere.cc.
ns1.hsphere.cc.
This is listed as an ERROR because there are some cases where nasty problems can occur (if the TTLs vary from the NS records at the root servers and the NS records point to your own domain, for example).

FAIL Missing nameservers 2 ERROR: One or more of the nameservers listed at the parent servers are not listed as NS records at your nameservers. The problem NS records are:
ns.soky.net.
ns1.soky.net.

FAIL Stealth NS record leakage Your DNS servers leak stealth information in non-NS requests:

Stealth nameservers are leaked [ns.hsphere.cc.]!
Stealth nameservers are leaked [ns1.hsphere.cc.]!

This can cause some serious problems (especially if there is a TTL discrepancy). If you must have stealth NS records (NS records listed at the authoritative DNS servers, but not the parent DNS servers), you should make sure that your DNS server does not leak the stealth NS records in response to other queries.

[dpyers]

That looks like the DNS Reports comment on aliased name servers. Doesn't really mean anything as long as the aliases for SoKy.net map correctly to hsphere.cc.

You should leave the name field blank. Putting 'spf' there will only affect mail coming from whatever@spf.yourdomain.com.

[soky]

thank you

----- edit

That worked! It passes the test. Thanks to all!!!!

Josh... care to comment on the NS failures?

I'm still not sure why, but DNSReport likes to occasionally show false errors when it comes to connecting to nameservers. Trust me, our nameservers are rock solid. NS - NS3 have been up over 400 days. NS4 and NS5 have been up since they were installed. I've been here almost a year and I have yet to see them fail with other tools (like dig).

[tkraffty]

My clients and I have experienced the same issues as well.

I'm thinking this is a situation where Vortech could more proactively address the issue, helping to reduce the impact to their resellers and the resellers' customers -- rather than waiting for complaints, and then handling requests on a one-off basis, ...or expecting the individual resellers or their even less-technical end-users to make sometimes complicated changes themselves (DNS is complicated for most people - not to mention, we resellers either have to hand-hold all our customers through this update, or make the individual changes ourselves - since we don't have access to command line functions and the entire server group, like Vortech does).

Email is critical... and while we don't expect 100% protection from catastrophic failures or other "acts of god", ...when it comes to something like knowing AOL and Comcast need some additional information from messages headers and the broadcast server information, then it seems like a no-brainer to me -- that Vortech should be the one to make the changes to the 99.9% of DNS settings here that are not customized...

OK - maybe I'm getting off track this morning, and haven't had enough coffee. This really isn't a gripe. I'm just not happy at the prospect of updating 50+ accounts one at a time, *guessing* that the changes *might* help improve the reliability of their email communications... and am wondering if Vortech knows the real solution, and can do something in "one swell foop" to resolve it.

[levseltzer]

Regarding the SPF record, does this mean that for all my clients, regardless of what mail server they are on, and regardless of what their domain is, I should use the line:
v=spf1 a mx include:hsphere.cc ~all
as the "data" value for a custom DNS text record?
If not, what values do I alter to make the data valid for each of my clients? Or do I need to use the SPF wizard each time?

Thank you.

[retronaut]

Originally Posted by soky

thank you
----- edit
That worked! It passes the test. Thanks to all!!!!
Josh... care to comment on the NS failures?

Excellent. It fixed the DNS reports but has it stopped email being rejected?

I agree about setting SPF records automatically. But that is really for Hsphere to address.

Can Vortech add a message to Hsphere's mail adminitstraion page?
They could instruct clients that they should add a SPF record and how to do it just like we did here.

[soky]

Originally Posted by retronaut

Excellent. It fixed the DNS reports but has it stopped email being rejected?

Yes... email is getting through nicely. I've had no complaints since I made the change.

I also agree with the automatic update. Since it's not domain name specific, one would think it could be scripted in.

[levseltzer]

It was implied that AOL uses SPF, and implementing this procedure will get the emails through AOL.com. I did this on one client, and we're still getting at least one rejection per day from AOL.com, such as the rejection below.
I asked if I have to use the EXACT string that was posted before (v=spf1 a mx include:hsphere.cc ~all), and I am still not sure if I use that string, or if I have to customize it per client. Does anyone know for sure what the answer is? Is this really supposed to help AOL?

Thanks.

Lev

> <indianadorothy@aol.com>:
> 64.12.138.57 failed after I sent the message.
> Remote host said: 421-: (RLY:NW)
> http://postmaster.info.aol.com/errors/421rlynw.html
> 421 SERVICE NOT AVAILABLE
> I'm not going to try again; this message has been in the queue too long.