Have you gotten your head wrapped around everything related to website management? You need to be familiar with a lot of new things like DNS, nameservers, A records, and that is not even considering the CMS you should use. This whole enchilada is no joke – it takes a serious amount of time to learn everything but once you learn about it, the whole investment is worth it.
There is, however, a way around the long process – learn piecemeal. It may not be the best way to learn, but with the constant pressure of website management, it really is the only way. If you need to test MX records, you really do not need to know about domain names and the W3C guidelines, restrictions and issues. You don't even need to know why your mail server entries have to end with a period. But you do need to follow instructions carefully, blindly and faithfully. Otherwise, you will have to learn everything if something goes wrong.
What Is an MX Record?
MX stands for mail exchange. E-mails do not get sent directly from your device to its destination. Mail servers handle the process in between. It stands to reason that if you configure your mail server incorrectly, the mail will be incorrectly sent or received.
To see your MX record values from your own computer, you just have to run CMD in Windows or open a terminal window in Linux or Mac. Type this command: nslookup –q=mx thedomain.com where thedomain.com is really your domain.
You will then get a server value and an address, but your MX record values appear after the line “Non-authoritative answer.” You are given three columns – your domain, a mail exchanger value, and the mail server. The mail exchanger value indicates the priority by which the servers process messages - the lower the number, the higher the priority.
If you see an errant priority number or a mail server, then go to your e-mail host and set it right. But know that whenever you edit your MX records, you usually have to wait at least 48 hours before you can start checking if your changes are correct. While your domain's need for e-mail access may be terribly important, there is no workaround for the wait.
Testing Your MX Record Values
A simple test if your MX record settings are correct would be to send and receive an e-mail from the domain. If the e-mails were sent and received, then the settings work. Sometimes, it helps that you are able to send/receive e-mails from other locations or countries – some mail hosts limit this by default.
However, this is only a part of the whole scenario – the real issue with testing mail servers is with the Sender Policy Framework (SPF) and the Blacklist Check. E-mails are a spammer and a phisher’s best friends and sometimes even innocent domains fall prey to hacking. E-mails may be sent and received with your trial messages, but the real test is if your domain or IP has been compromised and included in a spam database somewhere. And unless you have access to e-mail addresses in other locations or spam databases from other mail servers, you cannot do it on your own.
Using Tools for the Test
Fortunately, you can use free tools from WebSitePulse to help you with this type of problem. As a matter of fact, you can even completely skip the part about testing your MX records yourself and rely on this tool completely.
Just click on Free Tools -> Test Tools - > DNS, and you will find three services – the MX Records Lookup, the SPF Lookup and the Blacklist Check to help you diagnose any possible trouble with your MX records. For fun and practice, try various domains like hotmail.com, outlook.com or gmail.com and see how those domains perform with the free tools.
The Next Step
If your domain is free and clear, well and good. However, if you find problems, at least you know beforehand, and knowing is half the battle. Contact tech support for your domain name and web hosting to find a solution, which brings to the forefront another step in the never-ending learning process of website management.
See how the mx records test tool works like:
Email providers are celebrated for offering an easy, accessible, and free service, but their maximal accessibility often translates to a minimal amount of security. Unfortunately, this issue comes into play when people become faced with the question of whether or not an email address they have received is valid or not. Invalid or invented email addresses have become a communication bane for online business people, networks, and other social groups that have to rely on email to communicate with prospective clients. Additionally, users frequently find themselves wondering whether or not a mysterious email they received is legitimate or not. Illegitimate emails often act as a dangerous gateway for viruses, spyware, and phishing tools.
Users typically only know how to verify email accounts through basic methods, such as sending a test mail to the address and waiting to see if the email is bounced. However, this jack-of-all-trades solution is not reliable due to the multitude of email addresses that currently exist, which could intersect unknowingly with a bogus address from an equally bogus contact who happened to put together a combination that a previous user registered. Luckily, there are some advanced methods that you can use to verify the legitimacy of any given email.
Validating an email address may sound like an intimidating process without a large amount of computer experience under your belt. However, even the advanced methods of verifying fake email addresses typically come prepackaged with easy-to-follow directions and fairly basic commands that can be instructed to Internet users of any skill level.
The easiest alternative solution involves pinging an email address in order to deduce validity. For bewildered Internet users, a brief education is necessary: every email is received by a SMTP server, and this server subsequently finds the accorded email address by automatically searching through Mail Exchange records for the allocated domain name. Any message sent to various online services -- Yahoo, Gmail, Hotmail, and so forth -- will first go through this process wherein the SMTP server identifies the aforementioned services’ Mail Exchange records in order to narrow down the search. If this search fails and the Mail Exchange, or MX server, cannot find the specific address, it switches over to the initial wording that precedes the host's name in the email address and tries to find matches. Manipulating this process allows users to verify the legitimacy of an email address without even sending a test email to bounce back.
In order to execute this process, users should familiarize themselves with the command prompt on their operating system. The command prompt allows the administrator of the operating system to input specific commands for their system to follow, saving the time and confusion spent wading through available applications and deciding how to work through those middlemen in order to get the OS to do what you want it to. As long as your computer is allowed to interface online, the following command will extract the entire list of MX records for you to sort through yourself with no further automation required: nslookup - q=mx (any email domain name).
The appropriate command to fill inside the parenthetical would be something like yahoo.com, gmail.com, hotmail.com, and so forth. Once this basic command is entered, your OS will display the respective Mail Exchange list for the email service. After the respective server is discovered, you need to utilize the command prompt function in order to connect to the server by inputting the following code: telnet mail (the respective listed domain).
Now that your OS is connected with the MX, playing the part of the intermediary server that would otherwise be filled by SMTP, it's time to begin a fake conversation with the given contact in order to verify whether or not 'anybody's home'. This means quite literally saying hello to the server, at which point you should identify yourself by any randomized email address with the following command: mail from:<firstname.lastname@example.org> . You can then address the message to the email address that you want to verify. In this case, we will pretend that you want to verify email@example.com with the following command: rcpt to:<firstname.lastname@example.org>.
The response that follows will be all the verification you need.
The distinct trait of command prompts is that they are very literal with few customizable areas requiring the user's own discretion. This function allows anyone to utilize the service; without its safeguard, the command prompt has the potential to severely damage your operating system if used improperly. Thankfully, the commands given in this article are not remotely close to any catastrophic, OS-destroying commands that could be accidentally executed by a simple typo, but inexperienced users should still make sure to follow the command prompts to a 'T' for the safety of their computer and the appropriate functionality of the command itself.
External tools such as the WebSitePulse’s test tools could also be used to validate an email address.
Watch this video to find out how the email validation test is performed via such tool:
In our previous post we discussed the email round-trip monitoring level as the best solution for prevention of email outages. Today we will dig a little deeper and see the possible scenarios which the email round-trip test can follow. Let me clarify what the email round-trip test actually does.
First, our monitoring agent connects to the SMTP server that you have specified or retrieved automatically through the MX records and sends a test message. By doing this, our system verifies that your SMTP server is working properly. Next, the agent will try to log into the POP3/IMAP server and retrieve the message. If the message is received, the test will be considered successful and the message will be deleted. If, on the other hand, the message is not found in the mailbox after a certain period, which is configurable and usually between 5 and 15 minutes, the check will be considered a failure and you will be alerted.
Depending on your system and your goals there can be different scenarios.
In this case the goal of the monitoring is clear. You want to keep an eye on the usual mail receiving procedure. For this purpose the monitoring agent communicates with your SMTP and POP3/IMAP clients directly. But what if you cannot grant or don’t have access to the POP3/IMAP from the outside?
WebSitePulse mailbox scenario
This is the best option for monitoring the whole send-receive process if you have a Microsoft Exchange Server, or don’t want to open your IMAP/POP3 to the outside. The difference in the setup here is that when the test message goes to the POP3/IMAP mailbox on your end it should be automatically forwarded to a WebSitePulse mailbox. The latter is then checked by our monitoring agent and if the message is received, the test is considered OK. If your goal is to monitor authenticated SMTP servers and forwarders (relays), pay attention to round-trip scenario 3.
Authenticated SMTP servers scenario
You can see that in this case the second SMTP server (SMTP 2), NOT the first SMTP, is responsible for the domain of the POP3/IMAP. So, the transaction starts by sending a message to the first SMTP server which is then forwarded to SMTP 2. From there the test email is dispatched to the POP3/IMAP mailbox and our monitoring agent tries to retrieve it to verify the success of the check.
And what if you don’t want to monitor your own SMTP directly?
In this case our system communicates with your POP3/IMAP only. Our monitoring agent sends the message via the local mail sending program. The message goes to the WebSitePulse mail server (WSP SMTP), and from there it is sent to SMTP2 (responsible for the client’s domain). As in the previous scenario the test email is sent to the POP3/IMAP mailbox, and our monitoring agent tries to retrieve it and thus complete the transaction.
The final email round trip test scenario shows the case where you do not want to directly monitor the SMTP and/or the POP3/IMAP servers.
WebSitePulse POP3/IMAP only scenario
As you can see, in this case the monitoring agent communicates with the WebSitePulse POP3/IMAP only. However, while this type of monitoring setup can still guarantee that your email process is working, the procedure itself is not monitored, and the response times of your servers cannot be recorded.
So, now that you know how email round-trip works, why don’t you give it a try here?
The email monitoring agent will connect to the outgoing (SMTP) mail server, send a test message, and then will connect and login into your incoming (POP3 or IMAP) server and try to retrieve the message. If the message is retrieved, the test is successful and the message will be deleted from your email system. If the message cannot be retrieved, the test will be considered as failed and alerts will be sent to the designated contacts. Of course, there are other possibles scenarios, but we will take a closer look at them in our next posts.
Sooner or later email blacklists become the nightmare of most system administrators. Long story short - when your email provider is reported as a source of email spam, a lot of your email messages won't reach your family, friends, business partners, loyal and prospective customers alike.
Becoming part of a blacklist isn't what gets other email providers to filter you, it is the way they decide to do so. Blacklisting causes problems when the administrator decides to simply filter out all emails coming from a network device on a blacklist. Medieval doctors did a similar job when taking off an arm to save the patient from an infected finger. Clean email has no chance of reaching its intended location. Decent e-mail service providers usually filter spam, employing methods that utilize multiple filters before deciding whether an email message is spam or not.
Email blacklists can be IP-based and domain-based. There are a lot of blacklists out there. A week-to-week comparison of DNS blacklists is available on sdsc.edu. If your e-mail gets filtered as spam, it is very likely it has become a part of one or more of the blacklists provided on that site. Actually, if you want to filter some spam e-mails you might consider using one of the suggested blacklists.
How can you get out of a blacklists, or get the good e-mail accounts unblocked? You can try contacting the blacklist provider and promise them you will track down the spammer and never have the same problem again. That is impossible. Not the part where you track the spam account, but the part when this never happens again. No one can guarantee that. In many cases it is beyond the administrator, for one reason or another. It is way more efficient to contact the administrator of the server which is not receiving you messages and deal with them. If that does not work, try contacting the party not receiving your email and get them to speak with the administrator. That might be even better and it is more likely you sort out the situation faster.
Is your server or domain blacklisted? Find out here.