MX записи и приоритет

Модул 4: Записи за имейл · Време за четене: 8 минути

Цел на урока: След този урок ще можете да четете и настройвате MX записи, да изберете правилния приоритет и да обясните какво се случва, ако даден домейн няма MX запис.

Основни понятия: MX запис, приоритет (preference), резервен MX, мейл сървър (hostname), имплицитен MX, null MX, локално доставяне

Къде трябва да отиде имейлът?

Когато някой изпрати имейл до info@example.com, мейл сървърът на подателя трябва да разбере на кой сървър да достави този имейл. Той проверява това в DNS, с заявка за MX записа (Mail eXchanger) на example.com.

Отговорът не е IP адрес, а списък с мейл сървъри, всеки с число пред себе си:

example.com.   3600  IN  MX  10 mail.example.com.
example.com.   3600  IN  MX  20 backup.example.net.

След това изпращащият сървър заявява A или AAAA записа на mail.example.com, и едва тогава знае към кой IP адрес да се свърже. Значи MX записът винаги сочи към име, което от своя страна има собствен A или AAAA запис.

MX записът почти винаги е на самия домейн (@), защото става дума за частта след @ в имейл адреса. Искате ли да получавате имейли на info@nieuws.example.com, тогава nieuws.example.com се нуждае от собствен MX запис.

Приоритет: по-ниското число е на ред първо

Числото пред мейл сървъра се нарича приоритет (в стандарта, RFC 5321, се нарича preference). Правилото е просто:

• Колкото по-ниско е числото, толкова по-рано този сървър е на ред.
• Ако този сървър не е достъпен, подателят опитва следващия.
• Ако два сървъра имат едно и също число, подателят разпределя имейлите произволно между двата. Така можете да разпределите натоварването.

Самото число не означава нищо. 0, 1, 5, 10 или 100: само редът има значение. Запис с приоритет 10 и друг с 20 работи по абсолютно същия начин като 1 и 2. Ако Вашият доставчик на имейл услуги Ви даде число, използвайте точно него. Ако той посочи само един сървър, числото няма значение.

Сървър с по-високо число често наричаме резервен MX. Преди това беше обичайна практика: ако собственият Ви сървър не работеше, резервният запазваше имейлите. Днес изпращащ сървър сам запазва имейлите за няколко дни и опитва отново. Неправилно настроен резервен MX (например без спам филтър) всъщност привлича спам. Затова използвайте такъв само ако доставчикът Ви изрично го препоръчва.

Правила за добър MX запис

1. Име, не IP адрес. MX 10 192.0.2.25 е невалиден. Създайте A запис mail с 192.0.2.25 и оставете MX да сочи към mail.example.com.
2. Не към CNAME. Името в MX запис трябва само по себе си да има A или AAAA запис, не CNAME (RFC 2181, параграф 10.3). Много сървъри все пак го разрешават, но не всички.
3. Точката в края. В много контролни панели въвеждате mail.example.com. с точка. Без точка панелът ще добави домейна Ви отново в края: mail.example.com.example.com. Това име не съществува и имейлите Ви няма да пристигнат.
4. Мейл сървърът трябва да съществува. Ако MX сочи към име без A или AAAA запис, нищо няма да пристигне. На практика това често се случва, когато някой прехвърли DNS сървърите на домейна си към уебсайт билдър: MX записът се прехвърля, но A записът на mail не.
5. Премахнете старите записи. Ако преминавате към друг доставчик на имейл услуги, премахнете MX записите на стария доставчик. Ако ги оставите, част от имейлите Ви все още ще пристигат при стария доставчик.

Без MX запис: имплицитен MX и null MX

Какво се случва, ако даден домейн изобщо няма MX запис? Според RFC 5321 изпращащият сървър тогава опитва A или AAAA записа на самия домейн. Това се нарича имплицитен MX. Ако уебсайтът Ви е на сървър без имейл услуга, светът ще се опита да достави имейлите до Вашия уеб сървър. Това причинява забавяне и съобщения за грешка при подателя.

Искате ли да покажете ясно, че даден домейн никога не получава имейли, използвайте null MX (RFC 7505):

example.net.  3600  IN  MX  0 .

Приоритет 0 и като мейл сървър само точка. Подателят веднага вижда, че не трябва да опитва, и изпраща директно коректно съобщение за грешка на подателя. Комбинирайте това със SPF запис v=spf1 -all (урок 4.3), ако домейнът също не изпраща имейли.

Локално доставяне: капанът при хостинг с имейл

Много хостинг пакети имат уеб сървър и мейл сървър на една машина. Този сървър по подразбиране мисли: "имейла за този домейн ще доставя сам". Ако преместите имейла си към друг доставчик, Вие променяте MX записите, но сървърът не запомня това автоматично. Резултатът: имейли от собствената Ви контактна форма, както и от други уебсайтове на същия сървър, остават на стария сървър и никога не пристигат при новия Ви доставчик. Подателят понякога получава 550 Unknown user обратно.

Този въпрос хостинг компаниите получават много често. Затова в повечето контролни панели има превключвател с име като "Използвай този сървър за обработка на моите имейли" или "Локално доставяне на имейли". Премествате имейла си при друг доставчик? Променете MX и изключете този превключвател. Ако направите само едното, нещо ще се обърка.

На практика: ето как изглежда в контролен панел

В този пример използваме DirectAdmin. Под E-mail Manager, MX Records виждате MX записите на домейна си. При всеки запис въвеждате приоритета в поле и мейл сървъра след него, с точка в края. Отдолу е отметката Използвай този сървър за обработка на моите имейли. При MX Template можете да изберете готови настройки например за Microsoft 365 или Google Workspace.

В Моят WebOké същото е в раздела DNS на даден домейн; превключвателят там се нарича Доставяне.

В cPanel, Plesk, Cloudflare или при Вашия регистратор екранът изглежда по различен начин, но винаги попълвате едни и същи три неща: името (@ или празно), приоритета и мейл сървъра.

Обобщение

• MX записът казва къде трябва да отиде имейлът за Вашия домейн. Той сочи към име, никога към IP адрес или CNAME.
• Най-ниският приоритет е първи; еднакви числа разпределят имейлите; самото число не означава нищо.
• Без MX, светът опитва Вашия A запис (имплицитен MX). Ако никога не получавате имейли, използвайте MX 0 . (null MX).
• Ако преместите имейла си, премахнете старите MX записи и изключете локалното доставяне на хостинг сървъра си.

Тест

Задача

Задача Z4.1: Търсене на MX. Намерете MX записите на wikipedia.org (или на собствения си домейн). Попълнете кой мейл сървър има най-ниското число за приоритет и кое е това число.

Задача O4.1: Самостоятелна настройка в тренировъчната Ви зона. Създайте в тренировъчната си зона <code>.dnspractice.eu два MX записа: приоритет 10 към mail.<code>.dnspractice.eu и приоритет 20 към backup.<code>.dnspractice.eu. Създайте за двете имена по един A запис: mail към 192.0.2.25 и backup към 192.0.2.26. След това натиснете Проверка.

Допълнително четене

Стъпките в тези статии важат за контролните панели на WebOké; в други панели работи по подобен начин.

• Ръководство за DirectAdmin 5.5: MX records: къде пристига Вашата електронна поща?
• Вашият имейл другаде: Microsoft 365, Google Workspace или собствен пощенски сървър
• Изпращането на имейл през PHP не работи, MX записите сочат другаде
• Ръководство за DirectAdmin 18.9: Вече не получавам имейли
• RFC 5321 параграф 5.1 (маршрутизация на имейли), RFC 7505 (null MX)