Продали проект, а домен и почта остались на вас: как закрыть хвосты

MAATRIX

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

Почему домен и почта проваливаются между кодом и сервером

Передача проекта обычно строится вокруг того, что легко пощупать: репозиторий, сервер с работающим приложением, дамп базы. У каждого артефакта есть точка «передал — принял», и стороны интуитивно понимают, что с ней делать. Домен в эту логику вписывается плохо, потому что формально он не лежит внутри проекта — это отдельная запись в личном кабинете регистратора, которая просто указывает на сервер через DNS. Пока сайт открывается, кажется, что домен уже «передан» вместе со всем остальным, хотя на деле поменялся только IP-адрес в A-записи, а сам домен как актив как был приписан к аккаунту продавца, так и остался.

С почтой то же самое, только незаметнее. Домен почти всегда используется не только для сайта, но и для служебных адресов: admin@project.ru, noreply@project.ru, адрес, на который зарегистрированы аккаунты в платёжных системах, у хостинг-провайдера, в CRM. Если эти ящики физически размещены на почтовом сервере продавца — например, на его VPS с Mailcow или iRedMail, — покупатель может месяцами не подозревать, что вся переписка от имени его бизнеса технически идёт через инфраструктуру человека, который к бизнесу больше не имеет отношения.

Разница между «сайт открывается» и «домен и почта переданы» — это разница между делегированием и владением. Первое делается за пять минут сменой NS или A-записи. Второе требует смены регистранта в WHOIS или полноценного transfer-переноса домена к регистратору покупателя, плюс переноса почтовых ящиков на инфраструктуру, которую контролирует покупатель. Если в момент сделки об этом не договорились явно — по умолчанию остаётся первый, самый слабый вариант.

Риски для продавца: чужой бизнес на вашей карте

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

• Продолжающаяся оплата за чужой бизнес. Автопродление домена списывается с карты продавца каждый год, пока кто-то явно не сменит платёжный метод или регистранта. То же с почтовым сервером, если ящики покупателя размещены на сервере, который продавец продолжает оплачивать «по инерции» — отключить его страшно: вдруг там что-то важное, а явной договорённости о переносе не было.
• Юридическая неопределённость. Если в договоре прямо не прописано, что домен и почта передаются покупателю (или прописано расплывчато — «вся инфраструктура проекта»), формально непонятно, кто отвечает за домен после сделки. Продавец получил деньги за бизнес, но по документам регистратора остаётся администратором домена — а значит, для регистратора и любого третьего лица, ответственным лицом.
• Риск обвинений за то, что вы уже не контролируете содержательно. Домен физически всё ещё под вашим аккаунтом — значит, если на сайте покупателя появится что-то проблемное (спорный контент, утечка через почту, фишинговое письмо с домена), формальная точка ответственности в WHOIS — это вы, даже если вы давно не влияете на содержание проекта. Обратная сторона той же медали: если продление домена просрочится или почта откажет, обвинят тоже вас — с формулировкой «ты же говорил, что всё передал».

Ни один из этих рисков не снимается фразой «мы вроде обо всём договорились на словах». Пока в WHOIS стоит ваш email, а в панели хостинга — ваша карта, ответственность формально остаётся на вас, что бы ни говорилось в переписке.

Риски для покупателя: бизнес на чужом фундаменте

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

• Зависимость от бывшего владельца в критичном узле. Домен — не второстепенный технический элемент, а фактический адрес бизнеса в интернете: на нём завязаны сайт, почта, интеграции, SEO-история, репутация у поисковиков и email-провайдеров. Если продавец сохраняет административный контроль над доменом, покупатель зависит от доброй воли и внимательности человека, с которым у него больше нет общих деловых интересов.
• Риск внезапного падения без предупреждения. Продавец может забыть продлить домен — не из злого умысла, а потому что проект для него больше не в фокусе внимания, а письма от регистратора улетают в спам или на давно не читаемый ящик. Домен с истёкшей регистрацией уходит в grace-период, а затем в открытую продажу — и восстановление в этот момент требует уже не пары кликов, а срочных звонков в поддержку и риска не успеть вовсе. Похожая логика потери контроля разобрана в статье про домен без развёрнутой инфраструктуры: там причина другая — домен купили заранее и отложили запуск, — но механизм риска для владельца бизнеса тот же: пока актив не под явным вашим контролем, чужая случайность или невнимание может обнулить работающий проект.
• Утечка контроля через почту. Если почтовые ящики бизнеса физически стоят на сервере продавца, у него остаётся техническая возможность читать входящую почту, включая переписку с клиентами, уведомления от банков и письма для восстановления доступа к другим сервисам. Даже без злоупотреблений сам факт такой возможности — дыра в безопасности бизнеса, о которой покупатель может не подозревать месяцами.

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

Полная передача домена: transfer, а не просто смена NS

Ключевая ошибка обеих сторон — путать делегирование DNS с передачей владения. Смена NS-записей на серверы покупателя (или просто A-записи на его IP) заставляет сайт открываться с новой инфраструктуры, но домен как актив остаётся зарегистрированным на аккаунт продавца в личном кабинете регистратора. Это удобно для быстрого технического переезда, но не решает вопрос владения.

Правильная передача домена — это одно из двух:

1. Смена регистранта (owner change) у текущего регистратора, если он это поддерживает и обе стороны согласны оставить домен там же. В личном кабинете меняются контактные данные регистранта на данные покупателя (email, ФИО/юрлицо, платёжный метод), после чего аккаунт продавца теряет административный доступ к домену.
2. Полный transfer к регистратору покупателя — если покупатель хочет вести домен у своего привычного регистратора. Механика стандартная: снятие Registrar Lock, получение EPP/auth-кода, инициация переноса на стороне нового регистратора, подтверждение через email, привязанный к домену. Подробный разбор шагов и типичных ограничений (60-дневный лок после регистрации или предыдущего переноса, обязательное отключение DNSSEC перед стартом) — в статье про перенос домена к другому регистратору.

Перед переносом стоит зафиксировать факты, а не полагаться на память:

# кто сейчас регистрант и админ-контакт домена
whois project-domain.ru

# кто хостит DNS-зону прямо сейчас
dig NS project-domain.ru +short

# какой email привязан к аккаунту регистратора — только из личного кабинета

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

• Договоритесь заранее, кто оплачивает перенос (если регистратор берёт комиссию) и что делать, если домен близко к истечению срока — некоторые регистраторы блокируют перенос в последние дни перед продлением.
• Снимите Registrar Lock и отключите DNSSEC, если включён — с этими опциями перенос не запустится.
• Убедитесь, что email для подтверждения переноса — тот, к которому у продавца ещё есть доступ на момент операции: если ящик уже отключён, подтвердить перенос будет неоткуда.
• После завершения перенеса проверьте whois ещё раз: регистрант должен смениться, а не только NS-записи.

Если покупатель пока не готов вести домен у себя, временный вариант — смена только регистранта у текущего регистратора без переноса между регистраторами. Это быстрее и не запускает лок на перенос, но требует, чтобы регистратор такую операцию вообще поддерживал.

Перенос почты: ящики, пересылка, DKIM/SPF

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

Если ящики физически стоят на сервере продавца (Mailcow, iRedMail, Postfix напрямую), варианты для покупателя:

• Поднять собственный почтовый сервер и перенести ящики (IMAP-синхронизация, imapsync или штатный экспорт панели) — подходит, если покупатель уже размещает инфраструктуру на своих серверах.
• Перейти на управляемую почту (Google Workspace, Яндекс 360 для бизнеса или аналог) — быстрее по внедрению, снимает вопрос администрирования, но требует смены MX и повторной настройки SPF/DKIM/DMARC под новый сервис.
• Временная переадресация на новый ящик покупателя — не решение, а способ не потерять письма, пока идёт полноценный перенос. Оставлять её как постоянную схему нельзя: почта продолжает физически проходить через инфраструктуру продавца, проблема контроля не решена, только замаскирована.

MX-записи домена меняются в любом варианте — а значит, эта часть переноса возможна только после того, как решён вопрос с самим доменом: если он ещё числится за продавцом, менять MX без согласования — риск для обеих сторон, а если уже передан покупателю, он вправе менять их сам.

После переноса стоит проверить:

# MX должны указывать на новую почтовую инфраструктуру
dig MX project-domain.ru +short

# SPF должен перечислять именно новые отправляющие серверы
dig TXT project-domain.ru +short | grep spf

# DKIM-селектор должен быть переиздан для нового сервера,
# старый селектор от сервера продавца лучше отозвать
dig TXT selector._domainkey.project-domain.ru +short

Если SPF/DKIM не обновить после смены почтового сервера, письма от нового ящика начнут попадать в спам или отклоняться — частая грабля именно при переезде почты вместе с бизнесом: про MX вспоминают, а про SPF/DKIM/DMARC — не всегда. Отдельно стоит пройтись по старым адресам, на которые зарегистрированы сторонние сервисы (платёжная система, хостинг, аналитика, CRM), и явно поменять контактный email на адрес покупателя — иначе письма о смене пароля или подозрительном входе годами будут приходить туда, откуда покупатель их никогда не увидит.

Как закрыть сделку документально

Технический перенос без документального подтверждения оставляет ту же проблему, из-за которой появилась эта статья: устная договорённость «мы вроде всё передали» не защищает ни одну из сторон, если через полгода что-то пойдёт не так. Полное закрытие хвостов требует явного двустороннего подтверждения — не обязательно тяжёлого юридического документа, но обязательно письменного и датированного.

Минимальный набор, который стоит зафиксировать по каждому пункту:

Проще всего оформить это коротким письмом или сообщением в переписке с датой, где перечислено, что именно передано и подтверждено обеими сторонами, — не как замена договору купли-продажи, а как техническое приложение к нему, на которое можно сослаться, если через полгода возникнет вопрос «а мы точно всё передали?». Если сделка оформлялась договором, разумно включить пункт о домене и почте явно, а не полагаться на общую формулировку «вся инфраструктура проекта переходит покупателю» — она слишком расплывчата, чтобы предъявить её регистратору или использовать как аргумент в споре.

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

Частые вопросы