Technical and administrative requirements for incoming messages
These requirements are designed to meet the standards developed and adopted by the participants of the global working group on countering spam, fraud and other forms of electronic abuse.
Failure to comply may result in partial or complete non-delivery of Your e-mail.
- all e-mails must meet the RFCstandarts (e.g., SMTP 5321; MIME 2045, 2046, 2047, 2048, 2049;
- All e-mail servers that connect to Inbox.lt must have valid (true), sensible, not automatically generated reverse DNS records (rDNS, PTR-records). Contact details on IP-addresses in the WHOIS must be relevant and accessible.
Examples of rDNS:
Correct rDNS: mail.domain.com
Generated incorrect rDNS: 126.96.36.199.domain.isp.com
- All mail servers that connect to the Inbox.lt mail servers must be adequately protected from unauthorized or anonymous use. Make sure that Your server is not an open proxy or open relay.
- Ensure that all web forms on Your sites are safe;
- If You are using scripts that send e-mails from a web form, make sure that they cannot be used to send spam;
- Direct connection to the Inbox.lt MX-mail servers from dynamic IP-addresses or home networks’ addresses are not allowed;
- Inbox.lt MX-records are not allowed to be hard-coded in the configuration files of sender servers;
- Attempt to use third-party services (redirectors, "URL shorteners") to conceal information about the landing page of any web links in the letter could lead to the fact that the delivery will be blocked;
- URL-encoded IP-addresses and domain names are forbidden to use as links in the letters.
- mailing should be carried out exclusively by explicit and direct request or consent of the recipient (opt-in);
- all subscription sent e-mails should contain valid non-electronic contact information about the subscription company in the text of each message, including the phone number and physical address;
- The process of unsubscribing should not require complex actions, such as password input or recovery, registration, etc. We recommend to add a clearly visible link with the opportunity to unsubscribe in a single click as an unsubscribe mechanism in each e-mail. Users do not need to authenticate on the website to unsubscribe;
- mailers shall not engage in acts of concealment, falsification or distortion of the e-mail’s sender and the sending source;
- subscription information, including the method how the e-mail address has been received, date and time of subscription, and the IP-address from which the user has confirmed the subscription should be available on user demand;
- Subscription e-mails should contain information about the way how user's address was obtained and user’s agreement to receive subscription e-mails. For example, "You are receiving this e-mail because You have subscribed on our website ...";
- Services that perform subscription-based mailing should definitely remove subscribers from the database or take action to suspend the mailings to addresses that generate an SMTP protocol error: 550 user not found (tracking the validity of the recipient base is a necessary condition to maintain the positive reputation of the mailer).
User complaints, sending to non-existent recipients (including the pre-existing, but deleted), the inability for sender to receive non-delivery reports and if messages are getting in the Inbox.lt spam traps – all this affects the reputation of the sender. The ability to deliver messages to Inbox.lt can be disabled for any sender with a negative reputational feature.
A series of violations by the same mailer may lead to partial or complete blockage of its IP-addresses in Inbox.lt.
If you were unable to find answer for your question, please write to email@example.com