Если вы постоянно сталкиваетесь с подсказкой ” DMARC policy not enabled” для вашего домена, это означает, что ваш домен не защищен от подделки и выдачи себя за другого с помощью DMARC аутентификации электронной почты. Вы можете часто сталкиваться с этой подсказкой во время обратного поиска DNS для вашего домена. Тем не менее, это часто легко исправить. В этой статье мы рассмотрим различные шаги, которые необходимо выполнить для настройки DMARC и установки правильной политики для вашего домена, чтобы вы больше никогда не сталкивались с подсказкой “Политика DMARC не включена”!
Важные концепции: Политика DMARC и режимы применения
Чтобы исправить ошибку “Политика DMARC не включена”, нам нужно понять, что делает подобная политика и какие различные типы мы можем настроить для нашей системы DMARC-аутентификации.
1. Отклонять несанкционированные электронные письма
Вы можете настроить свой режим отказа на максимальное применение, отклоняя все электронные письма, которые не прошли аутентификацию, установив тег p= в вашей записи на “reject“.
2. Зарезервируйте несанкционированные электронные письма, чтобы просмотреть их позже
Если вы не хотите отбрасывать несанкционированные письма, держите их в карантинном ящике получателя. Этого можно добиться, установив тег p= на “карантин“.
3. Ничего не делать, позволить несанкционированным письмам доставляться как есть
Возможно, вы не захотите предпринимать никаких действий против писем, не прошедших проверку DMARC. В этом случае просто установите для тега p= значение “none“.
Основное требование этих режимов – предоставить владельцам доменов гибкость в выборе того, как они хотят, чтобы их получатели реагировали на электронные письма, которые могут быть вредоносными или исходить из источников, не имеющих специальных полномочий. Это важный шаг на пути к пресечению самозванства доменов.
Почему вы должны включать политику DMARC в первую очередь?
DMARC, что является аббревиатурой от Domain-based Message Authentication, Reporting, and Conformance, – это стандарт для проверки подлинности исходящих сообщений электронной почты, чтобы гарантировать, что ваш домен адекватно защищен от BEC и попыток подмены прямого домена. DMARC работает путем согласования домена обратного пути(адреса возврата), домена подписи DKIM и домена From: для поиска совпадений. Это помогает проверить подлинность источника отправки и не позволяет неавторизованным источникам отправлять электронные письма, которые кажутся исходящими от вас.
Домен вашей компании – это ваша цифровая витрина, которая отвечает за вашу цифровую идентичность. Организации всех размеров используют маркетинг электронной почты для достижения охвата и привлечения клиентов. Однако если ваш домен подменяется и злоумышленники рассылают фишинговые письма вашим клиентам, это резко ухудшает не только ваши маркетинговые кампании по электронной почте, но и репутацию и доверие к вашей организации. Вот почему использование DMARC становится обязательным для защиты вашей личности.
Для того чтобы начать внедрение DMARC для вашего домена:
- Откройте консоль управления DNS
- Перейдите в раздел записей
- Опубликуйте свою запись DMARC, которую вы можете легко создать с помощью нашего бесплатного инструмента генератора записей DMARC, и укажите политику DMARC, чтобы включить ее для вашего домена (эта политика будет определять, как принимающий MTA отвечает на сообщения, не прошедшие проверку подлинности).
- DNS может потребоваться 24-48 часов для обработки этих изменений, и все готово!
- Вы можете проверить правильность записи с помощью нашего бесплатного инструмента поиска записей DMARC после настройки его для вашего домена
Как исправить “Политика карантина/отклонения DMARC не включена”
Когда вы получаете предупреждение “Политика DMARC карантина/отклонения не включена” или иногда просто “Политика DMARC не включена” или ” Нет защиты DMARC”, это просто указывает на то, что ваш домен настроен с политикой DMARC, не позволяющей только мониторинг.
Если вы только начинаете свой путь аутентификации электронной почты и хотите контролировать свои домены и почтовый поток, чтобы обеспечить бесперебойную доставку почты, то мы рекомендуем вам начать с политики DMARC “none”. Однако политика “нет” обеспечивает нулевую защиту от подделки, и поэтому вы будете часто сталкиваться с запросом: “Политика DMARC не включена”, где вам напоминают, что ваш домен не защищен должным образом от злоупотреблений и самозванства.
Чтобы исправить это, достаточно изменить механизм политики (p) в вашей записи DMARC с p=none на p=reject/quarantine, тем самым перейдя к применению DMARC. Если ваша DMARC-запись ранее была:
v=DMARC1; p=none; rua=mailto:[email protected]; ruf=mailto:[email protected];
Ваша оптимизированная запись DMARC будет иметь следующий вид:
v=DMARC1; p=reject; rua=mailto:[email protected]; ruf=mailto:[email protected];
Или, v=DMARC1; p=карантин; rua=mailto:[email protected]; ruf=mailto:[email protected];
Устранение [Ошибка] “Политика DMARC не включена Cloudflare”
Если вы используете Cloudflare в качестве хостинг-провайдера DNS, вы можете столкнуться с этой ошибкой. Чтобы избавиться от этой ошибки в Cloudflare,
- Войдите в свою учетную запись Cloudflare для просмотра консоли управления DNS
- Выберите свое доменное имя
- В левой боковой панели меню выберите “DNS”.
- В разделе управления DNS для вашего домена нажмите “Добавить записи”.
Создайте свою запись с помощью нашего инструмента генератора DMARC. Это займет всего несколько секунд! [Скопируйте значение вашей записи после ее генерации].
ПРИМЕЧАНИЕ: при создании записи DMARC убедитесь, что вы выбрали соответствующий режим политики. Поле p= не должно быть пустым для вашей записи.
- В разделе добавления записей установите тип “TXT”, TTL “Auto”, имя “_dmarc” и в поле значения вставьте значение, сгенерированное инструментом.
- Сохранить изменения
Я исправил “Политика DMARC не включена”, что дальше?
После устранения ошибки “Политика DMARC не включена” мониторинг доменов должен быть непрерывным процессом, чтобы убедиться, что развертывание DMARC не влияет на доставляемость электронной почты, а наоборот, улучшает ее. Отчеты DMARC помогут вам получить представление обо всех ваших каналах электронной почты, чтобы вы никогда не упускали из виду происходящее. После выбора политики внедрения DMARC, PowerDMARC поможет вам просмотреть результаты проверки подлинности электронной почты в сводных отчетах DMARC с легко читаемыми форматами, понятными каждому. Благодаря этому вы сможете увидеть 10-процентное увеличение коэффициента доставляемости электронной почты с течением времени.
Более того, вам необходимо убедиться, что ваш SPF не сломается из-за слишком большого количества DNS-поисков. Это может привести к сбою SPF и повлиять на доставку электронной почты. Динамический SPF – это простое решение, позволяющее не превышать жесткий лимит SPF, а также постоянно быть в курсе всех изменений, вносимых вашими ESP.
Сделайте процесс развертывания DMARC максимально беспроблемным, подписавшись на наш бесплатный DMARC-анализатор уже сегодня!
- О сайте
- Последние сообщения
Менеджер по цифровому маркетингу и написанию контента в PowerDMARC
Ахона работает менеджером по цифровому маркетингу и контент-писателем в PowerDMARC. Она страстный писатель, блогер и специалист по маркетингу в области кибербезопасности и информационных технологий.
The warning “DMARC quarantine reject policy not enabled” means that your domain lacks a DMARC policy that is set to either quarantine or reject non-compliant mail. Although this exact phrasing of the warning comes from mxtoolbox.com, many other providers give similar warnings when your DMARC policy is not strong enough. For example, the following are common alternative warnings:
- “DMARC policy not enabled”
- “DMARC not at enforcement” (Valimail’s preferred term for this condition)
- “DMARC policy set to monitoring only”
If you’re not familiar with DMARC yet, check out our article What is DMARC? It will provide you with a lot of background knowledge that will aid you as we help you understand what this warning means and how you can fix it.
If this warning comes up, your DMARC policy either doesn’t exist or is set to p=none (also known as monitoring mode). Although monitoring is great because it gives you visibility into mail sent using your domain, you’re missing out on most of the benefits of DMARC by not setting a policy. This can be problematic for your email security because it makes it easier for hackers to forge emails that impersonate your domain.
In this article, we’ll help you set up and properly configure your DMARC policy to fix this warning and enjoy the protections offered by a strong DMARC policy.
Summary of DMARC Policies
You can set three distinct DMARC policies using the p tag: none, quarantine, and reject. The table below provides a brief summary of each of these. Later in the article, we’ll go into greater depth, but this serves as a reference you can look at as needed.
Note that it’s up to the receiving server to honor your DMARC policy, which is only a suggestion that recipients can interpret as they wish. Some recipients don’t even check DMARC, in which case your policy won’t do anything at all.
| Policy Value | Description |
|---|---|
| None | Has no impact on mail that fails DMARC. Reporting should still occur, though, hence the alternative name “monitoring mode.” |
| Quarantine | Suggests that the receiving server should treat mail with extra suspicion, for example, by segregating it into a spam folder or warning the reader. |
| Reject | Advises receiving servers to reject the message, preventing it from arriving in the recipient’s inbox. |
The specific warning we’re looking at tells us that the administrator of a domain hasn’t enabled a reject or quarantine policy. Either no DMARC record is published, or the policy may be set to “none.”
Addressing the Warning
To fix this warning, you’ll need to configure DMARC to reject or quarantine non-compliant mail. We recommend reject, for reasons we’ll touch on later. This means that you advise recipient servers to reject mail that doesn’t pass DMARC validation.
Review Your Current DMARC Policy
It’s easy to review your current DMARC posture: Simply use an online tool like Valimail’s Domain Checker to get a full report for free. Here’s what it looks like in practice:
This shows us the entire DMARC record. In this case, we used the domain valimail.com, which is set to enforce DMARC using a reject policy. You can see this by looking at the p tag, which says p=reject. However, this site will also show you if it’s set to none or missing entirely.
If you prefer a non-commercial source, several command-line tools can also do this. For example, the nslookup tool can check your DMARC record like this:
nslookup -type=txt _dmarc.valimail.com
Server: 10.240.80.234
Address: 10.240.80.234#53
Non-authoritative answer:
_dmarc.valimail.com text = "v=DMARC1; p=reject; rua=mailto:dmarc_agg@vali.email,mailto:dmarc.reports@valimail.com"
Authoritative answers can be found from:Beware, however: Unlike Valimail’s Domain Checker, the command line won’t warn you of misconfigurations in your policy. Therefore, we recommend only relying on the command line if you’re already knowledgeable about DMARC tags and how they should be configured.
Do You Need A Strong DMARC Policy?
You might wonder whether you really need to set up a DMARC policy other than none. This is actually acceptable when you very first deploy DMARC, so you can just set up monitoring and make sure everything works.
However, once you’re sure that everything is working correctly, you should set your policy to reject in order to protect your domain’s reputation and safeguard recipients against fraud.
In other words: yes, you should aim to deploy a strong DMARC policy, even if you don’t ever intend to send email from your domain.
|
Platform |
Success Rate |
Success Rate Frame |
Estimated FTEs |
Maintenance |
Marketplace Apps Identified |
|---|---|---|---|---|---|
|
DIY Manual |
20% |
12+ Months |
2-3 |
Never ending |
~100 services |
|
Outsourced Manual |
<40% |
9-12 Months |
1-2 |
Never ending |
~100 services |
|
Valimail Automation |
97.8% |
0-4 Months |
0.2 |
Automated |
6,500+ |
Craft a New Policy
If you already have DMARC in place, it’s usually best to go from none to quarantine for some time, just to be safe. Then once you’re sure everything is working, switch fully to reject. If you don’t already have DMARC, on the other hand, you’ll need to craft a policy from scratch. You may also need to set up SPF and DKIM if you don’t have those either.
The simplest possible policy that would address this warning is v=DMARC1; p=reject. However, you’ll likely want to take advantage of additional features, like reporting. Our article What is DMARC will help you understand how to set up reporting and other optional but recommended tags. Make sure to check out the “Optional — but Recommended — DMARC Tags” section, in particular.
Deploy Your New Policy
To deploy your new policy, you’ll need to publish it as a DNS record. How this works depends on what DNS provider you use. If you’re using Office 365, you can learn about setting up DMARC on that specific platform with our article DMARC Office 365. Otherwise, you’ll want to create a DNS record, including your strong new policy, using whatever DNS platform you happen to manage your domain with.
Due to DNS propagation, it could take up to 48 hours before the new policy is visible to everyone. Don’t panic if your record doesn’t change immediately.
To check when the DMARC record becomes visible, you can check up on it using the same tools you used to review your policy before.
Limitations and Best Practices
A strong DMARC policy is a great addition to your email safety practices. However, this protocol by itself can only do so much. In this section, we’ll look at how you can get the most out of DMARC.
Why Use reject Instead of quarantine?
Because quarantine is so inconsistently interpreted and applied across providers, you can’t rely on how recipient servers will react. Even with reject, you don’t know whether receiving hosts will actually drop the message, so it’s best to aim for the strongest result you can and hope that other mail servers will respect your suggestion.
For this reason, we recommend setting your DMARC policy to reject instead of quarantine.
Is DMARC Enough?
DMARC is a great tool in the email administrator’s toolkit, but it only protects you from very specific threats. Additionally, it’s built on top of other protocols that we’ve barely touched on in this article.
Email benefits from the existence of many other security tools and practices that can make you safer. Whether it’s enterprise anti-phishing for Office 365, requiring encryption for inbound mail by deploying MTA-STS, or just starting out with SPF and DKIM, there are a plethora of ways to make email safer. Learn more about them by reading the rest of our guide on email security: The Guide to Email Security Best Practices.
Minimal resource requirement with only a single one time DNS change needed
DMARC Enforcement guarantee and 97.8%+ success rate
100% Automated service discovery and 1-click validation
Conclusion
A strong DMARC policy protects your domain’s reputation from fraudulent senders. Additionally, you protect people who trust your domain from being victimized by bad actors impersonating your domain. That’s why setting up DMARC with a policy that assertively protects your domain by rejecting non-compliant mail is a critical component of solid email security principles. Nevertheless, implementing DMARC can be complicated if you don’t know what you’re doing, leading to warnings and problems.
Thankfully, you can easily address the “DMARC quarantine reject policy not enabled” warning by making sure your DMARC policy rejects non-compliant mail. Whether it’s by adjusting your current DMARC policy to be stricter or creating a new policy from scratch, the tips above will help clear up this warning and let you enjoy safer email.
Организационные домены / Organizational Domains
Начнем с выдержек из RFC:
Organizational Domain:
The domain that was registered with a domain name registrar. In the absence of more accurate methods, heuristics are used to determine this, since it is not always the case that the registered domain name is simply a top-level DNS domain plus one component (e.g., “example.com”, where “com” is a top-level domain). The Organizational Domain is determined by applying the algorithm found in Section 3.2.
…
The Organizational Domain is determined using the following algorithm:1. Acquire a “public suffix” list, i.e., a list of DNS domain names reserved for registrations. Some country Top-Level Domains (TLDs) make specific registration requirements, e.g., the United Kingdom places company registrations under “.co.uk”; other TLDs such as “.com” appear in the IANA registry of top-level DNS domains. A public suffix list is the union of all of these. Appendix A.6.1 contains some discussion about obtaining a public suffix list.
2. Break the subject DNS domain name into a set of “n” ordered labels. Number these labels from right to left; e.g., for “example.com”, “com” would be label 1 and “example” would be label 2.
3. Search the public suffix list for the name that matches the largest number of labels found in the subject DNS domain. Let that number be “x”.
4. Construct a new DNS domain name using the name that matched from the public suffix list and prefixing to it the “x+1″th label from the subject domain. This new name is the Organizational Domain.Thus, since “com” is an IANA-registered TLD, a subject domain of “a.b.c.d.example.com” would have an Organizational Domain of “example.com”.
The process of determining a suffix is currently a heuristic one. No list is guaranteed to be accurate or current.
1. Получается список “публичных суффиксов”, за объяснениями что это такое лучше пойти сюда publicsuffix.org
2, Из письма извлекается почтовый домен, разбивается и нумеруется справа налево на части. В терминологии этой статьи – sub.domain.tld превратится в #3 – sub, #2 – domain, #1 – tld.
3. В списке публичных суффиксов найти такой суффикс, чтобы с ним совпадало наиболшее число частей, пусть это будет Х.
4. Собрать новый домен из Х+1 частей – это и будет организационный домен.
Пример:
Письмо от info@a.sub.domain.tld
Части: tld – #1, domain – #2, sub – #3, a – #4
Далее в списке публичных суфиксов находится tld, поэтому Х=1
Соответственно новый домен для письма будет из 2х частей – domain.tld
s – strict – FQDN из поля d= в подписи и RFC5322.From из письма должны полностью совпадать для прохождения проверки.
ruf - reporting URI for forensic reports - почта для немедленных отчетов об ошибках аутентификации. К сожалению не все почтовые сервисы поддерживают отсылку этих отчетов (например, Gmail на момент написания этой статьи).
fo - failure report options - контролирует в каком случае присылается forensic report:
0 - используется по умолчанию - присылать отчет если не пройден ни один этап аутентификации;
1 - присылать отчет если не пройден хотя бы один этап аутентификации;
d - присылать отчет если не пройдена аутентификация DKIM;
s - присылать отчет если не пройдена аутентификация SPF.
Как правильно использовать DMARC?
Тут всё зависит от ваших потребностей:
Для вебсерверов я бы рекомендовал простой DMARC, указанный мною ранее:
_dmarc.domain.tld IN TXT "v=DMARC1; p=none; sp=none; rua=mailto:postmaster@domain.tld"
В любом случае начинать нужно с такой политики и какое-то время нужно мониторить чтобы все письма приходили. Далее можно сменить политику на quarantine, применить её к 5% (указав pct=5) почты и с интервалом в, например, одну неделю поднимать процент до 10-20-35-50-75-100%, а потом так же перейти на политику reject.
При перенастройках SPF/DKIM также неплохо выставлять ruf=mailto:your-mbox@domain.tld и fo=1 для получения отчетов о поломках.
На этом всё, об опечатках прошу сообщать в личку, а о неточностях и ошибках - в комментариях, я внесу исправления в статью.
Когда вы используете различные онлайн-инструменты для проверки записи DMARC домена, вы можете столкнуться с одной из ошибок:
“No DMARC record found”
“DMARC record not found”
“Missing DMARC record”
“Unable to find DMARC record”
“No DMARC record published”
“Hostname returned a missing or invalid DMARC record”
“DMARC policy not enabled”
Любое из этих или подобных сообщений означает одно: проверка DMARC показывает, что ваш домен не защищен и подвергается спуфинговым атакам. Любой злоумышленник, использующий спуфинг, может отправлять вредоносные электронные письма с использованием вашего домена, что потенциально может нанести ущерб вашему бренду после попадания в почтовые ящики ваших клиентов.
Чтобы исправить это, вам нужно начать внедрять DMARC, который является ратифицированным отраслевым стандартом для проверки подлинности электронной почты, для вашего домена.
Что такое DMARC
DMARC расшифровывается как «Domain-based Message Authentication, Reporting & Conformance». Это протокол проверки подлинности электронной почты со встроенными функциями отчетности и применения политик. DMARC построен на основе двух других широко распространенных протоколов электронной почты, SPF и DKIM. DMARC проверяет результаты, возвращаемые SPF и DKIM, и определяет, проходит ли входящая электронная почта аутентификацию или нет, и, в зависимости от политики, указанной в записи DMARC, предпринимает определенные действия для предотвращения попыток злонамеренной подделки.
Вот визуальное представление о том, как работает DMARC, с сайта dmarc.org:
См. официальную спецификацию DMARC здесь: DMARC RFC7489.
Что такое запись DMARC
Запись DMARC — это запись типа TXT, опубликованная для домена в DNS владельцем или администратором домена. Когда принимающему почтовому серверу необходимо проверить входящую электронную почту по DMARC, он будет искать запись DMARC в домене, извлеченную из адреса электронной почты отправителя.
Запись DMARC определяет политику DMARC, которая применяется, когда электронная почта не проходит аутентификацию DMARC с использованием тега p, например, none (никаких действий), quarantine (переместить в спам) или reject (полностью отклонить электронное письмо).
Он также должен указать список получателей сводных отчетов DMARC, используя тег rua. Таким образом, эти получатели смогут анализировать эти отчеты, выявлять потенциальные проблемы в инфраструктуре электронной почты и устранять их, если таковые имеются.
Вот пример записи DMARC:
v=DMARC1; p=quarantine; rua=mailto:[email protected]; ruf=mailto:[email protected];Приведенная выше запись DMARC предписывает помещать в карантин сообщения электронной почты, не прошедшие проверку подлинности, сводные отчеты DMARC следует отправлять на адрес [email protected], а отчеты судебной экспертизы следует отправлять на адрес [email protected]
Как исправить «No DMARC Record Found»
Эту проблему легко исправить: нужно создать DMARC-запись с соответствующими настройками, опубликовать ее в DNS, а затем проверить.
Вот 3 шага, чтобы исправить «No DMARC Record Found».
1. Создать запись DMARC
Прежде чем мы сможем его опубликовать, используйте наш бесплатный DMARC record generator, чтобы создать запись DMARC.
2 вещи, чтобы отметить здесь. Во-первых, если вы внедряете DMARC впервые, скорее всего, вам нужно установить политику на none (p=none), что переводит DMARC в режим мониторинга. Это никоим образом не влияет на ваши потоки электронной почты, но позволяет вам получать отчеты DMARC, которые дают представление о вашем статусе аутентификации электронной почты.
Во-вторых, вы можете запросить у DMARC отправку сводных отчетов на почтовый ящик, к которому у вас есть доступ, указав тег rua на этот почтовый ящик. Если вы используете DMARCLY’s dashboard для создания такой записи DMARC, она также настроит для вас почтовый ящик. Таким образом, вам не нужно беспокоиться о настройке почтового ящика и его обслуживании.
2. Опубликовать запись DMARC
DMARC работает, публикуя запись в DNS, чтобы она была доступна для принимающих почтовых серверов. После создания записи вам необходимо войти в панель управления DNS-провайдера домена, чтобы добавить запись.
Например, если ваш домен domain.com размещен на Cloudflare, вам необходимо войти в Cloudflare.
Вот несколько ссылок на руководства по добавлению записи DMARC с различными службами DNS:
- Как добавить запись DMARC в Cloudflare
- Как добавить запись DMARC в Namecheap
- Как добавить запись DMARC в GoDaddy
- Как добавить запись DMARC в cPanel
3. Проверьте запись DMARC
После публикации записи вы можете использовать нашу бесплатную онлайн-проверку DMARC, чтобы убедиться, что она действительно находится в DNS и доступна для всех.
Советы
На самом деле, всё просто
DMARC — технология, которая снижает количество спама и фишинговых писем за счёт обмена информацией между отправителем и получателем.
Получатель сообщает данные об инфраструктуре проверки подлинности почты. Отправитель — о том, что делать, если сообщение не прошло проверку.
Пока звучит запутанно, но скоро мы во всём разберёмся.
Как работает DMARC
DMARC разработан так, чтобы с минимальными усилиями внедрить его в любой процесс отправки почты.
Он помогает определить, соответствует ли сообщение тому, что получатель знает об отправителе. Или проще: можно ли доверять этому отправителю. Если да — подписчик получает сообщение. Если нет — срабатывает политика DMARC для неаутентифицированных сообщений.
Приведём пример.
Пример
Допустим, есть две страны (домена), причем пересечение границы первой страны (получателя) гражданами второй страны (отправителя) разрешено второй страной только при наличии паспорта (SPF, DKIM).
На границу попадает гражданин второй страны (во всяком случае, он так уверяет). Паспортный контроль (антиспам-фильтр получателя) просит паспорт, но слышит в ответ, что паспорта нет. Зная, что вторая страна не разрешает впускать таких граждан (DMARC), пограничник запрещает въезд и отправляет первой стране отчет, что была попытка въезда в первую страну предположительно гражданином второй страны. Документов не было, поэтому въезд был запрещен.
Вот как выглядит полный цикл отправки-приёма email сообщений с включённой DMARC-политикой.
Пользу DMARC трудно переоценить. Не требуя специфических навыков для внедрения, DMARC позволяет полностью исключить нежелательный мошеннический трафик для отправителя, доставляя до получателя только аутентифицированные сообщения.
Важно отметить, что DMARC основывается на спецификациях DomainKeys Identified Mail (DKIM) и Sender Policy Framework (SPF), которые в настоящее время разрабатываются в IETF (Инженерный совет Интернета (англ. Internet Engineering Task Force, IETF) — открытое международное сообщество проектировщиков, учёных, сетевых операторов и провайдеров, созданное IAB в 1986 году и занимающееся развитием протоколов и архитектуры интернета).
Подробная техническая информация о DMARC
FAQ по DMARC
Как добавить DMARC
Добавить DMARC для вашего домена довольно просто. Для этого надо найти панель управления DNS-записями на вашем хостинге и внести туда новую TXT-запись с хостом _dmarc.
Примерный порядок действий:
- Вспоминаем, на каком хостинге у нас сайт.
- Заходим на сайт хостинг-провайдера.
- Заходим в панель управления хостингом.
- В настройках находим управление DNS-записями.
- Вносим новую TXT-запись (ниже покажем, что именно надо написать).
- Сохраняем изменения.
Вот пример, как это выглядит в хостинге Fornex.
Рассмотрим пример записи DMARC TXT для домена «sender.example.com»:
v=DMARC1;p=reject;pct=100;rua=mailto:postmaster@example.com
В этом примере отправитель требует, чтобы получатель отклонил все неаутентифицированные сообщения и отправил агрегированный отчёт об отклонении по адресу postmaster@example.com.
Часто используемые записи DMARC
Чтобы вам не ломать голову, приведем ниже четыре самые распространенные DMARC-записи:
Самая простая DMARC-запись. По сути, она не призывает сервер получателя ни к каким действиям по отношению к неаутентифицированным письмам. Мы рекомендуем её внести, чтобы проверить, что всё работает исправно.
v=DMARC1;p=none;rua=mailto:postmaster@yourdomain.com
Показывает получателю, что не надо отклонять никаких писем, но вам на указанный адрес будет отправляться письмо. В письме — агрегированный отчёт об отправленных письмах и серверах, откуда они ушли. Такая запись нужна, если вы хотите увидеть, идёт ли от вас нежелательный трафик. Ещё это промежуточный вариант перед включением политики reject (полного отклонения неаутентифицированных сообщений).
v=DMARC1;p=quarantine;rua=mailto:postmaster@yourdomain.com
Вариант-середнячок, один из самых распространённых. Письма, которые не аутентифицированы, будут помечаться вашим почтовым сервисом как спам или как нежелательные (зависит от сервиса).
v=DMARC1;p=reject;pct=25;rua=mailto:postmaster@yourdomain.com
Это уже строгая политика DMARC относительно неаутентифицированных сообщений. Мы рекомендуем вам постепенно наращивать процент отклонения таких писем: начиная с 25%, понемногу переходить к 100%. Например, когда мы в UniSender вводили DMARC, мы перешли на 100% за полтора месяца.
Ниже описываю синтаксис и значение тэгов.
Синтаксис DMARC и описание тэгов
Начну с таблицы тэгов. Потом подробнее расскажу о каждом из них.
Как вы поняли, все тэги делятся на обязательные и нет. Начнём с обязательных.
Обязательные тэги
p
Политика для приёма сообщений. Обязательный тэг. Определяет политику приёма сообщений для домена и поддоменов (если отдельно не указана политика для поддоменов с помощью тега «sp»).
Принимаемые значения:
- none: никаких действий предпринимать не требуется.
- quarantine: владелец домена просит, чтобы сообщения, не прошедшие DMARC проверку, рассматривались как подозрительные. В зависимости от получателя это значит, что сообщения попадут в папку «спам», получат пометку о необходимости быть внимательным или помечены подозрительными.
- reject: владелец домена просит, чтобы сообщения, не прошедшие проверку DMARС, были отклонены. Отклонение должно производиться во время SMTP-транзакции.
v
Версия. Обязательный тэг. Обязательно должен принимать значение DMARC1. Если это не так, то запись будет проигнорирована.
Необязательные тэги
adkim
Проверка на аутентификацию DKIM-записи. Может принимать значение «r» — relaxed или «s» — strict. По умолчанию принимает значение «r».
В режиме relaxed, если проверяемая DKIM-запись относится к домену d=example.com, а отправка идет от адреса email@news.example.com, проверка будет пройдена. В случае strict проверка будет пройдена только в том случае, если отправка идет от адреса на домене example.com. Поддомены не пройдут проверку.
aspf
Проверка на аутентификацию SPF-записи. Не обязательный тэг. По аналогии с adkim, может принимать значение «r» — relaxed или «s» — strict. По умолчанию принимает значение «r».
fo
Настройки отчетов об ошибках. По умолчанию принимает значение «0».
Принимаемые значения:
- 0: генерировать отчёт об ошибках DMARC, если все основные механизмы аутентификации не пройдены.
- 1: генерировать отчёт об ошибках DMARC, если хотя бы один механизм аутентификации не пройден.
- d: генерировать отчёт об ошибке DKIM, если сообщение провалило проверку на DKIM, независимо от аутентификации.
- s: генерировать отчёт об ошибке SPF, если сообщение провалило проверку на SPF, независимо от аутентификации.
pct
Процент сообщений, к которым применяется политика DMARC. Любое целое число от 0 до 100. По умолчанию значение 100.
Это необходимо для постепенного развёртывания политики, чтобы избежать ошибок.
rf
Формат для отчётов об ошибках. По умолчанию значение afrf. На текущий момент поддерживается только это значение.
ri
Интервал между отправкой агрегированных отчетов (в секундах). Значение по умолчанию: 86400 (1 раз в сутки).
rua
Адреса для отправки агрегированных отчётов, разделенные запятой. Возможно указание mailto: ссылки для отправки отчетов по почте.
ruf
Адреса для отправки отчетов об ошибках, разделенные запятой. Указание этого тэга подразумевает, что владелец домена требует от серверов получателей отправлять детальные отчеты о каждом сообщении, не прошедшем проверку DMARC.
sp
Политика DMARC для поддоменов (по аналогии с тегом p).
История DMARC
Пара слов о создании и задачах политики DMARC.
Больше 10 лет назад для аутентификации отправителя были созданы технологии SPF и DKIM. Они помогали отследить мошеннические сообщения, отправленные от имени банков, социальных сетей, почтовых служб.
Казалось бы, SPF и DKIM позволяли легко отличить мошеннические сообщения от нормальных. Но это стало трудным по ряду причин:
- Многие отправители имеют сложную систему отправки сообщений. Например, используют сторонних поставщиков услуг. Например, сервисы рассылок.
- Если часть отправляемых сообщений аутентифицированы, а часть нет. Получатели вынуждены как-то различать неаутентифицированные и мошеннические сообщения. Иначе мошеннические могут попасть во «Входящие».
- Плохая обратная связь. Нет никакого способа определить, сколько неаутентифицированных или мошеннических сообщений отравлено. DMARC решает эту проблему.
- Если даже все сообщения аутентифицированы, получатели могут предположить, что неаутентифицированное сообщение — ошибка, а не способ мошенничества. Получатели не могут быть уверены, что не существует легитимных неподписанных ключами сообщений.
Пример
В папку «спам» пришло письмо. Иван открыл этот письмо и видит, что почтовик пишет «Это письмо может быть мошенническим». Отправитель, тема, дизайн письма — всё соответствует тем письмам, которые он получал раньше от, скажем, банка.
В чем может быть проблема? Сообщение действительно мошенническое? Или у отправителя письма произошел глюк и письмо не было подписано ключом? Или же почтовик просто ругается, что в письме используются трекинговые ссылки для отслеживания переходов?
Если Иван не имеет достаточного опыта, чтобы изучить технические заголовки письма, он не сможет разобраться, на самом ли деле сообщение мошенническое или нет.
В 2007 году PayPal впервые применил этот подход и разработал в сотрудничестве с Yahoo, Google и Microsoft систему обмена данными между отправителем и получателем. Результат был чрезвычайно эффективным. Мошеннических email, предположительно полученных от PayPal, стало намного меньше.
Запомнить главное
DMARC — это политика, благодаря которой получатель письма понимает, можно ли доверять его отправителю. Позволяет бороться со спамом, фишингом и нежелательной почтой.
Чтобы настроить DMARC, зайдите в панель управления хостингом и внесите в настройки DNS-запись формата TXT. Распространённые примеры записей (в порядке нарастания строгости политики):
v=DMARC1;p=none;rua=mailto:postmaster@yourdomain.com
v=DMARC1;p=quarantine;rua=mailto:postmaster@yourdomain.com
v=DMARC1;p=reject;pct=25;rua=mailto:postmaster@yourdomain.com
DMARC — ? На текущий момент некоторые почтовые провайдеры, такие как Mail.ru, Yahoo, AOL уже включили строгую политику DMARC p=reject для своих доменов.
Круто, что вы заботитесь о безопасности ваших рассылок. Если возникнут трудности — пишите в комментариях.
ЭКСКЛЮЗИВЫ ⚡️
Читайте только в блоге
Unisender
Поделиться
СВЕЖИЕ СТАТЬИ
Другие материалы из этой рубрики
Не пропускайте новые статьи
Подписывайтесь на соцсети
Делимся новостями и свежими статьями, рассказываем о новинках сервиса
«Честно» — авторская рассылка от редакции Unisender
Искренние письма о работе и жизни. Свежие статьи из блога. Эксклюзивные кейсы
и интервью с экспертами диджитала.
