Листи WordPress потрапляють у спам: SPF/DKIM/DMARC — пояснення та налаштування

Що насправді відбувається, коли пошта WordPress потрапляє у спам

Поштові провайдери не «ненавидять WordPress». Вони не довіряють неверифікованим відправникам, непослідовній ідентичності та патернам відправлення, схожим на спам. WordPress часто лишень кур’єр, а не корінь проблеми.

Коли ви натискаєте «Надіслати», задіяно щонайменше чотири ідентичності:

• Envelope sender / Return-Path: куди повертаються відмови. Зазвичай контролюється SMTP‑сервером або провайдером.
• Header From: те, що бачать користувачі. Часто задається WordPress, плагіном форм або налаштуванням «From email».
• DKIM d= domain: домен, який криптографічно підписує повідомлення (якщо використовується DKIM).
• Sending IP: сервер, який фактично провів SMTP‑транзакцію.

SPF оцінює IP відправника відносно домену в конверті. DKIM перевіряє підпис проти публічного ключа в DNS. DMARC перевіряє, чи хоча б SPF або DKIM проходять і вирівнюються з доменом у Header From.

Якщо ви не контролюєте ці ідентичності свідомо, ваша пошта виглядатиме як фальсифікат, навіть якщо вона легітимна. І поштові системи за замовчуванням підозрюють вас.

Практична порада: припиніть намагатися змусити PHP mail() поводитися. Використовуйте автентифікований SMTP або транзакційного провайдера. А потім погодьте DNS‑записи з реальністю. Ось і вся гра.

Швидка діагностика (перевірте спочатку/далі/остання)

Перше: підтвердіть, яка ідентичність використовується

1. Візьміть реальний лист, який потрапив у спам (або «показати оригінал» у отримувача).
2. Запишіть: Header From, Return-Path, DKIM d=, sending IP і чи пройшли SPF/DKIM/DMARC.

Проблема, яку ви шукаєте: невирівнювання (DMARC fail навіть якщо SPF проходить) або «відсутня автентифікація взагалі».

Друге: перевірте, що DNS‑записи присутні, поодинокі та правильні

1. Переконайтеся, що у домені є рівно один SPF TXT запис.
2. Перевірте, що DKIM TXT існує для селекторів, які фактично використовуються.
3. Перевірте, що DMARC запис існує і синтаксично коректний.

Проблема, яку ви шукаєте: «permerror» через множинні SPF записи, відсутній DKIM‑ключ, опечатка в DMARC або неправильний піддомен.

Третє: підтвердіть, що WordPress надсилає через очікуваний шлях

1. Якщо ви очікуєте SMTP: перевірте, що плагін WordPress налаштований і сервер може дістатися до SMTP‑хоста на потрібному порту.
2. Якщо ви очікуєте локальний MTA: перевірте, що Postfix/Exim релеїть через надійний smarthost, а не надсилає напряму з випадкового VPS IP.

Проблема, яку ви шукаєте: ви виправили DNS для «Провайдера A», але WordPress все ще надсилає через «Сервер B». Це найпоширениша самосаботажна помилка.

Цікаві факти та трохи історії (бо електронна пошта старша за вашого CTO)

• Електронна пошта з’явилася раніше за веб. Перші мережеві поштові системи існували на початку 1970‑х; автентифікація з’явилася значно пізніше, як доповнення.
• SPF почався як прагматичний хак. Його створили, щоб дозволити власникам доменів публікувати, які IP мають право надсилати, бо сам SMTP на це не звертав уваги.
• DKIM народився з двох конкуруючих систем. DomainKeys та Identified Internet Mail об’єднали в DKIM — «операційний компроміс» з криптографією.
• DMARC — це по суті клей політик. Він пов’язує SPF і DKIM з правилами вирівнювання і додає звіти, щоб ви бачили, хто намагається вас імітувати.
• Алігація існує тому, що зловмисники можуть пройти SPF для іншого домену. Без вирівнювання повідомлення можуть «автентифікуватися», але брехати в видимому From.
• Розсилки руйнують DKIM. Зміни тіла повідомлення ламають DKIM‑підписи; індустрія створила ARC, щоб зменшити побічні ефекти.
• «p=reject» не став масовим, поки великі провайдери не підштовхнули до нього. DMARC існував роки, перш ніж багато організацій наважилися застосувати жорсткі політики.
• SPF має ліміт DNS‑запитів — 10. Ця межа пояснює, чому «додати ще одне include» зрештою підриває роботу в продакшені.
• Деякі провайдери тепер за замовчуванням підозрюють неавтентифіковану пошту. Планка підвищилася; те, що працювало в 2016, у 2025 стало ризиком.

SPF, DKIM, DMARC: що це таке і чого це не є

SPF: «Цей IP має право надсилати від імені цього домену»

SPF — це TXT‑запис в DNS, який перелічує, які IP (або інші домени через include) авторизовані надсилати пошту від імені домену — конкретно, для домену envelope sender (Return‑Path). Отримувач порівнює підключний IP з цією політикою.

SPF це не: шифрування, гарантія потрапляння в папку «Вхідні» або гарантія того, що видимий заголовок «From:» правдивий. SPF може проходити, а From бути зовсім іншим.

Що SPF робить добре: запобігає випадковому спуфінгу і допомагає системам отримувача оцінити вашу пошту як легітимну в поєднанні з DKIM/DMARC.

DKIM: «Це повідомлення підписане доменом з цим ключем»

DKIM додає заголовок підпису, який покриває вибрані заголовки і (зазвичай) тіло. Отримувач дістає публічний ключ із DNS (селектор + домен) і перевіряє підпис.

DKIM це не: обіцянка, що вміст коректний, або що дружній заголовок From вирівняний із підписувачем. DKIM лише говорить: «домен, що контролює цей DNS‑ключ, підписав цей вміст».

Режими відмов DKIM: модифікація тіла в дорозі, неправильний селектор, неправильний ключ у DNS або відправна система просто не підписала повідомлення.

DMARC: «Приймайте або відхиляйте на основі автентифікації та вирівнювання; надсилайте мені звіти»

DMARC розміщується на _dmarc.yourdomain як TXT‑запис. Він каже отримувачам:

• Що робити, якщо пошта не пройшла DMARC (none/quarantine/reject).
• Куди надсилати агреговані та форензичні звіти.
• Наскільки суворим має бути вирівнювання (relaxed vs strict).

DMARC проходить, якщо або SPF проходить з вирівнюванням, або DKIM проходить з вирівнюванням.

DMARC це не: фільтр проти спаму. Це механізм примусового дотримання ідентичності. Антиспам‑фільтри все одно оцінюють вміст і репутацію.

Сухий висновок: автентифікація пошти — як ремінь безпеки. Вона не запобіжить аваріям, але ви помітите, коли її немає.

Цитата: «Надія — це не стратегія.» — Gene Kranz

Жарт #1: SPF — це по суті ваш домен, що каже «Так, цей IP зі мною». Це як VIP‑список охорони, тільки з більше DNS і менше оксамитових шторок.

Алігація: частина, яку всі пропускають і потім страждають

Якщо запам’ятаєте лише одне: DMARC не цікавить, що SPF або DKIM пройшли. Йому важливо, щоб вони пройшли для того ж домену, який бачить користувач у From.

Relaxed проти strict вирівнювання

• Relaxed (adkim=r, aspf=r): піддомени можуть вирівнюватися. Приклад: From — example.com, DKIM‑підписувач mail.example.com може вирівнюватися (організаційний домен співпадає).
• Strict (adkim=s, aspf=s): потрібне точне співпадіння. Якщо From — example.com, DKIM‑підписувач має бути рівно example.com.

Типова помилка вирівнювання у світі WordPress

Ви надсилаєте пошту «From: you@yourdomain.com», але ваш SMTP‑провайдер використовує bounce‑домен на кшталт bounces.provider-mail.net. SPF проходить для домену провайдера, але він не вирівнюється з yourdomain.com. DKIM також може підписувати як домен провайдера, якщо ви не налаштували власний DKIM.

Результат: SPF=pass, DKIM=pass, DMARC=fail. Це найзаплутаніша ситуація «все пройшло, але не пройшло».

Що робити: налаштуйте провайдера так, щоб він підписував ваш домен (custom DKIM) і/або використовуйте власний return‑path (custom bounce domain), який вирівнюється з вашим From.

Практичні завдання: команди, виводи та рішення (12+ реальних перевірок)

Це перевірки, які я насправді виконую, коли пошта поводиться неправильно. Кожна включає: команду, що означає вивід, і яке рішення приймати далі.

Завдання 1: Знайдіть публічний IP відправки (якщо ви надсилаєте прямо з сервера)

cr0x@server:~$ curl -s ifconfig.me
203.0.113.42

Значення: якщо ваш MTA надсилає напряму, це ймовірно IP, який бачать отримувачі.

Рішення: якщо цей IP — типовий діапазон VPS без репутації, не надсилайте напряму. Використайте smarthost або транзакційного провайдера.

Завдання 2: Перевірте зворотній DNS (PTR) для IP відправника

cr0x@server:~$ dig +short -x 203.0.113.42
wp01.mail.example.com.

Значення: отримувачам подобається бачити PTR, що мапить IP на хостнейм, який виглядає навмисним.

Рішення: якщо нічого немає або PTR за замовчуванням провайдера — виправте PTR через ваш ISP/провайдера хмари або припиніть відправляти напряму.

Завдання 3: Підтвердіть forward‑confirmed reverse DNS (FCrDNS)

cr0x@server:~$ dig +short wp01.mail.example.com A
203.0.113.42

Значення: PTR вказує на хостнейм; хостнейм резолвиться назад на той же IP.

Рішення: якщо не співпадає — виправте DNS (A‑запис) або PTR. Деякі отримувачі карають за невідповідності.

Завдання 4: Інспектуйте SPF‑запис (і зловіть катастрофу з «двома SPF»)

cr0x@server:~$ dig +short TXT example.com
"v=spf1 include:_spf.google.com include:spf.protection.outlook.com -all"

Значення: у вас є один SPF‑рядок. Добре.

Рішення: якщо повертаються кілька окремих v=spf1 рядків — об’єднайте їх в один SPF‑запис.

Завдання 5: Перевірте синтаксис SPF і ризик ліміту 10 запитів

cr0x@server:~$ python3 - <<'PY'
import dns.resolver, re
domain="example.com"
txt=[]
for r in dns.resolver.resolve(domain,"TXT"):
    s=b"".join(r.strings).decode()
    if s.startswith("v=spf1"):
        txt.append(s)
print("SPF records:", len(txt))
print(txt[0] if txt else "none")
print("includes:", len(re.findall(r'\\binclude:', txt[0])) if txt else 0)
PY
SPF records: 1
v=spf1 include:_spf.google.com include:spf.protection.outlook.com -all
includes: 2

Значення: спрощений підрахунок, але він виявляє неконтрольовані ланцюги include.

Рішення: якщо ви близькі до 10 DNS‑запитів — згладьте SPF або видаліть невикористовувані відправники перед тим, як SPF перетвориться на permerror.

Завдання 6: Перевірте наявність і читабельність DMARC‑запису

cr0x@server:~$ dig +short TXT _dmarc.example.com
"v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r; pct=100"

Значення: DMARC опубліковано з політикою quarantine, relaxed вирівнюванням і агрегованими звітами.

Рішення: якщо відсутній — опублікуйте. Якщо політика p=none, ви лише моніторите (добре тимчасово, але не назавжди).

Завдання 7: Перевірте DKIM‑селектор для вашого провайдера

cr0x@server:~$ dig +short TXT s1._domainkey.example.com
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."

Значення: публічний DKIM‑ключ існує для селектора s1.

Рішення: якщо порожньо/NXDOMAIN — або ви вказали неправильний селектор, або провайдер ще не почав підписувати ваш домен.

Завдання 8: Підтвердіть, яку ідентичність думає про себе Postfix (поширено для self‑hosted WordPress)

cr0x@server:~$ postconf -n | egrep 'myhostname|mydomain|myorigin|relayhost|inet_interfaces'
myhostname = wp01.mail.example.com
mydomain = example.com
myorigin = $mydomain
relayhost = [smtp.mailprovider.net]:587
inet_interfaces = loopback-only

Значення: сервер налаштовано релеїти через smarthost, а не надсилати напряму; також слухає лише loopback (гарне підкріплення).

Рішення: якщо relayhost порожній і сервер надсилає напряму — очікуйте проблем з доставкою, якщо тільки ви серйозно не керуєте репутацією.

Завдання 9: Перевірте SMTP‑підключення до вашого ретранслятора (мережа і фаєрвол)

cr0x@server:~$ nc -vz smtp.mailprovider.net 587
Connection to smtp.mailprovider.net 587 port [tcp/submission] succeeded!

Значення: сервер може дістатися до порту submission на SMTP.

Рішення: якщо з’єднання не вдається — виправте правила вихідного фаєрволу, security group або обмеження провайдера (деякі хмари блокують 25/587 за замовчуванням).

Завдання 10: Надішліть тестовий лист з сервера з явним envelope sender

cr0x@server:~$ printf "Subject: SMTP test\nFrom: wp@example.com\nTo: you@example.net\n\nhello\n" | sendmail -f bounce@example.com you@example.net

Значення: це тестує локальний MTA шлях і встановлює envelope sender як bounce@example.com.

Рішення: якщо приходять відмови або логи показують відмову — перевірте логи MTA і автентифікацію до relayhost.

Завдання 11: Читайте логи пошти для негайних відмов (істина в логах)

cr0x@server:~$ sudo tail -n 50 /var/log/mail.log
Dec 27 10:42:11 wp01 postfix/smtp[21455]: to=, relay=smtp.mailprovider.net[198.51.100.10]:587, delay=1.2, delays=0.1/0.1/0.6/0.4, dsn=2.0.0, status=sent (250 2.0.0 queued as 9A1BC2D3)

Значення: Postfix передав листа ретранслятору успішно (2.0.0 sent).

Рішення: якщо бачите 5xx відмови — виправте автентифікацію, політики From домену або статус аккаунта провайдера перед тим, як торкатися DNS.

Завдання 12: Переконайтеся, що WordPress дійсно використовує SMTP (а не падає назад на PHP mail)

cr0x@server:~$ grep -R "WP_MAIL_SMTP" -n /var/www/html/wp-config.php
37:define('WP_MAIL_SMTP_HOST', 'smtp.mailprovider.net');
38:define('WP_MAIL_SMTP_PORT', 587);
39:define('WP_MAIL_SMTP_AUTH', true);

Значення: конфігурація присутня (метод залежить від плагіна). Це показує, що WordPress має намір використовувати SMTP.

Рішення: все одно перевірте логи плагіна або зіставте часові мітки в mail.log. Конфігураційний дріфт — реальний ворог.

Завдання 13: Проаналізуйте результати автентифікації у заголовках отриманого повідомлення

cr0x@server:~$ python3 - <<'PY'
import sys, re
raw = """Authentication-Results: mx.example.net;
 spf=pass smtp.mailfrom=bounce.example.com;
 dkim=pass header.d=example.com header.s=s1;
 dmarc=pass header.from=example.com
"""
print("SPF:", re.search(r"spf=\\w+", raw).group(0))
print("DKIM:", re.search(r"dkim=\\w+", raw).group(0))
print("DMARC:", re.search(r"dmarc=\\w+", raw).group(0))
PY
SPF: spf=pass
DKIM: dkim=pass
DMARC: dmarc=pass

Значення: так виглядає «гарний» результат: DMARC пройшов з вирівняними ідентичностями.

Рішення: якщо DMARC не пройшов — перевірте вирівнювання: чи відрізняються header.from, smtp.mailfrom і header.d?

Завдання 14: Виявлення множинних SPF‑записів (явно)

cr0x@server:~$ dig +short TXT example.com | grep -c "v=spf1"
2

Значення: існує два SPF‑записи. Для багатьох отримувачів це SPF permerror.

Рішення: об’єднайте їх в один SPF негайно. «Але минулого тижня це працювало» — не аргумент.

Завдання 15: Перевірте, що в домені присутній include провайдера

cr0x@server:~$ dig +short TXT example.com | tr ' ' '\n' | grep -E '^include:'
include:_spf.google.com
include:spf.protection.outlook.com

Значення: SPF включає два екосистемних механізми. Це може бути правильно або залишком від минулого.

Рішення: якщо ви більше не надсилаєте через один з них — видаліть його. Невикористовувані include збільшують радіус ураження і кількість запитів.

DNS‑записи, що реально працюють (приклади для адаптації)

DNS — це місце, де добрі наміри гинуть. Тримайте все нудним і правильним.

SPF: один запис, мінімально необхідні відправники, явна політика

Приклад: ви надсилаєте через транзакційного провайдера плюс Microsoft 365. Ви не надсилаєте напряму з веб‑сервера.

cr0x@server:~$ cat spf-example.txt
example.com. 300 IN TXT "v=spf1 include:spf.protection.outlook.com include:send.mailprovider.net -all"

Що це означає: лише включені системи можуть надсилати; усе інше жорстко відхиляється (-all).

Рішення: використовуйте ~all тільки під час переходу. Залишати ~all назавжди — як залишати двері офісу незамкненими, бо ключі незручні.

DKIM: опублікуйте ключі, якими користується відправник

Ваш провайдер скаже селектор і TXT‑значення. Опублікуйте його точно. Не «красиво» обгортайте.

cr0x@server:~$ cat dkim-example.txt
s1._domainkey.example.com. 300 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."

Рішення: періодично обертайте ключі, але не робіть це «для фану» під час маркетингового запуску.

DMARC: почніть з моніторингу, потім вводьте примус

DMARC — це політика. Ставтеся до неї як до політики.

cr0x@server:~$ cat dmarc-monitoring.txt
_dmarc.example.com. 300 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r; fo=1"

Рішення: використайте p=none, доки не дізнаєтесь, хто надсилає від вашого імені. Потім перейдіть на quarantine, потім на reject.

Приклад примусового DMARC

cr0x@server:~$ cat dmarc-enforce.txt
_dmarc.example.com. 300 IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; adkim=s; aspf=r; pct=100"

Значення: суворе DKIM‑вирівнювання, relaxed SPF‑вирівнювання. Це поширений варіант, коли ви сильно покладаєтесь на DKIM‑підписи з точним доменом.

Рішення: суворе вирівнювання — не для демонстрації. Використовуйте його лише коли впевнені, що всі легітимні відправники вирівнюються точно.

Стратегія піддоменів: відокремте транзакційну пошту від людської

Якщо ваш маркетинг, WooCommerce і скидання пароля всі надсилають від example.com, ви поєднали репутації. Іноді це нормально; іноді це повільний інцидент.

Розгляньте відправку транзакційної пошти з mail.example.com або notify.example.com, залишивши людську пошту на example.com. Вам все одно потрібні DMARC і вирівнювання, але ви зменшите радіус ураження.

Моделі відправки WordPress: PHP mail проти SMTP проти API

Варіант A: PHP mail() (за замовчуванням). Дешево. Крихке.

На багатьох хостах mail() передає управління локальному MTA або спільній інфраструктурі, якою ви не керуєте. Заголовок From може бути переписаний. DKIM може бути відсутній. SPF може вказувати на щось інше. Ви отримуєте таку доставлюваність, на яку заслуговуєте, делегуючи ідентичність випадку.

Використовуйте тільки якщо: ваш хост надає автентифіковану, підписану і вирівняну відправку для вашого домену (деякі так роблять; більшість — ні).

Варіант B: Автентифікований SMTP через плагін. За замовчуванням — розумний підхід.

WordPress передає пошту на SMTP‑сервер, яким ви керуєте або орендуєте. Цей SMTP‑сервер підписує DKIM і керує bounce‑ами. Ви налаштовуєте SPF/DMARC для домену. Всім стає спокійніше.

Ключові рішення:

• Використовуйте порт 587 з STARTTLS (або 465 implicit TLS) згідно з вказівками провайдера.
• Використовуйте обліковий запис, присвячений сайту, а не чиїсь особисті пошти.
• Переконайтеся, що провайдер може підписувати DKIM вашим доменом (не своїм).

Варіант C: Email API (HTTP) до транзакційного провайдера. Дуже надійно, менше «SMTP‑драми».

Це уникає блокувань SMTP‑мережі і проблем з обліковими даними. Провайдер все ще надсилає пошту, але ваш застосунок спілкується через HTTPS.

Операційно: відмінно. Щодо доставлюваності: все одно потрібні SPF/DKIM/DMARC‑вирівнювання. API не обходить фізику.

Жарт #2: Надсилати пошту без DKIM у 2025 — як розгортати без бекапів: технічно можливо, душевно тривожно.

Три корпоративні міні‑історії з траншей доставлюваності

Міні‑історія 1: Інцидент через неправильне припущення

Вони мігрували WordPress з керованого хостингу до блискучого нового кластера Kubernetes. Додаток працював. Оформлення замовлення працювало. Скидання пароля працювало в стейджингу. Хоча виробництво запустили в четвер після обіду — традиція велить.

Потім почалися тікети підтримки: ніхто не отримував підтвердження замовлень. Не «йшло в спам». Просто не доходило. Маркетинг відправив розсилку зі своєї платформи — та досягла входу. Це був перший підказ: лише транзакційна пошта із WordPress падала.

Неправильне припущення було просте: «Наш домен має SPF та DMARC, отже автентифікація в порядку.» Ні. Їхній SPF авторизував Microsoft 365 і маркетинговий інструмент. Новий шлях відправки — Postfix pod, що виходив через NAT IP, якого не було в SPF. DKIM не було налаштовано, бо старий хост тихо підписував листи від їх імені.

Отримувачі зробили свою роботу: SPF не пройшов, DKIM відсутній, DMARC не пройшов, політика домену — quarantine. Деякі провайдери відправили в спам; інші відхилили залежно від локальної політики і репутації.

Виправлення теж було простим, але не миттєвим: вони припинили прямі відправлення і перенаправили транзакційну пошту через транзакційного провайдера з DKIM для їх домену, потім оновили SPF, щоб включити його. Лише коли DMARC‑звіти показали чисте вирівнювання, вони посилили політику. Урок: «У нас є DMARC» не означає «цей новий відправник авторизований». Це означає «цей новий відправник буде покараний, якщо ні».

Міні‑історія 2: Оптимізація, що дала відкат

Компанія вирішила «зменшити DNS‑запити», агресивно сплескуючи SPF і видаляючи include. На папері мета правильна: ліміт SPF у 10 запитів реальний, а include може стати ланцюгом залежностей, якими ви не керуєте.

Провал стався через процес, не принцип. Вони сплескали SPF, взявши знімок поточних IP провайдера, потім видалили include, який би відстежував зміни автоматично. Швидше. Хоробро. Але застигаюче в часі.

Через тижні провайдер додав інфраструктуру і почав доставляти з IP, яких не було в зафіксованому SPF. Деякі отримувачі трактували SPF‑fail як сильний негатив, а DKIM був час від часу вимкнений під час оновлень на боці провайдера. Результат виглядав як «випадкові проблеми з доставкою», що найгірше — бо посилає команди шукати магію там, де її немає.

Вони повернули include для провайдерів, що часто змінюються, а сплескували лише ті частини, які контролювали. Додали щотижневу перевірку DMARC‑агрегатів на незнайомі джерела. Урок: жорстке підсилення без механізму оновлення перетворює вашу «закалку» на часову бомбу.

Міні‑історія 3: Нудна, але правильна практика, що врятувала день

Інша організація мала дурну, але правильну звичку: кожного разу, коли новий SaaS хотів надсилати від їх домену, це проходило короткий огляд. Перевіряли From‑домен, чи підтримує вендор custom DKIM, який буде return‑path, і чи пройде DMARC‑вирівнювання.

Команда продукту запустила новий плагін форми WordPress, інтегрований з хелпдеском. Поведінка вендора за замовчуванням була надсилати як noreply@vendor.example з reply‑to адресою клієнта — нормально. Але команда хотіла брендований вигляд: support@theircompany.com. Тут DMARC вбиває мрії.

Оскільки огляд існував, вони виявили проблему до релізу: вендор не міг вирівняти DKIM під домен компанії без налаштування custom sending domain і публікації DKIM‑записів. Без цього DMARC під p=reject політикою просто відкидав би листи.

Вони зробили нудну річ: створили піддомен support-mail.theircompany.com, опублікували DKIM, додали мінімальний SPF include і встановили окрему DMARC‑політику для цього піддомену. День запуску настав. Листи дійшли. Ніхто не помітив. Це найкращий результат, який операції можуть отримати.

Поширені помилки: симптом → корінна причина → виправлення

1) «SPF проходить, але DMARC не проходить»

Симптом: Authentication‑Results показує spf=pass і dmarc=fail.

Корінна причина: SPF пройшов для домену конверта, але домен конверта не вирівнюється з видимим From.

Виправлення: використайте кастомний return‑path/bounce‑домен, що вирівнюється з вашим From, або покладіться на DKIM, вирівняний з вашим From (custom DKIM).

2) «DKIM не проходить лише для деяких отримувачів»

Симптом: У деяких провайдерів DKIM проходить, у інших — ні; або невдачі почалися після додавання розсилки/форвардингу.

Корінна причина: проміжний учасник змінює тіло повідомлення або заголовки, які покриває DKIM, і це ламає підпис.

Виправлення: підписуйте з relaxed canonicalization (налаштування провайдера), уникайте систем, що переписують тіла, або покладіться на SPF+вирівнювання там, де це доречно. Для розсилок ARC може допомогти, але не універсально.

3) «SPF permerror»

Симптом: Заголовки показують spf=permerror або отримувачі трактують SPF як невдалий, незважаючи на правильний IP.

Корінна причина: опубліковано кілька SPF‑записів або SPF перевищує ліміт DNS‑запитів.

Виправлення: об’єднайте в один SPF‑запис; згладьте або обріжте include; видаліть застарілі сервіси.

4) «Усе автентифікується, але Gmail все одно кладе в спам»

Симптом: SPF/DKIM/DMARC проходять, але потрапляння в папку «Вхідні» погане.

Корінна причина: проблеми з репутацією/вмістом: різкі стрибки обсягу, низька взаємодія, спамні шаблони, погана гігієна списків або репутація IP.

Виправлення: сегментуйте транзакційну і маркетингову пошту, прогрівайте обсяги, зменшуйте рівень скарг і забезпечуйте послідовні патерни відправлення. Автентифікація — квиток на вхід, але не весь концерт.

5) «From WordPress має @yourdomain, але відправка через shared host»

Симптом: Повідомлення показують ваш домен у From, але Return‑Path — домен хоста; DMARC не проходить або йде у карантин.

Корінна причина: спільний хост переписує envelope sender; у вас немає вирівняної автентифікації для вашого домену.

Виправлення: використовуйте SMTP/API з вашим власним sending domain і DKIM; припиніть покладатися на спільну вихідну пошту.

6) «Після ввімкнення p=reject деяка легітимна пошта зникає»

Симптом: користувачі перестають отримувати певні автоматизовані листи (CRM, тикетинг, старі принтери, випадкові SaaS).

Корінна причина: ці відправники не були вирівняні; DMARC‑примус зробив саме те, що ви попросили.

Виправлення: інвентаризуйте відправників через DMARC‑звіти, потім або переведіть їх на вирівняну відправку (переважно), або змініть їхній From на піддомен під вашим контролем з правильною автентифікацією.

7) «Відповіді з контактної форми йдуть не туди або не доходять»

Симптом: ви ставите From як адресу відвідувача, щоб «відповідь» йшла їм; тепер DMARC не проходить.

Корінна причина: ви імітуєте домен відправника у From; отримувачі це виявляють.

Виправлення: залишайте From як свій домен; ставте submitter у Reply‑To. Це не обговорюється для DMARC.

8) «Microsoft 365 працює, а квитанції WooCommerce — ні»

Симптом: людська пошта в порядку; транзакційна пошта WordPress має проблеми.

Корінна причина: ви аутентифікували одну екосистему відправників, а іншу — ні. SPF включає 365, але WordPress надсилає через IP сервера або іншого провайдера.

Виправлення: прокладіть WordPress‑пошту через ту саму вирівняну систему (SMTP Microsoft 365 з правильним auth, або транзакційний провайдер) і оновіть SPF/DKIM відповідно.

Чек‑листи / покроковий план

Покроково: як вивести транзакційну пошту WordPress з папки спам надійно

1. Виберіть шлях відправки, який ви можете контролювати. Віддавайте перевагу транзакційному провайдеру або автентифікованому SMTP. Уникайте direct‑to‑MX з випадкового веб‑сервера.
2. Визначте стратегію From‑домену. Розвʼяжіть, чи надсилати з example.com або піддомену на кшталт mail.example.com.
3. Налаштуйте WordPress на використання SMTP/API. Підтвердіть це логами (server mail logs, provider logs або заголовками повідомлень).
4. Опублікуйте DKIM для цього відправника. Переконайтеся, що DKIM підписує як ваш домен (а не домен провайдера). Підтвердіть селектор у DNS.
5. Опублікуйте рівно один SPF‑запис. Включайте лише легітимних відправників для цього домену/піддомену. Тримайте підрахунок запитів розумним.
6. Спочатку публікуйте DMARC у режимі моніторингу (якщо ви новачок). Використайте p=none, збирайте звіти, ідентифікуйте невідомих відправників.
7. Виправте проблеми вирівнювання, виявлені у звітах. Переведіть відправників на вирівняний DKIM і/або вирівняні return‑path домени.
8. Запровадьте DMARC поступово. Перейдіть на p=quarantine, потім на p=reject. Не робіть «reject» у пʼятницю ввечері.
9. Розділіть маркетинг і транзакції. Використовуйте різні піддомени за потреби; навмисно різні репутації.
10. Перевіряйте з реальними отримувачами і реальними заголовками. Не довіряйте повідомленням плагінів «тест пройшов». Зазвичай це означає «SMTP прийнято», а не «доставлено в inbox».

Операційний чек‑лист: як запобігти регресії

• Коли додаєте новий SaaS, що надсилає пошту, включіть його в інвентар відправників і перевірте вирівнювання до запуску.
• Щомісяця: перевіряйте, щоб SPF не перетворився на гранату з 10 DNS‑запитів.
• Щокварталу: ротуйте DKIM‑ключі, якщо провайдер це підтримує, і впевніться, що старі селектори безпечно виведені з експлуатації.
• Після міграцій: перевіряйте, що шлях відправки не змінився (новий IP, новий relay, новий провайдер за замовчуванням).
• Слідкуйте за поштовою скринькою для DMARC‑звітів. Розглядайте їх як телеметрію, а не як спам.

FAQ (питання, які ваше майбутнє «я» поставить о 2:00)

1) Чи потрібні мені SPF, DKIM і DMARC, чи вистачить одного?

Використовуйте всі три. SPF сам по собі легко обійти і не захищає видимий заголовок From. DKIM сам по собі може ламатися через проміжні системи. DMARC пов’язує їх і дає звіти.

2) Чому листи працювали раніше, а тепер йдуть у спам?

Бо політики поштових провайдерів посилилися, змінився IP відправника, змінився патерн відправлення або ви додали нового відправника без оновлення SPF/DKIM. «Раптові» проблеми з доставкою зазвичай — відкладена реакція на дрейф конфігурації.

3) Яка найбезпечніша DMARC‑політика для початку?

p=none з агрегованими звітами, потім виправте невідомих відправників. Коли все чисто, переходьте на quarantine, потім на reject. Стрибати відразу до reject без видимості — шлях до втрати важливої пошти.

4) Що означає «вирівнювання» простими словами?

Домен, який бачать користувачі в заголовку From, має співпадати (або бути організаційно повʼязаним) з доменом, що підтверджується через SPF і/або DKIM. Саме це DMARC і примушує виконувати.

5) Чи повинна контактна форма WordPress ставити From як email відвідувача?

Ні. Це викликає DMARC‑невдачу для відвідувачів, чиї домени застосовують DMARC (а таких стає більше). Тримайте From як ваш домен; ставте submitter у Reply‑To.

6) Чи можу я надсилати WordPress‑пошту через Microsoft 365 SMTP і на цьому зупинитися?

Так, якщо зробите це правильно: автентифікована передача, правильний From‑домен і DKIM/DMARC для цього домену. Будьте уважні до лімітів і облікових даних застосунків; не використовуйте чиїсь особисті акаунти.

7) Чому я бачу «SPF neutral» або «softfail»?

Зазвичай це означає, що ваш SPF закінчується ?all (neutral) або ~all (softfail). Це може бути прийнятно під час переходу, але це слабша політика і може знизити довіру. Підтягніть до -all, коли будете готові.

8) Як дізнатися, чи провайдер підписує DKIM моїм доменом?

Подивіться заголовок отриманого повідомлення: знайдіть DKIM-Signature і прочитайте значення d=. Це має бути ваш домен (або вибраний піддомен). Якщо там домен провайдера — ви не вирівняні, хіба що ваш From співпадає з доменом провайдера (а так не повинно бути).

9) У чому різниця між Header From і Return‑Path і чому це важливо?

Header From — те, що бачать люди. Return‑Path — куди йдуть bounce‑и і що перевіряє SPF. Невирівнювання між ними — класична DMARC‑ситуація невдачі.

10) Чи гарантує виправлення SPF/DKIM/DMARC потрапляння в папку «Вхідні»?

Ні. Це прибере базові проблеми ідентичності, що є обовʼязковою умовою. Потрапляння в inbox також залежить від репутації, вмісту, взаємодії, рівня скарг і послідовності відправок.

Висновок: практичні наступні кроки

Якщо пошта WordPress потрапляє в спам, не продовжуйте підганяти теми листів, ніби підкуповуєте спам‑фільтр. Виправте ідентичність відправника.

1. Визначте, як будете надсилати: SMTP/API через надійного провайдера, а не рулетка PHP mail.
2. Зробіть автентифікацію вирівняною: SPF авторизує реального відправника; DKIM підписує як ваш домен; DMARC примушує вирівнювання.
3. Перевірте доказами: заголовки, DNS‑запити та логи пошти. Не скріншоти плагінів.
4. Впроваджуйте навмисно: DMARC p=none → quarantine → reject, підкріплено реальними звітами і інвентарем відправників.

Зробіть це один раз, зробіть правильно — і ваші листи для скидання паролів перестануть робити піший маршрут через папку спам.