[{"data":1,"prerenderedAt":160},["ShallowReactive",2],{"publication:ru:P045":3},{"meta":4,"copy":17,"relatedArticles":151,"terms":152,"term":153,"resourceParent":154,"glossaryParent":157},{"id":5,"path":6,"kind":7,"keyword":8,"title":9,"seoTitle":10,"description":11,"incoming":12,"updated":16},"P045","\u002Fservices\u002Fdmarc-spf-dkim","service","настройка SPF DKIM DMARC","Настройка SPF, DKIM и DMARC для корпоративного домена","Настройка SPF, DKIM и DMARC для бизнеса","Настройка SPF, DKIM и DMARC с учетом CRM, рассылок и корпоративной почты. Проверка отправителей, согласования доменов и передача результата владельцу.",[13,14,15],"\u002Fservices","\u002Fservices\u002Femail-domains","\u002Fservices\u002Fcorporate-email","2026-10-31",{"intro":18,"sections":19,"checklistTitle":86,"checklist":87,"faq":94,"sources":104,"links":117,"cta":146},"Составим список систем, которые отправляют письма от вашего домена, настроим SPF и DKIM и проверим реальные сообщения перед выбором политики DMARC. Вы получите список отправителей, результаты проверок и оставшиеся исключения. Для оценки объёма пришлите домен и названия почтовых сервисов, сайта и других систем отправки.",[20,26,57,68,76,81],{"title":21,"paragraphs":22},"Какая задача решается настройкой почтового домена",[23,24,25],"Услуга нужна, когда появились новые отправители, письма стали получать ошибки проверки или домен используется для подделки отправителя. Начинать с копирования универсальной TXT-записи рискованно: реальный отправитель может быть не учтен. Сначала выясняем, какие системы разрешены владельцем, какие адреса видит получатель и кто может изменить настройки в каждой системе.","SPF проверяет полномочия отправляющего узла для определенной SMTP-идентичности, DKIM связывает подпись с доменом подписанта, а DMARC сопоставляет прошедший SPF или DKIM с доменом в видимом From. По RFC 9989 достаточно одного успешного согласованного механизма для DMARC pass. Два независимых статуса pass без такого согласования сами по себе не доказывают прохождение DMARC.","Практическая задача CyberFixCrew шире проверки наличия записей: определить владельцев отправки, согласовать изменения и сохранить понятный порядок добавления новых систем. Наши израильские знания в области защиты цифровой инфраструктуры применяются к конкретному домену заказчика. Для международного проекта отдельно согласуем часовой пояс, полномочия и взаимодействие с вашим почтовым провайдером.",{"title":27,"paragraphs":28,"table":30},"Составляем карту отправителей до изменения DNS",[29],"Для каждого потока нужны назначение, техническая система, владелец и возможность проверить тестовое сообщение. Корпоративный ящик и уведомление интернет-магазина могут идти через разные сервисы. Поэтому проверка одного письма не заменяет проверку всех потоков. Неизвестный источник в отчете нельзя автоматически разрешать: сначала нужно подтвердить, связан ли он с бизнесом и кто отвечает за него.",{"caption":31,"headers":32,"rows":36},"Рабочий реестр отправляющих систем",[33,34,35],"Поток","Что уточнить","Условие приемки",[37,41,45,49,53],[38,39,40],"Корпоративная почта","Провайдер, домен From, подпись","Контрольное письмо и согласованный механизм",[42,43,44],"CRM и счета","Отправляющий сервис и владелец","Письмо из настоящего рабочего маршрута",[46,47,48],"Уведомления сайта","SMTP или почтовый сервис, шаблон From","Отправка без раскрытия данных клиентов",[50,51,52],"Маркетинговая рассылка","Домен подписи и возвратный адрес","Проверка согласования и правил провайдера",[54,55,56],"Неизвестный источник","Разрешение бизнеса и техническая история","Решение владельца до включения в разрешенные",{"title":58,"paragraphs":59,"steps":62},"Проверяем записи и реальные заголовки сообщений",[60,61],"DNS показывает опубликованную конфигурацию, но не то, каким маршрутом ушло конкретное письмо. Для проверки нужны исходные заголовки сообщения у контролируемого получателя и контекст отправляющей системы. Заголовок Authentication-Results интерпретируют с учетом того, какой доверенный принимающий узел его добавил. Пересланный скриншот имени отправителя не заменяет эти данные.","Для SPF учитываем действующую запись и ограничения вычисления, а не создаем вторую независимую политику. Для DKIM проверяем домен подписи и нужный селектор, а не случайное имя в DNS. Доступ к секретному ключу не требуется передавать в заявку. При изменениях сохраняем исходное состояние, согласованный порядок публикации и способ возврата, если рабочая отправка нарушится.",[63,64,65,66,67],"Подтвердить владельца домена и разрешенных отправителей.","Согласовать доступ к DNS и настройкам каждого сервиса.","Подготовить изменения с учетом существующих записей.","Проверить сообщения из согласованных рабочих потоков.","Записать результат, ограничения и план дальнейшего наблюдения.",{"title":69,"paragraphs":70,"example":73},"Как выбирать политику DMARC без слепого ужесточения",[71,72],"Решение о политике принимается после проверки отправителей и оставшихся исключений. Наблюдение с p=none не просит получателя применять quarantine или reject к сообщениям, не прошедшим DMARC. Более строгая политика тоже не заменяет решение принимающей стороны. Нельзя обещать, что публикация p=reject остановит все мошеннические письма или обеспечит доставку каждого законного сообщения.","RFC 9989 опубликован в мае 2026 года и заменил RFC 7489 и RFC 9091. Старый параметр pct не используем как обещание постепенного применения текущей политики. Готовность к изменениям оцениваем по известным потокам, отчетам и проверенным исключениям. Условия Gmail относятся к его получателям и категориям отправителей; их нельзя автоматически объявлять одинаковыми требованиями всех почтовых систем.",{"title":74,"text":75},"Условный пример перехода к политике","У компании проверены рабочие ящики и CRM, но письма со склада отправляет отдельный сервис без назначенного владельца. Решение: выяснить этот поток и проверить сообщение до ужесточения политики. Это пример порядка принятия решения, а не выполненная настройка или обещание срока перехода.",{"title":77,"paragraphs":78},"Какие угрозы остаются после настройки",[79,80],"DMARC не защищает от письма с похожего, но другого домена, обманного отображаемого имени или уже захваченного законного ящика. При изменении платежных реквизитов требуется независимая проверка известным способом связи. Успешная аутентификация показывает определенные свойства домена и сообщения, а не добросовестность человека и не полномочие менять условия оплаты.","Проблема доставки может также зависеть от репутации, содержания, согласия адресата и правил получателя. Поэтому отчет об успешной настройке не должен превращаться в гарантию попадания во входящие. Если есть признаки компрометации учетной записи, отдельно проверяем доступ, сеансы и правила пересылки в согласованном объеме. Подмена домена и взлом ящика требуют разных действий.",{"title":82,"paragraphs":83},"Что входит в передачу результата и как подготовиться",[84,85],"В передаваемом результате нужны карта отправителей, согласованные изменения, проверенные маршруты, исключения и владельцы дальнейших действий. Уточняем, кто получает агрегированные отчеты и кто добавляет новые сервисы. Отчеты могут содержать технические сведения о почтовом потоке; доступ и хранение выбираются под условия бизнеса. Постоянный анализ отчетов не включается автоматически в разовую настройку.","Для заявки укажите домен, почтового провайдера, известные CRM и сервисы рассылок, а также наблюдаемую проблему. Не отправляйте пароли, полный почтовый архив или клиентские письма с лишними персональными данными. Стоимость зависит от числа доменов, потоков и ограничений доступа; после обсуждения согласуем объем работ. Лицензии сторонних сервисов и последующее сопровождение нужно оговорить отдельно.","Что подготовить к настройке",[88,89,90,91,92,93],"Домен и контакт уполномоченного владельца DNS.","Перечень почтовых систем, CRM, сайта и рассылок.","Ответственного за каждую систему и безопасные контрольные сообщения.","Исходную конфигурацию и порядок согласования изменений.","Условия перехода к политике и оставшиеся исключения.","Получателя отчетов и порядок добавления новых отправителей.",[95,98,101],{"question":96,"answer":97},"Можно ли сразу поставить p=reject?","Сначала нужно выяснить, какие разрешенные системы отправляют письма и проходят ли их сообщения согласование доменов. Неучтенная CRM или уведомление сайта могут оказаться за пределами проверки. Политику выбирают по фактическим результатам и допустимым рискам, с согласованием владельца. Нельзя назвать любую строгую запись безопасной для всех потоков заранее.",{"question":99,"answer":100},"Почему SPF и DKIM проходят, а DMARC нет?","DMARC учитывает связь прошедшего механизма с доменом в видимом поле From. SPF может проходить для возвратного домена стороннего сервиса, а DKIM для другого домена подписанта. Нужно посмотреть исходные заголовки и реальную конфигурацию отправителя. Одного наличия двух записей DNS для ответа недостаточно.",{"question":102,"answer":103},"Будут ли после настройки все письма во входящих?","Нет такой гарантии: аутентификация и согласование доменов важны, но получатель также применяет собственные правила. На доставку влияют и другие обстоятельства отправки. CyberFixCrew документирует проверенный объем и обнаруженные ограничения; доставляемость и безопасность учетных записей требуют своих отдельных проверок.",[105,108,111,114],{"label":106,"url":107},"RFC 9989: DMARC, май 2026 года","https:\u002F\u002Fwww.rfc-editor.org\u002Frfc\u002Frfc9989.html",{"label":109,"url":110},"RFC 7208: SPF","https:\u002F\u002Fwww.rfc-editor.org\u002Frfc\u002Frfc7208.html",{"label":112,"url":113},"RFC 6376: DKIM","https:\u002F\u002Fwww.rfc-editor.org\u002Frfc\u002Frfc6376.html",{"label":115,"url":116},"Google: требования к отправителям писем","https:\u002F\u002Fsupport.google.com\u002Fmail\u002Fanswer\u002F81126?hl=ru",[118,121,124,125,128,131,134,137,140,143],{"path":119,"label":120},"\u002Fblog\u002Femail-spoofing-domain","Как разбирать поддельные письма",{"path":122,"label":123},"\u002Fblog\u002Fspf-dkim-dmarc-explained","Объяснение SPF, DKIM и DMARC",{"path":15,"label":38},{"path":126,"label":127},"\u002Fservices\u002Fdns-ssl","DNS, домен и сертификаты",{"path":129,"label":130},"\u002Fservices\u002Faccess-2fa-audit","Проверка защиты учетных записей",{"path":132,"label":133},"\u002Fglossary\u002Fdmarc","DMARC: значение и пределы проверки",{"path":135,"label":136},"\u002Fblog\u002Fdkim-selector-check","Проверка селектора и подписи DKIM",{"path":138,"label":139},"\u002Fblog\u002Fdmarc-none-to-reject","Готовность к строгой политике DMARC",{"path":141,"label":142},"\u002Fglossary\u002Fbec","BEC: запрос и состояние почтового ящика",{"path":144,"label":145},"\u002Fblog\u002Finvoice-bank-change-scam","Проверка изменения реквизитов поставщика",{"title":147,"description":148,"button":149,"type":150},"Проверим задачу вашего почтового домена","Укажите домен, провайдера и известные отправляющие системы. Согласуем объем настройки и проверку рабочих потоков.","Обсудить настройку почты","setup",[],[],null,{"path":155,"label":156},"\u002Fresources","Материалы и шаблоны безопасности сайта",{"path":158,"label":159},"\u002Fglossary","Словарь кибербезопасности для бизнеса",1794134063749]