Email is sent using a protocol called SMTP, which is implemented on SMTP servers. These servers receive a request to send an email, and either send it on to another SMTP server, or deliver it to the correct mailbox, if this server is the final stop for the message. This is a very neat and simple system, and it worked really well until spammers came along. They discovered that an SMTP server will send email to anyone, so all they had to do was identify a couple of robust servers (that someone else was paying for), and dump millions of their spam emails onto it.

To combat this rather nasty and unscrupulous practice, SMTP servers have evolved, and added restrictions on which emails they will relay. There are several types of restriction. The first and most obvious, of course, is an authorisation restriction: the person sending the email must be authorised with a username and password before they can send the email. This works well for individuals who are sending directly to their own SMTP server, but the problem with this is that SMTP servers often send email among themselves, and they cannot possibly authorise themselves to each other (or more accurately, if they had to, the authorisation username and passwords would need to be published, which would make them redundant).

The second important type of restriction is a domain restriction. The SMTP server knows which domains it serves emails to, and it will only relay messages that pertain to email addresses in one of those domains. So, for example, the SMTP server we use to send emails from the blacksquare.co.za domain knows that it is responsible for all email deliveries for our domain. It will therefore relay any email sent from a blacksquare.co.za email account (ie: a blacksquare.co.za email address is used as the FROM field), and assume that it has come from a legitimate source. It will also deliver any email that is sent to a blacksquare.co.za email address. It will refuse, however, to have any dealings with any email that does not have a blacksquare.co.za email address in either the FROM, TO, CC or BCC fields. (Practically, that SMTP server also manages a number of other domains, and it would not refuse any of those, either.)

Your website email address

Ok, so what does that have to do with the website? Well, every email has to have at least two email addresses associated with it; a TO address, the destination of the email, and a FROM address, the source of the email. When your website sends out automated emails (eg: to notify you that an order has been placed, or to reset your password), each of those emails also needs two addresses. One is the target, and we cannot control what that might be, and the other is the source. We also know that in order to avoid the SMTP server refusing to send the email, one of these email addresses must be on a domain hosted by the local SMTP server. So, we need to provide the website with its own email address, to use as the FROM address. This will usually be info@yourdomain.com.

It is important, however, that a human being actually check email on this address. Users who receive order notices from the website, for example, will naturally reply to the email in order to query something. Users will generally ignore any instructions not to reply to this address, no matter how clear they are. The standard practice is to simply forward all emails to this address on to your primary email address.

Summary

In summary: your website requires an email address in order to be able to send and receive emails using the SMTP server that recognises your domain name. Without this address, you will not be able to process orders, queries, or contact requests via your website.