frustratedinco said:
Task '(e-mail address removed) - Receiving' reported error (0X80040900) :
'The server name you entered cannot be found on the network (it might
be down temporarily). Verify that you are online and that the server
name is correct.'
Your outbound mail server is notifying you that it could not do a DNS
lookup on that domain. Humans like names. Computers always use numbers
hence the need to do an IP name to IP address lookup. If the DNS server
used by your e-mail provider doesn't have the lookup, it fails and a
lookup proceeds to the next higher-up nameserver. It may eventually get
to the nameserver operated by the target domain to provide lookups on
its own hosts (or, at least, its boundary hosts that hosts external to
their network can see). If the target domain's nameserver doesn't have
a record in its nameserver for a host, no IP address gets returned so
the sending mail server has nowhere to connect.
Another possible cause is that the target domain's nameserver doesn't
list its authorized mail servers (MX records). Your e-mail provider may
only permit connecting to authenticated mail servers as an anti-spam
measure. I won't get into that because the error you showed says the
host wasn't found, not that an authenticated mail server isn't listed at
that domain. Plus, I used mxtoolbox.com to see if the sandersonlaw.net
domain had a valid MX record, and it does (174.123.176.66 gets returned
from the nameserver operated by the webhoster for that domain). It
isn't on a blacklist (mxtoolbox runs the IP address through many
blacklists but these are public blacklists and your e-mail provider may
use their own; however, their error should show if they rejected your
e-mail because the destination was blacklisted, and blacklisting is
mostly used when receiving e-mails, not when sending them. Once you do
the MX lookup at mxtoolbox, you can even click the SMTP test link to
have them check if the SMTP server at that domain (which is for the
webhoster) is working. It was working when I tried. Their test does
report the possibility that the SMTP mail host is a relay which isn't a
surprise since it is the boundary host for a webhosting service where
thousands of domains reside.
Do a traceroute to that domain to see through which hosts you have to go
through to get there. When I did it, I got:
1 ...
:
6 TenGigabitEthernet2-2.ar5.CHI1.gblx.net [64.213.79.245]
7 The-Planet.TenGigabitEthernet2-3.ar2.HOU1.gblx.net [64.214.196.58]
8 po1.car08.hstntx2.theplanet.com [74.55.252.90]
9 hybrid.pilotservers.com [174.123.176.66]
Are any of those hosts shared between my traceroute and yours (the last
one should be since that is the target host)? A flaky intervening host
in the route can cause problems. However, it is more important what
route your outbound mail server takes to get to the recipient's
receiving mail server (and only your e-mail provider would know that).
You would need your e-mail provider do the testing to not only check
that they can connect okay to the receiving mail host but that there are
also no so huge delays or lost packets (that require retries) as to
interfere with the mail session. Again, only the e-mail provider can do
their testing. Your e-mail provider can only tell you that their server
is working (and might, if really pushed, check that mail sessions
between their mail server and the target mail server are functioning).
Your e-mail provider can say nothing about the stability of someone
else's mail server.
Since it appears the destination is some webhosting provider, they are
known for not being as reliable as an email-only provider or even as
reliable as most ISPs (but some ISPs are well-noted for unreliable email
service). They offer MANY domains at their domain and, for example,
their nameserver might get screwed up. A host, like your sending mail
server, tries to find the DNS record in their own DNS server, doesn't
find it, passes it on, and eventually hits the other domain's nameserver
to find out to what host (by IP number) to which it should connect. If
the other party's nameserver doesn't have a record for that webhosted
domain, the one trying to connect there can't connect. It's been told
there is no such lookup.
pilotservers.com, to where a traceroute follows to find sanderson.net,
is operated by ivaluehost.net (as found when looking up the domain
registration for pilotservers.com). They might have thousands of
webhosted domains there. Some have their own domains (i.e., the owner
registered their own domain at a registrar or through the webhoster).
That means the nameservers for ivaluehost.net must keep track of them
all to provide the DNS lookups. All e-mails to those webhosted domains
(that include e-mail service) have to go to ivaluehost.net's mail
server. That means there could be thousands of domains that all go to
the same e-mail provider, the service provided by the webhoster.
You complaining to their webhoster will get nowhere. You aren't their
customer. Like your own e-mail provider, they're only interested in
handling complaints regarding their service from their own customers.
So you'll have to contact Sanderson Law (phone or mail but not by e-mail
unless it happens to work) to tell them that their webhoster's e-mail
service is regularly unavailable (or as often as you have encountered
the outage).
The problem is on their end. That it is a webhosting service for the
sandersonlaw.net domain where that providers e-mail service is flaky is
not a surprise. Sometimes it is a per-account problem and the account
owner (Sanderson Law) will have to work with their webhoster to resolve
the problem. Sometimes it is an innate defect with that webhoster's
e-mail service and lots of customers there are having problems. Only
the customer and the webhoster can work on the problem. You can only
wait to see if they ever get the problem fixed.
