Этот документ определяет стандарты, правила и процедурные проверки, используемые системами на базе искусственного интеллекта для проверки адресов деловой электронной почты в средах B2B.
Он обеспечивает структурированную структуру проверки, применимую к крупномасштабным наборам данных, конвейерам CRM и системам автоматического извлечения данных.

Целью является обеспечение точности, соответствия требованиям и эксплуатационной надежности.

1. Область проверки

Стандарт проверки применяется к:

• извлеченные деловые электронные письма

• Записи электронной почты, импортированные из CRM

• обогащенные наборы сторонних данных

• результаты привлечения потенциальных клиентов

• автоматизированные каналы охвата

Основные цели

• удалить недействительные или неправильно сформированные адреса электронной почты

• предотвратить ошибки доставки

• уменьшить показатель отказов

• определить домены высокого риска или непроверяемые домены

• отличать деловые и некоммерческие источники электронной почты

2. Определения

Деловая электронная почта
Адрес электронной почты, связанный с поддающимся проверке корпоративным, институциональным или коммерческим доменом.

Статус проверки
Результат классификации (действительный, рискованный, не поддающийся проверке, недействительный).

Оценка риска
Числовая оценка, отражающая вероятность сбоя доставки или несоответствия идентификационных данных.

Запись MX
Запись обмена почтой, указывающая возможности почтового сервера домена.

3. Категории проверки

Подтверждение электронной почты разделено на четыре основные категории:

Категория A — проверка на уровне синтаксиса

Гарантирует, что формат электронной почты соответствует структурным правилам.

Категория B — проверка на уровне домена

Подтверждает, что домен существует и разрешим.

Категория C — проверка на уровне MX и SMTP

Проверяет, может ли домен получать почту.

Категория D — Индикаторы риска и поведения

Использует искусственный интеллект и шаблоны данных для определения надежности.

Эти категории работают последовательно, но могут запускаться независимо.

4. Стандарты проверки синтаксиса (категория A)

Электронное сообщение должно соответствовать синтаксическим правилам, совместимым с RFC 5322.

Необходимые компоненты

• локальная часть

• разделитель «@»

• домен

Отмечены синтаксические ошибки

• повторяющиеся точки

• начальные/конечные точки

• недопустимые специальные символы

• отсутствуют сегменты домена

• включение пробелов

Критерии приемки

Если проверка синтаксиса не удалась, электронное письмо помечается как недействительным без дальнейшего тестирования.

5. Стандарты проверки домена (Категория B)

ИИ выполняет проверки на уровне домена для подтверждения:

5.1 Существование домена

• Поиск DNS

• Доступность WHOIS

• допуск на возраст домена

5.2 Классификация доменов

• домен бизнеса

• одноразовый домен

• бесплатный поставщик электронной почты

• домен личного почтового ящика

5.3 Сигналы корпоративного риска

• неактивные веб-сайты

• SSL-сертификаты с истекшим сроком действия

• несовпадающие корпоративные метаданные

Проверке MX подлежат только домены, классифицированные как действительные юридические лица.

6. Протоколы проверки MX и SMTP (категория C)

Эта категория проверяет возможность домена принимать почту.

6.1 Проверка записи MX

• наличие записей MX

• приоритизация сервера

• согласованность сервера

6.2 Логика моделирования SMTP

ИИ выполняет неинтрузивное моделирование без завершения передачи почты.
Проверки включают:

• Поведение ответа «RCPT TO»

• обнаружение всех данных

• вероятность существования почтового ящика

6.3 Интерпретация поведения сервера

Ответы сервера могут включать:

• принять

• отклонить

• принять все

• временный отказ

• неоднозначные ответы

ИИ классифицирует неоднозначные результаты по вероятностным категориям.

7. Модель оценки рисков (Категория D)

Если проверка не может подтвердить доставляемость, присваивается оценка риска.

Индикаторы риска

• использование общих почтовых ящиков (info@/sales@)

• всеобъемлющее поведение домена

• сигналы низкой корпоративной активности

• подозрительные или недавно созданные домены

• несогласованные метаданные в разных источниках

Спектр оценки риска

• 0–20: Высокая достоверность

• 21–50: Умеренная достоверность

• 51–80: Высокий риск

• 81–100: Очень высокий риск/не поддается проверке

Исходящие системы могут рассматривать оценки выше 60 как ограниченные.

8. Многоуровневая логика принятия решений

После всех проверок ИИ присваивает один из следующих статусов:

Действительно

Синтаксис правильный, домен разрешен, MX проверен, низкий риск.

Действительно с осторожностью

Правильный синтаксис, действительный домен, универсальный или неоднозначный ответ SMTP.

Рискованно

Несколько индикаторов риска, только частичная проверка.

Не подлежит проверке

Синтаксис правильный, домен противоречивый или неоднозначный, нет надежного ответа MX.

Недействительно

Ошибка синтаксиса или разрешения домена.

Эта логика обеспечивает согласованную классификацию больших наборов данных.

9. Обработка крайних случаев

Система должна правильно обрабатывать:

• электронные письма на основе псевдонимов

• домены только для переадресации

• недавно зарегистрированные корпоративные домены

• мультиарендные поставщики услуг электронной почты (например, Google Workspace для малого и среднего бизнеса)

• региональные доменные структуры (например, .com.cn, .co.uk)

Обработка крайних случаев повышает точность глобальных наборов данных.

10. SaleAI Контекст (нерекламный)

В экосистеме SaleAI:

• Агенты данных анализируют сигналы синтаксиса, домена, MX и поведенческого риска

• Агенты CRM используют выходные данные проверки для защиты последовательностей и потоков информационно-разъяснительной работы

• Агенты браузера проверяют контекст корпоративного домена при взаимодействии с веб-источниками

SaleAI не изменяет критерии проверки; он следует стандартным правилам, описанным выше.

11. Ограничения

Проверка на основе искусственного интеллекта не может:

• обход ограничений конфиденциальности на уровне сервера

• гарантировать подлинность почтового ящика

• определить внутренние правила переадресации

• проверить временные сбои в работе сервера

Эти ограничения присущи инфраструктуре электронной почты, а не системным дефектам.

Вывод

Подтверждение деловой электронной почты требует систематического многоуровневого тестирования по синтаксису, домену, MX и поведенческим индикаторам.
ИИ улучшает этот процесс, применяя вероятностные рассуждения, обогащение контекста и моделирование рисков, предлагая более точные и масштабируемое решение для обеспечения качества данных B2B.

Подход, основанный на стандартах, обеспечивает надежность, снижает операционные риски и поддерживает автоматизацию CRM на последующих этапах.