[jhollington]

Originally Posted by tony17112acst

Well, I tried it and it still failed.

I'm not surprised. It was a bit of a long shot as all of the DNS stuff looked okay from everywhere else, but then again, everywhere else you've tried can also get mail through to 50Webs/Freehostia, so it wouldn't have been out of the question for it to be a DNS issue. At least we've eliminated that possibility.

I'm trying to think this through - Godaddy is where I purchased all 3 of my domains, which makes them the registrar and that's the only place I can tell where my web+email hosting is ...by entering the name of the name server for whatever hosting service I want, right?

Essentially correct, although name server hosting, web hosting, and e-mail hosting are three separate things. As you've already discovered, GoDaddy can host your name servers while still having individual records point elsewhere, or you can have GoDaddy as your registrar point to whichever name servers you like. The hierarchy is conceptually REGISTRAR --> NAME SERVERS (DNS) --> WEB/MAIL/etc.

I say "conceptually" because technically the registrar is just responsible for populating the name server entries into the root domain — the ".COM" domain in this case. It's not involved the lookup and discovery process. In other words, if you tell GoDaddy that you want your name servers located at Freehostia, for instance, then GoDaddy will publish ns1.freehostia.com and ns2.freehostia.com in the ".COM" domain as the entries for anthonytonini.com, and from there it's up to the DNS system to do the rest of the work — the registrar doesn't play any part in the process beyond the initial registration of name servers.

If I changed my name servers (via Godaddy) to point to 50webs for my email+web hosting and then made an MX record at 50Webs to point to Godaddy's email host only ...Comcast's SMTP would successfully send it to Godaddy's email because the only thing 50Webs did was store DNS records for where to point mail (MX) traffic ...right?

That's correct, assuming of course that it's not a DNS problem in the first place. However, the test we've just done has eliminated that as a possibility (or at least a key factor), since if it were only a DNS issue, then the lookup would have succeeded and the message would be relayed to 50Webs.

So if Comcast isn't send email traffic to 50Webs, is it possible that the DNS traffic would fail too?

Exactly, which is why I said "only" above. It's entirely possible that Comcast can't reach 50Webs/Freehostia's subnets at all, in which case the DNS lookups and the mail delivery would be failing.

You could eliminate that by doing the reverse test — move the DNS for tonytonini.com back over to 50Webs/Freehostia and point the MX record to GoDaddy's mail server. If messages still fail to get through, it's a broader communication issue from Comcast to Liquidnet's network.

...or aren't there any checks on DNS traffic like email (spam/SPF/DKIM/DMARK/ETC) and everything is just passed through?

There aren't the same kind of checks in DNS traffic at all, so it should just be passed through, but if this is a network-level routing issue, which it very well could be, then if Comcast can't reach anything on the 162.210.102.x subnet, it's going to have just as much trouble reaching the DNS servers as it does the mail servers. Of course, we don't know this at all, but it's a possibility.

As we've been through, most of the spam/SPF/DKIM/DMARC/etc stuff shouldn't be causing this type and level of non-delivery, and in almost all of these cases, Freehostia should know about it if it is — they'd have a log entry indicating that they blocked Comcast and why (assuming of course that they know what they're doing and are looking in the right places).

If what Freehostia is telling you is accurate, Comcast's mail servers can't reach Freehostia's in the first place. This speaks to either a DNS or routing issue, and we've eliminated the likelihood that it's purely a DNS issue.

Originally Posted by tony17112acst

I sent that test email from my Comcast webmail to tonytonini.com when its MX record was pointed to 50webs and I never received it (as expected).

But once I changed the MX record back to godaddy's host, that failed email came through (to godaddy's mail server)!

Sadly, this doesn't really tell us anything beyond the fact that Comcast's systems are otherwise working fine. Based on the fact that we've been seeing temporary failures from Comcast all along, this is completely expected behaviour. The standard SMTP outbound delivery process does a DNS query every time it tries to send the message, since of course a bad DNS entry could be a reason for a transient failure. So in other words, when Comcast tried again later on, it found the updated MX record pointing to GoDaddy, and was able to make a successful connection.

Basically, this is what I think is happening from a procedural point of view:

1. A message is created at Comcast.net, destined for tonytonini.com
2. Comcast places that message in an outbound delivery queue.
3. Comcast's outbound SMTP server attempts to look up the MX record for tonytonini.com, and (hopefully) comes back with the 50Webs mail server. If there's a DNS problem and no MX record is found, we basically skip to step 6.
4. If an MX record is found, Comcast's outbound SMTP server attempts to establish an SMTP session with the 50Webs mail server.
5. However, Comcast's outbound SMTP server can't establish a connection for whatever reason — either the 50Webs mail server is unreachable, or it unceremoniously hangs up on Comcast without providing a reason.
6. Comcast logs this as a temporary failure and schedules another attempt later on. This could be 20 minutes later, an hour later or four hours later. The retry intervals depend entirely on the sending server's configuration.
7. When Comcast tries again, it repeats steps 3 to 6, because of course based on everything we've seen, 50Webs remains unreachable.
8. Eventually, Comcast's outbound SMTP server gives up on trying (again, a configurable interval, but it appears to be 48 hours based on what we've seen), and bounces the message as entirely undeliverable.

However, if the MX record is changed before steps 3 to 6 are repeated, then Comcast's outbound SMTP server would use the new server, and attempt to communicate with that, delivering the message there, assuming it can find it properly — which in your case, it did, and that's why the message came through.