Manually test a failed email. First, use the Dmoain Dossier tool at CentralOps.net to find the MX record info that is seen by this reliable service (example microsoft.com):
http://centralops.net/co/DomainDossier.aspx?addr=microsoft.com&dom_dns=true Next, use nslookup on your mail server to see if what your mail server sees matches. You mail server may be configured to use alternate DNS resolution than that of the OS - so be mindful of that possibility (example microsoft.com. : nslookup -type=MX microsoft.com Next, try some manual testing from your mail server to the MX identified recieving server (example microsoft.com): telnet mail.global.frontbridge.com 25 Specifying 25 on the end instructs the telnet application to connect to port 25 (SMTP) instead of the default Telnet port of 23. Tap enter a couple of times and you should get an SMTP connection banner. If you know SMTP, you can send some manual commands to test. You can Google the commands. Even Microsoft's KB has examples for that. Sorry, but I have to go catch a train. Good luck! On Tue, Aug 26, 2008 at 3:39 PM, <[EMAIL PROTECTED]> wrote: > Greetings! > > We are the mid-west office of the ASPCA (Illinois). Our HQ is in NYC. Our > wires, DNS, etc are via AT&T. Their wires, DNS, etc are through > QualityTech. As NY is the parent office (to say nothing of older and > bigger), the QualityTech system is the SOA for ASPCA.ORG. For the > Illinois public addresses (including the IP address stamped onto all our > outgoing email), we have NS records on the QualityTech system pointing our > network (mwro.aspca.org) to the AT&T name servers. All had been well the > past several months... > > Last week, attempts to send mail to various corporations and educational > institutions has been bouncing. The headers of our bounce notices say > simply "Failed to connect to SMTP host COMPANY.COM because: Remote system > no longer responding" > > One company told us it is because the IP address is not resolving > properly... > > I have checked the DNS tables for QualityTech, and they do show "mwro" > being delegated to a pair of AT&T DNS servers. I have checked the DNS > tables for AT&T, and we do have records in both forward and reverse lookup > zones (br.mwro.aspca.org <-> 12.15.29.130). > > Any ideas (while I wait and wait and wait to talk to AT&T)? The Boss > suggests the "fix" for last month's "DNS Poisoning" might have "fixed" > things so that anything claiming to be from [anything].aspca.org must > resolve to a QualityTech address and not to an AT&T address. Still, I > don't see that we can do much to fix this... > > We are considering using a VPN tunnel to try to use a NY machine as an > outgoing SMTP server. What else might we try? > > Other folks experiencing this? > > Thanks!!!!! > -------------------------------------- > Richard McClary, Systems Administrator > ASPCA Knowledge Management > 1717 S Philo Rd, Ste 36, Urbana, IL 61802 > 217-337-9761 > http://www.aspca.org > > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ > ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > -- ME2 ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
