SPF, DKIM и DMARC: пълното ръководство за имейл автентикация

Email authentication е основата на надеждна email доставка. Без правилна SPF, DKIM и DMARC конфигурация, твоите внимателно изработени имейли може никога да не достигнат inbox-овете на клиентите ти. Вместо това, те завършват в спам папки или биват отхвърлени изцяло.

Това изчерпателно ръководство обяснява какво прави всеки email authentication протокол, осигурява step-by-step DNS setup инструкции, покрива troubleshooting на често срещани проблеми и ти показва как да верифицираш, че конфигурацията ти работи правилно.

Защо Email Authentication има значение

Email е дизайниран в ера, когато сигурността не е била основна грижа. Оригиналният SMTP протокол няма вграден verification механизъм, за да потвърди, че email наистина идва от този, за когото се представя. Тази фундаментална слабост позволява email spoofing, phishing атаки и спам.

Email authentication протоколите решават този проблем, като позволяват на собствениците на домейни да специфицират:

• Кои сървъри могат да изпращат email от тяхно име (SPF)
• Cryptographic доказателство, че съобщенията са истински и непроменени (DKIM)
• Какво да правят със съобщения, които се провалят на authentication (DMARC)

Бизнес влиянието на лош authentication

Без правилен email authentication:

• По-нисък deliverability: Основни доставчици като Gmail, Microsoft и Yahoo филтрират unauthenticated имейли по-агресивно
• По-високи спам rates: Твоите легитимни имейли се конкурират със spoofed съобщения, използващи домейна ти
• Brand щета: Phishing атаки, имитиращи марката ти, ерозират customer доверие
• Загуба на приходи: Маркетингови кампании не успяват да достигнат абонати, които са се записали да получават
• Compliance рискове: Много регулации сега изискват правилен email authentication

Authentication триадата

SPF, DKIM и DMARC работят заедно като пълна authentication система:

Всеки протокол адресира различни attack vectors. SPF предотвратява unauthorized сървъри от изпращане като теб. DKIM предотвратява message tampering след изпращане. DMARC ги връзва заедно и осигурява видимост на authentication резултатите.

Разбиране на SPF (Sender Policy Framework)

SPF (Sender Policy Framework) е DNS-based email authentication метод, който специфицира кои mail сървъри са оторизирани да изпращат email от името на твоя домейн.

Как работи SPF

Когато email пристига на receiving сървър, този сървър търси SPF записа на sender домейна. После проверява дали IP адресът, който е изпратил имейла, е изброен като оторизиран. Ако IP-то съвпада, SPF минава. Ако не, SPF се проваля.

Процесът на SPF верификация:

1. Изпращаш email от маркетинговата си платформа
2. Receiving сървърът извлича твоя домейн от Return-Path (envelope sender)
3. Сървърът заявява DNS за SPF записа на домейна ти
4. Сравнява sending IP-то спрямо оторизирания списък в SPF записа
5. Сървърът записва pass, fail, softfail или neutral резултат

SPF Record синтаксис

SPF записите се публикуват като TXT записи в DNS на твоя домейн. Ето базовата структура:

v=spf1 [mechanisms] [qualifier]all

Version tag: Винаги започва с v=spf1

Mechanisms: Дефинират кой може да изпраща

Qualifiers: Дефинират как да обработват съвпадения

The all механизъм: Прилага се на всичко, което не съвпада с предишните mechanisms

Примери за SPF записи

Базова настройка с един email доставчик:

v=spf1 include:spf.brevo.com -all

Това оторизира Brevo да изпраща email за домейна ти и отхвърля всички други senders.

Множество email услуги:

v=spf1 include:spf.brevo.com include:_spf.google.com include:spf.protection.outlook.com -all

Това оторизира Brevo, Google Workspace и Microsoft 365.

Включване на собствен mail сървър:

v=spf1 ip4:203.0.113.10 include:spf.brevo.com -all

Това оторизира конкретен IP адрес (твоя сървър) плюс Brevo.

Започване със soft fail при тестване:

v=spf1 include:spf.brevo.com ~all

Използване на ~all вместо -all маркира провали, но не отхвърля. Полезно по време на първоначална настройка.

Настройка на SPF записи

Стъпка 1: Идентифицирай sending източниците си

Изброй всяка услуга, която изпраща email от домейна ти:

• Email маркетингови платформи (Brevo, Mailchimp и т.н.)
• Транзакционни email услуги
• CRM системи
• Help desk софтуер
• Корпоративен email (Google Workspace, Microsoft 365)
• Собствените ти mail сървъри

Стъпка 2: Събери SPF include statements

Всеки email доставчик документира изисквания си SPF include. Често срещани примери:

Стъпка 3: Създай SPF записа си

Комбинирай всички includes в един запис:

v=spf1 include:spf.brevo.com include:_spf.google.com -all

Стъпка 4: Добави DNS записа

В DNS management интерфейса си:

• Type: TXT
• Host/Name: @ (или празно за root домейн)
• Value: Твоят пълен SPF запис
• TTL: 3600 (или default)

Стъпка 5: Верифицирай записа

Използвай DNS lookup инструменти за потвърждение:

dig TXT yourdomain.com

Или използвай онлайн инструменти като MXToolbox SPF Lookup.

SPF ограничения и Best Practices

Лимитът от 10 DNS lookups:

SPF има максимум 10 DNS lookups. Всеки include: се брои като един lookup, а included записи може да съдържат свои includes, броещи към лимита ти. Превишаването на това причинява SPF permerror (permanent error), проваляйки всички проверки.

Стратегии за оставане под лимита:

• Използвай IP адреси директно, когато е възможно (ip4: не се брои като lookup)
• Консолидирай услуги, използващи същия доставчик
• Използвай SPF flattening услуги, които конвертират includes в IP адреси
• Премахни неизползвани includes от стари услуги

Други SPF best practices:

• Само един SPF запис на домейн (множество записи причиняват провали)
• Започни с ~all (softfail) по време на настройка, мини на -all след като се потвърди
• Актуализирай SPF при смяна на email доставчици
• Не използвай deprecated ptr mechanism
• Дръж записите максимално прости

Често срещани SPF грешки

Множество SPF записи:

Грешно:
v=spf1 include:spf.brevo.com -all
v=spf1 include:_spf.google.com -all

Правилно:
v=spf1 include:spf.brevo.com include:_spf.google.com -all

Превишаване на DNS lookup лимита:

Ако имаш много includes, провери общия си lookup count. Използвай SPF analyzers, за да верифицираш, че си под 10.

Забравяне да се актуализира след смяна на доставчици:

Когато преминаваш от една email услуга към друга, премахни стария include и добави новия.

Използване на +all:

Никога не използвай +all, тъй като оторизира всеки да изпраща като твой домейн.

Разбиране на DKIM (DomainKeys Identified Mail)

DKIM (DomainKeys Identified Mail) добавя cryptographic signature към имейлите ти, доказвайки, че съобщението произхожда от домейна ти и не е било модифицирано в transit.

Как работи DKIM

DKIM използва public-key cryptography:

1. Твоят email доставчик генерира public/private key pair
2. Публикуваш публичния ключ в DNS
3. Доставчикът подписва outgoing имейлите с private ключа
4. Receiving сървърите извличат публичния ключ от DNS
5. Те използват публичния ключ, за да верифицират signature-а
6. Валиден signature доказва автентичност и integrity

Какво подписва DKIM:

DKIM signatures обикновено покриват конкретни headers и тялото на съобщението:

• From header (задължително)
• Subject header
• Date header
• Message body
• Други headers според конфигурацията

Това предотвратява атакуващите от модифициране на тези елементи след изпращане.

DKIM Record структура

DKIM записите се публикуват като TXT записи със специфичен naming формат:

selector._domainkey.yourdomain.com

Selector е уникален идентификатор, който ти позволява да имаш множество DKIM keys. Различни email услуги използват различни selectors (напр. brevo, google, s1, s2).

DKIM record съдържание:

v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC...

Настройка на DKIM

Стъпка 1: Генерирай DKIM keys

Твоят email доставчик обикновено генерира keys за теб. В Brevo:

1. Иди на Settings > Senders, Domains & Dedicated IPs
2. Избери домейна си
3. Навигирай до DKIM секцията
4. Копирай предоставения DNS запис

За self-hosted mail сървъри, генерирай keys чрез OpenSSL:

openssl genrsa -out private.key 2048
openssl rsa -in private.key -pubout -out public.key

Стъпка 2: Добави DKIM DNS запис

В DNS management-а си:

• Type: TXT
• Host/Name: selector._domainkey (напр. brevo._domainkey)
• Value: DKIM записът от доставчика ти
• TTL: 3600

Стъпка 3: Активирай DKIM signing

В настройките на email доставчика, активирай DKIM signing за домейна ти. Това казва на доставчика да подписва outgoing съобщения.

Стъпка 4: Верифицирай настройката

Изпрати тестов имейл и провери headers-ите за DKIM-Signature. Използвай инструменти като:

• mail-tester.com
• DKIM Validator
• MXToolbox DKIM Lookup

DKIM Best Practices

Използвай 2048-bit keys:

По-стари 1024-bit keys се считат за слаби. Модерните security стандарти препоръчват минимум 2048-bit RSA keys.

Ротирай keys периодично:

Макар не строго изискано, годишна ротация на DKIM keys е добра security практика. Добави новия ключ преди да премахнеш стария, за да избегнеш gaps.

Мониторирай за key compromise:

Ако private ключът ти е compromised, атакуващите могат да подписват съобщения като теб. Мониторирай за необичайни authentication модели.

Използвай различни selectors за различни услуги:

Всеки email доставчик трябва да използва уникален selector. Това позволява независимо key management и не конфликтира с други услуги.

Провери DNS propagation:

DKIM keys могат да са дълги. Гарантирай, че твоят DNS доставчик поддържа TXT записи с достатъчна дължина. Някои доставчици изискват разделяне на ключа в множество strings.

Четене на DKIM Headers

Когато получиш email, DKIM-Signature header-ът показва:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
  d=example.com; s=brevo;
  h=from:to:subject:date:message-id;
  bh=base64hashofbody;
  b=base64signature;

Разбиране на DMARC (Domain-based Message Authentication, Reporting, and Conformance)

DMARC се изгражда върху SPF и DKIM, за да осигури policy enforcement и reporting. Казва на receiving сървърите какво да правят, когато authentication се провали, и ти изпраща отчети за authentication резултатите.

Как работи DMARC

DMARC добавя две критични възможности:

1. Policy enforcement: Дефинирай как receivers трябва да обработват authentication провали
2. Reporting: Получавай данни за това кой изпраща email, използвайки твоя домейн

DMARC verification процес:

1. Receiving сървър получава email, представящ се за от твоя домейн
2. Проверява SPF (съвпада ли sending IP?)
3. Проверява DKIM (валиден ли е signature-ът?)
4. Проверява DMARC alignment (съвпадат ли authenticated домейните с From header?)
5. Ако alignment се провали, прилага твоята DMARC политика
6. Изпраща ти aggregate и/или forensic отчети

DMARC Alignment

DMARC изисква alignment между домейна в From header и домейните, които минават SPF или DKIM:

SPF Alignment: Домейнът в Return-Path (envelope sender) трябва да съвпада или да е subdomain на From header домейна.

DKIM Alignment: Домейнът в DKIM signature (d= tag) трябва да съвпада или да е subdomain на From header домейна.

Alignment режими:

С relaxed alignment, ако твоят From header показва [email protected] и DKIM подписва с brevo.example.com, alignment минава, защото и двата споделят example.com organizational домейна.

DMARC Record синтаксис

DMARC записите се публикуват като TXT записи на _dmarc.yourdomain.com:

v=DMARC1; p=reject; rua=mailto:[email protected]; pct=100

Задължителни tags:

Опционални tags:

DMARC политики обяснени

p=none (Само мониторинг):

Без действие при провали. Имейлите се доставят нормално. Използвай това, докато анализираш отчетите и поправяш authentication проблеми.

v=DMARC1; p=none; rua=mailto:[email protected]

p=quarantine (Спам папка):

Провалени имейли се изпращат в spam/junk папка. Добра междинна стъпка преди пълно отхвърляне.

v=DMARC1; p=quarantine; rua=mailto:[email protected]; pct=100

p=reject (Блокиране):

Провалените имейли се отхвърлят изцяло. Максимална защита, но гарантирай, че всички легитимни източници минават първо.

v=DMARC1; p=reject; rua=mailto:[email protected]; pct=100

Настройка на DMARC

Стъпка 1: Гарантирай, че SPF и DKIM работят

DMARC зависи от SPF и DKIM. Верифицирай, че и двете са правилно конфигурирани преди добавяне на DMARC.

Стъпка 2: Започни с мониторинг (p=none)

Започни с най-разрешителната политика, за да събереш данни без да повлияеш на доставката:

v=DMARC1; p=none; rua=mailto:[email protected]

Стъпка 3: Добави DNS записа

В DNS management-а си:

• Type: TXT
• Host/Name: _dmarc
• Value: Твоят DMARC запис
• TTL: 3600

Стъпка 4: Анализирай отчети 2-4 седмици

DMARC aggregate отчети пристигат ежедневно като XML файлове. Те показват:

• Кои IPs са изпращали email, използвайки твоя домейн
• SPF и DKIM pass/fail rates
• DMARC alignment резултати
• Действия на receiving сървъра

Използвай DMARC report analyzers за визуализация на тези данни:

• DMARC Analyzer
• Postmark DMARC
• Valimail
• dmarcian

Стъпка 5: Поправи authentication проблеми

Често срещани проблеми, разкривани от отчетите:

• Легитимни услуги, липсващи от SPF
• DKIM не активиран за sending услуга
• Third-party услуги, изпращащи без правилен authentication
• Forwarding, чупещ SPF alignment

Стъпка 6: Постепенно enforce-вай

След като легитимните източници минават последователно:

1. Премини на p=quarantine; pct=10 (карантирай 10% от провалите)
2. Увеличи pct на 25, 50, 75, 100
3. Премини на p=reject; pct=10
4. Увеличи на пълно отхвърляне

Стъпка 7: Поддържай и мониторирай

Продължи да преглеждаш отчетите. Нови sending източници, промени на доставчика или configuration drift могат да причинят authentication провали.

Разбиране на DMARC отчетите

Aggregate отчети (rua):

Ежедневни XML обобщения, показващи:

• Reporting организация
• Период от време
• Твоята публикувана политика
• Authentication резултати по source IP
• Обем на имейли

Пример откъс:

<record>
  <source_ip>203.0.113.10</source_ip>
  <count>1250</count>
  <policy_evaluated>
    <disposition>none</disposition>
    <dkim>pass</dkim>
    <spf>pass</spf>
  </policy_evaluated>
</record>

Forensic отчети (ruf):

Детайли на индивидуални съобщения за провали. По-подробни, но privacy-sensitive. Много receivers не изпращат forensic отчети.

DMARC Best Practices

Винаги започвай с p=none:

Скачане директно на reject може да блокира легитимен email. Мониторирай първо.

Използвай dedicated email адрес за отчети:

DMARC отчетите могат да са обемисти. Използвай dedicated адрес или third-party услуга.

Задай subdomain политика (sp=):

Ако не изпращаш email от subdomains, задай sp=reject, за да ги защитиш от spoofing.

Използвай percentage (pct=) за постепенно разгръщане:

pct tag-ът ти позволява да enforce-неш политика на процент от провалите, докато мониторираш останалото.

Помисли за dedicated DMARC услуги:

За големи организации, услуги като Valimail, dmarcian или Postmark DMARC осигуряват по-добър анализ на отчети, отколкото raw XML файлове.

Настройка на DNS Record: пълен walkthrough

Настройката на email authentication изисква добавяне на конкретни DNS записи. Тази секция осигурява пълен walkthrough за основни DNS доставчици.

Събиране на изискваните стойности

Преди да започнеш, събери тези стойности от твоите email доставчици:

За SPF:

• Всички include statements (напр. include:spf.brevo.com)
• Всякакви конкретни IP адреси, които трябва да оторизираш

За DKIM:

• Името на selector (напр. brevo, google, s1)
• Пълната DKIM key стойност

За DMARC:

• Твоят reporting email адрес

Добавяне на записи в често срещани DNS доставчици

Cloudflare:

1. Логни се в Cloudflare Dashboard
2. Избери домейна си
3. Иди на DNS > Records
4. Кликни Add Record
5. За SPF: Type=TXT, Name=@, Content=твоят SPF запис
6. За DKIM: Type=TXT, Name=selector._domainkey, Content=DKIM key
7. За DMARC: Type=TXT, Name=_dmarc, Content=DMARC запис
8. Кликни Save

Google Domains/Squarespace:

1. Иди на DNS настройки за домейна си
2. Скролни до Custom Records
3. Кликни Manage Custom Records
4. Добави всеки запис с подходящ type, host и data
5. За SPF: Host=@, Type=TXT, Data=SPF запис
6. За DKIM: Host=selector._domainkey, Type=TXT, Data=DKIM key
7. За DMARC: Host=_dmarc, Type=TXT, Data=DMARC запис

GoDaddy:

1. Иди на My Products > Domains
2. Кликни DNS до домейна си
3. Скролни до Records секцията
4. Кликни Add за всеки нов запис
5. Избери TXT за Type
6. Въведи Name (@ за SPF, selector._domainkey за DKIM, _dmarc за DMARC)
7. Въведи Value
8. Save

Namecheap:

1. Иди на Domain List > Manage
2. Кликни Advanced DNS
3. Add New Record за всеки
4. Избери TXT Record
5. Host: @ за SPF, selector._domainkey за DKIM, _dmarc за DMARC
6. Value: Съдържанието на твоя запис
7. Save All Changes

DNS Propagation

След добавяне на записи, промените отнемат време да се propagate-нат глобално. Това обикновено отнема:

• 5-30 минути за първоначална видимост
• До 48 часа за пълна глобална propagation

Използвай dig или nslookup за верификация:

dig TXT yourdomain.com
dig TXT selector._domainkey.yourdomain.com
dig TXT _dmarc.yourdomain.com

Или използвай онлайн инструменти като whatsmydns.net, за да провериш propagation в целия свят.

Пример за пълна настройка

За домейн, използващ Brevo и Google Workspace:

SPF запис (TXT на @):

v=spf1 include:spf.brevo.com include:_spf.google.com -all

DKIM запис за Brevo (TXT на brevo._domainkey):

v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBA... [key from Brevo dashboard]

DKIM запис за Google (TXT на google._domainkey):

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BA... [key from Google Admin]

DMARC запис (TXT на _dmarc):

v=DMARC1; p=none; rua=mailto:[email protected]

Troubleshooting на често срещани проблеми

Дори с внимателна настройка, email authentication може да се провали. Ето често срещани проблеми и как да ги решиш.

SPF Troubleshooting

SPF запис не намерен:

Симптоми: SPF проверки показват “none” или “no record”

Причини:

• Запис не добавен към DNS
• Запис добавен на грешна локация (subdomain вместо root)
• DNS propagation не завършена

Решения:

• Верифицирай, че записът съществува с dig TXT yourdomain.com
• Провери Name/Host полето (трябва да е @ или празно за root домейн)
• Изчакай DNS propagation (до 48 часа)

SPF PermError (твърде много lookups):

Симптоми: SPF резултати показват “permerror”

Причини:

• Повече от 10 DNS lookups в SPF записа ти
• Includes, съдържащи прекомерни nested includes

Решения:

• Одитирай includes-ите си и премахни неизползваните
• Замени includes с ip4: entries, където е възможно
• Използвай SPF flattening услуги
• Консолидирай услугите на по-малко доставчици

SPF SoftFail или Fail за легитимна поща:

Симптоми: Легитимни имейли провалящи SPF

Причини:

• Sending услугата не е включена в SPF
• Изпращане от IP, който не е оторизиран
• Използване на relay, който променя envelope sender

Решения:

• Добави липсващия include за sending услугата
• Провери кой IP действително е изпратил имейла (от headers)
• Свържи се с email доставчика за правилни SPF настройки

Множество SPF записи:

Симптоми: SPF показва permerror или случайни провали

Причини:

• Два или повече TXT записа, съдържащи v=spf1

Решения:

• Комбинирай всички mechanisms в един SPF запис
• Изтрий дублирани SPF записи

DKIM Troubleshooting

DKIM signature липсва:

Симптоми: Без DKIM-Signature header в имейлите

Причини:

• DKIM signing не активиран в email доставчика
• Domain верификация не завършена
• Изпращане през non-DKIM path

Решения:

• Активирай DKIM в настройките на доставчика
• Завърши domain верификационни стъпки
• Провери документацията на доставчика за DKIM настройка

DKIM verification се провали:

Симптоми: DKIM показва “fail” в authentication резултатите

Причини:

• DNS запис не публикуван или неправилен
• Грешен selector използван
• Key несъответствие между DNS и signing
• Съобщение модифицирано в transit

Решения:

• Верифицирай, че DNS записът съществува на selector._domainkey.domain
• Сравни selector в DKIM-Signature header-а с DNS
• Регенерирай keys, ако се подозира несъответствие
• Провери за mail filters или relays, модифициращи съобщения

DKIM ключ твърде дълъг за DNS:

Симптоми: Не може да се запази DKIM запис, truncation грешки

Причини:

• 2048-bit keys надхвърлят дължината на единичен TXT запис
• DNS доставчикът има символни лимити

Решения:

• Раздели ключа в множество quoted strings (повечето доставчици обработват това автоматично)
• Провери дали DNS доставчикът ти поддържа дълги TXT записи
• Използвай 1024-bit keys временно (по-малко сигурно)

Пример на split DKIM запис:

"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."
"...continuation of key..."

DMARC Troubleshooting

DMARC alignment провали:

Симптоми: SPF и DKIM минават, но DMARC се проваля

Причини:

• Authenticated домейнът не съвпада с From header домейна
• Third-party sending услуга, използваща собствения си домейн
• Misconfigured envelope sender

Решения:

• Гарантирай, че email доставчикът подписва с твоя домейн (custom DKIM)
• Конфигурирай custom Return-Path/envelope sender
• Използвай relaxed alignment режим (adkim=r; aspf=r)

Не получаваш DMARC отчети:

Симптоми: Без aggregate отчети пристигащи

Причини:

• rua адрес неправилен
• Email адресът не може да получава external email
• Отчетите отиват в спам
• Receiving сървърите не изпращат отчети

Решения:

• Верифицирай rua синтаксиса: rua=mailto:[email protected]
• Тествай, че reporting адресът може да получава external поща
• Провери спам папката за отчети
• Бележка: Не всички receivers изпращат DMARC отчети

DMARC запис не намерен:

Симптоми: DMARC проверки показват “no record”

Причини:

• Запис публикуван на грешна локация
• Използване на грешен формат (трябва да е TXT на _dmarc subdomain)

Решения:

• Записът трябва да е на _dmarc.yourdomain.com
• Верифицирай с dig TXT _dmarc.yourdomain.com

Общи Troubleshooting инструменти

Онлайн validators:

• MXToolbox (mxtoolbox.com) - SPF, DKIM, DMARC lookups
• Mail Tester (mail-tester.com) - Изпрати тестов имейл за пълен анализ
• DMARC Analyzer - Визуализация на отчети
• Google Admin Toolbox - Провери MX, SPF, DKIM

Command line инструменти:

# Провери SPF
dig TXT yourdomain.com

# Провери DKIM
dig TXT selector._domainkey.yourdomain.com

# Провери DMARC
dig TXT _dmarc.yourdomain.com

# Провери от конкретен DNS сървър
dig @8.8.8.8 TXT yourdomain.com

Анализ на email header:

Провери Authentication-Results header в получени имейли:

Authentication-Results: mx.google.com;
  dkim=pass header.d=example.com header.s=brevo;
  spf=pass smtp.mailfrom=example.com;
  dmarc=pass action=none header.from=example.com

Email Authentication и Brevo

Brevo осигурява изчерпателна поддръжка на email authentication, правейки праволинейно конфигурирането на SPF, DKIM и DMARC за твоите sending домейни.

Настройка на Authentication в Brevo

Стъпка 1: Добави домейна си

1. Логни се в Brevo акаунта си
2. Навигирай до Settings > Senders, Domains & Dedicated IPs
3. Кликни Add a Domain
4. Въведи името на домейна си

Стъпка 2: Конфигурирай SPF

Brevo осигурява SPF include за добавяне към DNS:

include:spf.brevo.com

Добави това към съществуващия си SPF запис или създай нов:

v=spf1 include:spf.brevo.com -all

Стъпка 3: Конфигурирай DKIM

Brevo генерира DKIM keys автоматично. Копирай предоставения запис:

1. Иди на domain настройки в Brevo
2. Намери DKIM секцията
3. Копирай името и стойността на DNS записа
4. Добави TXT записа към твоя DNS

Стъпка 4: Верифицирай конфигурацията

Brevo автоматично проверява DNS записите ти. Зелени отметки показват успешна конфигурация.

Предимства на правилен Brevo Authentication

Когато правилно конфигурираш authentication с Brevo:

• По-висок inbox placement: Gmail, Microsoft и други доставчици се доверяват на authenticated съобщения
• Brand защита: DMARC предотвратява spoofing на твоя домейн
• По-добра аналитика: Точно tracking на отваряния и кликове
• Изграждане на репутация: Консистентен authentication изгражда sender репутация

Tajo Integration ползи

Използването на Tajo за свързване на Shopify магазина с Brevo осигурява допълнителни предимства:

• Автоматичен customer sync: Customer данни текат безпроблемно за персонализирани имейли
• Event tracking: Purchase, browse и cart събития тригерират authenticated транзакционни имейли
• Multi-channel координация: Поддържай консистентна authentication през email, SMS и WhatsApp
• Унифицирана аналитика: Проследи email performance наред с други маркетингови метрики

Комбинацията от правилен email authentication и real-time customer data синхронизация гарантира, че имейлите ти не само достигат inbox-а, но резонират с всеки получател.

Често задавани въпроси

Каква е разликата между SPF, DKIM и DMARC?

SPF специфицира кои сървъри могат да изпращат email за твоя домейн. DKIM добавя cryptographic signature, доказваща message автентичност. DMARC задава политика за това как receivers трябва да обработват authentication провали и осигурява reporting. Всичките три работят заедно за пълна email authentication.

Имам ли нужда от всичките три (SPF, DKIM и DMARC)?

За оптимална deliverability и сигурност, да. SPF сам по себе си е уязвим на spoofing. DKIM сам по себе си не специфицира политика. DMARC изисква SPF или DKIM, за да функционира. Заедно, те осигуряват изчерпателна защита и най-добрите inbox placement rates.

Колко време отнема email authentication да заработи?

DNS промените обикновено propagate-ват в рамките на 30 минути до 48 часа. След propagate-ване, authentication се прилага веднага. Все пак, изграждане на sender репутация на база консистентен authentication отнема седмици до месеци.

Ще блокира ли настройването на DMARC с p=reject легитимните ми имейли?

Може, ако е конфигуриран неправилно. Затова трябва винаги да започваш с p=none (мониторинг), да анализираш отчетите 2-4 седмици, да поправиш всякакви проблеми, после да преминеш постепенно към quarantine и reject. Никога не пропускай мониторинг фазата.

Какво е SPF alignment спрямо DKIM alignment?

Alignment означава, че authenticated домейнът съвпада с видимия From header домейн. SPF alignment сравнява Return-Path домейна. DKIM alignment сравнява signing домейна (d= tag). DMARC изисква поне един да align-не.

Мога ли да имам множество DKIM keys за един домейн?

Да. Всяка email услуга може да използва различен selector (напр. brevo._domainkey, google._domainkey). Това позволява на множество услуги да подписват с DKIM независимо. Няма лимит на броя DKIM selectors.

Защо имейлите ми все още отиват в спам след настройка на authentication?

Authentication е необходим, но не достатъчен за inbox placement. Други фактори включват sender репутация, качество на съдържанието, engagement rates и list hygiene. Authentication те прекарва през първия филтър; добрите практики определят финалното placement.

Как да чета DMARC aggregate отчети?

DMARC aggregate отчетите са XML файлове. Използвай инструменти като dmarcian, Postmark DMARC или DMARC Analyzer, за да ги парсваш и визуализираш. Тези инструменти показват кои IPs изпращат email като твоя домейн и техните authentication pass/fail rates.

Какво се случва, ако надхвърля SPF лимита от 10 lookups?

SPF връща permanent error (permerror) и всички SPF проверки се провалят. За да поправиш това, премахни неизползвани includes, замени includes с IP адреси, където е възможно, или използвай SPF flattening услуги.

Трябва ли да използвам -all или ~all в SPF записа си?

Използвай ~all (softfail) при тестване и изграждане на увереност. След като потвърдиш, че всички легитимни източници минават, премини на -all (hard fail) за по-силна защита. Softfail маркира провали, но не отхвърля; hard fail оторизира отхвърляне.

Колко често трябва да ротирам DKIM keys?

Няма строго изискване, но годишна ротация е добра security практика. При ротиране, добави новия ключ първо, изчакай DNS propagation, активирай signing с новия ключ, после премахни стария ключ след transition период.

Subdomains нуждаят ли се от отделен authentication?

SPF: Да, всеки subdomain се нуждае от собствен SPF запис, ако изпраща email от него. DKIM: Keys могат да са споделени или отделни на subdomain. DMARC: Subdomains наследяват parent политиката, освен ако sp= не е зададен или subdomain има собствен DMARC запис.

Заключение

Email authentication чрез SPF, DKIM и DMARC вече не е опционален за бизнеси, които разчитат на email комуникация. Тези протоколи защитават марката ти от spoofing, подобряват deliverability-то и изграждат доверието, необходимо за ефективен email marketing.

Ключови изводи:

• SPF оторизира sending сървъри през DNS
• DKIM доказва message автентичност с cryptographic signatures
• DMARC enforce-ва политика и осигурява видимост чрез отчети
• Започни с мониторинг (p=none) преди enforce-ване на отхвърляне
• Всички легитимни sending източници трябва да са правилно конфигурирани
• Редовният мониторинг предотвратява configuration drift

За e-commerce бизнеси, използващи Shopify, комбиниране на правилен email authentication с customer data интеграция чрез Tajo и Brevo създава мощна основа. Твоите транзакционни имейли достигат клиентите надеждно, маркетинговите ти кампании постигат по-добър inbox placement, а марката ти остава защитена от spoofing атаки.

Готов да подобриш email deliverability-то си? Започни с одит на текущата си authentication настройка с инструментите, споменати в това ръководство, после систематично конфигурирай SPF, DKIM и DMARC, следвайки осигурените step-by-step инструкции.

Научи как Tajo се интегрира с Brevo, за да осигури безпроблемен email authentication наред с real-time customer data синхронизация за твоя Shopify магазин.