Rules and restrictions on sending emails

Information about rules and restrictions on sending email messages from Webhosting, WebSite, Mailhosting and virtual or dedicated servers

In order to prevent and suppress the sending of unsolicited e-mail messages (spam), certain rules are in place for all of our hosting services. The restrictions are designed to protect the reputation of shared mailservers, particularly in the event of mailbox or web form attacks.

Webhosting, WMS, WebSite, Mailhosting

Any bulk sending of email messages, whether solicited or unsolicited, is completely prohibited from Webhosting, WMS, WebSite and Mailhosting. This includes bulk sales offers and newsletters to subscribers. If you need to send such mail, set up a service that specializes in bulk mailing (VEDOS does not offer, provide or recommend one), or you can set up your own mailserver on a VPS or dedicated server.

Webhosting, WMS and WebSite sends emails in two ways:

  • from the web hosting server using the mail() function in PHP: this includes many contact forms, WordPress password recovery and various other (at least partially) automated messages.
  • from the email software via our SMTP server: to send an email in this way, you need to log in with your username and password to your mailbox.

Mailhosting allows sending emails only via SMTP. For Webhosting and WMS , it is not possible to send unauthorized emails via SMTP protocol (it is not possible to establish a connection outside via TCP port 25). To send mail via SMTP protocol from the web application, it is necessary to send authorized (i.e. after logging in) via our mail server or a third-party server on port 587.

The following table summarizes the email sending restrictions of the hosting services:

RestrictionsWebhosting NoLimit/Extra,
WebSite (except Free),
WMS
LowCost Web HostingMailhosting IndividualMailhosting Business (forthcoming)
Maximum number of emails sent via PHP per day50050*--
Maximum number of SMTP emails sent per day50050*5002500
Maximum size of sent e-mail including attachments (MB)100*100*100*100*
* Cannot be individually increased

When you try to send an email over the limit:

  • the mail() function in PHP returns false and the server will discard the message
  • The SMTP server rejects the message with an error message informing that the limit has been exceeded

The limitation is per calendar day, the counter is reset every day at midnight (CEST).

These limits of sent emails, except for Webhosting LowCost, can be increased by agreement with us. The legitimacy of such a request is assessed by a VEDOS technician. The increase cannot be claimed.

Virtual and dedicated servers

You can use VPS and dedicated servers to send bulk messages if the following conditions are met:

  • they must be solicited messages, i.e. recipients must be aware that they have subscribed to these messages
  • messages must be sent in non-intrusive quantities
  • messages must be sent in reasonably small batches, never in large quantities at once
  • the unsubscribe procedure must be specified in the message and the sender must accept and respect the unsubscribe requests

In the case of virtual and dedicated servers, the customer is obliged to provide us with information regarding the bulk distribution upon our request:

  • how recipients' email addresses are obtained and how consent to receive them is obtained
  • what messages are sent out
  • how often messages are sent out
  • how much is being sent (total number, rate of sending)
  • how recipients can cancel their subscription
  • any other information according to our request

If the customer violates these terms or fails to provide us with the requested information, we are entitled to block the sending of emails completely or suspend the entire server.

Why these restrictions?

First of all, it should be stressed that these restrictions are not primarily directed against our customers. Common causes and sources of spam include:

  • A security hole in the PHP script that allows it to be exploited - e.g. bulk posting to the discussion forum (the forum then sends these new posts to forum members), a bug in the contact form, etc.
  • Stealing the password to the FTP account of a website (usually from a compromised home PC), the attacker then places a malicious PHP script on the customer's website, which is then used to mass spam. The customer may not have the slightest idea about this.
  • A bug in the customer's PHP script, which, for example, "loops" and starts sending emails unplanned and intensively.

Deliberate spamming by our customers is the last thing that happens and what we deal with.

So why these restrictions? The e-mail service of Webhosting, WMS, WebSite and Mailhosting is shared - several hundred customers have their pages or mailboxes on one server. If such a server starts sending out messages in bulk (for any reason) and is subsequently blocked by the recipient's email server, everyone else on the same server will be temporarily, or even permanently, blocked as well (because they all have the same IP address). If such blocking is set up by a major email service provider such as List, Gmail, or Outlook, large numbers of users and customers will not receive even legitimate messages from that server until the situation is remedied and the address is unblocked. This can take hours or even longer.

Why aren't restrictions addressed when something happens? The solution must be preventive. If an attacker finds a loophole in the security of a website or email and starts exploiting it for mass spamming, it's too late. Sending tens of millions of messages is a matter of a single script and a relatively short time; by the time we would have received and processed the message, such a server would already be blocked in various places on the Internet.

This solution is not evil. Do not take this as a restriction against you. Think of it as protecting you from having your site used for illegal activities. With this precautionary measure, we are able to ensure that the right solicited emails always arrive from your site to your customers, friends, visitors, etc. Without this restriction, it might not work.

Go to top