Menu
homeExcel

Lost email messages. Mail system errors

Examples of letters:

550 5.7.1 This message was not accepted due to domain owner DMARC policy (RFC 7489) https://help.mail.ru/mail-help/postmaster/dmarc

550-5.7.1 Unauthenticated email from mail.ru is not accepted due to domain"s 550-5.7.1 DMARC policy. Please contact administrator of mail.ru domain if this 550-5.7.1 was a legitimate mail. Please visit 550 -5.7.1 https://support.google.com/mail/answer/2451690 to learn about DMARC

550 5.7.1 Email rejected per DMARC policy for ...

Message delivery issue due to new policy being applied DMARC, associated with tightening the rules for passing spam filters.

DMARC is an anti-spam and anti-unauthorized mail protection protocol on behalf of a domain, based on existing mechanisms DKIM and SPF. Official website: dmarc.org.

If you receive messages similar to the ones above, most likely, mail from your site is sent on behalf of mailbox on the base @mail.ru, @bk.ru, @list.ru or @inbox.ru. Mail.Ru does not accept messages sent via phpmail if mail headers The mailbox is listed as belonging to mail.ru. Such messages, according to the policy implemented by Mail.Ru DMARC, are rejected.

How to solve a problem

There are two ways to solve the problem:

Method 1: Change the mailbox from which messages are sent

Typically, the e-mail on behalf of which mail messages are sent is registered in the administrative part of the CMS. It can also be changed directly in the script that sends messages (the “From” field).

It is necessary that messages are sent from a mailbox based on your domain name, for example « [email protected]» , where domain.ru is your domain. .

Also, the mailbox must be changed in the php.ini file:

Changing the mailbox in php.ini

  1. 1 log into your hosting control panel and open the php.ini file for editing: ;
  2. 2

    find a line like:

    sendmail_path = "/usr/sbin/sendmail -t -i -f [email protected]"

    In this line, instead of « [email protected]» specify a non-domain mailbox @mail.ru, @bk.ru, @list.ru And @inbox.ru.
    It is advisable to specify a mailbox on your domain, for example, « [email protected]» , where domain.ru is your domain.

    In addition, the mailbox specified in php.ini must exist. If you use mail on a hosting, create a mailbox on the domain and write it in the php.ini file.

Method 2: Use SMTP Authentication

You can send messages on behalf of your mailbox based on Mail.Ru by setting up SMTP authorization. In this case, all messages through your website will be sent directly from Mail.Ru servers.

Fighting spam is a headache for all responsible mail administrators. What they don’t invent to make their beloved users have a better life. However, as practice has shown in communicating with many system administrators, for some reason, not everyone understands how to properly filter spam.

The most common approach is “let’s add a bunch of RBL (DNSBL) and enjoy life.” The approach is more than completely wrong. The second most popular are content filters, often purchased for crazy amounts of money. This approach is also completely unjustified in most cases.

But everything is so simple, for a quiet life you just need to take a close look at the three headers of the incoming SMTP session. Having rummaged around on Habré and in the nooks and crannies of the Internet, I still haven’t found a comprehensive article on the topic of correct SMTP settings servers from the point of view of anti-spam. Therefore, I decided to write down everything that I know on this topic myself and what I successfully use.

By the way: this article is of course aimed primarily at administrators who want to create a high-quality spam filter. However, on the other hand, it contains very important information for those who simply have to work with mail, but who are poorly versed in all the intricacies of the process of sending electronic correspondence.

So, if you want to protect your users from spam, or vice versa, you want to prevent someone from accidentally protecting users from your letters - welcome to the cat.

A small note: the article was written with an eye to setting up a mail server Postfix, but in general it is rather theoretical in nature. The Postfix options described must be specified in the appropriate *_restriction parameters configuration file, see any Postfix configuration guide for details.

A little about the SMTP protocol

Email has many similarities to regular mail. The most important thing for us now is that all the information on the electronic “envelope” consists of only two addresses: the recipient and the sender, as well as the stamp of the postman who delivered the envelope.

Let's digress a little: imagine that a person of extremely repulsive appearance will come to you and hand over a tightly sealed parcel with the return address “Tryam from Tilimilitryamdia.” Will you risk accepting and opening? Hardly. So, email can also be easily checked and screened out based only on address information, and the scope for possible actions is much wider here.

As you should know, mail on the Internet is transferred between mail servers using the SMTP protocol. Any communication using this protocol begins with three required headers: HELO, MAIL FROM And RCPT TO. That is, before starting to transmit any data, the server first introduces itself (HELO), then reports the sender's return address (MAIL FROM) and then the recipient's address (RCPT TO). These three headings are the signature on the electronic envelope, and almost all spam can be eliminated only based on their analysis. Most attempts to send something to my server do not get beyond MAIL FROM, that is, letters are eliminated before they are actually accepted, which significantly reduces the load. That is, instead of opening a package from Tryam and finding anthrax spores there, I immediately send the postman to hell.

So, what should you do to avoid accepting emails that are known to be spam? Let's go in order.

A little about DNS

Once upon a time, in the early days of the Internet, mail was delivered directly to the nodes specified in the postal address. That is, to deliver a letter for [email protected] mail server looked for the IP address of domain.com and tried to send a package to the found IP. Then MX records appeared, which immediately solved most of the problems of such organization of mail interaction. However, some programs can still work with A records when delivering mail. But of course you have at least one MX record for your domain, right?

MX records contain server addresses, on which letters should be delivered to specified domain. However, in order to combat spam, technology has emerged that allows you to also specify server addresses in the DNS, With which letters can arrive from the specified domain. Its name is Sender Policy Framework.

I won’t go into detail about all the intricacies of the technology, I’ll just say that TXT recording

V=spf1 +mx -all

Always register an SPF record for your domain, and also enable SPF checking on your mail servers. I recommend strictly prohibiting emails from your domain from all hosts except your MX servers. Together with SPF check on your server, such a setting will immediately cut off all letters sent from third-party hosts on behalf of users of your domain to the addresses of users of your same domain. And almost half of this is spam, since usually SMTP servers are very poorly protected from letters from their own domain, and spammers actively take advantage of this. SPF will once and for all rid you of letters to Vasya Pupkin, which, judging by the envelope, were written by Vasya Pupkin, but came from a server in some Nicaragua.

Google will tell you how to set up SPF in Postfix, there is a ton of information and you can’t go wrong, so we won’t waste time on technical details.

There are a couple more extremely important notes about DNS. Most likely you know that the main DNS records, so-called A records, convert a name to an IP address. In addition to them, there are also CNAME records, which assign an alias to an already existing name. It is these two types of records that form the basis of the entire domain name system.

But few users know that there is also back entries, which convert IP to Domain name. They are called PTR. So, there are two unwritten (strictly speaking) rules that everyone still follows:

  • For each A record there must exist mirror PTR record, that is, by the host name via DNS we get the IP, and by IP we get the same host name back.
  • The address in the MX record should always be Name(not IP!) host for which an A record exists. That is, it is impossible for an MX record to contain an IP or an alias (CNAME).

If you do not comply with one of these requirements, get ready for at least a quarter of the mail from your domain to be recognized as spam. This is due to a simple thesis: a trustworthy sender always sets everything up following the rules, therefore, if the rules are not followed, then you should not trust the sender, and therefore should not accept mail from him either.

Well, to enable PTR checking for yourself, use the option

Reject_unknown_client_hostname

It requires that the IP from which the connection is made is resolved into a name via PTR, and this name is, in turn, resolved back into the desired IP.

There is also a less severe restriction specified by the option

Reject_unknown_reverse_client_hostname

In this case, the server will only check for the presence of a PTR record, but will not require the existence of a corresponding A record.

Checking the greeting

So, someone wanted to send an email to your server. The transmission begins with a greeting - the HELO header. The HELO must indicate the full domain name (FQDN) of the sender, so if this is not the case, you can safely immediately refuse acceptance. Postfix has two options for this:

Reject_invalid_helo_hostname
reject_non_fqdn_helo_hostname

The first prohibits receiving letters from hosts sending greetings with incorrect syntax, the second - from hosts sending a non-FQDN in a HELO request.

However, only the stupidest spammers (and MS products, but as they know, no laws are written) transmit FQDNs; in the end, introducing yourself to gmail.com is not difficult. Therefore, we need to take a little closer look at HELO. For this purpose use the option

Reject_unknown_helo_hostname

Which prohibits receiving letters from servers that appear to be an address for which there is no A or MX record.

The sender - should he be trusted?

So, the server has successfully introduced itself to you, the next item in the program is the sender’s address. You can also extract a lot from it useful information. I would like to note right away that the sender’s address does not have to be from the same domain as the server itself. This is a common misconception, so be aware that it is not true. One mail server can easily serve several domains.

However, if the sender's address contains a domain that does not exist at all, then the letter is clearly not worth accepting. And you certainly shouldn’t accept a letter that contains something that is not an address at all as a return address. There are two options for refusing to accept such letters:

Reject_non_fqdn_sender
reject_unknown_sender_domain

The first is checking the spelling of the address, the second is checking the existence of the domain.

Already good, but we can do something more. You can request the server serving specified address sender, to see if there is a user with this address. Indeed, it seems like a good idea to make sure that the return address really exists, otherwise we may well receive a letter from an ephemeral phantom that no one has ever heard of.

Technically, this is implemented very simply: our server opens a counter SMTP session, trying to send a letter to the sender's address. If you can successfully complete the RCPT TO sending stage with this address, i.e. If the receiving server does not suddenly declare that the specified mailbox is not on it, then it is considered that the return address sent to us exists. Naturally, no data (that is, a letter) is transmitted during verification; the session is interrupted after RCPT TO.

The option is responsible for this check of the return address

Reject_unverified_sender

From the above it follows that for any address from which you send mail from your domain, there must be a mailbox on your server. Otherwise, your letters will not pass the return address check on the recipient's side and, accordingly, will not be delivered to their destination. This is relevant for all sorts of mailings and other seemingly one-way communications that do not require a response. Always create mailboxes for all addresses from which you send mail. If you do not want to receive replies to a certain address, then simply send letters to it in /dev/null, but you can accept these letters obliged.

Does the recipient even exist?

Now we have reached the last heading of the envelope - the recipient. Everything is simple here: firstly, it would be good to check that the information transmitted to us is even an address Email. This is done using the directive

Reject_non_fqdn_recipient

In addition, we would not like to accept mail to addresses for which we do not have mailboxes. To configure this behavior, you must first create a list of serviced mailboxes, then tell Postfix about it through one of *_recipient_maps configuration file parameters, and then either use the configuration file parameter

Smtpd_reject_unlisted_recipient = yes

Or a prohibiting option that has the same effect:

Reject_unlisted_recipient

In any case, Postfix will stop accepting emails for accepted domains, if there is no mailbox for the recipient. However, this restriction will not affect the forwarding of correspondence to addresses that are not in accepted domains.

And finally, you can completely prohibit the open forwarding of letters through your Postfix, leaving only the ability to receive letters to known addresses. For these purposes, use the option

Reject_unauth_destination

It prohibits sending emails to all unregistered users (yes, you will have to configure SMTP authorization). Always use this option! Otherwise, you will quickly end up in all sorts of DNSBLs.

As a subtotal

This is how you can weed out only based on the analysis of three envelope headings great amount spam. However, spammers are cunning, so this is still not enough.

Greylisting

Sometimes mail servers are overloaded and cannot accept the letter. How do you think they respond to incoming requests in this case? Oddly enough, they answer - server temporarily unavailable, try again later. In this case, no normal sender will ever consider that the letter cannot be delivered with all the ensuing consequences. On the contrary, the sender will attempt to deliver the letter later, putting it in the queue for sending. This fact can (and without a doubt should!) be used very effectively: with every first attempt to connect from an unfamiliar host, our server will send a message about a temporary error, and let the letter pass only the second time. This will immediately filter out almost all the remaining spam, since spam servers almost never make more than one attempt to deliver a letter (otherwise they would simply “fall” due to the queue being full). This technology is called Greylisting, and it is simply necessary to use it in modern realities.

The downside of the application is a small (usually no more than half an hour) delay in the delivery of letters at the first connection from an unknown host. That is, if a server not yet known to our postfix wants to send a letter, then during the first connection attempt it is sent an error about temporary unavailability. If the server tries to connect again, then the letter is accepted, and the server is entered into reliable nodes and in the future letters from it are accepted without delay.

I also suggest you read about setting up greylisting in Postfix on Google, it’s not difficult and you can’t make a mistake.

Blocklists, or what not to do

When filtering spam, some mail administrators rely on so-called DNSBLs (RBLs) - blacklists of hosts found to be sending spam. So, never don't add no DNSBL checks to your mail servers. There are two reasons for this: the first, and most basic, lies in the second part of the first sentence of this section. Hosts are entered into these lists completely randomly and there is no guarantee that a normal host will not get there (which, perhaps at some point, was inhabited by a virus sending spam, but now the virus has already been cured, or simpler and much more realistic - one external IP for large network, in which the spammer started). The second reason is more banal: the filtering mechanism proposed above is much more effective than any DNSBL and does not rely on unverified data from third parties.

Upside down, or look from the other side of the barricades

We have learned how to filter spam, but now I will try to bring together all the information on what needs to be done to Not get into spam.

For mail server administrators:

  • Always make MX records referencing A records.
  • The A record for the mail server must always have a mirror PTR record.
  • The host in the HELO header must have an A or MX record.
  • Always create SPF records (yes, this is not necessary, but just a rule of good manners).
  • For all mail sent from an accepted domain, the return address box must exist and accept mail.
For those who send mail (from programs, websites, etc.):
  • Always send mail only with an existing return address.
  • Never send mail from a domain you don't control without checking the SPF rules for it. For example, gmail.com currently allows you to send letters on its behalf to any server, but yandex.ru and mail.ru report through SPF that sending messages on their behalf from third-party servers should attract close attention, which is interpreted by smart spam filters as an increase in the spam rating level for a given letter.
  • Never send mail through incorrectly configured SMTP servers. Checking the server for lice using the list above takes 5 minutes, the utility will help you dig or nslookup.

Summary

Of course, the proposed settings do not filter all spam. Therefore, it is quite possible that you will need to additionally use a context filter that will analyze the content of letters, for example,

Setting up sending emails without them going to spam.

Option to send emails through third-party SMTP servers (Mandrill, Mailgun, Yandex) and via personal addresses I will not consider mail services (everything is very simple there if you follow the installation instructions provided) - I will only consider the option that we have our own server on which a mail server is installed, for example Exim (like most hosters).

We will need access to edit DNS records and minimal command of the console to configure DKIM (if there is ISPmanager - and this point becomes irrelevant). In total, you will need to configure (add) 4 new entries in the DNS records of your domain: PTR, SPF, DKIM And DMARC.

  • PTR- the so-called “reverse” DNS record. It must be mandatory, because it is very big number postal services are intolerant of its incorrect indication. In theory, it should be installed by your hoster, for example DigitalOcean does this automatically. - but there is an option to manually configure it.
  • SPF- a record indicating that your server is allowed to send letters from this domain and IP. Without this entry, you are almost guaranteed to end up in spam. The installation is very simple - comprehensive information with examples on setup can be obtained at (information in the green plate) or at.
  • DKIM- electronic signature your letters. If there are two previous entries, it gives your domain and letters from it “weight,” thanks to which Yandex, for example, marks letters with a nice green checkmark.

Setting up this signature is perhaps the most difficult - as a result, 90% of sites do not have it, but it is highly recommended. It’s very easy to set it up in ISPmanager: enable DKIM support in the features tab, in editing mail domain check the DKIM box and take it already finished recording in domain properties (NS). If you don’t have ISPmanager, I advise you to use this fairly simple article: .

  • DMARC- the standard is completely new, but it is already being actively implemented by postal services and this year it is already a 100% must have. The setup is the simplest of all the entries listed above, you just need to add one of the examples listed on this page below: - I recommend the second one.
Your server is now configured and if everything is done correctly, not a single letter will go to spam. For example, a confirming screenshot from the mail.ru post office (a similar situation with complete absence defining emails as spam and by Yandex):

Setting up a return mail collector.

XenForo has an absolutely amazing mechanism that almost no one uses - a bounce email collector. I think everyone has encountered the situation that after sending a mass mailing, a large number of letters of the following type arrive in the mailbox:

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of it
recipients. This is a permanent error. The following address(es) failed:

***@rambler.ru
SMTP error from remote mail server after RCPT TO:<***@rambler.ru>:
host imx1.rambler.ru : 540 5.7.1<***@rambler.ru>:
Recipient address rejected: Your emails has been returned because the intented recipient"s email account has been suspended. The account must be re-activated to receive incoming messages.

These letters are a signal that your users’ email addresses are outdated (mailboxes are blocked, deleted, full), which means they will not receive new letters from you and, if necessary, they will not be able to restore their forum account. Many users don’t even know that they are using an outdated email address, but postal services, seeing a large number of emails being sent to non-existent addresses, they can simply add your domain to the spam list.

We need to fight this, because even on my forum, where this system has been running for several years now, there are a lot of “returned” letters, compared to the number of users:

  • To begin with, let's create mailing address, to which we will send returned letters (the mailbox is a system one and should not be used for any other purposes) - for example , where google.com is your domain.
  • Go to the admin section Settings - Email Settings. In the return address field, indicate the mailbox you created. Put a tick automatic processing undelivered letters and indicate the data for logging into your service mailbox that you created earlier: address (in the case of your own SMTP server, indicate your own), login (the address you created) and password for the mailbox. I’ll give an example of my settings - I have business mail from Mail.ru - therefore, I connect to their server to receive mail from my service mailbox

Basically, that's all the setup is. The forum will automatically, at certain intervals, go to the service mailbox you specified, download copies of returned letters that were received there, and delete them from there. In chapter Tools - Letter delivery refusal log you can view these statistics. I especially emphasize that this box cannot be used for any other purposes, otherwise you risk getting several rather funny bugs in the admin logs.

According to the conditions you set, when returning, for example, 3 emails from one address, the user will be sent to automatic reactivation - he will be asked to provide a current email address and reactivate the account. No participation from you is required - users will indicate their own current addresses email, and therefore the problem will go away over time. And when sending mailings, users with incorrect address email can be excluded from it - thereby avoiding possible hit to spam lists.

A lot of text has been written, but in fact, setting up everything - both the server and the mail collector - takes just a few minutes if you follow the instructions exactly. Set it up once and forget about the fact that letters from your forum did not reach somewhere or that your domain was added to spam lists because the database was out of date.

To simplify some of the tasks described above, you can use either - whichever you like best. I use the first one - but the choice is entirely yours. Adding your domains there will give you convenient, unlimited size mailboxes with already built-in spam filters + some simplification of server setup (some of the records will be provided automatically (with the exception of DKIM, which must be generated manually one way or another to send mail from your server)).

When you are away from home and send an email using your home email account, this message may return with a 550, 553, or relay error. The same thing can happen when you are out of the office and try to send an email using your work email account.

Description

Relaying occurs when an email message is sent to an email address whose domain (the name after the @ symbol, such as adatum.com) is not processed by SMTP or by the outgoing mail server that receives the sender's request to deliver the message. The SMTP server needs to connect to another SMTP server in order to relay the message.

If a relay error occurs while sending an email message, your SMTP (outgoing mail) server may return your message along with an error message like this:

    Subject:<тест>, Account:<тест>, server: , protocol: SMTP, server response: "550 Relay prohibited", port: 25, security (SSL): no, server error: 550, error number: 0x800CCC79".

    "The message cannot be sent because the server refused to accept the address of one of the recipients. The email contained the address:<адрес эл. почты>. Subject:<тест>, Account:<тест>, server: , protocol: SMTP, server response: "553 Sorry, this domain is not in my list of allowed hosts (#5.7.1)", port: 25, security (SSL): no, server error: 553, error number: 0x800CCC79" .

The exact text of the error message will depend on your Internet service provider. Some providers do not return an error message when they define outgoing messages as unwanted advertising. In these cases, it looks like your message is being sent to normal mode(in Outlook it remains in the folder Outgoing and appears in the folder Sent), but it is not delivered to the recipient.

Your message was rejected because the SMTP (outgoing mail) server did not recognize you as an authorized user.

SMTP is a protocol (standards used by computers to communicate) that is used by most email servers to send messages on the Internet. If you use an email program (such as Outlook) that allows you to store messages on your computer, you need access to an SMTP server to send messages.

Note: Web-based email systems (such as Windows Live Mail or Yahoo! Mail) work differently and are not covered in this article.

Spam and open relays

Advertising messages messages distributed without a request are called junk mail or spam. The volume of junk mail continues to grow because it costs those sending it virtually nothing to send. In fact, the sender doesn't even have to send the spam through their ISP's SMTP (outgoing mail) server.

While creating basic structure No one foresaw the Internet, what consequences the ability to send millions would lead to unwanted messages for a negligible fee. Thanks to the relaying capabilities of SMTP servers, spam senders disguise the true source of spam by passing it through third-party servers that allow such open relays. As a result, the spam appears to come from a site that relays the message and hides the identity of the real sender.

Until recently, most SMTP email servers operated on a trust basis. open system. In such a system, anyone from anywhere can submit a mail message to an SMTP server, and the server must accept it and forward it to the recipient or another mail server that hosts the recipient's mailbox. With this open relay, there are no restrictions preventing anyone from sending mail through the SMTP server.

Internet service provider restrictions on relaying email messages

As spam volumes increased, network administrators (the people responsible for managing Internet service provider servers) began to impose restrictions on their SMTP mail servers. These restrictions do not allow everyone to use the mail server. Imagine having a telephone in your organization's lobby that is accessible to everyone, including those outside the organization. Now only employees are allowed to use the phone.

Today, several types of restrictions are used.

    SMTP authentication is required. Just as you use a username and password to access the POP3 server (incoming mail) and your mail messages, you are required to enter a username and password to send mail messages via SMTP server. This is usually the same username and password as for the POP3 server, but can be unique.

    You must first connect to your ISP's POP3 (incoming mail) server. To receive your new mail messages, you usually connect to a POP3 (incoming mail) server. To access your mailbox you need to enter your username and password. Your network administrator can configure the server so that if you connect to the incoming POP3 server first and are authenticated, it will approve all requests to send mail messages through the outgoing SMTP server, which would otherwise be restricted from doing so.

    Requires connection from an authorized network location. If you connect to your Internet service provider from home using telephone line, via cable or via DSL modem, connection is in progress directly to the supplier's network. You are trustworthy because you have an account with a username and password provided by your Internet Service Provider. You as a client are allowed to use the SMTP server to send mail messages.

    Requires connection from a specific IP address or range of IP addresses. Your Internet service provider may allow people not directly connected to the network to access the SMTP server. For example it could be remote user in the office. The main problem is that many places use dynamic IP addresses. However, you cannot be sure that you have the same IP address every time you connect. Some organizations may have a block or range of IP addresses reserved. The ISP may consider those connecting from these IP addresses to be verified users. He may be able to provide additional information.

There are a lot of possible relay scenarios. Below are the most common situations. Perhaps one of them is similar to yours.

Situation

Is this a relay?

You're at home and have an Internet Service Provider account ending in @proseware.com that you connect to via dial-up, cable, or DSL modem. You send a message to another person whose email address also ends in @proseware.com.

Same as in the first situation, only you are sending a message to a person whose email address ends in @adatum.com.

Yes, but it doesn't block. You connect directly to the Internet service provider and thereby receive the authority to send mail through their SMTP server (outgoing mail) to any addresses, regardless of the location of the recipient's mailbox.

Are you at work. Your work email address ends in @thephone-company.com and you have a home Internet service provider account that ends in @proseware.com that you connect to via dial-up, cable, or DSL modem . In Outlook, you have the same SMTP server settings configured as at home. You send a message to a person whose email address also ends in @proseware.com.

No. Your mail is processed as usual.

You are staying at a hotel or using an Internet terminal at the airport that provides Internet access. You have a home ISP account ending in @proseware.com that you connect to via dial-up, cable, or DSL modem. In Outlook, you have the same SMTP server settings configured as at home. You send a message to another person whose email address also ends in @proseware.com.

No. Your mail is processed as usual.

Same as in the previous situation, only you are sending a message to a person whose email address ends in @adatum.com.

Yes, and this message may be blocked as relay mail. You are trying to use your ISP's home SMTP (outgoing mail) server even though you are not connected to their network. The SMTP server cannot authenticate you as an authorized subscriber to your ISP. Additionally, you are asking the SMTP server to accept the message and connect to another SMTP server to deliver it to the recipient's mailbox.

Solutions

If your situation is considered a relay, you must send the message through the server you are currently connecting to. That is, if you are at work or away from home and do not use your ISP to connect to the Internet, but want to send a message from your home account provided by that provider, you need to change your mail account settings to that SMTP server , which you use where you are (for example, a working SMTP server). Step by step instructions see article.

If this doesn't work or you prefer to use a home account, you'll need to contact your internet service provider and ask if the options described earlier are available to you. Regarding the first two restrictions (requires SMTP authentication and requires first connecting to the ISP's POP3 incoming mail server), you can make changes to Account Settings in Outlook. For instructions, see Change your email account settings.

Messages still not being sent?

You've changed your SMTP settings in Outlook or found a setting that will allow you to send email messages. But you still cannot send mail and receive an error message.

You may have done everything correctly, but network administrators use another security feature to prevent identity spoofing. Identity spoofing is simply a way of sending an email message where you hide who you are.

In Outlook, like most email programs, you can specify a "display name" and a return mailing address that appears when your message is replied to. IN junk mail these fields almost always contain false information. Do you really believe that get-rich-quick messages came from a supermodel or a world leader?

To prevent identity spoofing, some Internet service providers limit the ability to insert false information into the address field of responses. For example, if your Internet service provider's domain name ends in proseware.com, the provider may not allow you to provide a return address [email protected]. This restriction is not as widely used as those previously described, but can apply to all users regardless of their location or connection method. In this case there is no alternative. If the server administrator uses this method, you must specify the domain corresponding to your current connection in the return address.

Problem of non-delivery of mail messages - typical problem which has to be investigated.
The reason such problems arise is that the state of current standards and practices of mail systems does not allow for guaranteed delivery of messages or even for receiving a clear message about non-delivery.
Moreover, on various stages message delivery is present a large number of incorrectly configured filters.

Usually, unfortunately, no exclusive measures can be taken to investigate the problem of lost mail. This article provides a final algorithm of actions, following which you will clearly understand where the problem arose and how to fix it, if possible.
For each option, additional comment is given on whether further investigation into the issue makes sense or whether a final decision on the issue can be made immediately.

Problem sending messages from the site

Please make sure that you follow all the tips in this article exactly.

The most important:

1) The return address of the letter must be a registered mailbox on our hosting!
2) Mass mailings prohibited, by default, you can send up to 500 emails per day from the site.
3) The letter must comply with postal standards. Your script independently generates a letter and if it is not of very high quality, it will be accepted by our server, but it will not be delivered, because it will be delayed by the filters of our system or the recipient.

Problem sending messages from a person

Situation 1

The email you are sending is not in the message list.
This means our mail server did not accept the letter. The reasons may be the following:

  • The message did not arrive on our SMTP server: your mail program did not send the message. The source or solution to the problems may be the following -
    • Your account settings mail program, more precisely - the SMTP server settings. Remember that the SMTP server requires authorization with the same login and password as the incoming mail server.
    • Antivirus, security system, proxy server.
  • The letter was received by the system, but was rejected because... did not contain a correct return address. The return address of the letter must exactly match either the address of the mailbox name or one of the aliases.

Situation 2

The message is present in the list of messages in the queue.
You need to open “mail delivery statistics”, “SMTP delivery”.

Situation 2.1

The letter is present in the SMTP delivery list.
One message may have multiple delivery attempts. Preliminary attempts may be unsuccessful, this is normal. Need to find last block(string) that is relevant to the delivery of your message.

Situation 2.1.1

The “delivery log” block ends with the message 250 OK or any other message that begins with code 250 (except last line « Connection closed normally" - it does not need to be taken into account).
This means that the next mail server in the delivery chain accepted the letter and confirmed receipt of the message. All subsequent questions about the fate of the message must be directed to the administrator of this mail server. Information from the “delivery log” block, along with the date and time, will help the administrator understand the fate of the message and, if necessary, fix the problem.

Situation 2.1.2

The “delivery log” block ends with a message that begins with a code other than 250, or is accompanied by the message “Processing of job XXXXXXX incomplete or failed.”
This means that our mail server was unable to deliver the message to the recipient. In this case, you should receive a message indicating that the mail message was not delivered (“bounced”). Additional Information available from the SMTP log of the delivery you are currently viewing.

  • The message may be rejected by the recipient's server due to incorrect spam filtering. Responsibility for returning the letter lies with the server administrator whose mail server has decided that the letter is spam. Spam is not sent from the addresses of our mail server, so the decision to reject a letter based on an IP address or other formal characteristics is obviously erroneous.
    Investigate this problem There is no point on our part, because the receiving server's response is quoted. You must contact the administrator of the receiving server.
    Examples of messages indicating that the recipient's mail server rejected a message on suspicion of spam:
    • 591 your host is blacklisted
    • 450 5.7.1 ... Mail from a.b.c.d refused - see http://spamcop.net ...
    • 553 5.3.0 Spam blocked see: http://spamcop.net/ ...
    • 550 5.7.0 Your server IP address is in the SpamCop database, bye
    • 554 Service unavailable; Sender address blocked using list.dsbl.org
    • 550-Message rejected because… (…)
    • 591 your host is blacklisted, see ...
    • Message with code 4xx or 5xx, mentioning the words spam, blocked, Spamcop, Spamhaus, RBL, SBL, XBL, SPEWS, policy analysis, denied, or similar.
  • The message may be rejected by the recipient's server if the recipient is not on the server, i.e. due to an address error.
    Please specify the address before the @ symbol.
    There is no point in investigating this problem on our part, because... the receiving server's response is quoted. If you think that the address is accurate, then you need to contact the administrator of the receiving server to clarify the reason for the refusal to accept the letter.
    Examples of missing address messages:
    • 550 , Recipient unknown
    • 553 We do not relay without RFC2554 authentication
    • 550 Message was not accepted -- invalid mailbox
    • 554 …This account has been disabled or discontinued
  • Error message in the mailing address after the @ symbol. Verify the mailing address and that the recipient's domain is active and working.

    Examples of error messages after @:
    • Temporary error XXX (temporary MX resolution error) resolving "aaa.bb"
  • There was a technical error while sending the message. You can try to resend the email, or check with the recipient to see if their email server is working properly.
    You can contact the support service with a request to comment on the situation more precisely.
    Examples of technical error messages:
    • Error connecting to primary server "a.b.c.d"
    • Error connecting to alternate server "a.b.c.d"

Situation 2.2

The message is not in the SMTP delivery list. Contact Support.

Problem receiving messages

You need to go to Personal Area, select “mail delivery statistics”, “message queue” for the mailbox you need.
IMPORTANT: This type of problem can only be investigated for messages that were delivered directly to the mailbox, without the participation of a mailing list or spam filter. If your mailbox receives the message indirectly (via a mailing list), you need to investigate the issue for the mailbox that is the mailing list's primary mailbox. If the spam filter is enabled, it must be turned off.

Situation 3

The message is present in the list.
This means that the message was received by the server and posted to your mailbox. Problems with receiving such a letter are related to your system or its settings.

  • Check your spam filter settings (“ full list functions", "filtering of unwanted messages"). If the spam filter is enabled, the email may have been moved or rejected (depending on your settings). The letter could also be destroyed, regardless of the settings, if it contained a virus.
    You should try disabling mail filtering or checking all the mailboxes where the letter could have been moved, if this mode is selected.
  • Your mail system may not accept mail from our server at all. To clarify this case, look at the contents of your mailbox via web access to mail, see the link opposite the desired box on the “resource passwords” page of your personal account.
  • Sometimes the mail system of a computer or organization receives a message, and then for some reason deletes it from the server, without transmitting or saving it anywhere else. You need to contact your administrator postal system to investigate these types of problems.
    There is no point in investigating this problem on our part, because... the email was placed in your mailbox and could only be removed from it using commands from your computer using the POP3 or IMAP protocol.

Situation 4

The message is not in the list.
This means that our mail server did not accept the message.
There is no point in investigating this problem on our part. This only poses a problem to our mail system if there is evidence that the message was delivered to our server. The proof is a piece of log SMTP client sending server (a case mirrored in situation 2.2.1 above). If there is no such evidence, then investigate this case Non-deliveries must be resolved by the administrator of the sending party's mail server.

You can also try to take into account the various operating circumstances of your domain, which may lead to the fact that mail delivery to it will not work at all.

  • Make sure that the domain is active (DELEGATED), that the DNS servers correspond to the DNS servers of the site (ns1.site, ns2.site).
    • If the domain is maintained by others DNS servers, make sure the domain's MX record points to our mail server (unless stated otherwise, this should be mail.site).
    • If the domain is served by our DNS servers, go to the “full list of functions”, “DNS zone editor”, select the domain, make sure that the “1Gb..” checkbox is checked.
  • Make sure the domain was registered more than 3 days ago.