Deliverability 101 – 1. část

Deliverability vs. Delivery

Nejprve si ujasněme rozdíl mezi pojmy delivery a deliverability.

Delivery (doručení)
Základní technický proces odeslání e‑mailu ze serveru odesílatele na server příjemce.

Deliverability (doručitelnost)
Detailnější pohled na to, kam se e‑mail na straně příjemce skutečně doručí – zda do spamu, do konkrétní složky v inboxu apod. – za předpokladu, že nebyl zahozen (blackholed) ani vrácen jako nedoručitelný (bounce).

Doručitelnost ovlivňuje řada faktorů – například reputace domény, autentifikace, způsob sběru kontaktů a správa databáze, frekvence rozesílek, obsah kampaní, předmět zprávy a mnoho dalších prvků. Proto se doručitelnost ve většině případů nedá vyřešit jednou jedinou změnou. Klíčová je dlouhodobá a konzistentní práce podle best practices, která v čase zajišťuje stabilní doručitelnost a zdravý engagement odběratelů.

Reputace domény a autentifikace

V posledních letech má reputace domény ještě větší vliv na celkovou doručitelnost než dříve, a proto je nesmírně důležité, aby byla v pořádku. Proto je jednou z prvních věcí, které byste měli udělat, když se poprvé pouštíte do e‑mailového marketingu, ujistit se, že branding vaší soukromé domény je v souladu s tím, co je na vašem webu, v reklamách a na sociálních platformách.

V říjnu 2023 navíc Google a Yahoo oznámily nové požadavky na autentifikaci pro všechny odesílatele, kteří posílají více než 5 000 e‑mailů denně. Další velcí poskytovatelé jejich přístup rychle následovali a poskytovatelé e‑mailových služeb (ESP) museli do dubna 2024 splnit nové podmínky. Mailkit se této změny nemusel obávat – tato nastavení byla již dříve povinná pro odesílání přes Mailkit. Podívejme se proto na to, jaké záznamy jsou vyžadovány a k čemu slouží.

Na své doméně musíte nastavit několik DNS záznamů. U všech záznamů, o kterých zde mluvíme, doporučujeme TTL minimálně 3 600 sekund (1 hodina). Kratší TTL může způsobovat dočasné DNS chyby, zejména u domén Microsoftu. Vyžadované záznamy jsou DKIMy a DMARC. DMARC vyhodnocuje výsledky SPF (které za vás zpracovává Mailkit) a DKIM, proto je vždy nutné nejprve správně nastavit DKIMy a teprve poté implementovat DMARC.

SPF

SPF (Sender Policy Framework) je TXT DNS záznam nastavený na úrovni odesílací domény nebo subdomény, ve kterém definujete seznam schválených zdrojů odesílání – tedy IP adres a serverů, které jsou oprávněny odesílat e‑maily jménem vaší domény.

V Mailkitu existují dvě možnosti nastavení SPF. První je, že neděláte nic a my pro veškerou poštu používáme naše domény. Například Return-Path/Envelope From by vypadala nějak takto: localpart@customer.mkt-synd/mkt-ags/txnmail.com v závislosti na typu odesílané zprávy.

Druhou možností je použití delegace odesílací domén pro subdomény mkt.domain.com a mktxn.domain.com (kde domain.com je vaše doména nebo subdoména), což povede k SPF alignmentu. Jedná se o CNAME záznam s hodnotou dist.mailkit.com. Obě možnosti jsou zcela přijatelné, ale pouze delegace odesílací domén povede SPF alignmentu.

Záznam vždy začíná v=spf1 a končí ~all, -all, ?all nebo +all. Mezi těmito částmi je seznam IP adres nebo serverů, a to pomocí mechanismů jako include, a, mx, ptr, exists (tyto se počítají jako lookup - DNS dotaz), nebo ip4 a ip6 (tyto se jako lookup nepočítají).

Lookup (s výjimkou „a“ a „mx“) se obvykle zapisuje jako název serveru, například spf.mailkit.eu, nikoli jako IP rozsah typu 217.11.236.80/28.

Pro ilustraci uvádíme dva SPF záznamy. První záznam obsahuje 2 lookupy – jeden pro spf.mailkit.eu a jeden pro spf.protection.outlook.com. To znamená, že je potřeba další DNS dotaz pro zjištění IP rozsahů za těmito doménami, proto se jedná o lookup. Druhý záznam obsahuje pouze IP rozsahy, a proto má 0 lookupů:

• v=spf1 include:spf.mailkit.eu include:spf.protection.outlook.com ~all
• v=spf1 ip4:217.11.236.80/28 ip4:185.136.200.0/22 ~all

SPF záznamy mají svá omezení, například pokud jde o povolený počet lookupů a void lookupů.

Pokud je počet lookupů v SPF záznamu vyšší než 10, záznam je považován za neplatný a SPF selže. Pro snížení počtu lookupů používejte skutečné IP rozsahy namísto aliasů.

Pokud počet void lookupů v SPF záznamu překročí 2, kontrola vrátí chybu typu permerror. To v praxi znamená, že ve SPF záznamu nemohou být více než dvě neúspěšná ověření.

Je také důležité vědět, že přeposílání e‑mailu (forwarding) SPF narušuje. Proto je nutné mít na doméně nastavené jak SPF, tak DKIM, aby alespoň jeden z mechanismů prošel a byl v souladu (alignment), což následně umožní úspěšné vyhodnocení DMARC.

DKIM

DKIM (DomainKeys Identified Mail) je autentifikační metoda, která využívá asymetrickou kryptografii (veřejný/soukromý klíč) k ověření identity odesílatele a integrity zprávy, tedy k zajištění toho, že e‑mail nebyl během přenosu změněn. Tento proces zahrnuje vytvoření páru veřejného a soukromého klíče, publikování veřejného klíče tak, aby byl dostupný poskytovatelům schránek (Mailbox Providers – MBP), a uložení soukromého klíče na vašich serverech, kde se používá k podepisování e‑mailů. Pokud používáte Mailkit, je tento proces zajištěn za vás a stačí pouze nastavit DKIM DNS záznamy.

Při nastavování DNS záznamů jsou DKIM záznamy typu TXT (někteří poskytovatelé však mohou používat delegaci pomocí CNAME, v závislosti na konfiguraci – více níže) a nacházejí se v prostoru _domainkey. dané domény. Budete také potřebovat znát selector DKIM záznamu a hodnotu DKIM klíče. Obojí určuje hostingový poskytovatel vaší domény nebo ESP, který používáte pro odesílání e‑mailů. Poznámka: z bezpečnostních důvodů by minimální délka klíče měla být 2 048 bitů.

Pokud používáte poskytovatele, jako je Mailkit, který využívá delegaci pomocí CNAME, konfigurace bude mírně odlišná. Poskytovatelé používají CNAME záznam v podstatě jako alias (který se nemění), který odkazuje na TXT záznam s plným DKIM klíčem (který se může měnit) na jejich serverech.

Například CNAME záznam v Mailkitu může vypadat takto, kde k1-1234 je selector, mailkit.com je doména a k1-1234-5678.dkim.mailkit.eu je hodnota CNAME:

k1-1234._domainkey.mailkit.com    IN CNAME    k1-1234-5678.dkim.mailkit.eu

Pokud byste následně provedli dotaz na hodnotu za k1-1234-5678.dkim.mailkit.eu, uvidíte plný DKIM klíč v TXT záznamu:

k1-1234-5678.dkim.mailkit.eu     IN TXT       “v=DKIM1;k=rsa;p=1M2a3i4L5k....”

Doporučuje se mít více DKIM klíčů, protože to umožňuje rotaci DKIM klíčů. Rotace DKIM klíčů je bezpečnostní opatření používané ESP, které umožňuje změnit DKIM klíč používaný k podepisování odchozích e‑mailů. To je důležité, protože DKIM klíče je nutné z bezpečnostních důvodů pravidelně aktualizovat nebo měnit. Pokud existuje pouze jeden DKIM klíč, mohou během doby, kdy se změny v DNS šíří (propagace), vzniknout problémy s doručitelností.

Jedním z klíčových rozdílů mezi chováním SPF a DKIM při přeposílání je to, že přeposílání e‑mailů může narušit DKIM. To ale záleží také na chování přijímacího a zprostředkujícího serveru..

DMARC

DMARC (Domain-based Messaging, Authentication, and Reporting Conformance) je DNS záznam, který navazuje na SPF a DKIM a poskytovatelům schránek (MBP) signalizuje, jak mají nakládat s e‑maily, které neprojdou kontrolou SPF a DKIM. Poznámka: slovo „měly by“ používáme záměrně – existuje mnoho situací, kdy MBP politiku uvedenou v DMARC záznamu nepoužijí a přepíší ji vlastním rozhodnutím. Mějte to na paměti při čtení charakteristik níže uvedených politik.

DMARC záznam obsahuje více tagů ve formátu klíč–hodnota, ale pouze některé jsou povinné. Jednotlivé páry klíč–hodnota jsou odděleny středníkem (;). Níže je příklad nejjednoduššího DMARC záznamu, který doporučujeme:

v=DMARC1;p=none;rua=mailto:dmarc-rua@mailkit.com,mailto:example@domain.com

Tag v= označuje verzi a má vždy hodnotu DMARC1. Tento tag musí být v záznamu uveden jako první.
Tag p= určuje DMARC politiku a existují tři možné hodnoty:

• p=none: signalizuje straně příjemce, že se s e‑mailem nemá nic stát (nemá být odmítnut ani umístěn do spamu), pokud selže autentifikace. V tomto režimu je hlavním přínosem DMARC reporting, proto je nutné uvést adresu v tagu rua=.
• p=quarantine: signalizuje, že e‑maily z vaší domény, které neprojdou autentifikací, mají být umístěny do složky spam.
• p=reject: e‑maily, které neprojdou autentifikací, mají být okamžitě odmítnuty (vráceny odesílateli).

Pokud je DMARC záznam nakonfigurován s tagem rua=, protistrany (přijímací servery) generují agregované DMARC reporty pro odesílatele, což je pravděpodobně největší přínos DMARC. Tyto reporty poskytují přehled o jednotlivých e‑mailových tocích – například které IP adresy odesílají e‑maily jménem vaší domény a zda procházejí nebo neprocházejí kontrolami SPF, DKIM a DMARC.

Pokud použijete adresu rua= od Mailkitu uvedenou výše, reporty jsou dostupné v aplikaci v sekci Reporty – Doručitelnost. Pokud chcete v tagu rua= použít více adres, musí být odděleny čárkou (,) a před každou musí být uvedeno mailto: (viz příklad výše).

Existují také forenzní reporty využívající tag ruf=, ale tyto reporty nejsou v souladu s GDPR, proto by neměly být v DMARC záznamu používány.

Nenechte se odradit technickou povahou tohoto průvodce. Část 1 je nejvíce technická část celého materiálu. V části 2 se budeme věnovat sběru kontaktů a správě databáze.