Свързване на Microsoft 365

Модул 7: Свързване на външни услуги · Време за четене: 9 минути

Цел на урока: След този урок ще можете да поставите DNS записите за Microsoft 365 и да проверите дали са правилни.

Основни понятия: верификационен TXT (MS=ms...), MX към Microsoft, SPF include, DKIM CNAME (selector1 и selector2), autodiscover, административен център

Защо Microsoft 365 се нуждае от записи

С Microsoft 365 Вашата имейл поща пристига при Microsoft. Уебсайтът Ви може спокойно да остане при Вашия собствен уеб хостинг. За това разделяне Microsoft се нуждае от няколко неща от Вашия DNS:

1. доказателство, че домейнът е Ваш (верификация);
2. мястото, където пристига пощата (MX);
3. разрешение да се изпраща поща от името на Вашия домейн (SPF);
4. подпис под Вашата поща (DKIM);
5. запис, с който Outlook сам намира настройките (autodiscover).

Тези записи поставяте при доставчика, който управлява DNS на Вашия домейн. Не знаете кой е той? Погледнете DNS сървърите (nameservers) на Вашия домейн (урок 2.1). Ако промените на друго място, нищо няма да се случи.

Най-важното правило в този урок: винаги следвайте точно това, което административният център на Microsoft показва за Вашия домейн. Примерите по-долу показват как изглеждат записите. Точните стойности се различават за всеки домейн и абонамент, а Microsoft понякога променя формата.

Стъпка 1: верификация на домейна

Когато добавяте домейн в административния център на Microsoft 365, получавате TXT запис с код:

example.com.   3600   IN   TXT   "MS=ms12345678"

Поставете този запис на основния домейн (@). След това натиснете в административния център бутона за верификация. Ако не стане веднага, изчакайте четвърт час и опитайте отново: понякога резолверът все още има старото копие в кеша (урок 6.1). Този TXT запис може да стои редом с други TXT записи, включително с Вашия SPF запис (урок 4.2).

Стъпка 2: MX към Microsoft

MX записът сочи към пощенски сървър, свързан с Вашия домейн. Дълго време това беше домейнът с тирета вместо точки, последван от mail.protection.outlook.com:

example.com.   3600   IN   MX   0 example-com.mail.protection.outlook.com.

По-новите абонаменти понякога получавате адрес, завършващ на mx.microsoft, например нещо като example-com.x-v1.mx.microsoft. Това не е печатна грешка: .microsoft е истински домейн от първо ниво (TLD). Кой от двата варианта ще получите, виждате в административния център. Копирайте го точно, с точка накрая, ако Вашият панел изисква това (урок 2.2).

Тук често се допускат две грешки:

• Оставяне на стари MX записи. Премахнете MX записите към предишния Ви пощенски сървър. Ако останат, част от пощата Ви ще продължи да пристига на старото място, дори и при по-висок приоритет (урок 4.1).
• Локално доставяне при Вашия уеб хостинг. Много хостинг панели доставят поща от Вашия собствен уебсайт (формуляр за контакт, онлайн магазин) директно в пощенската кутия на същия сървър, ако той смята, че Вашата поща живее там. В DirectAdmin тази настройка се нарича „Use this server to handle my email“. Когато насочите MX към Microsoft, изключете това локално доставяне. Иначе формулярите никога няма да достигнат до Microsoft. В други панели това се нарича например „Remote mail exchanger“ или „Disable local mail“.

Стъпка 3: допълване на SPF, не дублиране

Microsoft иска в SPF записа Ви да стои:

include:spf.protection.outlook.com

Вече имате SPF запис? Тогава не създавайте втори, а добавете include в съществуващия запис. Два SPF записа правят SPF невалиден (урок 4.3). Ако уебсайтът Ви изпраща поща чрез сървъра на Вашия уеб хостинг, оставете и него в записа:

example.com.   3600   IN   TXT   "v=spf1 a mx include:spf.hosting.example include:spf.protection.outlook.com ~all"

Внимавайте за ограничението от десет DNS заявки: всеки include се брои, а и include-ите на Microsoft сами по себе си добавят заявки.

Стъпка 4: DKIM с два CNAME записа

Microsoft подписва пощата Ви с ключ, който се намира при Microsoft. Вие само създавате две препратки, като CNAME:

selector1._domainkey.example.com.   3600   IN   CNAME   selector1-example-com._domainkey.example.x-v1.dkim.mail.microsoft.
selector2._domainkey.example.com.   3600   IN   CNAME   selector2-example-com._domainkey.example.x-v1.dkim.mail.microsoft.

От май 2025 г. новите домейни получават този формат, завършващ на dkim.mail.microsoft. Буквата пред -v1 (тук x) се различава според абонамента. По-старите домейни често все още имат формата, завършващ на onmicrosoft.com, например selector1-example-com._domainkey.example.onmicrosoft.com. И двата варианта работят. И тук важи: копирайте стойностите от административния център (в настройките за DKIM в портала Defender) и не ги измисляйте сами.

Защо два? Microsoft от време на време сменя ключовете (ротация на ключове). Ако в DNS Ви стои само selector1, DKIM ще работи до първата смяна и след това внезапно ще спре. Затова винаги създавайте и двата.

Щом CNAME записите станат видими, включете DKIM в административния център. Често срещана грешка е да създадете TXT запис там, където се изисква CNAME; тогава Microsoft съобщава, че CNAME липсва.

Обърнете внимание на името: във Вашия панел обикновено въвеждате само selector1._domainkey. Ако въведете цялото име, а панелът Ви сам добави домейна отзад, ще получите selector1._domainkey.example.com.example.com (урок 8.4).

Стъпка 5: autodiscover

При настройване на акаунт Outlook търси autodiscover.<Вашия домейн>. Насочете това име към Microsoft:

autodiscover.example.com.   3600   IN   CNAME   autodiscover.outlook.com.

Вече имате A запис или wildcard запис, който насочва autodiscover към Вашия уеб сървър? CNAME запис със същото име не може да стои редом с друг запис: първо премахнете A записа за autodiscover. Срещу wildcard (*) не е необходимо да правите нищо: отделно зададено име има предимство (урок 3.3).

А DMARC?

Microsoft не го изисква при настройването, но без DMARC пощата по-често попада в спам. Ако вече имате DMARC запис, той може да остане. Уверете се обаче, че SPF и DKIM за Microsoft са правилно настроени, преди да зададете политиката на quarantine или reject (урок 4.5).

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

В примерния панел Моят WebOké на раздела DNS на даден домейн има карта Настройки за имейл с Бързо настройване. Ако там изберете Microsoft 365, предварително виждате кои записи ще бъдат създадени: MX, допълнение към SPF и autodiscover, а локалното доставяне се изключва. Верификационния TXT и DKIM CNAME записите получавате от самия Microsoft; тях добавяте отделно с Add Record. В DirectAdmin правите същото чрез MX Records (шаблон Microsoft 365, и отметката за изключване на доставянето) и DNS Administration.

Използвате друг панел, например cPanel, Plesk, Cloudflare или DNS екрана на Вашия регистратор? Там бутоните се наричат различно, но полетата са същите: име, тип, стойност и TTL. Някои регистратори имат и бутон „Microsoft 365“, който поставя записите наведнъж.

Обобщение

• Копирайте всички стойности от административния център на Microsoft 365, не от пример.
• Верификация: TXT MS=ms... на @. MX: адресът, който Microsoft дава за Вашия домейн; премахнете старите MX записи.
• SPF: добавете include:spf.protection.outlook.com към съществуващия запис, не създавайте втори.
• DKIM: два CNAME записа, selector1 и selector2, и двата необходими заради ротацията на ключовете.
• Autodiscover: CNAME към autodiscover.outlook.com, и изключете локалното доставяне при Вашия уеб хостинг.

Тест

Задача

Задача Z7.1: разпознаване на Microsoft 365. Разгледайте как две реални организации използват Microsoft 365: microsoft.com и sidn.nl (сайтът на SIDN, регистъра на .nl в Нидерландия).

1. Намерете MX записа на sidn.nl и на microsoft.com. Кой от двата използва стария формат (mail.protection.outlook.com) и кой новия (mx.microsoft)?
2. Намерете в SPF записа на sidn.nl include-а на Microsoft и го препишете.
3. Намерете CNAME записа на selector1._domainkey.sidn.nl. На коя дума завършва целевото име (последните два компонента)?

Въведете отговорите си в полето за попълване. Проверката изисква записите на момента на предаване на живо, така че ако организацията промени нещо, важи новият отговор.

Задача O7.1: самостоятелна настройка във Вашата тренировъчна зона. Свържете тренировъчната си зона <code>.dnspractice.eu със симулиран Microsoft 365. В тренировъчната зона използвате фалшивата услуга office-demo.dnspractice.eu; при реалния си домейн копирате стойностите от административния център на Microsoft 365.

1. Верификация: поставете TXT запис на <code>.dnspractice.eu с кода, който страницата на задачата Ви дава (MS=oefen-<код>-<...>).
2. MX: оставете <code>.dnspractice.eu да получава поща на mail.protection.office-demo.dnspractice.eu. с приоритет 0. Премахнете другите MX записи на <code>.dnspractice.eu.
3. SPF: допълнете съществуващия SPF запис на <code>.dnspractice.eu с include:_spf.office-demo.dnspractice.eu, и оставете mx в него. Може да има само един SPF запис.
4. DKIM: създайте CNAME selector1._domainkey.<code>.dnspractice.eu към selector1.dkim.office-demo.dnspractice.eu. и CNAME selector2._domainkey.<code>.dnspractice.eu към selector2.dkim.office-demo.dnspractice.eu.
5. Autodiscover: създайте CNAME autodiscover.<code>.dnspractice.eu към autodiscover.office-demo.dnspractice.eu.

За допълнително четене

Тези страници описват стъпките в панелите на WebOké (DirectAdmin и Моят WebOké). В други панели процесът е аналогичен.

• Ръководство за DirectAdmin 5.10: E-mail при Microsoft 365 или Google Workspace, уебсайт при WebOké
• Ръководство на WebOké 5.6: Бързо настройване на имейл в DNS
• Вашият имейл другаде: Microsoft 365, Google Workspace или собствен пощенски сървър
• Изпращането на имейл през PHP не работи, MX записите сочат другаде
• Ръководство за DirectAdmin 5.7: Настройка и допълване на SPF