Решението: запазвате кутията, сменяте MX
Смяната на пощенската система и смяната на защитата са два различни проекта. Първият премества кутиите, историята, календарите и акаунтите на телефоните. Вторият засяга само пътя на входящата поща.
Този път се определя от един DNS запис: MX, който казва на изпращащите сървъри къде да доставят пощата за вашия домейн. Когато той сочи към шлюза, шлюзът получава, анализира и предава съобщението на сървъра с пощенските кутии. Това важи за:
- Microsoft 365 (Exchange Online);
- Google Workspace;
- Exchange, инсталиран при вас или хостван;
- всеки друг пощенски сървър, който получава по SMTP;
- Klytic Mail, който е само един от случаите, а не предварително условие.
Това ръководство разглежда случая, в който кутията се запазва. Ако сменяте и сървъра, ръководствата Миграция от Microsoft 365 и Миграция от Google Workspace описват този проект.
Кой какво променя
| Настройка | Къде | Кой |
|---|
| MX запис на домейна | DNS зона, при регистратора или DNS хостинг доставчика | Човекът, който управлява DNS, или доставчикът, на когото е делегирано |
| Деклариране на шлюза в пощенската система | Административна конзола на Microsoft 365, Google Workspace или сървъра | Администраторът на пощенската система |
| SPF, DKIM и DMARC | DNS зона | Отговорникът за DNS, след опис на сървърите, които изпращат от името на домейна |
| Домейни и сървър за доставка | Шлюз | Доставчикът на шлюза, който подготвя конфигурацията |
Принципът при Microsoft 365
Документацията на Microsoft за филтриране чрез услуга на трета страна е ясна: MX записът на домейна трябва да сочи към тази услуга, която след това доставя към Exchange Online. Microsoft препоръчва входящ конектор от тип „партньор“, който може да отказва пощата, пристигнала без да мине през услугата. Препоръчва също да се включи подобреното филтриране за конектори (Enhanced Filtering), така че собственият му анализ да оценява истинския подател, а не адреса на шлюза. Microsoft не препоръчва просто да се заобикаля неговото филтриране за адресите на услугата на трета страна.
Принципът при Google Workspace
Google описва „входящ пощенски шлюз“ (inbound mail gateway): MX сочи към шлюза, след което администраторът декларира неговите IP адреси в конзолата. Gmail ги използва, за да намери в заглавните редове истинския адрес на подателя, от който зависят SPF и оценката му за спам. Може също да се отказва пощата, която не идва от шлюза. Google уточнява, че не прилага DMARC политиката на подателя към пощата, получена чрез деклариран шлюз: тогава тази проверка е задача на шлюза.
Това ръководство не копира екраните на тези конзоли, които се променят. При настройката следвайте официалната страница, посочена в края.
Няколко сървъра зад един шлюз
Чест случай в група дружества: дружеството майка е в Microsoft 365, едно дъщерно дружество в Google Workspace, трето на по-стар собствен сървър. Един шлюз може да стои пред трите.
Принципът е маршрутизиране по домейн. MX записът на всеки домейн сочи към шлюза. За всеки домейн шлюзът знае на кой сървър да предаде пощата след анализа. Анализът е общ, местоназначението е различно.
Предимство: една и съща политика за филтриране или различни настройки според домейна, и преглед на всички решения на едно място. Какво да подготвите: домейн, чиито кутии са разпределени между два сървъра, изисква да се знае, адрес по адрес, къде да се доставя. Този случай се проучва преди превключването.
Какво се променя и какво не
Не се променят: адресите, кутиите, историята, пощенският клиент, уеб пощата, телефоните. Вграденият филтър на пощенската система продължава да работи. Правата и вътрешните споделяния остават тези на платформата.
Променя се:
- Първият сървър, който получава пощата. Той вижда изходната връзка и проверява автентичността на подателя.
- Сървърът с кутиите вече не вижда подателя пряко, а шлюза. Оттук и декларирането, описано по-горе.
- Съобщенията носят заглавните редове с решението на шлюза: администраторът може да прочете в тях защо съобщението е доставено или отделено.
- Ако шлюзът препредава и изходящата поща, SPF записът на домейна трябва да го разрешава, а DKIM подписът трябва да бъде публикуван за него. Смисълът на тези механизми е обяснен в SPF, DKIM и DMARC: какво защитават и какво не.
В деня, в който смените и сървъра с кутиите, шлюзът може да остане: променя се само неговият сървър за доставка. Ръководството Миграция на електронната поща без прекъсване остава отправната точка за този ден, включително за SPF, DKIM и DMARC.
Въвеждането, по ред
- Опис: домейни, сървърът с кутиите на всеки от тях, приложения, които изпращат поща от името на домейна.
- Подготовка на шлюза от неговия доставчик: приети домейни, сървър за доставка, правила за изходящата поща.
- Деклариране на шлюза в пощенската система (входящ конектор или входящ шлюз), ако платформата го предвижда.
- Предварително намаляване на TTL на MX, след това промяна на MX. Докато трае DNS кешът, част от подателите все още доставят пряко на сървъра с кутиите: това е нормално.
- Проверка: съобщение, изпратено от външен адрес, трябва да пристигне със заглавните редове с решението на шлюза.
- Наблюдение на карантината през първите дни, за да се освобождават фалшивите сигнали и да се настройват правилата.
Връщането назад е просто: възстановява се старият MX. То се подготвя както при миграция, с човек, който има право да вземе решението.
Какво шлюзът не прави
Той вижда пощата, която минава през него, и само нея. Не вижда съобщенията, разменени между две кутии на една и съща платформа, които не излизат от нея, нито файловете, споделени в онлайн хранилище, нито влизанията на потребителите.
Затова той не замества вътрешните настройки на Microsoft 365 или Google Workspace: права, двуфакторна автентикация, известия за влизане, правила за автоматично препращане. Откраднатият акаунт остава преди всичко въпрос на пощенската система. Ръководството Спам, фишинг, зловреден софтуер и компрометиран акаунт разграничава нещата.
Накрая, подател, който знае техническия адрес на сървъра с кутиите, може да опита да доставя пряко до него, без да минава през MX. Това е причината за заключването, предлагано от Microsoft (партньорски конектор) и от Google (отказ на пощата извън шлюза).
Често задавани въпроси
Трябва ли да предупредим потребителите?
Адресите им не се променят. Предупредете ги обаче, че може да получават известия за карантина: вижте Карантина, фалшиви сигнали и докладване.
Трябва ли да изключим филтъра на Microsoft 365 или на Google?
Не. Microsoft препоръчва анализът му да остане включен и да се настрои така, че да вижда истинския подател, вместо да се заобикаля.
Колко време отнема превключването?
Самата смяна на MX влиза в сила с темпото на DNS кеша. Подготовката зависи от броя на домейните и сървърите. За Klytic MTA вижте следващия раздел.
Променя ли шлюзът, поставен отпред, доставимостта на нашата изходяща поща?
Само ако препредава и изходящата поща. В този случай SPF и DKIM трябва да го отчитат: вижте SPF, DKIM и DMARC: какво защитават и какво не.
Защо просто да не сменим пощенската система?
Това е друго решение, с други критерии. То е разгледано в Избор на европейска корпоративна електронна поща.
Къде е Klytic
Klytic MTA се поставя пред пощенската система, която имате: Microsoft 365, Google Workspace, Exchange, Klytic Mail или всеки друг сървър. Не изисква кутия в Klytic.
- Пускане в действие: обикновено от 24 до 48 часа. Klytic подготвя конфигурацията; вие променяте MX записа на домейна си или Klytic го прави вместо вас. Декларирането на шлюза в конзолата на Microsoft 365 или Google Workspace се извършва от администратора на тази пощенска система и се подготвя заедно с Klytic при пускането в действие.
- Внедряване: облакът на Klytic, отделна инстанция или сървърите на клиента. За специфични нужди с Klytic могат да се проектират и други архитектури, например филтриране в облака и реле, инсталирано при вас, или няколко региона.
- Планове: Essential и Advanced. Essential покрива автентичността, антиспама, антивируса, фишинга, домейните двойници, карантината, DKIM подписа на изходящата поща и отзоваването преди изпращане. Advanced добавя финансовите измами, защитата при щракване, DMARC конзолата и експорта на журналите към SIEM.
- Пробен период: 30 дни безплатно, без смяна на пощенската система.
Klytic MTA не управлява правата и акаунтите на сегашната ви пощенска система и не обещава равностойност с вградените инструменти за сигурност на Microsoft 365 или Google Workspace: той се добавя пред тях.
Тази страница описва принцип. Конзолите на Microsoft и Google се променят: за конкретните действия меродавна е тяхната официална документация.
Източници
Консултирани през октомври 2026 г.
- Microsoft Learn, „Manage mail flow using a third-party cloud service with Exchange Online“: MX трябва да сочи към услугата на трета страна; входящ конектор от тип партньор; подобрено филтриране за конектори вместо заобикаляне на филтрирането. learn.microsoft.com
- Помощ за Google Workspace, „Set up an inbound mail gateway“: MX към шлюза, деклариране на неговите IP адреси, възможен отказ на пощата извън шлюза; Gmail не прилага DMARC политиката на подателя към пощата, получена чрез шлюза. knowledge.workspace.google.com
- RFC 5321, SMTP: междинните хостове обикновено се посочват чрез MX записа в DNS. rfc-editor.org
- Klytic, страница Klytic MTA: модули на плановете Essential и Advanced, опции, начини на внедряване, пускане в действие чрез MX. klytic.com
