DMARC

Роз'яснення запису DMARC

_dmarc  3600  TXT
v=DMARC1; p=quarantine; rua=mailto:postmaster@slavaswim.com; ruf=mailto:postmaster@slavaswim.com; fo=1; adkim=s; aspf=s

Чудове запитання! Цей запис виглядає як типовий DMARC-запис для домену. Давайте розберемо його по частинах, щоб зрозуміти, що означає кожен елемент.

DMARC (Domain-based Message Authentication, Reporting & Conformance) — це протокол, який допомагає власнику домену контролювати, що відбувається з його електронною поштою. Він працює в парі з SPF і DKIM, що є основними механізмами автентифікації електронної пошти.

Ось повний розбір наданого вами запису:

_dmarc3600TXTv=DMARC1; p=quarantine; rua=mailto:postmaster@slavaswim.com; ruf=mailto:postmaster@slavaswim.com; fo=1; adkim=s; aspf=s

  • _dmarc

    Це обов'язкова частина, яка вказує, що цей запис стосується політики DMARC для вашого домену. Вона допомагає поштовим серверам ідентифікувати DMARC-запис.

  • 3600

    Це TTL (Time-to-Live) запису, вимірюється в секундах. Значення 3600 означає, що поштовий сервер має зберігати цей запис у кеші протягом однієї години (3600 секунд), перш ніж запитувати оновлення.

  • TXT

    Тип запису DNS. Записи DMARC завжди мають тип TXT.

  • v=DMARC1

    Це обов'язковий тег, який вказує версію DMARC. Наразі існує лише одна версія.

  • p=quarantine

    Це основна політика, яка визначає, що робити з електронними листами, які не пройшли DMARC-перевірку. У цьому випадку, p=quarantine означає, що такі листи мають бути поміщені в карантин, тобто, зазвичай, у теку зі спамом.

    Існує три можливих значення для цього тегу:

    • p=none: Не застосовувати жодних дій. Просто надсилати звіти. Цей режим використовується для тестування.

    • p=quarantine: Помістити в карантин.

    • p=reject: Повністю відхилити лист. Цей режим є найсуворішим.

  • rua=mailto:postmaster@slavaswim.com

    Цей тег задає електронну адресу, на яку надсилатимуться агреговані звіти (RUA). Ці звіти надходять щодня, у форматі XML, і містять загальну інформацію про кількість листів, що пройшли та не пройшли перевірку DMARC.

  • ruf=mailto:postmaster@slavaswim.com

    Цей тег задає адресу для звітів про збій (RUF). Ці звіти містять більш детальну інформацію про кожен лист, який не пройшов DMARC-перевірку. Вони можуть містити приватну інформацію, тому їх використовують рідше, ніж RUA.

  • fo=1

    Цей тег задає опції для звітів про збій. Значення 1 означає, що звіт буде надісланий, якщо лист не пройшов перевірку хоча б однієї з двох технологій: SPF або DKIM.

  • adkim=s

    Цей тег визначає політику вирівнювання ідентифікаторів для DKIM. Значення s означає строге вирівнювання (strict). Це означає, що домен в заголовку "From" листа має точно збігатися з доменом, підписаним DKIM.

    Інше можливе значення: r (relaxed).

  • aspf=s

    Цей тег визначає політику вирівнювання для SPF. Значення s також означає строге вирівнювання. Це означає, що домен в заголовку "From" має точно збігатися з доменом, який використовується для SPF-перевірки.

    Інше можливе значення: r (relaxed).

Підсумовуючи, цей запис DMARC говорить поштовим серверам: "Якщо лист від slavaswim.com не пройшов SPF або DKIM-перевірку (і домени не співпали), помістіть його в карантин (спам). Надішліть щоденні агреговані звіти та детальні звіти про помилки на адресу postmaster@slavaswim.com".

Цей запис є хорошим прикладом збалансованої DMARC-політики, оскільки він захищає домен від спаму та фішингу, а також надає власнику інформацію для моніторингу.

Якщо mail-сервер налаштовано на домен mail.first.com, але окрім цього, є і інший домен, який відправляє пошту, наприклад mail.second.com. То, в запису DMARC краще прописати "... adkim=r; aspf=r"?

Ваше запитання стосується ключового аспекту DMARC — вирівнювання (alignment) доменів, що є важливим для доменів, які використовують кілька джерел відправки пошти.

Коротка відповідь: Так, у вашому випадку, коли пошта надсилається з різних доменів, краще встановити adkim=r; aspf=r, що означає "розслаблене" (relaxed) вирівнювання. Це дозволить DMARC перевіряти пошту, що надсилається з mail.second.com, без негативних наслідків.

Пояснення

Давайте розберемо, чому це важливо.

Строге вирівнювання (s):

  • aspf=s: Домен у полі From: листа має точно збігатися з доменом у полі Return-Path: (домен SPF).

  • adkim=s: Домен у полі From: листа має точно збігатися з доменом, який був використаний для підписання DKIM.

Якщо ваш основний домен — first.com, а пошта відправляється з сервера mail.second.com, то при строгому вирівнюванні DMARC може ідентифікувати цю пошту як потенційно шахрайську, оскільки домени не збігаються. Листи можуть не пройти DMARC-перевірку та потрапити у спам, або бути відхиленими.

Розслаблене вирівнювання (r):

  • aspf=r: Домен у полі From: листа має збігатися з доменом SPF на рівні кореневого домену. Тобто, якщо From: — user@first.com, а SPF-домен — second.com, вони будуть вважатися вирівняними. Це корисно для служб, які відправляють пошту від вашого імені.

  • adkim=r: Те саме стосується і DKIM. Домен у полі From: повинен збігатися з доменом, використаним для DKIM-підпису, на рівні кореневого домену. Це дозволяє використовувати субдомени.

У вашому випадку, де пошта відправляється з mail.second.com для домену first.com, розслаблене вирівнювання є оптимальним вибором. Це забезпечить проходження DMARC-перевірки та збереже довіру до вашої пошти.

Важливо: Навіть якщо ви використовуєте розслаблене вирівнювання, вам все одно потрібно переконатися, що SPF та DKIM налаштовані правильно для обох доменів, які відправляють пошту.

Коротко, обидва записи DMARC містять помилки або неточності. Запис для mail.first.com — це не DMARC-запис, а запис DMARC для кореневого домену first.com. Запис для mail.second.com — це DMARC-запис для кореневого домену second.com, який має дуже обмежені функції.

DNS запис для first.com

Запис, який ви навели, не є записом для mail.first.com, а є DMARC-записом для кореневого домену first.com. DMARC-записи завжди починаються з _dmarc.

Правильний формат запису DNS TXT для домену first.com має бути таким:

  • Назва запису: _dmarc.first.com

  • Значення запису:

    v=DMARC1; p=quarantine; rua=mailto:postmaster@first.com; ruf=mailto:postmaster@first.com; fo=1; adkim=r; aspf=r

Цей запис застосовуватиметься до всіх листів, які відправляються з домену first.com або його субдоменів, якщо для них не визначено окремий DMARC-запис.

DNS запис для mail.second.com

Запис, який ви навели, також не є DMARC-записом для mail.second.com, а є записом для кореневого домену second.com. Крім того, він містить лише базову інформацію і не є ефективним для повного захисту.

Правильний формат запису DNS TXT для домену second.com має бути таким:

  • Назва запису: _dmarc.second.com

  • Значення запису:

    v=DMARC1; p=quarantine; rua=mailto:postmaster@second.com; ruf=mailto:postmaster@second.com; fo=1; adkim=r; aspf=r

Чому це краще:

  1. Повний захист: Ваша версія запису для second.com відсутні теги rua та ruf, що означає, що ви не отримуватимете звітів. Без звітів ви не можете моніторити, як працює ваша політика DMARC, і чи не блокуються легітимні листи.

  2. Дві сторони: Оскільки ви використовуєте second.com для відправки пошти від імені first.com, налаштування adkim=r та aspf=r для second.com є важливими. Це дозволить DMARC-перевірці для first.com проходити успішно, навіть коли пошта надсилається з домену second.com.

Підсумкові рекомендації

  1. Для first.com: Створіть DNS TXT-запис з назвою _dmarc.first.com і вашим варіантом значення. Це правильна конфігурація для кореневого домену.

  2. Для second.com: Створіть DNS TXT-запис з назвою _dmarc.second.com та розширеним значенням. Це забезпечить повний захист та можливість моніторингу.

  3. Записи для субдоменів: DMARC-записи за замовчуванням успадковуються субдоменами. Якщо вам потрібно налаштувати окрему політику для mail.first.com або mail.second.com, ви можете створити DNS-записи з іменами _dmarc.mail.first.com та _dmarc.mail.second.com відповідно.

Чи правильно так оформити DNS запис "_dmarc"?

Для mail.first.com:

v=DMARC1; p=quarantine; rua=mailto:postmaster@first.com; ruf=mailto:postmaster@first.com; fo=1; adkim=r; aspf=r

Для mail.second.com:

v=DMARC1; p=quarantine; pct=100

DNS запис для first.com

Правильний формат запису DNS TXT для домену first.com має бути таким:

  • Назва запису: _dmarc.first.com

  • Значення запису:

    v=DMARC1; p=quarantine; rua=mailto:postmaster@first.com; ruf=mailto:postmaster@first.com; fo=1; adkim=r; aspf=r

Цей запис застосовуватиметься до всіх листів, які відправляються з домену first.com або його субдоменів, якщо для них не визначено окремий DMARC-запис.

DNS запис для mail.second.com

Запис, який ви навели, містить лише базову інформацію і не є ефективним для повного захисту.

Правильний формат запису DNS TXT для домену second.com має бути таким:

  • Назва запису: _dmarc.second.com

  • Значення запису:

    v=DMARC1; p=quarantine; rua=mailto:postmaster@second.com; ruf=mailto:postmaster@second.com; fo=1; adkim=r; aspf=r

Чому це краще:

  1. Повний захист: Ваша версія запису для second.com відсутні теги rua та ruf, що означає, що ви не отримуватимете звітів. Без звітів ви не можете моніторити, як працює ваша політика DMARC, і чи не блокуються легітимні листи.

  2. Дві сторони: Оскільки ви використовуєте second.com для відправки пошти від імені first.com, налаштування adkim=r та aspf=r для second.com є важливими. Це дозволить DMARC-перевірці для first.com проходити успішно, навіть коли пошта надсилається з домену second.com.

Підсумкові рекомендації

  1. Для first.com: Створіть DNS TXT-запис з назвою _dmarc.first.com і вашим варіантом значення. Це правильна конфігурація для кореневого домену.

  2. Для second.com: Створіть DNS TXT-запис з назвою _dmarc.second.com та розширеним значенням. Це забезпечить повний захист та можливість моніторингу.

  3. Записи для субдоменів: DMARC-записи за замовчуванням успадковуються субдоменами. Якщо вам потрібно налаштувати окрему політику для mail.first.com або mail.second.com, ви можете створити DNS-записи з іменами _dmarc.mail.first.com та _dmarc.mail.second.com відповідно.

а для SPF двох доменів такий запис коректний? (при IP сервера 11.22.33.44):

@ 86400 TXT "v=spf1 a mx ip4:11.22.33.44 -all"

Цей запис SPF є коректним для одного домену, але його недостатньо для двох доменів, які ви відправляєте. Вам потрібно створити окремий запис SPF для кожного домену.

Пояснення

  • @: Це вказує на те, що запис відноситься до кореневого домену.

  • 86400: Це час життя (TTL) запису в секундах, що дорівнює 24 годинам.

  • TXT: Тип запису DNS. SPF-записи завжди мають тип TXT.

  • "v=spf1 ...": Це сам запис SPF.

    • v=spf1: Позначає версію SPF (завжди v=spf1).

    • a: Дозволяє відправляти пошту з IP-адреси, яка відповідає запису A домену.

    • mx: Дозволяє відправляти пошту з IP-адреси, яка відповідає записам MX домену.

    • ip4:11.22.33.44: Дозволяє відправляти пошту з конкретної IP-адреси.

    • -all: Це жорстка політика, яка вказує, що пошту, відправлену з будь-яких інших IP-адрес, крім зазначених, слід відхиляти.

Як це працює з двома доменами?

Оскільки ваш сервер з IP-адресою 11.22.33.44 буде відправляти пошту для обох доменів, вам потрібно, щоб обидва домени мали SPF-запис, що включає цю IP-адресу.

Приклад налаштувань:

  1. Для first.com:

    • Створіть запис TXT для домену first.com (або _spf.first.com):

      v=spf1 ip4:11.22.33.44 -all

      (Якщо ваш поштовий сервер має інше доменне ім'я, можна використовувати include замість ip4).

  2. Для second.com:

    • Створіть запис TXT для домену second.com (або _spf.second.com):

      v=spf1 ip4:11.22.33.44 -all

      (Так само, якщо ваш поштовий сервер має інше доменне ім'я, можна використовувати include).

SPF-запис для кожного домену має містити список усіх серверів, які дозволено відправляти пошту з цього домену. Якщо ви використовуєте один і той же сервер для обох доменів, то цей сервер повинен бути включений в обидва записи SPF.

PreviousDKIM extNext_dmarc _domainkey

Last updated