Как правильно настроить SPF, DKIM и DMARC в Plesk

В этом руководстве я покажу вам шаг за шагом, как SPF DKIM и DMARC в Plesk, чтобы ваши электронные письма надежно аутентифицировались. Вы получите четкие процедуры для DNS-записей, переключателей Plesk и методы тестирования, с помощью которых вы сможете повысить доставляемость и блокировать недобросовестных отправителей.

Центральные пункты

• SPF определяет, какие системы имеют право отправлять почту для вашего домена.
• DKIM подписывает исходящие сообщения и защищает их от манипуляций.
• DMARC связывает SPF/DKIM с руководствами и отчетами.
• Плэск предоставляет мастера и шаблоны DNS для быстрого старта.
• Мониторинг отчетов DMARC оттачивает вашу политику в работе.

Проверьте предварительные условия в Plesk

Перед выполнением любых настроек я проверяю почтовый сервер, используемый в Плэск и управление DNS. В Linux я обычно работаю с Postfix, в Windows - с SmarterMail, поскольку эти службы обеспечивают функции SPF, DKIM и DMARC. Я также проверяю, есть ли у домена DNS-зоны в Plesk DNS или у внешнего провайдера, потому что тогда я могу управлять записями вне Плэск должны быть добавлены. Для бесперебойной работы я держу в чистоте имя хоста, обратный DNS и действующие сертификаты TLS, поскольку серверы доставки проверяют эти пункты. Чистая стартовая точка экономит много времени в дальнейшем и укрепляет Репутация.

Настройка SPF в Plesk - шаг за шагом

Чтобы начать, я открываю "Инструменты и настройки" → "Настройки DNS" и ищу TXT-запись, которая начинается с v=spf1 начинается. Если его нет, я его надеваю, например: v=spf1 a mx include:yourmailprovider.de -allчтобы авторизованным системам было разрешено отправлять сообщения, а все остальные были заблокированы. Если домен использует дополнительные отправители, такие как Microsoft 365, Google Workspace или службы рассылки, я добавляю соответствующие параметры. включить-механизмы из их документации. После сохранения я даю до 48 часов на глобальное вступление изменений в силу и проверяю запись с помощью SPF-чекера через тестовое письмо на выбранный почтовый ящик. Компактную классификацию взаимодействия механизмов вы можете найти в компактный путеводительв котором описаны наиболее важные сценарии.

Активируйте DKIM в Plesk - вот как это делается

Для DKIM Я перехожу в раздел "Инструменты и настройки" → "Настройки почтового сервера" и активирую опцию подписи исходящих писем. Затем я открываю "Веб-сайты и домены" на уровне домена → Домен → "Почта" → "Настройки" и проверяю, включена ли подпись для каждого домена. Если я управляю DNS извне, я экспортирую данные из Плэск сгенерированные открытые ключи DKIM и введите их в качестве TXT-записей у DNS-провайдера (обратите внимание на имя селектора). Максимум через 24-48 часов получатели должны подтвердить DKIM-подписи, что я подтверждаю, отправляя тестовое письмо на почтовый ящик для проверки DKIM или проверки заголовка. Действительная подпись укрепляет Доставляемость заметный.

Определите политику DMARC и используйте отчеты

Теперь я установил DMARC как TXT-запись на _dmarc.yourdomain.tld со значением v=DMARC1; p=карантин; rua=mailto:[email protected]; ruf=mailto:[email protected]; adkim=s; aspf=s. Метки p, rua и звоните политика контроля и отчетность, в то время как adkim/aspf определите строгое выравнивание (strict). На практике я часто начинаю с p=noneоценивать отчеты в течение двух-четырех недель, а затем составлять карантин или отказ . Отчеты показывают, какие системы отправляют почту от вашего имени и где SPF или DKIM не работают, что позволяет внести прямые исправления. Более подробная последовательность шагов описывает Реализация DMARC с конкретными примерами.

Распространение DNS, тесты и лучшие практики

Каждое изменение DNS требует времени, поэтому я планирую до 48 часов на глобальные изменения DNS. Распространение далее. На этом этапе я отправляю тестовые письма на внешние почтовые ящики и проверяю результаты аутентификации в заголовке для spf=pass, dkim=pass и dmarc=pass. Если почта получает softfail или НейтральныйЯ проверяю механизмы SPF, селекторы DKIM и конверт-from (путь возврата) на соответствие From:. При использовании редиректов я слежу за результатами DMARC, так как SPF часто нарушается; DKIM обычно компенсирует это. Я избегаю ~ все постоянно и для продуктивных настроек постоянно полагаться на -все.

Теги и значения DMARC - компактная таблица

Я использую следующий обзор, чтобы DMARC быстро и надежно и избежать неправильного толкования. Я поддерживаю согласованность значений на основных и поддоменах и документирую изменения отслеживаемым образом. Для продуктивных доменов я устанавливаю строгое выравнивание и всегда активирую агрегированные отчеты. Криминалистические отчеты (звоните) Я планирую в соответствии с правилами защиты данных. Установление четких руководящих принципов стабилизирует Репутация домена.

День	Значение	Возможные значения	Рекомендация
p	Политика для основного домена	нет, карантин, отказ	Начните с отсутствия, затем увеличьте до отказа
sp	Политика для поддоменов	нет, карантин, отказ	sp=отклонить для продуктивных установок
rua	Агрегированные отчеты	mailto:adresse	Используйте свой собственный адрес для отчетности
звоните	Отчеты судебно-медицинской экспертизы	mailto:adresse	Активируйте только в случае необходимости
adkim	Выравнивание DKIM	r (расслабленный), s (строгий)	adkim=s для четкого назначения
aspf	Выравнивание SPF	r (расслабленный), s (строгий)	aspf=s для уменьшения количества ложных срабатываний
пкт	Процент применения	0-100	Поэтапная подтяжка с помощью пкт

Интеграция внешних отправителей: Microsoft 365, Google, службы рассылки новостей

Если домен использует дополнительные пути доставки, я добавляю SPF для Microsoft 365, Google Workspace, Mailgun, SendGrid или инструменты рассылки в точности соответствуют документации. Для каждого сервиса я проверяю, активен ли отдельный ключ DKIM и действительно ли подписан домен from. Я избегаю дублирования или слишком большого количества включить-каскады, поскольку SPF ограничен десятью DNS-поисками. Если бюджет на поиск недостаточен, я консолидирую отправителей или перемещаю отдельные потоки на поддомены с собственной политикой DMARC. Таким образом я поддерживаю SPF и обеспечиваю безопасность Подписи от.

Глубокие проверки и выбор сервера

Для входящих писем я активирую в Плэск проверка SPF, DKIM и DMARC, чтобы сервер отфильтровывал спам на ранней стадии. В Linux эти проверки доступны по умолчанию, а в Windows они реализованы в SmarterMail. Я слежу за тем, чтобы почтовый сервер обновлялся должным образом, чтобы сигнатурные процедуры и парсеры оставались актуальными. Если возникают проблемы с ложными срабатываниями, я корректирую пороги оценки, но никогда не Политика вашего собственного домена. Так я поддерживаю высокий уровень защиты и обеспечиваю доставку от легитимных отправителей.

Распространенные ошибки и быстрые решения

Митинги "SPF permerror", то обычно имеет место синтаксическая ошибка или превышен лимит поиска. Если DKIM не работает, я проверяю селектор, запись открытого ключа и завершение TXT-значения правильными инвертированными запятыми. Если DMARC не работает провалитьсяСначала я проверяю соответствие: From-Domain, Return-Path и DKIM-d= должны идеально совпадать. Если SPF нарушается при перенаправлении, я полагаюсь на DKIM и поддерживать статус подписи стабильным. Я использую эту последовательность, чтобы решить большинство проблем с доставкой без долгих поисков.

Шаблоны DNS и автоматизация в Plesk

Если я управляю многими доменами, я устанавливаю Шаблон DNS в Plesk и хранить там стандартные записи для SPF, DKIM и DMARC. Новые домены сразу же получают надежные настройки по умолчанию, которые мне остается только подправить. Я также внедряю запланированные изменения, такие как более строгий DMARC в масштабах всего домена, используя шаблоны и скрипты. Для ротации ключей DKIM я работаю с двумя селекторами, чтобы можно было вносить постепенные изменения. Это позволяет сохранить последовательность действий на десятках доменов и обслуживаемый.

Оцените отчеты DMARC и ужесточите политику

После ввода в эксплуатацию я ежедневно анализирую сводные отчеты и выявляю Источникикоторые отправляют сообщения от имени домена без авторизации. Я блокирую неожиданные IP-адреса и очищаю устаревшие инструменты, прежде чем ужесточать политику. Переход от p=none на сайте карантин а позже отказ Я провожу с пкт поэтапно, чтобы я мог контролировать эффект. Если в неудачном отчете появляются легитимные отправители, я исправляю SPF или активирую свой собственный ключ DKIM. Эта процедура укрепляет Репутация видимость и уменьшает количество подделок.

Правильное понимание выравнивания

Так что DMARC Я постоянно слежу за правильным выравниванием. С SPF это домен в конверте from (путь возврата) или идентификатор HELO/EHLO, который должен совпадать с видимым доменом from (строго: идентичный, расслабленно: тот же домен организации). С DKIM Я проверяю d=-атрибут подписи: она должна указывать на один и тот же домен (строгий) или на один и тот же организационный домен (расслабленный). На практике я слежу за тем, чтобы:

• используемый путь возврата (return path) использует домен, совпадающий с доменом from, или намеренно передается на поддомен с собственной политикой DMARC,
• всем сторонним провайдерам домен From подписать (DKIM), а не только свой собственный домен доставки,
• подпись DKIM остается нетронутой во время пересылки, чтобы компенсировать разрывы SPF.

Если выравнивание отсутствует, получатели DMARC сообщают об ошибке, несмотря на действительные SPF/DKIM dmarc=fail. Поэтому я проверяю поля в заголовках писем. Результаты аутентификации, Путь возвращения и параметры DKIM. Это позволяет мне быстро определить, обеспечивает ли SPF или DKIM выравнивание и где мне нужно внести улучшения.

Управление ключами и параметры DNS

Для прочного DKIM-установки, я использовал 2048-битные ключи. В Плэск Я могу задавать длину ключа для каждого домена; я оперативно использую старые 1024-битные ключи. При необходимости я разбиваю длинные TXT-записи DKIM на несколько сегментов через запятую, чтобы DNS-сервер доставлял их правильно. Я также определяю значимые TTL-значения: На этапах развертывания я перехожу к 300-900 секундам, в продуктивном режиме я использую 1-4 часа. Это позволяет мне гибко реагировать на изменения, не перегружая кэши.

Die Вращение Я делаю это без сбоев с двумя селекторами:

1. Создайте новый селектор в Plesk и опубликуйте открытый ключ как TXT в DNS.
2. Измените отправителя на нового селектора и наблюдайте за мониторингом (покажите заголовки). s=новый селектор).
3. Когда все потоки будут преобразованы, удалите старый селектор в DNS и деактивируйте его в Plesk.

По возможности я пользуюсь услугами сторонних провайдеров, делегированный DKIM-записи (например, CNAME для селектора провайдера). Это позволяет мне сохранять контроль над зоной и чередовать ключи без риска перебоев в работе.

Особые случаи: Переадресация, списки рассылки и шлюзы

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

• ПереадресацияSPF часто ломается, потому что IP-адрес пересылки отсутствует в SPF домена отправителя. Здесь я полагаюсь на DKIMкоторая обеспечивает защиту содержимого. Если подпись остается неизменной, DMARC существует благодаря выравниванию DKIM.
• Списки рассылкиМногие списки меняют темы или колонтитулы и тем самым нарушают подпись DKIM. В таких случаях я планирую расслабленное выравнивание и проверяю, использует ли список SRS/ARC или свои собственные подписи. Если возможно, я использую для списков поддомен с собственной политикой DMARC.
• Шлюзы безопасностиШлюзы, которые повторно подписывают сообщения или переписывают конверт "от", должны быть правильно согласованы с доменом отправителя. Я документирую их роль и привязываю их в SPF (ip4/ip6) или через include, чтобы соблюсти соответствие.

Встречайте письма с spf=fail через переадресацию, это не является автоматически критичным до тех пор, пока dkim=pass присутствует, а выравнивание DKIM корректно. Я оцениваю все результаты проверки подлинности, а не отдельные сигналы по отдельности.

Общие IP-адреса, HELO/EHLO и rDNS

Если несколько доменов используют один и тот же исходящий IP-адрес, я полагаюсь на чистый rDNS и согласованные имена HELO/EHLO. Обратный указатель указывает на FQDN (например. mail.hosting-example.tld), чья A-запись указывает на тот же IP. MTA сообщает именно это имя. Я убедился, что Сертификат SMTP TLS соответствует имени HELO (SNI, если обслуживается несколько имен). Для каждого домена отправителя я также убеждаюсь, что SPF/DKIM/DMARC полностью и правильно согласованы - общий IP сам по себе не влияет на DMARC, пока аутентификация эффективна.

Для специализированных отправителей (например, транзакционная почта против маркетинговой) я предпочитаю разделять их с помощью поддоменов и, как вариант, их собственных IP-адресов. Это помогает Управление репутациейупрощает оценку отчетов DMARC и минимизирует взаимные помехи.

Мониторинг и внедрение на практике

Чтобы обеспечить бесперебойную работу, я сочетаю непрерывное Анализ DMARC с четкими этапами развертывания:

• Базовый уровень2-4 недели p=noneСоберите все сводные отчеты (rua), определите источники ошибок.
• УборкаУдалите неавторизованных отправителей, очистите SPF-включения, активируйте DKIM на всех легитимных системах.
• ГардеробС пкт постепенно к карантин, позже отказ увеличение, измерьте эффект в процентах.
• ОповещениеОпределите пороговые значения (новые IP-адреса, количество отказов по провайдеру, новые из доменов) и настройте уведомления.
• ДокументацияДержите селекторы, TTL, время выполнения ключей, бюджет SPF и обязанности под контролем версий.

Я проверяю Бюджет поиска SPF (не более 10 механизмов с DNS-запросами) и консолидировать включает в себя. Критически важные механизмы, такие как ptr или +all Обычно я их не использую; ip4/ip6, a, mx и целенаправленный включить остаются средствами выбора. Так я поддерживаю стабильность и проверяемость установки.

Быстрая проверка для каждого домена

В конце каждой установки я запускаю фиксированную Проверьте через: SPF-запись доступна, бюджет поиска меньше десяти, механизмы правильно отсортированы, -все Активно. Подпись DKIM действительна, селектор документирован, длина ключа достаточна, планируется ротация. DMARC с действительной TXT-записью, строгое выравнивание, почтовые ящики для отчетности доступны и архивируются. Показать тестовые письма spf=pass, dkim=pass и dmarc=pass в заголовке. Я использую эту последовательность, чтобы сохранить воспроизводимость настроек и Низкая погрешность.

Практическое резюме для быстрого достижения успеха

Я начинаю каждый проект с четкого СтандартыПоддерживайте SPF в норме, активируйте DKIM для каждого отправителя и разверните DMARC с отчетностью. После этого в течение двух-четырех недель проводится мониторинг, чтобы закрыть "слепые зоны" и ужесточить рекомендации. Я контролируемо интегрирую внешние службы, документирую их использование и держу под контролем бюджет на поиск. Я использую шаблоны DNS для нескольких доменов и планирую ротацию ключей DKIM, чтобы поддерживать сигнатуры в актуальном состоянии. Я обобщаю полезные практические идеи и советы по устранению неполадок в своем Советы Plesk 2025 вместе, чтобы вы могли поддерживать сильную Доставляемость дойти.