Особистий кабінет DNS (ДНР). Пошта: Налаштування DNS-записів для Яндекс.Пошти - Довідковий центр Timeweb Пошта dns

ДНС – це мережа магазинів цифрової та побутової технікияка широко представлена ​​на території Росії. У магазинах є широкий вибір товарів. На офіційному сайті DNS є можливість вибрати та придбати будь-який товар, перебуваючи у комфортній домашній обстановці. Покупку можна забрати у вибраному магазині (до вказаного часу покупка буде підготовлена ​​менеджером магазину) або замовити доставку. Для всіх можливостей ресурсу є зручний сервіс «особистий кабінет». Працює служба клієнтської підтримки, з якою можна зв'язатись через спеціальну форму для замовлення зворотного дзвінка.

Можливості особистого кабінету ДНР

Сервіс працює у цілодобовому режимі. Він дозволяє оформляти замовлення на товари, які представлені на сайті, відстежувати їх. також в особистому кабінетіможна активувати картку, щоб стати учасником бонусної програми. Для отримання картки необхідно надати номер мобільного телефонаспівробітнику в будь-якому магазині мережі (вона видається безкоштовно, діє 5 років). У будь-який момент у кабінеті можна переглянути кількість бонусних балів, історію їх нарахування. Також власники особистих кабінетів можуть побачити всі акції та інші вигідні пропозиції, новини компанії. Актуальна інформація надходить на телефон або електронну пошту, які прив'язані до облікового запису.

За допомогою сервісу можна запитати службу технічної підтримки в чаті в режимі онлайн. Зберігається історія замовлень та платежів. На її підставі співробітник компанії формує вигідні індивідуальні пропозиції для зареєстрованих користувачів

Для правильної роботи поштового сервера важливо мати правильно налаштовану зону DNS. Ми вже стосувалися деяких аспектів, пов'язаних із системою DNS, сьогодні ми зупинимося на цьому питанні більш докладно. Налаштування DNSзони відноситься до підготовчих операцій перед розгортанням поштового сервера та від неї безпосередньо залежить працездатність системи електронної пошти.

Неправильні налаштуванняздатні призвести до того, що пошту буде неможливо доставити вашому поштовому серверу або сервера одержувачів будуть відхиляти вашу пошту. Справді, якщо записи вашої зони не містять відомостей про поштовий сервер, куди має надсилатися пошта? На село дідусеві? Можна, звичайно, попросити налаштувати зону DNS вашого провайдера, але краще зробити це самим.

Що нам знадобиться? Виділена IP-адреса (припустимо 11.22.33.44), яку ви повинні отримати у свого провайдера. Доменне ім'я (наприклад, example.com), його можна зареєструвати у будь-якого реєстратора або їхнього партнера. При реєстрації у партнера уточнюйте, чи він надає доступ до управління DNS зоною, інакше доведеться витратити додатковий час, нерви та гроші на перенесення домену до реєстратора.

Якщо у вас вже є домен і, швидше за все, на ньому функціонує сайт, уточніть, чи можливе керування DNS зоною з панелі хостинг провайдера, інакше краще перенести домен до реєстратора, для цього зверніться до підтримки провайдера.

Тож домен у нас є. Які записи містить його зона DNS? По-перше, це SOA запис - опис зони. Ми не будемо докладно розбирати всі записи, це виходить за межі нашої статті, але мати загальне уявлення про них необхідно. Також повинні бути два NS записи, що вказують на сервер імен ( DNS сервера) що обслуговують даний домен, це будуть сервери реєстратора або хостинг провайдера.

Першим записом, який необхідно додати, буде A запис або запис імені. Вона повинна вказувати на IP-адресу вашого сервера, якщо ви вирішите обслуговувати всі запити до домену у себе або на адресу IP хостинг провайдера, якщо вирішите розмістити свій сайт на хостингу. При розміщенні сайту у хостера домен зазвичай делегується на його DNS сервері (прописуються відповідні NS записи) і A запис буде зроблено автоматично при паркуванні домену.

Найчастіше зустрічається цей варіант, але при необхідності ви завжди зможете створити запис A самі. Цей запис має вигляд

Example.com. IN A 22.11.33.44

У нашому прикладі 22.11.33.44 адреса нашого хостинг-провайдера, у якого розташований сайт. Зверніть увагу на точку в кінці імені, це вказує, що ім'я абсолютне, за відсутності точки ім'я вважається відносним і до нього додається доменне ім'я з SOA. Перевірити запис можна командою nslookup.

Для роботи поштового сервера потрібно створити запис MX, який повинен вказувати на наш поштовий сервер. Для цього створимо запис:

Example.com. IN MX 10 mail.example.com.

Також можна написати просто:

Example.com. IN MX 10 mail

Таке ім'я (без точки на кінці) example.com буде додано автоматично. Цифра 10 визначає пріоритет сервера, що вона менше, тим вищий пріоритет. До речі, DNS зона вже може містити запис MX MX:

Example.com. IN MX 0 example.com

Зазвичай цей запис автоматично створюється хостинг-провайдером при розміщенні сайту, його потрібно видалити.

Тепер створимо запис A для mail.example.com

Mail.example.com IN A 11.22.33.44

Тепер вся пошта для домену example.com надсилатиметься хосту mail, що має адресу 11.22.33.44, тобто. Вашому поштовому серверу, в той же час, сайт example.com продовжить працювати на сервері провайдера за адресою 22.11.33.44.
Може виникнути питання, а чому не можна відразу вказати в MX запис IP адресу поштового сервера? В принципі, деякі так і роблять, але це не відповідає специфікаціям DNS.

Також можна зробити аліаси для поштового сервера типу pop.example.ruі smtp.example.ru. Для чого це треба? Це дозволить клієнту не залежати від особливостей вашої інфраструктури, один раз прописавши налаштування. Допустимо, що ваша компанія розрослася і виділила для обслуговування зовнішніх клієнтів окремий поштовий сервер mail1, все, що вам знадобиться, це змінити два DNS записи, клієнти і не помітять того, що працюють з новим сервером. Для створення аліасів використовуються записи типу CNAME:

Pop IN CNAME mail.example.com.
smtp IN CNAME mail.example.com.

На цьому налаштування прямої DNS зони можна вважати закінченою, залишається найцікавіше – зворотна зона. Зворотна зона управляється провайдером, який видав вам IP адресу і самостійно керувати нею ви не можете (якщо тільки ви не власник блоку IP адрес). Але додати щонайменше один запис у зворотну зону необхідно. Як ми писали в минулій статті, багато поштових серверів перевіряють PTR записи (записи зворотної зони) для відправляючого сервера і за їх відсутності або розбіжності з доменом відправника такий лист буде відхилено. Тому попросіть провайдера додати вам запис виду:

44.33.22.11.in-addr.arpa. IN PTR mail.example.com.

Трохи дивний вигляд, чи не так? Розберемо структуру PTR записи докладніше. Для зворотного перетворення імен використовується спеціальний домен верхнього рівня in-addr.arpa. Це зроблено для того, щоб використовувати для прямого та зворотного перетворення імен ті самі програмні механізми. Справа в тому, що менімонічні імена пишуться зліва направо, а IP адреси праворуч наліво. Так mail.example.com. означає, що хост mail знаходиться в домені example, який знаходиться в домені верхнього рівня com. задом наперед" доповнений доменом верхнього рівня in-addr.arpa.

Перевірити MX та PTR записи також можна командою nslookupвикористовуючи додатковий параметр -type=MXабо -type=PTR

Ну і звичайно не варто забувати, що будь-які зміни в DNS зонах відбуваються не миттєво, а протягом кількох годин або навіть доби, необхідних для поширення змін у світовій системі DNS. Це означає, що незважаючи на те, що поштовий сервер у вас почне працювати через 2 години після внесення змін, ваш партнер пошта може не відправлятися до вас протягом більш тривалого часу.

Для мене загадка чому розгортання навіть примітивної конфігурації поштового сервера для багатьох системних адміністраторівє такою серйозною проблемою. Проте це так. Мені б ніколи не спало на думку писати про це цілу статтю, але судячи з невичерпної кількості питань, це зробити все ж таки необхідно. Найбільше складнощів викликають базові DNS-записи для поштового сервера, про них і поговоримо.

Якщо вам цікава тематика поштових серверів, рекомендую звернутися до відповідних тегів на моєму блозі - і .

У статті розглянуті базові записи, які або необхідні, або дуже бажані для нормального функціонування поштового сервера.

Ну а тепер почнемо розбиратися, що потрібно зробити перед створенням записів.

Купівля доменного імені

Почати необхідно з придбання доменного імені. Це не так складно, як здається, і не так дорого. Новий доменв.ru-зоні може коштувати не більше 100-200 рублів.

Як тільки домен куплений, можна приступати до створення записів. У всіх реєстраторів різні адмінки, але знаючи теорію, у специфіці додавання записів розібратися найпростіше.

Примітка:коли ви вказуєте A-запис, на який посилається CNAME при його створенні, у деяких реєстраторів може знадобитися прописувати A-запис повністю з точкою (наприклад, record.bissquit.com.), а у когось достатньо вписати просто частину до домену (просто record без усього, як у попередньому прикладі).

Хочу відразу попередити, що поширення щойно створених записів займає деякий час, зазвичай це від 15 хвилин до декількох годин (або теоретично навіть доби, але мені таке не зустрічалося).

A

Насамперед створіть основний A-запис, який вказуватиме на зовнішню адресу вашого поштового сервера. Допустимі будь-які варіанти, але зазвичай вибирають щось схоже на mail.domain.tldабо mx1.domain.tld. Якщо ви використовуєте власний DNS-сервер bind, то A-запис усередині зони може виглядати так:

Shell

mail IN A 1.2.3.4

На цей запис буде вказувати MX.

MX

Цей запис перекладається як mail-exchangerі, власне, вона є основною для поштових серверів. Таких записів може бути кілька і кожна з них обов'язково має значення пріоритету - чим воно менше, тим пріоритет вищий. Навіщо це використовується? Головним чином визначення черговості звернення до MX-записів, якщо їх кілька.

Часто зустрічається, що кілька MX-записів для одного домену мають однаковий пріоритет. У цьому випадку вхідний трафік буде рівномірно балансувати між серверами.

Примітка:Строго кажучи, наявність пов'язаного MX-запису для вашого сервера, що відправляє, не так вже й обов'язково. Надіслати пошту ви зможете без проблем і сервери цільового домену її отримають. Але, ймовірно, на серверах, що приймають, пошта миттєво потрапить у спам, оскільки відправляючі домени без MX відразу ж позначаються як підозрілі. Виникнути проблеми можуть також і з отриманням пошти, хоча теоретично доставка листа без запису MX повинна виконуватися на основний A-запис домену (згідно RFC 5321).

Якщо заглиблюватися в архітектуру поштових рішень, дуже часто запис MX вказує на mail-relay або сервер антиспаму (spamassasin, наприклад, або Exchange Server Edge), а не на кінцевий поштовий сервер, що зберігає вхідні/вихідні листи. Це цілком розумний підхід, коли окремий сервер виступає як прикордонний шлюз, а інший — з критично важливими даними для бізнесу — своєрідним бекендом. Я скажу більше, це навіть best practice.

Скільки MX потрібно для щастя

Кмітливому читачеві може спасти на думку дуже цікава думка: «А що краще — два записи MX або один запис MX, але що посилається на два однакові A-записи?». Візуально це виглядає так:

В разі b.виходить своєрідний Round Robin. Але якщо відкинути нюанси, варіант a. аналогічний! Адже однаковий пріоритет MX-записів забезпечує таку саму функцію.

Тим не менш, і в цьому випадку у багатьох виникають сумніви. Головним чином вони обумовлюються думкою, що у випадку b., якщо сервер, що відправляє, в першій спробі відправки потрапить на непрацюючий сервер, то він відкладе відправку і спробує наступного разу, через таймати. Але це докорінно неправильно - він спробує відправити на другий сервер з видачі RR відразу ж. Це демонструє наочний експеримент.

Коли на запити відповідають обидва сервери з варіанта b., ми бачимо наступний запис у smtp-сесії при спробі надсилання на них листа ( Queued mail for deliveryлист прийнято до доставки):

Shell

Якщо ж з якихось причин один із серверів відключився і сторона, що відправляє, потрапила в першу спробу на нього, відразу ж піде друга спроба відправити пошту на другий сервер з видачі (після Connection timed outвперше йде вдала друга спроба):

Shell

Feb 14 14:02:16 mail postfix/smtp: connect to mail.domain.tld:25: Connection timed out Feb 14 14:02:17 mail postfix/smtp: 35E8F140073: to=

Примітка:якщо когось зацікавить дилема вибору «правильної» ієрархії MX, рекомендую звернутися до топіка DNS — MX, A, TLL та поштовий сервер на форумах Technet. Приклад з логами відправлення взято саме звідти, я є його автором.

А тепер повернемося від теорії до практики і подивимося, як же справи у великих публічних поштових сервісів:

Shell

#dig-t MX mail.ru +short 10 mxs.mail.ru. dig -t A mxs.mail.ru +short 94.100.180.104 94.100.180.31 dig -t MX yandex.ru +short 10 mx.yandex.ru. # dig -t A mx.yandex.ru +short 213.180.204.89 77.88.21.89 213.180.193.89 87.250.250.89 93.158.134.89

Mail та Yandex використовують для своїх сервісів саме варіант із RR для A-записів, а ось Google — ні:

Shell

# dig -t MX gmail.com +short 5 gmail-smtp-in.l.google.com. 20 alt2.gmail-smtp-in.l.google.com. 30 alt3.gmail-smtp-in.l.google.com. 40 alt4.gmail-smtp-in.l.google.com. 10 alt1.gmail-smtp-in.l.google.com.

Тому саме вам вирішувати, який варіант вибрати.

PTR

З PTR немає такого простору для творчості, як у випадку з MX, і від цього тільки легше. PTR-запис належить зворотній зоні і має зіставити ip-адресу з DNS-іменем (тобто, адреса має дозволятися в ім'я).

У ідеальному випадку має відбуватися «кругове» дозвіл записів. Що це таке, легко зрозуміти на прикладі: з MX отримуємо A-запис, з A-запису отримуємо ip-адресу, від цієї адреси беремо PTR-запис, який в ідеалі повинен вирішитися в A-запис, на який вказував MX спочатку. І так по колу:

Але насправді це явно надлишковий перфекціонізм. До того ж, що ви робитимете, якщо ваш сервер обслуговуватиме кілька доменів одночасно (адже це дуже часта ситуація)?

Примітка:гіпотетично ви можете створити кілька PTR для однієї ip-адреси, адже RFC це не забороняє. Тим не менш, софт на клієнтській стороні зазвичай не вміє коректно обробляти таку ситуацію і просто висмикне перший запис з видачі. Цей запис може виявитися зовсім не тим, який вам потрібний. Крім цього, більшість провайдерів просто відмовлять вам на прохання створити кілька PTR. Тому використовуйте один запис для однієї адреси і подбайте про те, щоб поштовий сервер у привітанні HELO видавав ім'я, в яке дозволяється адреса сервера, ось і все.

Заради інтересу давайте перевіримо тих самих публічних провайдерів:

Shell

#dig-t MX mail.ru +short 10 mxs.mail.ru. # dig -t mxs.mail.ru +short 94.100.180.104 94.100.180.31 # dig -x 94.100.180.104 +short mxs.mail.ru.

Ну і, зрозуміло, їхні адреси матимуть PTR абсолютно не пов'язану з ім'ям, наприклад bk.ru. Таким чином, по суті жорстка відповідність не обов'язково, і ви можете використовувати PTR з будь-яким вашим доменним ім'ям. Головне, щоб запис існував, адже дуже багато серверів перевіряють наявність PTR і, якщо його немає, різко підвищують спам-рейтинг ваших повідомлень.

На даний момент використання пошти на домені в Яндексі доступне в рамках сервісу Яндекс.Коннект.

4. Знайдіть домен, для якого планується внести зміни, клацніть на значок шестерні та виберіть "Налаштування DNS".

5. Натисніть на "Додати DNS-запис", виберіть "TXT" і вкажіть запис, отриманий в Яндекс.Коннекті.

Як правило, потрібно 10-15 хвилин, щоб зміни набули чинності.

7. Після того як зміни будуть застосовані, натисніть "Запустити перевірку" в Яндекс.Коннекті. Дочекайтеся підтвердження домену (зазвичай виконується дуже швидко).

8. Налаштуйте для домену записи DNS за вказівками нижче.

MX-запис

SPF-запис

2. Знайдіть домен, для якого планується внести зміни, клацніть на значок шестерні та виберіть "Налаштування DNS".

3. Видаліть існуючі TXT-записи (попередньо скопіюйте значення SPF-запису, якщо ви плануєте надсилати пошту також із вказаних у ній серверів).

V=spf1 ip4:IP1 ip4:IP2 ip4:IP3 include:_spf.yandex.net ~all

де IP1, IP2, IP3 – IP-адреси додаткових серверів.

6. Збережіть зміни за допомогою кнопки "Додати".

DKIM-підпис

1. Отримайте TXT-запис із публічним ключем в Яндекс.Коннекті:

• Відкрийте сторінку адміністрування електронної пошти .
• Перейдіть на вкладку "DKIM-підписи".
• Скопіюйте підпис DKIM для потрібного домену.

2. Знайдіть домен, для якого планується внести зміни, клацніть на значок шестерні та виберіть "Налаштування DNS".

3. Видаліть наявні записи MX.

4. Натисніть на "Додати DNS-запис", виберіть "MX" і у вікні позначте пункт "Яндекс.Пошта":

5. Збережіть зміни за допомогою кнопки "Додати".

6. Зачекайте, поки зміни в DNS набудуть чинності. Цей процес може тривати до 72 годин.

SPF-запис

2. Знайдіть домен, для якого планується внести зміни, клацніть на значок шестерні та виберіть "Налаштування DNS".

3. Видаліть існуючі TXT-записи (попередньо скопіюйте значення spf-запису, якщо ви плануєте надсилати пошту також із вказаних у ній серверів).

4. Натисніть "Додати DNS-запис", виберіть "TXT" і у вікні розмістіть наступне значення:

V=spf1 redirect=_spf.yandex.net

5. Якщо ви бажаєте надсилати листи не лише з серверів Яндекса, вкажіть додаткові сервери у такому форматі:

V=spf1 ip4:IP-1 ip4:IP-2 ip4:IP-3 include:_spf.yandex.net ~all

де IP-1, IP-2, IP-3 – IP-адреси додаткових серверів.

6. Збережіть зміни за допомогою кнопки "Додати".

7. Зачекайте, поки зміни в DNS набудуть чинності. Цей процес може тривати до 72 годин.

DKIM-підпис

2. Знайдіть домен, для якого планується внести зміни, клацніть на значок шестерні та виберіть "Налаштування DNS".

3. Натисніть "Додати запис DNS" і виберіть пункт "TXT".

4. У вікні параметрів вкажіть "mail._domainkey" у полі "Хост" та внесіть у поле "Значення" параметри DKIM з публічним ключем, отримані в Пошті для домену . Наприклад, "v=DKIM1; k=rsa; t=s; p=MIGfMA0GCSEBtaCOteH4EBqJlKpe..."

5. Збережіть зміни за допомогою кнопки "Додати".

6. Зачекайте, поки зміни в DNS набудуть чинності. Цей процес може тривати до 72 годин.

CNAME-запис

2. Знайдіть або створіть піддомен mail.ваш_домен і клацніть на значок шестерні.

3. Натисніть "Додати запис DNS" і виберіть "CNAME".

4. У вікні параметрів внесіть значення "domain.mail.yandex.net":

5. Збережіть зміни за допомогою кнопки "Додати".

6. Зачекайте, поки зміни в DNS набудуть чинності. Цей процес може тривати до 72 годин.

• Немає міток

3. Видаліть наявні записи MX.

4. Натисніть "Додати DNS-запис", виберіть "MX" і у вікні позначте пункт Mail.ru:

5. Збережіть зміни за допомогою кнопки "Додати".

6. Зачекайте, поки зміни в DNS набудуть чинності. Цей процес може тривати до 72 годин.

SPF-запис

2. Знайдіть потрібний домен, клацніть на значок шестерні та виберіть "Налаштування DNS".

3. Видаліть наявні TXT-записи, що починаються з v=spf1 (попередньо скопіюйте значення spf-запису, якщо ви плануєте надсилати пошту також із вказаних у ній серверів).

4. Натисніть "Додати DNS-запис", виберіть "TXT" і у вікні розмістіть наступне значення:

V=spf1 redirect=_spf.mail.ru

5. Якщо ви бажаєте надсилати листи не лише з серверів Mail.ru, вкажіть додаткові сервери у такому форматі:

V=spf1 ip4:IP1 ip4:IP2 ip4:IP3 include:_spf.mail.ru ~all

де IP-1, IP-2, IP-3 – IP-адреси додаткових серверів.

6. Збережіть зміни за допомогою кнопки "Додати".

7. Зачекайте, поки зміни в DNS набудуть чинності. Цей процес може тривати до 72 годин.

DKIM-підпис

2. Знайдіть потрібний домен, клацніть на значок шестерні та виберіть "Налаштування DNS".

3. Натисніть "Додати запис DNS" і виберіть пункт "TXT".

4. У вікні налаштувань:

• у полі "Хост" вкажіть mailru._domainkey
• у поле "Значення" внесіть параметри DKIM, отримані в особистому кабінеті https://biz.mail.ru/ у розділі " ".