Письма не приходят, отправка работает: чек-лист после переезда NS на Cloudflare демо-пример

Диагностика по вашему ТЗ: Google Workspace подключён, домен у регистратора IONOS, NS указывают на Cloudflare, а в вашем Cloudflare домена нет. Это универсальный чек-лист: домен в ТЗ не назван, поэтому записей вашего домена здесь нет и ничего о них не утверждается.

1. Почему так бывает

Входящую почту направляют MX-записи в той DNS-зоне, на которую домен указывает через NS. Исходящая почта от них не зависит: Google отправляет письма со своих серверов, а получатели проверяют SPF и DKIM. Поэтому, если NS перенесли на Cloudflare, а в зоне Cloudflare нет MX-записей Google (или зона создана не до конца), отправка продолжает работать, а входящие пропадают. Это типичная картина, но подтвердить её для вашего домена можно только проверкой по шагам ниже.

2. Где управляется DNS: проверка за 2 минуты

Откройте любой whois/DNS-сервис (например, who.is или dnschecker.org), введите домен и посмотрите поле Name Servers.
Если NS вида xxxx.ns.cloudflare.com, DNS ведёт Cloudflare. Зона лежит в чьём-то аккаунте Cloudflare: у веб-мастера, прошлого подрядчика или того, кто подключал сайт. В вашем аккаунте её нет, и это нормально.
Регистратор (IONOS) отвечает только за то, какие NS прописаны у домена. Войти в панель IONOS можно как владелец домена, там видно, какие NS стоят.

Два рабочих пути восстановления доступа:

А. Найти владельца зоны Cloudflare (кто делал сайт или переносил домен) и получить у него доступ к DNS либо попросить добавить записи из раздела 4.
Б. Создать зону в вашем аккаунте Cloudflare (бесплатный тариф), перенести туда все нужные записи и в IONOS сменить NS на пару, которую выдаст Cloudflare. Либо вернуть в IONOS его собственные NS и вести DNS там.

Важно для сайта: перед любой сменой NS скопируйте все существующие записи (A, AAAA, CNAME, TXT) из текущей зоны, тогда сайт не отвалится. Если доступа к старой зоне нет, список записей можно снять командами из раздела 5 и сверить с хостингом (Hosting.ua).

3. Чек-лист: что проверить и что должно быть

Что	Как должно быть	Типичный сбой
MX	Записи Google Workspace (раздел 4), без чужих MX рядом	MX нет вовсе, либо остались старые MX хостинга или Cloudflare Email Routing: почта уходит не в Google
SPF (TXT на корне)	Одна запись, содержит `include:_spf.google.com`	Две SPF-записи (по стандарту допустима одна) или Google не включён
DKIM	TXT `google._domainkey` с ключом из консоли администратора Google	Ключ не перенесён в новую зону
DMARC	TXT `_dmarc`, для начала `p=none`	Запись потеряна при переезде
Proxy в Cloudflare	Записи для почты (например, `mail`) только DNS only, серое облако. У MX proxy не бывает	Оранжевое облако на хосте, который используется для почты
Статус зоны в Cloudflare	Active	Pending: Cloudflare не отвечает за зону, записи не действуют
Подтверждение домена в Google	В консоли администратора Google домен подтверждён	Подтверждающая TXT-запись потеряна при переезде

4. Готовый набор записей для Cloudflare (режим DNS only)

Вместо example.com подставляется ваш домен. Имя «@» означает корень домена.

Вариант 1, актуальный для Google Workspace: одна запись MX

Тип	Имя	Значение	Приоритет
MX	@	smtp.google.com	1

Вариант 2, классический набор из пяти MX (тоже рабочий)

Тип	Имя	Значение	Приоритет
MX	@	ASPMX.L.GOOGLE.COM	1
MX	@	ALT1.ASPMX.L.GOOGLE.COM	5
MX	@	ALT2.ASPMX.L.GOOGLE.COM	5
MX	@	ALT3.ASPMX.L.GOOGLE.COM	10
MX	@	ALT4.ASPMX.L.GOOGLE.COM	10

Используется один из вариантов, не оба сразу. Все остальные MX на корне домена удаляются.

Остальные записи

Тип	Имя	Значение
TXT (SPF)	@	`v=spf1 include:_spf.google.com ~all` (если есть другие легальные отправители, например сервис рассылок, они добавляются в эту же запись)
TXT (DKIM)	google._domainkey	длинный ключ `v=DKIM1; k=rsa; p=...`: берётся в консоли администратора Google (Приложения, Google Workspace, Gmail, Аутентификация электронной почты), после добавления нажать «Начать аутентификацию»
TXT (DMARC)	_dmarc	`v=DMARC1; p=none; rua=mailto:адрес-для-отчётов@example.com`
TXT (проверка домена)	@	строка `google-site-verification=...`, если она была в старой зоне (значение видно в консоли Google)

Значения DKIM и проверочной строки для вашего домена видны только в вашей консоли администратора Google, поэтому здесь стоят шаблоны.

5. Как проверить, что всё сработало

# кто ведёт DNS (NS)
nslookup -type=NS example.com
# куда сейчас идёт входящая почта
nslookup -type=MX example.com
# SPF, DMARC, DKIM
nslookup -type=TXT example.com
nslookup -type=TXT _dmarc.example.com
nslookup -type=TXT google._domainkey.example.com
# то же через публичный DNS, в обход кэша провайдера
nslookup -type=MX example.com 1.1.1.1

В выдаче MX должны быть только адреса Google из раздела 4.
Инструмент Google Admin Toolbox Check MX (toolbox.googleapps.com/apps/checkmx) показывает, правильно ли настроены MX для Gmail.
Отправьте тестовое письмо с постороннего адреса (не с домена компании) и убедитесь, что оно дошло. Отдельно отправьте письмо с корпоративного ящика наружу и проверьте в заголовках spf=pass и dkim=pass.
Откройте сайт: записи A/CNAME не менялись, значит, он должен работать как раньше.

Срок вступления изменений зависит от TTL записей: обычно от минут до нескольких часов, смена NS целиком может занять до суток. Серверы отправителей обычно повторяют доставку несколько суток, но часть отправителей может вернуть отказ, поэтому о важных письмах за период сбоя лучше попросить повторить.

6. Порядок работы по вашему заказу

Проверяю NS, MX, SPF, DKIM и DMARC вашего домена, фиксирую найденные проблемы.
Определяю, где ведётся DNS, и помогаю получить доступ или перенести зону (путь А или Б из раздела 2).
Вношу записи из раздела 4, сохраняя записи сайта.
Проверяю получение и отправку письма, присылаю короткий итог: что стояло и что стало.

Это демонстрационный пример на языке вашего ТЗ. Данные вашего домена в нём не использовались.