Client-side validator for contact information form (name, phone, e-mail)
Validation problems
Beware of overzealous validation. It's easy to create bugs by rejecting valid input. For example:

Some people have only one name, so the one of the name fields must be allowed to be empty.
Names often contain non-ASCII characters. Validation must not tell the user their name is invalid!
Email addresses can contain more characters than you think. For example, &quot;Hello, world!&quot;@localhost.localdomain is a valid address. The validity rules are complex, so if you try to implement them with a regex, you will get it wrong. Fortunately you don't need to reject all invalid addresses, only the most common mistakes. So /@/ is enough validation for practical purposes.
Phone numbers can be long, because of country codes and extensions. They can also contain characters like +-()x.

You can avoid these problems by not doing much validation. Don't do unnecessary work that creates bugs!
I wouldn't bother with the event filters at all, especially for the name, where any character should be accepted.
Style
onlyAlphabets should be called onlyLetters (it allows letters, not whole alphabets!), or onlyNameChars, since it also allows some other characters.
e.which ? e.which : e.keyCode can be simplified to e.which || e.keyCode.
This conditional...
if ((charCode == 64) ||
    (charCode == 32) ||
    (charCode &gt;= 65 &amp;&amp; charCode &lt;=90) ||
    (charCode &gt;= 97 &amp;&amp; charCode &lt;=122))
    return true;
    else return false;

...can be simplified to:
return charCode == 64 ||
       charCode == 32 ||
       charCode &gt;= 65 &amp;&amp; charCode &lt;= 90 ||
       charCode &gt;= 97 &amp;&amp; charCode &lt;= 122;

...but character codes are hard to read. It might be better to use the string form instead, via operations like String.fromCharCode and charCodeAt.
There are too many blank lines. It's OK to leave one blank line to separate sections (like a paragraph break), but (like anything that consumes lines) they reduce the amount of code that fits on one screen, they should be used only when they improve clarity enough to be worth the extra scrolling.