Troubleshooting E-mail Problems

Troubleshooting E-mail Problems

Check your Configuration

The first thing to do is verify that you have configured your e-mail client correctly.

At the very least, make sure that you have your POP (Incoming) Mail Server set to (where is your actual domain name.) Do not prefix your domain name with http://www.,mail.pop3. or any other prefix.

Also verify that your username and password have been entered correctly. For the e-mail account, the correct username is: yourdomain — it is not

Check your Domain Registration Status

If your domain name registration has expired, no functions associated with your domain name (e-mail, www, ftp, etc.) will work. Also, if the Domain Nameserver (DNS) information associated with your domain name is not pointing to nameservers, you will not be able to access any functions on our servers by domain name. You can use any WHOIS lookup to check the status of your domain name.

Check Your Redirects, MailLists, Infobots, & PlusRoamer Configuration

The most common cause of e-mail delivery failures is an incorrectly configured default redirect in your e-mail forwarding. Log in to your Web Control Panel (, where “” is your actual domain name) and select the E-mail Forwarding link. The first redirect listed should look like this:


The default entry must be your primary account login (, where is your actual domain name.) If you set your default redirect to a different e-mail address, your e-mail will not be delivered predictably or reliably. For example, we see a lot of entries like this:


What you want is for all of your e-mail to be delivered to your AOL account. What you get is none of your e-mail being delivered anywhere. If you want your mail delivered to an e-mail account outside of our network, set up your redirects like this:


Also, note that the primary login is the only POP login that can be redirected. Another common problem occurs when you set up a POP login and a redirect for the same name. This can result in mail not being delivered. Make sure that you do not have the same name duplicated in your POP users and redirects. See the E-mail Forwarding Instructions for information on correctly configuring your redirect files.

Check your MailLists and Infobots (Autoresponders). You cannot have a maillist or an infobot with the same name as a POP user. CLICK HERE for instructions on correctly configuring autoresponder/infobots, and CLICK HERE for maillist configuration instructions.

Finally, if you’ve installed PlusRoamer on your account, make sure that your PlusRoamer usernames are unique, as well. PlusRoamer accounts cannot have the same name as a POP, redirect, autoresponder, or maillist. Also, remember that the PlusRoamer admin account will receive all e-mail that would otherwise be destined for your default ( e-mail address.

Relay Attempt Failed Error

You attempt to send mail, but receive an error message that looks like this:

protocol smtp; server response 550; relay attempt failed

This one’s usually easy to fix: Simply check and receive your mail before you try to send mail. In order to prevent our mail servers from being used for the transmission of SPAM (junk e-mail), we’ve configured our servers to require that no mail can be sent from a given domain’s SMTP (outgoing mail) server unless the same domain’s POP (incoming mail) server has been accessed prior to the send attempt.

At the present time, it is only necessary to have checked for new mail once during any 24 hour period. Checking the POP (incoming) mail server effectively “unlocks” the SMTP (outgoing) mail server and allows the relay to go through.

Port 25 (SMTP) Relay Blocking

Another common source of the relay error is due to your local ISP blocking relays to external SMTP servers (Port 25 Relays). ISPs do this to eliminate their network from being used to transmit spam — they simply do not allow anyone to connect to any SMTP server outside of their network. Almost all of the larger ISPS (notably, Earthlink and MSN) and more and more smaller ISPs are now blocking Port 25 Relays.

The solution to this problem is to simply substitute your ISP’s SMTP server information for your domain name in your e-mail client configuration. We recommend this configuration even if your ISP is not blocking relays, as it will generally result in more reliable SMTP connections. Mail will still appear as coming from your domain (as long as you have your From and/or Reply-to addresses configured correctly.) Your ISP can provide the information you need to set up the connection — usually or Contact your local ISP’s support staff to obtain the correct settings.

SSL Negotiation Failed Errors

You may see an error referring to problems with SSL, similar to one of the following:

SSL negotiation failed - negotiated key exchange length is -1

SSL negotiation failed. You have configured this personality/protocol to reject any exchange key lengths below 0. But the negotiated exchange key length is -1 Hence this established secure channel is unacceptable. Connection will be dropped. Cause (-6992).

Our mail servers do not currently support SSL connections. These errors indicate that your e-mail client is configured for this unsupported connection type. In Microsoft Outlook, uncheck the box next to This server requires a secure connection (SSL) in your Advanced properties section. See the Outlook configuration instructions for more information.

If you’re using Eudora to check your mail, review the Eudora configuration instructions, or follow these steps:

  1. Right click on your personality name to bring up the menu. Then, click “Properties”.
  2. Look toward the bottom of the box until you see “Secure Sockets When Sending”. Change that option to “Never”.
  3. Click on the “Incoming Mail” tab at the top of the box and change “Secure Sockets When Receiving” to “Never” also.
  4. Click “OK” and check mail again. The error should not return.

Firewall and Anti-Virus Software

Improperly configured firewalls and/or anti-virus software can interfere with POP and SMTP connections. Both the Norton and PC-Cillin anti-virus software packages have proven to cause sporadic and unpredictable failures with POP3 connectivity.

Try temporarily disabling any software of this nature and see if the problem disappears. If it does, you’ve identified the source of the problem. You’ll need to contact your network adminstrator or the software manufacturer for assistance with proper configuration.

After disabling any virus protection software, double-check your e-mail client configuration. Many virus protection programs will overwrite your settings (for example, they may replace the POP Server name withlocalhost and the Username with something that looks like yourdomain/ These settings will not work with the virus protection disabled — you’ll need to reset your configuration to correspond to our E-Mail Configuration Instructions.

Server Errors

You could receive any number of error messages describing unavailable server, connection with the server reset, server connection timed out, etc. In some cases you can receive mail without problem, but cannot send mail.

There are all sorts of conditions that can contribute to sendmail problems, including the standard internet connection issues, which can cause timeouts when connecting to your web site via browser, POP, FTP, or telnet. (These issues are described in the Connection troubleshooter. Most of these issues are not related to our servers.

Sending mail (via SMTP) and receiving mail (via POP) are related, but essentially independent, processes. The fact that you can receive mail, but not send mail, is not as inconsistent as you might imagine.

For example, when you send e-mail, the actual destination server of the mailto address is contacted and resolved before our server allows the mail to be sent. Problems with the destination server can result in timeouts and other errors.

This process also increases the number of “hops” the process encounters, as the transmission goes from your ISP to our servers to the destination server then back to our servers to be sent. The more hops, the greater the chance for a dead or slow node, the greater the chance for a timeout error.

Running a traceroute from your connection to your domain, and to the destination server might help pinpoint the source of the problem. If the problem is related to Internet congestion or problems with intermediate routers, it will usually disappear within a short time.

America Online (AOL) customers report more problems in this area than most other users. AOL was not originally conceived or designed as an Internet service provider and most of their system protocols are not standard Internet protocols. They seem to have consistent problems sending and receiving e-mail through their own system — trying to use an AOL connection to drive Internet protocols is even less reliable. According to the latest information, AOL does not support external POP/SMTP connections — they may work or they may not. The only solution to this problem is to switch to a “true” Internet Service Provider.

Reporting E-mail Problems

If the information above does not solve your e-mail problem, please provide enough information so that we can effectively troubleshoot the issue.

IMPORTANT NOTE: If you are unable to receive mail from your account, provide an off-network e-mail address that we can reply to — if the problem is not related to a server-side issue, and the only e-mail address you provide is on the affected domain, you won’t be able to receive our response to your problem report.

At the very least, we’ll need the following information:

  1. Your domain name
  2. Username(s) for the affected E-mail account(s)
  3. Password(s) for the affected E-mail account(s)
  4. A copy of the exact error message you’re receiving
  5. A complete description of the problem and when it occurs (e.g., sending, receiving, or both?)

Other information that can be helpful includes:

  1. The E-mail client you’re using (Outlook, Eudora, etc.)
  2. The speed and type of your Internet connection
  3. If you have access to a different ISP account, does the problem occur with that connection, too?
  4. Is the problem consistent or sporadic?
  5. When did the problem start?
  6. The results of a traceroute to, where is the name of your actual domain name