Модул 7 · 7.1

Български

Nederlands English Deutsch Français Español Italiano Polski Română Čeština Ελληνικά Magyar Slovenčina Български

Бюлетини от Вашия собствен домейн

Модул 7: Бюлетини и поща от Вашия уебсайт · Време за четене: 11 минути

Учебна цел: След този урок ще можете да свържете услуга за изпращане така, че Вашият бюлетин да преминава от името на Вашия собствен домейн през SPF, DKIM и DMARC, и ще можете да проверите в копрегелите дали това е успяло.

Основни понятия: услуга за изпращане, From домейн, Return-Path (bounce домейн), DKIM домейн (d=), подравняване (alignment), собствен bounce домейн чрез CNAME, DKIM чрез CNAME, поддомейн за маркетинг, лимит за изпращане, загряване (warm-up)

Защо бюлетинът е нещо различно от обикновената поща

Писмо до клиент или колега изпращате от собствената си пощенска кутия. Бюлетинът отива до стотици или хиляди хора едновременно. За получатели като Gmail, Outlook.com и T-Online това е различен вид трафик: bulkmail (масова поща). Те го проверяват по-строго, защото почти целият спам също е bulkmail.

Три неща правят разликата между бюлетин, който попада във входящата поща, и такъв, който изчезва в спама:

Техника: писмото трябва доказуемо да идва от Вашия домейн. Това уреждат SPF, DKIM и DMARC, и най-вече подравняването между тях.
Репутация: сървърите и домейнът, с които изпращате, трябва да имат добро име (урок 5.2).
Поведение на Вашите получатели: отварят ли писмото Ви, или натискат "Това е спам"? Това зависи от Вашия списък и от съгласието (урок 7.2).

Този урок е за първата точка. Основите на записите са описани в DNS курса, урок 7.4. Тук разглеждаме как на практика проверявате дали всичко е наред.

Защо не просто през собствената пощенска кутия?

Може да изглежда примамливо да изпратите бюлетин с BCC от обикновената си пощенска програма, или с пощенски списък (mailing list) на Вашия хостинг пакет. За малко сдружение с тридесет члена, които се познават, пощенски списък е напълно подходящ. За истински бюлетин не е, по четири причини:

Лимити за изпращане. Почти всеки доставчик ограничава колко поща може да изпрати пощенска кутия или пакет на ден, за да ограничи злоупотребите. При WebOké виждате този лимит в DirectAdmin при статистиките на потребителя; при други доставчици е посочен в условията или в клиентския панел. Бюлетин до 2000 души далеч надвишава това.
Споделена репутация. Споделяте изпращащия сървър с други клиенти. Ако получателите се оплакват от Вашия бюлетин, това засяга и тяхната поща, и обратно.
Няма бутон за отписване и няма управление на bounce съобщенията. Услугата за изпращане автоматично поставя копрегелите за отписване във всяко писмо (урок 7.2), премахва адресите, които вече не съществуват, от Вашия списък и обработва оплакванията. Това никога не можете да направите ръчно както трябва.
Поверителност. Един грешен клик и изпращате адресите на всички във всички в полето Към.

Услуга за изпращане (услуга за бюлетини като Laposta, Brevo, MailerLite или Mailchimp, или транзакционна услуга за потвърждения и фактури) е създадена точно за тази работа. Но тогава друг изпраща от името на Вашия домейн, и това трябва да го докажете.

Три домейна в едно писмо

Всяко писмо има поне три места, където е посочен домейн. При обикновена поща от собствената Ви пощенска кутия те обикновено съвпадат. При услуга за изпращане не съвпадат автоматично.

Място	Къде го виждате	Кой го проверява
From (видим подател)	`From: Nieuws <nieuws@example.com>`	DMARC проверява този домейн
Return-Path (envelope подател, bounce адрес)	`Return-Path: <bounce-8f3a@mail.sender.example>`	SPF проверява този домейн
DKIM домейн	`DKIM-Signature: ... d=sender.example; s=s1; ...`	DKIM проверява подписа на този домейн

DMARC (урок 4.4) одобрява писмо, ако SPF или DKIM премине успешно, и домейнът, който е преминал успешно, е подравнен с From домейна. Подравнен означава при настройките по подразбиране (relaxed), че е същият организационен домейн: mail.example.com е подравнен с example.com, но sender.example не е.

Без собствени настройки бюлетинът изглежда така:

Return-Path: <bounce-8f3a@mail.sender.example>
From: Nieuws <nieuws@example.com>
DKIM-Signature: v=1; a=rsa-sha256; d=sender.example; s=s1; ...
Authentication-Results: mx.example.net;
       spf=pass smtp.mailfrom=mail.sender.example;
       dkim=pass header.d=sender.example;
       dmarc=fail header.from=example.com

SPF преминава успешно и DKIM преминава успешно, но и двете за домейна на услугата. Нито едно от двете не е подравнено с example.com, затова DMARC се проваля (fail). Ако Вашата DMARC политика е p=none, ще забележите това само в отчетите си (урок 4.5). Ако е quarantine или reject, Вашият бюлетин изчезва в спама или бива отхвърлен.

Решението: удостоверяване на домейна при услугата

Всяка сериозна услуга за изпращане има стъпка, която се нарича "удостоверяване на домейн" (domain authentication), "верифициране на домейн" или "настройка на домейн на подателя". Услугата Ви дава тогава няколко записа, които трябва да въведете в своя DNS. Обикновено това са:

DKIM чрез CNAME, например s1._domainkey.example.com към име при услугата. След това услугата подписва писмата Ви с d=example.com. Това е най-важният запис: с него DMARC преминава успешно чрез DKIM.
Собствен bounce домейн, често CNAME на поддомейн, например bounce.example.com към услугата. Тогава Return-Path става ...@bounce.example.com. SPF на този поддомейн сочи чрез CNAME към услугата, и тогава SPF също е подравнен. Не всяка услуга предлага това; само DKIM е достатъчен за DMARC.
Понякога SPF include в собствения Ви запис, ако услугата използва главния Ви домейн като Return-Path. Правете това само ако услугата го изисква, и винаги в съществуващия си SPF запис (урок 4.2).
Понякога верификационен TXT запис, за да докажете, че домейнът е Ваш.

След правилните настройки същият бюлетин изглежда така:

Return-Path: <bounce-8f3a@bounce.example.com>
From: Nieuws <nieuws@example.com>
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=s1; ...
Authentication-Results: mx.example.net;
       spf=pass smtp.mailfrom=bounce.example.com;
       dkim=pass header.d=example.com;
       dmarc=pass header.from=example.com

Винаги взимайте имената и целите буквално от таблото (dashboard) на Вашата услуга. Те се различават според услугата и понякога според акаунта.

Отделен поддомейн за маркетинг?

Големите изпращачи често използват собствен поддомейн за бюлетини, като nieuws.example.com или info.example.com, с подател nieuwsbrief@nieuws.example.com. Идеята: репутацията на маркетинговата Ви поща е тогава отделена от обикновената Ви поща. Ако кампания се провали, обикновената Ви ежедневна поща с клиенти страда по-малко от това.

За тези, които изпращат бюлетин няколко пъти месечно, това не е необходимо. То прави управлението по-сложно: поддомейнът се нуждае от собствен DKIM, а Вашата DMARC политика за поддомейни (sp=) трябва да отговаря на това. Обмислете го, ако изпращате много или ако освен бюлетини имате и много транзакционна поща (поръчки, пароли). Тях никога не искате да пострадат от неуспешна кампания.

Важно: не поставяйте на поддомейн за изпращане никакъв MX запис към услугата, ако не Ви е нужен, и никога не променяйте MX на главния си домейн заради бюлетин. MX определя къде пристига поща; отговорите на Вашия бюлетин трябва просто да попаднат в собствената Ви пощенска кутия.

Загряване: не започвайте веднага с всичко

Изпращате за първи път с нова услуга или нов домейн, или изведнъж изпращате десет пъти повече от обичайното? Тогава получателите все още не Ви познават. Големите получатели забавят непознати податели (при Microsoft тогава виждате временни откази като 451 4.7.500, урок 6.4). Затова започнете малко: първо с най-активните си читатели, после всеки път с по-голяма част. Това се нарича загряване. При споделена услуга за изпращане услугата върши голяма част от това вместо Вас, но и там се отчита репутацията на Вашия домейн.

На практика: как изглежда в панел

Записите на услугата ги поставяте в DNS администрацията на Вашия домейн. При WebOké това е раздел DNS в Моят WebOké или DNS Administration в DirectAdmin; при други доставчици се нарича DNS управление, управление на зона или DNS записи и работи по подобен начин. Внимавайте за двете класически грешки: домейнното име двойно в името (s1._domainkey.example.com.example.com), и създаване на TXT запис там, където услугата иска CNAME.

Готово? Изпратете тестов бюлетин до собствен Gmail или Outlook.com адрес и отворете копрегелите (урок 1.5). Искате да видите при Authentication-Results: dkim=pass с header.d= Вашия домейн, и dmarc=pass.

Обобщение

Бюлетинът е bulkmail: получателите проверяват по-строго. Използвайте услуга за изпращане, не обикновената си пощенска кутия.
Във всяко писмо има три домейна: From (DMARC), Return-Path (SPF) и DKIM домейна d=.
DMARC преминава успешно само ако SPF или DKIM преминат успешно за домейн, който е подравнен с From домейна.
Удостоверете домейна си при услугата: DKIM чрез CNAME е най-важното, собствен bounce домейн е плюс.
Проверете с тестово писмо: dkim=pass header.d=<Вашия домейн> и dmarc=pass. При нова услуга започвайте малко.

Тест

Задача

Задача Z7.1: Проверка на подравняването на бюлетин. Изпратете бюлетин от собствената си услуга за изпращане до себе си (или използвайте примерния файл nieuwsbrief-kopregels-1.txt от курса) и поставете копрегелите. Попълнете: From домейна, Return-Path домейна, DKIM домейна (d=) и дали според Вас DMARC преминава успешно (да/не) и по какъв начин (SPF, DKIM, и двата, или нито един). Програмата сама анализира копрегелите, проверява DKIM селектора на живо в DNS и DMARC записа на From домейна, и поставя своя резултат до Вашия.

Задача Z7.1: Проверка на подравняването на бюлетин

Файл към тази задача: nieuwsbrief-kopregels-1.txt, nieuwsbrief-kopregels-2.txt, kopregels-1.txt

Поставете копрегелите на бюлетин, който Вие сами изпращате, или изберете примерен файл. Сървърът анализира копрегелите сам (само в паметта) и при истински копрегели търси DKIM ключа и DMARC записа.

Кои копрегели?

Поставени копрегели (незадължително)

Домейн на From

Домейн на Return-Path

DKIM домейн (d=)

Минава ли DMARC?

По кой път?

Това, което въвеждате, и резултатите от проверката не се съхраняват. Браузърът Ви запомня отговорите и дали сте изпълнили задачата. Ако сте влезли, запазваме само дали задачата е била (почти) правилна в Моите курсове; и там можете да го изтриете.

Допълнително четене

Стъпките в тези статии важат за панелите на WebOké; при други доставчици работи по подобен начин.

Бисквитки в WebOké

Настройки за бисквитки

Необходими

Маркетинг