Каналите за комуникация непрекъснато се увеличават, но електронната поща остава едно от най-използваните средства. Прогнозите в световен мащаб са броят на имейл акаунтите да достигне 4.4 милиарда до 2023г. Какво можем да допълним ние? 🙂
От сървърите ни за споделен хостинг и Managed VPS за месец юни 2019г.:
- са изпратени над 41,1 милиона имейл съобщения;
- средно на ден са изпратени над 1,3 милиона имейла;
- 96.95% от изпратените съобщения са доставени на получателите за по-малко от 1 минута;
- 1.60% от общия брой изпратени съобщения са върнати с грешка за несъществуващ получател.
Сигурни сме, че много от Вас използвате ежедневно имейл, като изпращате и получавате съобщения без проблем. Въпреки това може да Ви се случи някое съобщение да не се достави успешно. Вместо съобщението да се достави на имейл адреса, към който е изпратено, се връща съобщение със следната грешка:
–– This is a copy of the message, including all the headers. ––
Return-path: <user@DomainMailWasSentFrom.net>
Received: from DomainMailWasSentToUser.tld ([XXX.XXX.XXX.XXX] helo=username)
by Host.DomainMailWasSentFrom.tld with esmtp (Exim 4.92)
(envelope-from <user@DomailMailWasSentFrom.tld>)
id 1L21sl-0003VV-ML
for user@DomainMailWasSentTo.tld; Mon, June 10, 2019 10:03 +0300
From: <user@DomainMailWasSentFrom.tld>
To: <user@DomainMailWasSentTo.tld>
Subject: Tema
Date: Mon, 10 Jun 2019 10:01:36 +0300
Message-ID: <0E5E1B6E9B65465BAED3E4FD6A3ABCC0@username>
MIME-Version: 1.0
Content-Type: multipart/related;
boundary=“–-=_NextPart_000_0009_01C948B4.ABECB620″
This is a multi-part message in MIME format…
Най-често срещаната причина за неуспешната доставка на съобщението е:
Ако получите подобен имейл с информация, че писмото не е доставено, уверете се, че сте изписали правилно имейл адреса на получателя. Проверете да не е допусната грешка в името на получателя, включително и за символи изписани на кирилица.
Нека да разгледаме следната ситуация:
Имаме два домейна – domain1.com и domain2.com, които са разположени на един хостинг сървър, в един и същ хостинг акаунт.
Пощата на domain1.com се обслужва от мейл сървъра към хостинг акаунта. domain2.com се зарежда от същия хостинг акаунт, тъй като е насочен чрез А запис към него, но пощата му се получава от външен мейл сървър (което е зададено чрез MX записа му).
Имейл акаунтите към домейн domain2.com са създадени и се управляват от външния мейл сървър.
В една такава ситуация ако изпратим имейл от email@domain1.com към email@domain2.com, писмото ще се върне с грешка „No such user here„.
Защо?
При добавяне на домейна domain2.com в хостинг акаунта, където се намира и домейн domain1.com, се създава автоматично DNS зона за него, въпреки че реално такава вече съществува там, където са нейм сървърите му. И така domain2.com има DNS зона на сървъра, на който се намира и domain1.com. В тази DNS зона DNS записите са зададени по подразбиране, така че сайтът да се зарежда от акаунта (A записът на домейна domain2.com е към този хостинг сървър) и пощата да се обслужва от мейл сървъра към хостинг акаунта (MX записът сочи към domain2.com, който пък е насочен с А запис към същия този хостинг сървър).
Какво се случва, когато се изпрати имейл от имейл акаунт email@domain1.com до имейл акаунт email@domain2.com?
При изпращане на съобщение от имейл акаунт email@domain1.com до имейл акаунт email@domain2.com, мейл сървърът първо ще направи проверка дали domain2.com е конфигуриран на същия сървър.
В случая domain2.com е конфигуриран на същия сървър (защото е добавен в cPanel), настройката на MX записа му посочва, че пощата се получава в същия този хостинг акаунт. Но реално нито един имейл акаунт не е създаден в този хостинг акаунт.
Важно е да се отбележи, че когато мейл сървърът установи, че домейнът съществува на същия сървър, той няма да провери в DNS системата какъв е реалният MX запис в оригиналната DNS зона за domain2.com.
Следователно след като имейл акаунтът email@domain2.com не съществува на същия сървър, писмото се връща към email1@domain.com с грешка „No such user here„.
Защо има Local delivery и само при СуперХостинг ли е така?
Local delivery се ползва от почти всички мейл сървъри по света. Основното предимство на локалната доставка на писмата е по-бързата доставка и същевременно се намалява броя на DNS заявките в DNS системата.
Може би ще се зачудите колко са имейлите, в които се ползва Local delivery?
Веднага даваме отговор на този въпрос – 55.14% от всички изпратени имейли от сървърите ни за споделен хостинг и Managed VPS за месец юни 2019г. са доставени чрез Local delivery.
Какво е решението?
Решението е да се редактират настройките на domain2.com в контролния панел, така че мейл сървърът на domain1.com да знае накъде да насочи писмата.
За да се посочи, че пощата към domain2.com се получава от външен мейл сървър, в Редактор на DNS зони в cPanel трябва да се редактира MX записа му – като се въведе външния мейл сървър.
Също така в настройките за Имейл маршрутизиране в cPanel, задайте за domain2.com опцията „Отдалечен мейл сървър„.
След като настройките на domain2.com са извършени, при изпращане на имейл от email@domain1.com до email@domain2.com мейл сървърът ще види, че пощата на domain2.com се получава от друг мейл сървър и ще насочи писмото към него, вместо да търси имейл акаунта локално на същия сървър.
Колко често ползвате имейл? Обръщате ли внимание на грешките за недоставени съобщения? Каква е най-честата причина за недоставено съобщение, която сте получавали?
