Настройване на SPF, DKIM и DMARC за по-добра имейл доставяемост
Изпращате важен имейл – фактура, нулиране на парола, приветствено съобщение – а той тихо попада в папката за спам на получателя. Или изобщо не пристига. Причината обикновено е невидима: домейнът ви никога не е доказал, че съобщението наистина идва от вас.
Точно това правят SPF, DKIM и DMARC.
Настройте ги правилно и получаващите мейл сървъри ще се доверят на съобщенията ви достатъчно, за да ги доставят. Сгрешете един запис и може да счупите имейла – а понякога и целия уебсайт – за домейна си.
Всеки от тези записи се намира във вашия DNS, където една-единствена печатна грешка нанася реални щети.
Как работи имейл удостоверяването: SPF, DKIM и DMARC
Имейл удостоверяването е начинът, по който получаващият мейл сървър проверява дали дадено съобщение наистина идва от домейна, за който се представя. Три записа вършат тази работа в унисон: SPF изброява сървърите, на които е разрешено да изпращат от името на вашия домейн, DKIM прикрепя защитен от подправяне подпис към всяко съобщение, а DMARC казва на получателите какво да правят, когато съобщение не премине някоя от проверките и ви изпраща отчети.
Пропуснете един и веригата отслабва. SPF без DMARC може да бъде заобиколен. DKIM без DMARC няма механизъм за прилагане. Трите са създадени да работят като комплект, а не поотделно.
Предотвратяване на имейл спууфинг
Имейл спууфингът е атака, при която някой подправя подателския ви адрес, така че съобщението да изглежда сякаш идва от вас. SPF и DKIM спират по-голямата част от това. SPF публикува точния списък със сървъри, на които е разрешено да изпращат от името на вашия домейн, така че съобщение от друго място изглежда подозрително. DKIM подписва всяко съобщение криптографски, така че подправено или променено копие не преминава проверката при пристигане.
Ограничаване на фишинг атаките
Фишинг имейлите имитират доверен подател, за да подмамят хората да предоставят информация, идентификационни данни или пари. DMARC е записът, който ви позволява да се защитите в голям мащаб. Като зададете DMARC политика, казвате на получаващите сървъри да поставят под карантина или да отхвърлят пощата, която не премине SPF и DKIM, преди да стигне до входящата кутия. DMARC също ви изпраща отчети, така че да видите кой злоупотребява с домейна ви и да затегнете настройките си.
Изграждане на доверие у получателите
Потвърдената самоличност на подателя е тихият двигател зад доставяемостта и доверието в бранда. Хората отварят, кликват и отговарят по-охотно, когато едно съобщение доказано идва от този, за когото се представя. Това има още по-голямо значение за марките, които разчитат на имейл маркетинг и комуникация с клиенти.
ВАЖНО: SPF, DKIM и DMARC повишават доверието и намаляват риска от отхвърляне/спам, но не гарантират попадане във входящата кутия. Google казва, че удостоверените съобщения е “по-малко вероятно” да бъдат отхвърлени или маркирани като спам, а не че гарантирано ще стигнат до входящата кутия.
Sender Policy Framework (SPF) – обяснение
Sender Policy Framework (SPF) е DNS запис, който изброява пощенските сървъри и IP адресите, на които е разрешено да изпращат имейли от името на вашия домейн. Публикувате SPF запис в DNS на вашия домейн. Когато съобщението ви пристигне, получаващият сървър прочита този запис и проверява дали изпращащият сървър е във вашия одобрен списък. Съвпадение преминава SPF проверката; всичко друго изглежда неоторизирано.
Представете си, че служител изпраща имейл до доставчик. Пощенският сървър на доставчика прочита вашия SPF запис, потвърждава, че изпращащият сървър е оторизиран, и третира съобщението като легитимно. Всеки, който се опита да изпраща от вашия домейн чрез невключен в списъка сървър, бива маркиран или отхвърлен.
Как изглежда една SPF проверка
SPF проверката протича в три стъпки:
- Публикувате записа. Вашият SPF запис изброява всеки IP адрес и хост име, на който е разрешено да изпраща поща от името на вашия домейн.
- Сървърът на получателя го прочита. Когато имейлът ви пристигне, получаващият сървър изтегля вашия SPF запис от DNS и търси изпращащия сървър.
- Сървърът действа според резултата. Преминаването придвижва съобщението нататък по веригата. Провал може да означава попадане в спам папката, карантина или направо отхвърляне.
Как да публикувате SPF запис във вашия DNS
Публикуването на SPF запис отнема няколко минути в кой да е DNS редактор:
- Отворете DNS настройките си. Влезте при вашия хостинг или DNS доставчик и намерете DNS управлението за вашия домейн.
- Добавете нов TXT запис. SPF данните се съхраняват в TXT запис.
- Въведете SPF стойността. Тя започва с v=spf1, следвано от сървърите, на които е разрешено да изпращат. Например: v=spf1 ip4:192.0.2.1 include:mail.example.com -all разрешава този IP и пощенски сървър и казва на получателите да отхвърлят всичко останало.
- Запазете и проверете. Публикувайте записа, след което го потвърдете с инструмент за проверка на SPF. Промените в DNS може да отнемат време, за да се разпространят.
Започнете с така наречения soft fail (~all), докато тествате, след което преминете към hard fail (-all), след като сте сигурни, че всеки легитимен подател е включен в списъка.
DomainKeys Identified Mail (DKIM) – обяснение
DMARC свързва SPF и DKIM с видимия From домейн. Едно съобщение преминава DMARC, когато SPF или DKIM преминат и удостовереният домейн съвпада с домейна, който получателят вижда в полето From. Ако нито една от съгласуваните проверки не премине, получаващият сървър следва вашата DMARC политика: наблюдение, карантина или отхвърляне. Тя се основава на няколко идеи:
- Двойка ключове. Вашият изпращащ сървър държи частен ключ и публикува съответстващия публичен ключ във вашия DNS.
- Подпис върху всяко съобщение. Сървърът подписва всяко изходящо съобщение с частния ключ.
- Проверка при пристигане. Получателят изтегля вашия публичен ключ от DNS и проверява подписа. Съвпадение доказва, че съобщението е непокътнато и наистина идва от вашия домейн.
Как DKIM подписва вашите имейли
Ето процеса на подписване от началото до края:
- Генериране на ключовете. Вашият пощенски сървър създава двойка от частен и публичен ключ и публикува публичния ключ в DNS.
- Хеширане на съобщението. Сървърът създава уникален отпечатък на тялото на съобщението и избрани заглавки.
- Подписване на хеша. Частният ключ подписва този отпечатък, създавайки заглавка DKIM-Signature, която пътува заедно със съобщението.
- Проверка от другата страна. Получаващият сървър прочита селектора в подписа, изтегля съответстващия публичен ключ и повторно проверява отпечатъка. Ако двата съвпадат, съобщението преминава.
Domain-based Message Authentication, Reporting, and Conformance (DMARC) – обяснение
DMARC (Domain-based Message Authentication, Reporting, and Conformance) свързва SPF и DKIM: казва на получаващите сървъри какво да правят с пощата, която не премине – да я доставят, да я поставят под карантина или да я отхвърлят – и ви изпраща по имейл отчети за случващото се. Добавя три неща върху SPF и DKIM:
- Политика. Избирате как получателите да третират пощата, която не преминава: none, quarantine или reject.
- Съгласуване. DMARC проверява дали домейнът във видимия “From” адрес съвпада с домейните, потвърдени от SPF и DKIM.
- Отчитане. Получавате обобщени отчети, показващи кой изпраща от името на вашия домейн и дали преминава проверките.
Това вече не е незадължителна формалност. Google и Yahoo изискват SPF, DKIM и DMARC политика от масовите податели от февруари 2024 г. насам, а други доставчици затягат изискванията в същата посока.
Как да конфигурирате DMARC политика
Настройте DMARC по същия начин, по който настройвате SPF – като DNS запис:
- Създайте DMARC TXT запис. Добавете TXT запис на _dmarc.yourdomain.com.
- Задайте политиката и адреса за отчети. Например: v=DMARC1; p=quarantine; rua=mailto:[email protected] – версия, политика и къде да отиват обобщените отчети.
- Уверете се, че SPF и DKIM са активни. DMARC зависи и от двете, както и от съгласуването с вашия “From” домейн.
- Започнете с none, после затегнете. Започнете в режим на наблюдение, четете отчетите и преминете към quarantine, а след това reject, след като се уверите, че легитимната ви поща преминава.
Защо една печатна грешка може да счупи вашия DNS (и как да го избегнете)
Всеки запис, който разгледахме, се намира във вашата DNS зона – и повечето DNS редактори правят точно това, което им кажете, включително да запазят повреден запис.
Грешно форматиран TXT запис, SPF запис със случаен символ, CNAME, сочещ към IP адрес вместо към хост име – те невинаги се провалят. Повредена зона може да попречи на DNS сървъра изобщо да я зареди. Когато това се случи, не губите един запис; може да загубите имейла и уебсайта за целия домейн наведнъж.
DNS редактор, който сляпо запазва всичко, което въведете, е на един клавиш разстояние от прекъсване.
Тук панелът, който използвате, има значение.
Повечето контролни панели – включително cPanel – ви дават Zone Editor за добавяне на записи. Разликата, която си струва да вземете предвид, е дали панелът проверява работата ви, преди тя да влезе в сила. SPanel прави точно това. Преди да приложи промяна в зоната, той прекарва базовите BIND зонови файлове през синтактична проверка – същият вид валидация, която използва самият DNS сървър. Ако дадена редакция би повредила зоната, промяната се отхвърля и съществуващата ви работеща зона остава непокътната.
Лесна настройка на SPF, DKIM и DMARC със SPanel
Да – SPanel може да настрои SPF, DKIM и DMARC вместо вас автоматично. Когато DNS зоната на даден домейн се създаде на нашата платформа, трите записа се генерират от изпитани шаблони, така че новият домейн стартира удостоверен. Едно-единствено действие ви дава и трите:
- SPF, изграден около собствения IP на вашия сървър: v=spf1 +a +mx +ip4:your-server-ip -all.
- DKIM, с автоматично генерирана двойка ключове и публичен ключ, публикуван във вашата зона.
- DMARC, зададен с прилагаща политика от самото начало: v=DMARC1; p=reject; sp=none; rf=afrf; pct=100; ri=86400.
Тази настройка по подразбиране клони към строгост – p=reject прилага от първия ден, докато sp=none оставя поддомейните в режим на наблюдение. Ако мигрирате поща или тествате нова услуга за изпращане, можете да върнете политиката към none или quarantine, да следите отчетите и да се върнете към reject, след като всичко е наред.
Тъй като същата платформа валидира зоната, преди да я приложи, тези автоматично генерирани записи се публикуват правилно – без случайни символи, без счупен синтаксис. Получавате удостоверяване, което работи от първия ден, на всеки управляван VPS, без допълнителна такса.
SPanel може да опрости имейл удостоверяването, като създава нужните основни DNS записи за имейл удостоверяване на базата на домейн и като дава на потребителите директен контрол върху DNS записите от същия хостинг интерфейс. За много домейни, хоствани в NS1, това намалява обема на ръчната работа по DNS, нужна за настройката на SPF, DKIM и DMARC. Ако вашият домейн изпраща поща и през платформи на трети страни като Google Workspace, Microsoft 365, Mailchimp, Brevo или CRM, тези податели все пак трябва да бъдат добавени и потвърдени, преди да затегнете вашата DMARC политика.
При управляван VPS от NS1 можете да се възползвате и от dedicated IP (който гарантира, че сте единственият, използващ вашия IP адрес) и мониторинг на IP blacklists (при който следим популярните имейл черни списъци, за да гарантираме, че адресът ви не попада в негативната им статистика).
Естествено, всички потребители на управляван хостинг могат да се възползват и от компетентността на нашия екип за техническа поддръжка. Ако имате въпроси или проблеми с настройката и работата на SPF/DKIM/DMARC – свържете се с нашите оператори и те с удоволствие ще ви помогнат.
ВАЖНО: Много DNS редактори просто позволяват на потребителите да добавят TXT записи ръчно, докато SPanel може да създава записи за удостоверяване за домейни и дава на потребителите контрол върху DNS в рамките на същата хостинг среда.
Ползи от внедряването на SPF, DKIM и DMARC
Заедно трите записа се изплащат по три ясни начина:
| Полза | Какво означава |
|---|---|
| По-добра доставяемост, по-малко попадане в спам | Потвърдените податели са доверени податели. SPF потвърждава изпращащия сървър, а DKIM доказва, че съобщението не е променяно, така че за легитимната поща е далеч по-малко вероятно да бъде маркирана като спам. |
| По-силно доверие и защита на марката | Когато получателите могат да потвърдят, че едно съобщение наистина идва от вашия домейн, марката ви е по-трудна за имитиране, а комуникацията ви носи повече тежест. |
| Реална защита срещу фишинг и спуфинг | DMARC политика на карантина или отхвърляне спира пощата, която не преминава проверките, преди да стигне до входящата кутия, затваряйки вратата пред най-разпространените атаки чрез имитиране. |
Удостоверяването работи най-добре върху репутация на подател, на която можете да се доверите. Изпращането от доставчик с чисти, добре поддържани IP адреси – като хостинга за бизнес имейли на NS1 – означава, че вашите SPF, DKIM и DMARC записи гарантират за поща, която вече идва от добър квартал.
Заключение
Имейл удостоверяването вече не е приятна екстра – SPF, DKIM и DMARC са разликата между поща, която пристига, и поща, която изчезва. Най-рисковата част не са концепциите; това е ръчното редактиране на DNS записите, които ги задвижват. Оставете тази част на платформа, която валидира зоната ви и генерира записите вместо вас, и получавате доставяемостта без опасността.
Често задавани въпроси
В: Кои са най-добрите практики за имейл удостоверяване?
О: Поддържайте записите си актуални, прости и съгласувани. Преглеждайте редовно SPF и DKIM, за да добавяте нови податели и да премахвате стари, поддържайте SPF под лимита от 10 справки и използвайте DKIM ключове с дължина поне 2048 бита. Преминавайте към по-строг DMARC постепенно – от наблюдение към прилагане – и използвайте съгласуване на идентификаторите, така че потвърденият домейн да съвпада с видимия ви “From” адрес.
В: Коя е най-сигурната настройка на SPF, DKIM и DMARC?
О: Сигурната настройка използва SPF, за да изброи всеки одобрен подател, DKIM, за да подписва изходящите съобщения, и DMARC, за да налага съгласуване с видимия From домейн. Започнете DMARC с p=none, докато преглеждате отчетите, преминете към p=quarantine, след като легитимните податели преминават, и използвайте p=reject само когато всички критични за бизнеса източници на поща са удостоверени и съгласувани.
В: Как се четат DMARC отчетите?
О: Започнете с отчетите, които обобщават каква част от пощата ви е преминала или се е провалила и откъде е дошла. Търсете закономерности – особено легитимни източници, които се провалят, което обикновено сочи към липсващ запис в SPF или DKIM. Използвайте този сигнал, за да поправите записите си, преди да затегнете политиката.
В: Какво се случва, ако DNS запис има печатна грешка?
О: Зависи от вашия DNS редактор. Много от тях ще запазят повредения запис както е, а повредена зона може изобщо да спре да се зарежда, “бутайки” със себе си имейла и уебсайта. SPanel избягва това, като валидира зоната, преди да я приложи, така че невалидна промяна се отхвърля и работещата ви зона остава активна.
В: Настройва ли SPanel SPF, DKIM и DMARC автоматично?
О: Да. Когато се създаде зоната на даден домейн, SPanel генерира SPF, DKIM и DMARC записи от шаблони, включително новосъздадена двойка DKIM ключове. Получавате домейн, който е удостоверен от самото начало, без да редактирате ръчно нито един запис.
