SPF, DMARC и DKIM: полное руководство по аутентификации электронной почты

Ваш домен проходит все проверки безопасности. Ваш SSL-сертификат действителен, заголовки верны, ваш CSP заблокирован. Затем в почтовый ящик клиента из вашего домена попадает фишинговое письмо. указав название вашей компании в поле «От». Письмо фальшивое, но ущерб реален.

Это происходит потому, что электронная почта была разработана в 1982 году без встроенной проверки отправителя. Любой можно установить любой адрес «От» в электронном письме и без записей SPF, DMARC и DKIM на вашем домена, принимающие серверы не имеют возможности обнаружить подделку. Более 90% фишинговых атак используют подмена домена и неправильно настроенная аутентификация электронной почты — это открытая дверь.

В этом руководстве рассказывается, что делает каждая запись, как они работают вместе и как проверять все три. на любом домене с помощью одного скрипта, используя Botoi API безопасности DNS.

Как работает аутентификация по электронной почте

Три записи DNS работают как уровни защиты. Каждый решает свою задачу:

1. СПФ отвечает: «Разрешено ли этому серверу отправлять электронную почту для этого домена?»
2. ДКИМ отвечает: «Было ли это сообщение изменено после того, как оно покинуло сервер отправителя?»
3. ДМАРК отвечает: «Что делать, если вышел из строя SPF или DKIM, и куда отправлять отчеты?»

Когда кто-то отправляет электронное письмо, утверждая, что он от you@example.com, получение сервер последовательно проверяет эти записи. Если SPF и DKIM оба терпят неудачу и DMARC сообщает p=reject, сообщение будет удалено до того, как достигнет папки «Входящие». Без всего в-третьих, существуют бреши, которыми пользуются злоумышленники.

SPF: кто может отправлять от вашего имени

SPF (Sender Policy Framework) — это DNS-запись TXT в корне вашего домена. В нем перечислены все IP-адрес и почтовый сервер, авторизованные для отправки электронной почты для вашего домена. Когда принимающий сервер получает электронное письмо от example.com, он проверяет запись SPF, чтобы убедиться, что отправка сервер находится в одобренном списке.

Проверьте запись SPF любого домена с помощью одного вызова API:

curl -s -X POST https://api.botoi.com/v1/dns-security/spf-check \\
  -H "Content-Type: application/json" \\
  -d '{"domain": "example.com"}'

Ответ:

{
  "success": true,
  "data": {
    "domain": "example.com",
    "has_spf": true,
    "record": "v=spf1 include:_spf.google.com ~all",
    "mechanisms": ["include:_spf.google.com", "~all"],
    "all_policy": "~all",
    "includes": ["_spf.google.com"],
    "valid": true
  }
}

Ключевые поля для проверки:

• has_spf: Запись TXT, начинающаяся с v=spf1 существовать? Если ложно, любой сервер может подделать электронную почту из вашего домена.
• valid: Запись парсится без ошибок? Записи SPF автоматически разрушаются, когда они превышают лимит поиска DNS в 10 раз.
• all_policy: механизм отслеживания, определяющий, что происходит с отправителями, не включенными в список. -all (жесткий провал) отвергает их. ~all (мягкий сбой) отмечает их как подозрительные. +all позволяет всем, что противоречит всей цели.

Ограничение на 10 поисков

Записи SPF допускают максимум 10 DNS-запросов. Каждый include:, a:, mx:, и redirect: механизм считается за один поиск. Вложенные включает тоже посчитай. Как только вы добавите Google Workspace, свой маркетинговый инструмент и службу транзакционной электронной почты, и CRM, вы быстро достигнете этого предела.

Если количество запросов превышает 10, вся запись SPF становится недействительной. API valid поле улавливает это. Исправьте это, объединив вложенные включения в диапазоны IP-адресов или объединив провайдеры.

DMARC: что делать, если проверки не пройдены

DMARC (Аутентификация сообщений, отчетность и соответствие на основе домена) связывает SPF и DKIM. вместе. Он живет в _dmarc.example.com как запись TXT и сообщает о получении серверам две вещи: что делать с сообщениями, которые не проходят аутентификацию, и куда отправлять сообщает об этих неудачах.

Проверьте свою запись DMARC:

curl -s -X POST https://api.botoi.com/v1/dns-security/dmarc-check \\
  -H "Content-Type: application/json" \\
  -d '{"domain": "example.com"}'

Ответ:

{
  "success": true,
  "data": {
    "domain": "example.com",
    "has_dmarc": true,
    "record": "v=DMARC1; p=reject; rua=mailto:dmarc@example.com; pct=100",
    "policy": "reject",
    "subdomain_policy": null,
    "reporting": {
      "rua": ["mailto:dmarc@example.com"],
      "ruf": []
    },
    "pct": 100,
    "alignment": {
      "dkim": "r",
      "spf": "r"
    }
  }
}

Политика DMARC

The policy Поле определяет, что происходит с ошибочными сообщениями:

• none: Не предпринимать никаких действий. Только монитор. Вы получаете отчеты, но поддельные электронные письма все равно остаются. добраться до входящих сообщений.
• quarantine: Переместить неудавшиеся сообщения в спам. Получатель все еще может их найти. если они посмотрят.
• reject: полностью удалить ошибочные сообщения. Самая сильная защита, но неправильная конфигурация означает потерю законной электронной почты.

Стратегия безопасного внедрения DMARC

Идем прямо к p=reject рискованно. Следуйте по этому пути:

1. Начните с p=none; rua=mailto:dmarc@example.com собирать отчеты за 2-4 недели
2. Просмотрите отчеты. Определите всех законных отправителей, не прошедших аутентификацию. Исправьте их SPF-включения и ключи DKIM.
3. Перейти к p=quarantine; pct=10 помещать в карантин 10% ошибочных сообщений
4. Увеличивать pct до 25, 50, а затем 100 в течение следующих нескольких недель, если вы подтвердите, что законная почта не затронута.
5. Переключиться на p=reject; pct=100 как только вы будете уверены в своей настройке

The pct Поле в ответе API показывает, где вы находитесь в этом развертывании. Домен в pct=100 с policy=reject имеет полную защиту.

DKIM: криптографические подписи в каждом электронном письме

DKIM (DomainKeys Identified Mail) добавляет криптографическую подпись к заголовкам каждого сообщения. исходящее сообщение. Отправляющий сервер подписывает сообщение закрытым ключом; принимающий сервер проверяет его по открытому ключу, опубликованному в вашем DNS. Если сообщение было изменено при передаче (изменены заголовки, изменено тело, перенаправлено через список рассылки, который переписывает контент), подпись не получается.

Записи DKIM в прямом эфире на [selector]._domainkey.example.com. Селектор — это метка ваш провайдер электронной почты назначает, например google для Google Workspace или selector1 для Microsoft 365.

Проверьте запись DKIM:

curl -s -X POST https://api.botoi.com/v1/dns-security/dkim-check \\
  -H "Content-Type: application/json" \\
  -d '{"domain": "example.com", "selector": "google"}'

Ответ:

{
  "success": true,
  "data": {
    "domain": "example.com",
    "selector": "google",
    "has_dkim": true,
    "record": "v=DKIM1; k=rsa; p=MIIBIjANBgkq...",
    "key_type": "rsa",
    "public_key_length": 2048
  }
}

Ключевые поля:

• has_dkim: Опубликован ли для этого селектора открытый ключ? Если ложно, DKIM проверка не удалась для всех сообщений, подписанных с помощью этого селектора.
• public_key_length: NIST рекомендует минимум 2048 бит. Ключи до 1024 биты достаточно слабы, чтобы их можно было учитывать.
• key_type: RSA является стандартом. Ed25519 быстрее и использует более короткие клавиши, но имеет ограниченную поддержку почтового провайдера.

DKIM и пересылка электронной почты

Вот почему DKIM имеет значение, даже если настроен SPF. Когда кто-то пересылает ваше письмо, IP-адрес пересылающего сервера отсутствует в вашей записи SPF, поэтому SPF не работает. Но подпись DKIM сохраняется при пересылке (пока содержимое не изменяется). DMARC проходит успешно, если какой-либо SPF или DKIM выравнивается, поэтому DKIM – это ваша система безопасности для пересылаемых сообщений.

Как эти трое работают вместе

Угроза	СПФ	ДКИМ	ДМАРК
Поддельное письмо с неавторизованного сервера	Обнаруживает	Обнаруживает (нет действительной подписи)	Обеспечивает соблюдение политики
Тело сообщения подделано при передаче	Не обнаруживает	Обнаруживает	Обеспечивает соблюдение политики
Перенаправленное письмо от законного отправителя	Ошибка (другой IP-адрес сервера)	Пропуск (подпись нетронута)	Проходит, если DKIM выравнивается
Подмена поддомена (user@fake.example.com)	Нет защиты	Нет защиты	Блокирует через sp=reject
Видимость ошибок аутентификации	Никто	Никто	Отправляет сводные отчеты

Ни одна запись не обеспечивает полного охвата. SPF без DMARC означает, что сбои не применяются. DKIM без SPF означает, что любой, у кого есть действительный ключ, может отправлять сообщения с вашего домена. DMARC без обоих SPF и DKIM не к чему применять меры.

Аудит вашего домена за 30 секунд

Этот сценарий оболочки проверяет все три записи и печатает сводку «прошел/не прошел». Он использует ботой API безопасности DNS; ключ API не требуется для обработки до 5 запросов в минуту.

#!/bin/bash
# Audit SPF, DMARC, and DKIM for a domain in 30 seconds
DOMAIN=\${1:-"example.com"}
DKIM_SELECTOR=\${2:-"google"}
API="https://api.botoi.com/v1/dns-security"
PASS=0
FAIL=0

echo "Auditing email authentication for \$DOMAIN"
echo "==========================================="

# SPF check
SPF=\$(curl -s -X POST "\$API/spf-check" \\
  -H "Content-Type: application/json" \\
  -d "{\\"domain\\": \\"\$DOMAIN\\"}")

HAS_SPF=\$(echo "\$SPF" | jq -r '.data.has_spf')
SPF_VALID=\$(echo "\$SPF" | jq -r '.data.valid')
SPF_RECORD=\$(echo "\$SPF" | jq -r '.data.record // "not found"')
ALL_POLICY=\$(echo "\$SPF" | jq -r '.data.all_policy // "none"')

if [ "\$HAS_SPF" = "true" ] && [ "\$SPF_VALID" = "true" ]; then
  echo "[PASS] SPF: \$SPF_RECORD"
  PASS=\$((PASS + 1))
else
  echo "[FAIL] SPF: \$SPF_RECORD"
  FAIL=\$((FAIL + 1))
fi

if [ "\$ALL_POLICY" = "+all" ]; then
  echo "  WARNING: +all allows any server to send as your domain"
fi

# DMARC check
DMARC=\$(curl -s -X POST "\$API/dmarc-check" \\
  -H "Content-Type: application/json" \\
  -d "{\\"domain\\": \\"\$DOMAIN\\"}")

HAS_DMARC=\$(echo "\$DMARC" | jq -r '.data.has_dmarc')
POLICY=\$(echo "\$DMARC" | jq -r '.data.policy // "not set"')
PCT=\$(echo "\$DMARC" | jq -r '.data.pct // 0')

if [ "\$HAS_DMARC" = "true" ]; then
  echo "[PASS] DMARC: policy=\$POLICY pct=\$PCT%"
  PASS=\$((PASS + 1))
else
  echo "[FAIL] DMARC: no record found"
  FAIL=\$((FAIL + 1))
fi

if [ "\$POLICY" = "none" ]; then
  echo "  WARNING: policy=none only monitors, does not enforce"
fi

# DKIM check
DKIM=\$(curl -s -X POST "\$API/dkim-check" \\
  -H "Content-Type: application/json" \\
  -d "{\\"domain\\": \\"\$DOMAIN\\", \\"selector\\": \\"\$DKIM_SELECTOR\\"}")

HAS_DKIM=\$(echo "\$DKIM" | jq -r '.data.has_dkim')
KEY_TYPE=\$(echo "\$DKIM" | jq -r '.data.key_type // "unknown"')
KEY_LEN=\$(echo "\$DKIM" | jq -r '.data.public_key_length // 0')

if [ "\$HAS_DKIM" = "true" ]; then
  echo "[PASS] DKIM: selector=\$DKIM_SELECTOR key_type=\$KEY_TYPE key_length=\$KEY_LEN"
  PASS=\$((PASS + 1))
else
  echo "[FAIL] DKIM: no record for selector '\$DKIM_SELECTOR'"
  FAIL=\$((FAIL + 1))
fi

if [ "\$HAS_DKIM" = "true" ] && [ "\$KEY_LEN" -lt 2048 ] 2>/dev/null; then
  echo "  WARNING: DKIM key is \$KEY_LEN bits (2048 recommended)"
fi

# Summary
echo ""
echo "Results: \$PASS passed, \$FAIL failed"
[ "\$FAIL" -eq 0 ] && echo "All checks passed." || exit 1

Запустите его:

bash audit.sh example.com google

Первый аргумент — ваш домен; второй — ваш селектор DKIM. Скрипт делает 3 API звонки (в пределах лимита бесплатного уровня), проверяет каждую запись, помечает предупреждения о слабых конфигурациях, и завершается с ненулевым кодом, если какая-либо проверка не удалась. Перетащите его в задание cron или конвейер CI. для постоянного наблюдения.

Если вы предпочитаете JavaScript, вот тот же аудит, что и асинхронная функция:

async function auditEmailAuth(domain, dkimSelector = "google") {
  const api = "https://api.botoi.com/v1/dns-security";
  const headers = { "Content-Type": "application/json" };

  const [spf, dmarc, dkim] = await Promise.all([
    fetch(\`\${api}/spf-check\`, {
      method: "POST",
      headers,
      body: JSON.stringify({ domain }),
    }).then((r) => r.json()),

    fetch(\`\${api}/dmarc-check\`, {
      method: "POST",
      headers,
      body: JSON.stringify({ domain }),
    }).then((r) => r.json()),

    fetch(\`\${api}/dkim-check\`, {
      method: "POST",
      headers,
      body: JSON.stringify({ domain, selector: dkimSelector }),
    }).then((r) => r.json()),
  ]);

  return {
    domain,
    spf: {
      exists: spf.data.has_spf,
      valid: spf.data.valid,
      record: spf.data.record,
      allPolicy: spf.data.all_policy,
    },
    dmarc: {
      exists: dmarc.data.has_dmarc,
      policy: dmarc.data.policy,
      pct: dmarc.data.pct,
      reporting: dmarc.data.reporting?.rua || [],
    },
    dkim: {
      exists: dkim.data.has_dkim,
      selector: dkimSelector,
      keyType: dkim.data.key_type,
      keyLength: dkim.data.public_key_length,
    },
  };
}

// Usage
const report = await auditEmailAuth("example.com", "google");
console.log(JSON.stringify(report, null, 2));

Общие конфигурации провайдера

У каждого поставщика электронной почты есть собственный домен SPF и селектор DKIM. Вот значения для наиболее распространенных провайдеров:

Поставщик	SPF включает	Селектор(ы) DKIM
Google Рабочая область	include:_spf.google.com	google
Майкрософт 365	include:spf.protection.outlook.com	selector1, selector2
Амазон СЭС	include:amazonses.com	На основе UUID (проверьте консоль SES)
ОтправитьГрид	include:sendgrid.net	s1, s2
Почтовый штемпель	include:spf.mtasv.net	Для каждого домена (проверьте настройки DNS Postmark)
Mailchimp / Мандрил	include:servers.mcsv.net	k1

Если вы используете несколько поставщиков, ваша запись SPF включает их всех в одну запись TXT. Например: v=spf1 include:_spf.google.com include:sendgrid.net ~all. Смотреть ограничение в 10 поисков при добавлении поставщиков.

Ключевые моменты

• СПФ контролирует, какие серверы могут отправлять электронную почту для вашего домена. Проверьте это с помощью тот /v1/dns-security/spf-check конечная точка. Следите за ограничением в 10 поисков и избегать +all.
• ДМАРК определяет, что происходит при сбое SPF или DKIM. Выходить постепенно из p=none к p=reject используя pct поле. Всегда устанавливать а rua адрес для получения отчетов.
• ДКИМ подтверждает целостность сообщения с помощью криптографических подписей. Используйте 2048-битный минимум ключей и убедитесь, что ваш селектор опубликован с помощью /v1/dns-security/dkim-check.
• Все три записи работают вместе. Сам по себе SPF не останавливает подделку пересылаемой электронной почты. только DKIM не сообщает получателям, что делать в случае сбоя. DMARC без SPF и DKIM не требует соблюдения.
• Автоматизируйте свои проверки. Запускайте скрипт аудита по расписанию или в CI, чтобы отловить дрейф DNS, провайдера миграции и случайное удаление записей до того, как они повлияют на доставляемость.