wpnext
github wpnext
Cover Image for В WordPress 6.9 письма доставляются надежнее (SPF/DMARC)

В WordPress 6.9 письма доставляются надежнее (SPF/DMARC)

21 ноября 2025

В WordPress 6.9 отправка писем стала надежнее: исправлен Envelope-From, сброс кодировок PHPMailer и корректная обработка multipart. Это повышает доставляемость и снижает отказы по SPF/DMARC без дополнительных плагинов.

TL;DR

  • Envelope-From (Return-Path/MAIL FROM) теперь задаётся предсказуемо и расширяемо, что улучшает прохождение SPF/DMARC.
  • PHPMailer больше не «переносит» кодировки между письмами в одном запросе.
  • Исправлен 17‑летний баг с Content-Type для multipart: границы и заголовки формируются корректно.
  • Меньше необходимости в обходных плагинах и хаке через phpmailer_init — достаточно фильтра wp_mail_from.

Почему это важно

Ключ к доставляемости — соответствие протоколам аутентификации. SPF проверяет домен Envelope-From, а DMARC требует, чтобы домен в From был выровнен по SPF и/или DKIM. Ранее сервер исходящей почты часто подставлял технический адрес вроде www@node-14-dc3.example.com, что нарушало SPF/DMARC-выравнивание и приводило к отказам доставки или попаданию в спам. Кроме того, ошибки в формировании multipart и «утекающая» кодировка портили сообщения и их читаемость.

Что изменилось в WordPress 6.9

1) Предсказуемый Envelope-From

issue [61010]

Теперь WordPress определяет адрес отправителя так:

  • Если присутствует заголовок From — используется его адрес и как From, и как Envelope-From.
  • Иначе — по умолчанию задаётся wordpress@home_url().

Плагины могут скорректировать Envelope-From через фильтр wp_mail_from, если вы вычисляете адрес из настроек магазина, мультисайта или внешнего SMTP. Это устраняет прежние случаи, когда сервер подставлял случайный системный адрес, ломающий SPF/DMARC.

Практический эффект: письма с вашего сайта реже отклоняются, уведомления о недоставке (bounce) приходят на ожидаемый ящик, а политика DMARC можно применять жёстче без страха массовых отказов.

2) Сброс кодировок между отправками

изменение [61131]

wp_mail() использует глобальный объект $phpmailer. Раньше его внутреннее состояние кодировок могло «переезжать» из одного письма в следующее внутри одного PHP‑запроса. В 6.9 перед отправкой кодировка сбрасывается, и PHPMailer заново определяет её по контенту и настройкам. Это исправляет странности с чтением HTML/UTF‑8 после отправки текстового письма и наоборот.

3) Корректный Content-Type для multipart

изменение [61201]

Исправлен давний дефект, когда WordPress в ряде случаев передавал PHPMailer испорченный Content-Type для multipart‑сообщений. Это могло приводить к дублирующемуся заголовку или порче границ, из‑за чего вложения и альтернативные части (text/plain + text/html) отображались неверно. Теперь WordPress полагается на встроенную логику PHPMailer и не переопределяет заголовок вручную.

Кому важно отреагировать

  • Сайты, использующие внешние SMTP/API (почтовые сервисы, транзакционные провайдеры): проверьте домен Envelope-From и SPF/DMARC-выравнивание.
  • Инсталляции, где раньше применяли обходные пути через phpmailer_init или плагины для Return-Path: возможно, эти костыли больше не нужны.
  • Мультисайты и проекты с доменами для почты, отличными от домена сайта: настройте фильтр wp_mail_from.

Практика для администраторов: чек‑лист доставляемости

  1. Выберите домен отправителя. Желательно поддомен типа mail.example.com или bounce.example.com, принадлежащий вашему бренду.
  2. Согласуйте From и Envelope-From. В идеале — один и тот же домен. Это упрощает DMARC-выравнивание.
  3. Обновите DNS: SPF (включите ваш отправляющий сервис/сервер), DKIM (ключи от почтового провайдера), DMARC (например, p=quarantine или p=reject с адресом для отчётов).
  4. Проверьте обратный адрес для bounce-сообщений: почтовый ящик должен существовать или корректно обрабатываться вашим провайдером.
  5. Сделайте тесты отправки: обычный текст, HTML, письмо с вложением, многоязычное содержимое (UTF‑8), чтобы убедиться, что кодировка и multipart корректны.
  6. Посмотрите заголовки тестового письма в клиенте: From, Return-Path, SPF, DKIM‑подпись, результат DMARC.

Практика для разработчиков плагинов и тем

  • Предпочитайте фильтр wp_mail_from (и при необходимости wp_mail_from_name) вместо прямых манипуляций $phpmailer через phpmailer_init.
  • Не навязывайте вручную Content-Type для multipart: доверьте это PHPMailer.
  • Избегайте хранения состояния кодировок и заголовков между отправками в рамках одного запроса.
  • Добавьте автотесты на отправку: plain text, text/html, multipart/alternative + вложения; проверьте корректность границ и отсутствие дубликатов заголовков.
// Минимальная настройка адреса отправителя через фильтры
add_filter( 'wp_mail_from', function( $from ) {
    return 'no-reply@example.com';
} );

add_filter( 'wp_mail_from_name', function( $name ) {
    return 'Example Store';
} );

// Тестовая отправка с разными частями
wp_mail(
    'you@example.com',
    'Тест WordPress 6.9: multipart и UTF‑8',
    "Привет, это текстовая часть. Юникод: ✓",
    array( 'Content-Type: text/plain; charset=UTF-8' ),
    array()
);

Совместимость и типичные сценарии

  • Если ваш SMTP-плагин раньше выставлял Return-Path через phpmailer_init, проверьте, не происходит ли теперь двойная подмена. В большинстве случаев хватит wp_mail_from.
  • Сайты на поддоменах, шлющие письма от корневого домена, должны обеспечить выравнивание: SPF для Envelope-From и/или DKIM для From.
  • Хостинги, подставлявшие системный адрес отправителя, теперь меньше вмешиваются — письма станут стабильнее без нестандартных конфигов.

Итог

WordPress 6.9 делает отправку писем заметно более предсказуемой: правильный Envelope-From, чистое состояние PHPMailer и корректный multipart минимизируют отказы по SPF/DMARC и устраняют баги рендеринга. Для большинства сайтов улучшения сработают из коробки; тем, у кого сложная почтовая архитектура, достаточно тонко настроить wp_mail_from и DNS‑записи.

Source: https://make.wordpress.org/core/2025/11/18/more-reliable-email-in-wordpress-6-9/

Ещё почитать