# 07 · Пресеты почты

## Зачем пресеты

Записи почты домена связаны порядком: подтверждение домена → MX и SPF → DKIM → DMARC. Если
делать их вразнобой, получается «почта вроде настроена, но письма не подписаны» или «письма
ходят, а отчёты о подделках не приходят». Пресет знает порядок и знает, какие записи заменяются,
а какие добавляются.

## `google-workspace` — мастер из четырёх шагов

| Шаг | Что пишет | Подтверждение | Чем заблокирован |
|---|---|---|---|
| 1. Подтверждение домена | TXT `@` `google-site-verification=…` | именем домена | — |
| 2. Почта | MX 1, MX 5, MX 10 (`SMTP.GOOGLE.COM`), SPF | нет | шагом 1 |
| 3. DKIM | TXT `google._domainkey` | именем домена | шагом 1 и наличием ключа |
| 4. DMARC | TXT `_dmarc` | нет | — |

Подтверждение именем домена требуется только там, где значение **заменяется** (строка
подтверждения, ключ подписи). Шаги, которые только добавляют записи, применяются одной кнопкой —
копия зоны всё равно снимается.

### Почему три MX

Fornex отвергает вторую MX с идентичной строкой значения (приоритет не учитывается). Поэтому
записи с приоритетами 5 и 10 отличаются точкой на конце (`SMTP.GOOGLE.COM.`) и регистром букв
(`smtp.google.com.`) — для DNS это одна и та же цель, для API — разные строки.

### Почему DKIM только после подтверждения

Консоль администратора Google создаёт ключ домена лишь после того, как домен подтверждён и
включён Gmail. Шаг 3 без шага 1 не имеет смысла, поэтому он заблокирован, а не «просто не
работает».

### Нормализация DKIM

Ключ часто копируют фрагментами. Пресет приводит значение к валидному виду:

- `p=MIIB…` → `v=DKIM1; k=rsa; p=MIIB…`;
- голый base64 → добавляется `p=`;
- переносы строк схлопываются, пробелы внутри `p=` удаляются.

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

## `yandex-mail`

MX `mx.yandex.net.` (приоритет 10), SPF `include:_spf.yandex.net`, DKIM с селектором
`mail._domainkey`, DMARC. Параметры: ключ DKIM и строка DMARC.

## `site-on-vps`

A для `@` и `www` на указанный адрес, по желанию wildcard `*`. Параметры: IP сервера (если задан
`FORNEX_DEFAULT_IP`, поле уже заполнено) и «добавить wildcard».

## `mail-on-vps`

A `mail`, MX на `mail.<домен>`, SPF `mx a -all`, DKIM сервера (селектор `mail`), DMARC. Имя
хоста должно совпадать с PTR, иначе чужие серверы будут недоверчивы к письмам.

## Слияние вместо перезаписи

Три правила, из-за которых повторный запуск пресета не ломает почту:

1. **SPF сливается.** Существующие `include:`, `ip4:`, `a`, `mx` сохраняются; пресет добавляет
   свои механизмы и завершающий `all`. Если после слияния значение совпало с уже стоящим — план
   даёт «пропустить», а не «изменить».
2. **DMARC не ослабляется.** `p=quarantine` и `p=reject`, уже стоящие в зоне, никогда не
   понижаются до `none`; пресет добавляет `rua`, `pct` и недостающие теги.
3. **Одноимённые по смыслу записи заменяются.** Вторая SPF — это `permerror` для всего домена,
   поэтому запись ищется по смыслу (тип + имя + префикс значения), а не по точному совпадению.

## Проверка после применения

```bash
php backend/bin/fornex verify example.com
```

Отчёт спрашивает публичный резолвер и `ns1.fornex.com`. Если зона изменилась минуту назад, у
публичного резолвера ещё может быть старый ответ — это не ошибка, а кеш; авторитетный сервер
показывает истину.

## Чего пресеты не делают

- Не удаляют «мешающие» записи: конфликт показывается в плане, решение принимает человек.
- Не повышают политику DMARC сами: `p=none` → `p=quarantine` — осознанный шаг после того, как
  видно, что вся почта идёт через Google.
- Не трогают `SOA` и `NS`.
- Не создают зону: если её нет, это делает кабинет Fornex (панель покажет текст тикета).