24 августа 2026 года Apple подтвердила, что новые адреса Sign in with Apple позднее начнут использовать домен private.icloud.com; точная дата полного включения пока не объявлена в официальном обновлении. Поэтому не заменяйте privaterelay.appleid.com напрямую. В эту неделю добавьте оба домена в серверные правила, почтовые проверки и белые списки. Если изменение только серверное, новый релиз обычно не нужен. Если домен зашит в клиенте, исправьте код, соберите приложение в Xcode и проведите регрессию через TestFlight. Официальное обновление Apple от 24 августа 2026 года — исходная точка для этой проверки.

Эта статья для вас, если вы поддерживаете приложение или сайт с Sign in with Apple и проверяете домен пользовательского email в базе или API. Она также пригодится, если через Private Email Relay проходят коды подтверждения, заказы, подписки или обращения в поддержку. Небольшим командам здесь важно отделить серверную миграцию от клиентской и не запускать публикацию только из-за изменения адресного домена.

01

Что именно меняется и почему нельзя делать замену одним коммитом

Apple подтвердила две разные вещи:

  • новые адреса промежуточной почты позднее будут создаваться с доменом private.icloud.com;
  • уже существующие адреса privaterelay.appleid.com продолжат пересылать сообщения.

Полной даты перехода Apple пока не указала. Поэтому план с формулировкой «после такой-то даты удаляем старый домен» технически и операционно неверен. Состояние будет смешанным: один пользователь может иметь старый адрес, а новый пользователь — адрес с новым доменом.

Здесь легко перепутать пять сущностей:

  1. стабильный идентификатор пользователя из токена Apple;
  2. адрес, который вернулся при авторизации;
  3. домен адреса-посредника;
  4. зарегистрированный источник отправки писем;
  5. окружение, из которого вы собираете и публикуете приложение.

Это не взаимозаменяемые настройки. Изменение домена получателя не означает автоматического изменения SPF или DKIM. Оно также не означает, что нужно менять Bundle ID, Team ID или ключи подписи.

В документации по проверке токена пользователя Sign in with Apple Apple описывает проверку утверждений токена. Для связывания аккаунта используйте подтверждённый стабильный идентификатор, а не строку email. Иначе смена формата промежуточного адреса может создать дубль профиля или разорвать восстановление доступа.

Матрица ответственности до начала работ

Владелец Что проверяет Ошибка при пропуске
Сервер и база данных sub, доменные правила, регистрацию, вход, восстановление дубли аккаунтов или отказ авторизации
Почтовая система адрес отправителя, SPF, DKIM, пересылку и обработку недоставленных сообщений коды и уведомления не доходят
iOS, macOS и веб-клиент локальные регулярные выражения, классификацию адреса, объединение профилей клиент отклоняет корректный ответ сервера
Релиз и поддержка Xcode, TestFlight, логи, откат и инструкции для операторов неполная миграция без безопасного возврата

Таблица не заменяет тестирование. Она нужна, чтобы задача не осталась у одного backend-разработчика, хотя фактический сбой может находиться в мобильном клиенте или системе доставки.

02

Серверный владелец: сначала исправьте идентичность, затем доменные правила

Начните с поиска по репозиториям и конфигурации. Ищите не только строку privaterelay.appleid.com, но и более скрытые варианты:

  • регулярные выражения email;
  • список разрешённых доменов;
  • ограничения в схеме базы данных;
  • антифрод-правила;
  • обработчики импорта и объединения;
  • сценарии восстановления аккаунта;
  • административный поиск пользователей;
  • фильтры подавленных адресов.

Вместо проверки «адрес обязан заканчиваться старым доменом» задайте явное правило: принимаются оба домена, а обычные адреса обрабатываются по прежней логике. Не делайте проверку слишком широкой вроде «разрешить любой домен iCloud». Это ослабит контроль и смешает промежуточный адрес с обычным почтовым ящиком.

Вторая проверка касается ключа аккаунта. В таблице пользователя email должен быть контактным атрибутом. Связь с учётной записью Sign in with Apple должна строиться по стабильному идентификатору Apple и вашему контексту приложения. Подробности самого процесса авторизации приведены в официальном описании Sign in with Apple.

Проведите четыре сценария на обезличенных данных:

  • новый вход с адресом private.icloud.com;
  • повторный вход существующего пользователя с privaterelay.appleid.com;
  • попытка входа с тем же стабильным идентификатором, но обновлённым email;
  • восстановление профиля и изменение контактных данных.

Ожидаемый результат: один пользователь остаётся одним пользователем, независимо от домена. Если ваша система сейчас использует email как первичный ключ, сначала добавьте безопасную таблицу связей и процедуру разрешения конфликтов. Простая SQL-замена домена здесь опаснее, чем временная поддержка двух значений.

Важно: не переносите адрес получателя в настройки отправителя. private.icloud.com и privaterelay.appleid.com описывают адреса-посредники, а не автоматически разрешённые домены, с которых ваше приложение имеет право отправлять почту.

03

Почтовый владелец: проверяйте доставку, а не только формат строки

Private Email Relay — это промежуточная доставка. Поэтому валидный адрес в базе ещё не означает, что письмо попадёт пользователю. Проверьте четыре класса сообщений:

  • код входа и подтверждения;
  • чек, уведомление о заказе и системные письма;
  • сообщения о подписке;
  • ответы поддержки и письма о восстановлении доступа.

Сначала подтвердите, какие адреса отправителя зарегистрированы для Private Email Relay. Затем проверьте SPF и DKIM именно для этих источников. Официальные параметры регистрации и работы отправки собраны в инструкции Apple по настройке Private Email Relay. Отдельное описание работы сервиса пересылки помогает отделить проблему промежуточного адреса от проблемы вашей почтовой платформы.

Не меняйте SPF или DKIM только потому, что появился новый домен получателя. Сначала установите точку отказа:

  1. письмо не сформировано вашим приложением;
  2. письмо отклонено или заблокировано почтовым источником;
  3. письмо принято промежуточным сервисом, но не переслано;
  4. пересылка выполнена, но конечный ящик или локальный фильтр поместил письмо в спам.

Для каждого теста сохраните время события, обезличенный внутренний ID, код SMTP-ошибки, тип недоставки и результат пересылки. Реальные адреса, содержимое сообщений, токены и персональные данные в журнал не записывайте. Это особенно важно для команды, которая временно включает подробное логирование во время миграции.

Слабое место часто находится в списке подавления. Старый адрес мог попасть туда после временной ошибки, а новый адрес будет считаться отдельным значением. Не удаляйте старые записи автоматически. Проверьте, как система подавления соотносит адрес, стабильный ID пользователя и тип отказа.

04

Клиентские команды: найдите места, где домен стал бизнес-логикой

Если приложение лишь отправляет результат авторизации на сервер, а все правила находятся в API, изменение можно выпустить без нового клиента. Сначала разверните серверную поддержку двух доменов и выполните регрессию.

Новый билд нужен в трёх случаях:

  • iOS или macOS-код отклоняет адрес по локальному регулярному выражению;
  • интерфейс определяет тип аккаунта по домену;
  • локальное объединение или восстановление профиля использует email вместо серверного идентификатора.

Проверьте не только основной экран входа. Поиск по проекту должен включать формы профиля, экран поддержки, локальное хранилище, deep link-обработчики, импорт данных и аналитические события. Проверьте также веб-версию и внутреннюю панель: разные команды часто используют разные валидаторы.

Для настройки возможности Sign in with Apple в проекте сверяйтесь с документацией Apple по конфигурации Xcode. Если вход выполняется через сайт, отдельно проверьте настройки веб-страницы Sign in with Apple. Эти настройки не следует смешивать с доменным списком email: capability и адресная валидация находятся на разных уровнях.

05

Первый этап: проведите аудит до изменения кода

Создайте короткую карту потока:

авторизация Apple → проверка токена → поиск аккаунта → сохранение email → отправка письма → доставка → публикация клиента.

Для каждого перехода укажите владельца, окружение, журнал события и переключатель отката. Затем выполните поиск старого домена во всех репозиториях, Terraform или аналогичных конфигурациях, секретах, миграциях базы данных, шаблонах писем и тестовых фикстурах.

Отдельно зафиксируйте, где находится источник истины. Если белый список продублирован в мобильном приложении, API, панели поддержки и скрипте импорта, у вас уже есть риск рассинхронизации. Предпочтительно оставить критическое решение на сервере, а клиенту возвращать нормализованный результат.

06

Второй этап: добавьте совместимость без массового обновления базы

Не переписывайте старые адреса. Добавьте private.icloud.com в допустимый список и оставьте privaterelay.appleid.com. Проверьте регистр, пробелы, IDN-обработку и формат адреса до доменной проверки. Но не пытайтесь «исправить» адрес преобразованием домена: приложение не должно угадывать, какой адрес Apple считает актуальным.

Для уже существующих профилей сохраните исходное значение email. Если необходимо добавить новый адрес, делайте это через отдельную операцию с журналом изменений и возможностью отката. Слияние выполняйте по стабильной связи с Apple, а не по совпадению строки.

07

Третий этап: проверьте три платформы и четыре независимых результата

Минимальный прогон должен включать iOS, macOS или веб-клиент, если они используют общий аккаунт. Успешная авторизация — только первый результат. Зафиксируйте отдельно:

  • Apple разрешила вход;
  • сервер правильно связал аккаунт;
  • письмо дошло через промежуточный адрес;
  • сборка и публикация прошли ожидаемый путь.

Нельзя считать тест успешным, если экран входа открылся, но код подтверждения не пришёл. Нельзя считать релиз готовым, если TestFlight установил приложение, но старый пользователь получил новый профиль.

08

FAQ: решения для спорных случаев

Блок вопросов и ответов выше покрывает пять практических поисковых намерений: правила для private.icloud.com, сохранение старого privaterelay.appleid.com, необходимость нового релиза, тестирование входа и доставки, а также использование email как идентификатора. Внутри команды удобно превратить эти ответы в критерии приёмки, а не оставлять их только в документации.

09

Четвёртый этап: решите вопрос с релизом по фактам

Используйте это условие:

  • если меняется только backend, конфигурация или удалённый список — выпускайте серверное изменение и не отправляйте приложение без причины;
  • если домен присутствует в клиентской логике — исправляйте код, собирайте Xcode-архив и проверяйте TestFlight;
  • если клиентская и серверная версии обновляются вместе — включите совместимый порядок развёртывания и быстрый откат.

Для команды без локального Mac временная аренда Mac для сборки iOS может закрыть именно этап Xcode и TestFlight. Если окружение требуется регулярно, сначала сравните цены аренды Mac mini с покупкой собственного компьютера. Это решение относится к сборочной инфраструктуре, а не к самой миграции домена.

10

Пятый этап: выполните двухконтурную приёмку и подготовьте откат

Перед включением нового правила отметьте каждый пункт:

  • [ ] private.icloud.com добавлен в серверные проверки регистрации и входа.
  • [ ] privaterelay.appleid.com сохранён для существующих аккаунтов.
  • [ ] Регулярные выражения, база данных и антифрод используют совместимую логику.
  • [ ] Стабильный идентификатор Apple не заменён email-адресом.
  • [ ] Новый адрес прошёл вход, повторную авторизацию и восстановление.
  • [ ] Старый адрес прошёл тот же набор сценариев.
  • [ ] Обычный реальный email не ошибочно классифицируется как промежуточный.
  • [ ] Код подтверждения и уведомление о подписке дошли по обоим тестовым адресам.
  • [ ] SPF, DKIM и зарегистрированный источник отправки проверены отдельно от домена получателя.
  • [ ] Данные логов обезличены: удалены email, токены, Bundle ID, Team ID и локальные пути.
  • [ ] Есть переключатель возврата к прежней проверке без удаления данных.
  • [ ] При необходимости новый клиент собран в Xcode и установлен через TestFlight.
  • [ ] Проверены вход, создание аккаунта, почта и публикация как независимые статусы.

Для запуска используйте новую тестовую запись, старую обезличенную запись и обычный адрес. Не ограничивайтесь одним устройством. Прогоните повторный вход после очистки локального состояния и проверьте, что сервер не создаёт профиль заново.

11

Сценарий из практики: где обычно находится настоящий сбой

Представьте небольшую команду, у которой сервер уже принимает оба домена, но приложение показывает ошибку «некорректный email». Причина часто не в Apple и не в почтовой системе: старый локальный валидатор остался в форме профиля. После его удаления вход проходит, но письмо с кодом всё равно может не дойти, если адрес отправителя не зарегистрирован для Private Email Relay или список подавления содержит старую запись.

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

У такого подхода есть преимущества:

  • он сохраняет пользователей со старыми адресами;
  • позволяет выпустить серверное исправление без лишнего релиза;
  • разделяет проблему идентичности и проблему доставки;
  • оставляет понятный путь отката.

Есть и ограничения:

  • нужно поддерживать два домена неопределённый период;
  • потребуется больше тестовых фикстур и логики поддержки;
  • частичная миграция может выявить старые дубли;
  • TestFlight не проверяет саму серверную доставку без отдельного почтового сценария.
12

Последняя проверка перед публикацией

На 30 августа 2026 года ориентируйтесь на подтверждённое поведение Apple, а не на слухи о конкретном дне переключения. Последнее обновление этой статьи — 30 августа 2026 года; данные сверены с официальным обновлением Apple и документацией Sign in with Apple, Private Email Relay и проверки токенов.

Если проверка показала, что домен зашит в клиенте, сначала создайте изолированную ветку, исправьте валидатор и выполните сборку на стабильном локальном или удалённом Mac. Для повторяющихся задач может подойти заказ удалённого Mac для сборки, но арендовать окружение только ради серверного изменения не требуется.

Главный недостаток текущего подхода «исправить одну строку» — он оставляет старый домен в базе, письмах, мобильном клиенте или панели поддержки. Второй недостаток — невозможно понять, где произошёл отказ. Третий — массовая замена email может создать дубли и сломать восстановление. Если вам нужен временный Mac для Xcode, TestFlight и изолированной проверки, аренда VpsMesh даст более подходящую среду, чем покупка отдельного компьютера под разовую миграцию. Для постоянной тяжёлой сборки или работы с физическими устройствами собственный Mac всё же может быть рациональнее.