Technical and administrative requirements for sending emails to

The following recommendations conform to standards developed by global working groups against spam, fraud and other electronic abuses.

Non-compliance with the following recommendations may result in partial or full blocking of your messages. 

Technical requirements

  • all emails should comply with RFC standards (for example, SMTP 5321; MIME 2045, 2046, 2047, 20482049);
  • affiliation with mailings should be set in the "Precedence: bulk" header of emails;
  • all mail servers used to connect to servers should have valid (real), meaningful, not automatically generated reverse DNS records (rDNS, PTR records). Contact information for IP addresses in WHOIS should be accessible and up-to-date

    rDNS examples: 
    Incorrect: rDNS:
  • all mail servers used to connect to servers should be protected from unauthorized or anonymous use. Please make sure that your server is not an open proxy server or an open relay;
  • make sure that all web forms on your websites are safe;
  • if you use scripts for sending emails from a web form, make sure they can not be used for sending spam;
  • direct connections to MX-servers from dynamic IPs or LANs are forbidden;
  • it is prohibited to use MX-records in the configuration files for SMTP servers;
  • when adding HTML to your emails, make sure that the valid structure of an HTML document is used. It is forbidden to use potentially dangerous objects, such as ActiveX, JavaScript, VBScript, Java-applets, Frames and IFrames, connected from external CSS, Meta Refresh, etc. (using these elements may result in blocking of your mailings);
  • if you use tracking pixel in emails, make sure that it has a set size in <img> tag and the size does not exceed 1x1. Images that are not tracking pixels can be received and cached during delivery process;
  • an attempt to use third-party services (redirectors, "link shorteners") to hide information about target page of any web-link in an email may result in blocking of the mailing;
  • it is prohibited to use links to IP-addresses or domains in URL-encode format in emails.

Administrative requirements

  • a mailing must only be sent upon the explicit and direct request or consent of a user (opt-in);
  • the text of every email in a subscription-based mailing must include the contact information of the organization sending the mailing, including a phone number and physical address;
  • mailings should contain a simple and obvious mechanism for unsubscription. The process of unsubscribing should not require a user to take complex actions, such as entering or recovering a password, registering, etc. As a mechanism for unsubscription we recommend you to add a well-visible link to every email with an option to unsubscribe by one click. Users must not be required to authorize at the website in order to unsubscribe from a mailing;
  • mailing senders should not hide, falsify or distort the sender and the source of sending emails;
  • information about the subscription, including the way of getting the recipient's email address, the date and time of the subscription, and the IP address used for it, should be available upon the user's request;
  • mailings should contain information about the source the user's address was taken from and his consent to receive the mailing. For example, "You received this email because you subscribed for the mailings at our website ...";
  • subscription-based services for mailings should unconditionally remove from the recipient database or take measures to stop mailouts to addresses that generate an SMTP protocol error: 550 user not found (keeping track of the validity of the recipient database is a prerequisite for maintaining the positive reputation of the sender of mailouts);
  • keep an eye out for your reputation in Postmaster

    Reputation is an integrated indicator of the "good faith" of the mailing sender, counted on a lot of factors in our system, the main ones are the number of complaints on spam, the number of non-existent addresses, the number of emails which are hit spamtraps, etc. Reputation is used by our filters to decide whether an email is spam or not.
    In case of bad reputation, your mailings can go to the recipient's Spam folder or be completely or partially blocked.

    The number of complaints that should not be exceeded (the lower the numbers - the better):

    Emails per monthLimit of complaints
    up to 10 000 1,1 %
    up to 500 000 1 %
    up to 10 000 000 0,8 %
    up to 50 000 000 0,5 %
    more than 50 000 000  0,3 %

User complaints, sending emails to non-existent recipients' addresses (including those that existed earlier, but were deleted), the inability of the sender to get non-delivery reports, the fall of emails in spam traps affect the reputation of the sender.
Delivery of emails to Mail.Ru can be blocked for any sender with negative reputation. Several violations of one author of mailings may result in partial or complete blocking of his IP-addresses in

We recommend you to start monitoring your mailings in real time by registering your domain with Postmaster It is a service, which was created specifically for mail senders, who want to improve not only the deliverability, but the quality of mailings as well.

Обновлено 6 декабря 2023 г.
Was this information helpful?