Аудит SPF, DKIM та DMARC з Node.js із пріоритезованими результатами

Мета: викликати допоміжний скрипт Node.js на серверній стороні, який повертає числовий бал, докази рівня перевірки та впорядкований список знахідок щодо того, як проект у суспільному надбанні забезпечує безпеку своєї пошти.

Недостатньо лише перевіряти наявність трьох записів типу TXT. Оператори часто публікують правила SPF, ігноруючи DMARC, підписують повідомлення за допомогою DKIM за вибором, якого ніхто не очікував, або виглядають «підтвердженими» на папері, проте не використовують механізми контролю транспортування, такі як MTA-STS.

Тому корисний аудит збирає докази, різно класифікує підтверджені та невідомі проблеми, а також ранжує способи їх усунення. Наведений нижче огляд демонструє, як використовувати API для керування маршрутизацією, класичними записами автентифікації, політикою транспортування, звітністю та індикаторами бренду з клієнта Node.js, а також пояснює, що ці результати все ще не можуть підтвердити щодо розміщення пошти у скриньці.

Що повідомляє кожна перевірка безпеки пошти

Перші чотири елементи керування становлять основу процесу автентифікації. Подальші елементи покращують прозорість транспортування повідомлень, забезпечення дотримання правил та формування іміджу бренду.

Зберігайте чітке розмежування ролей: SPF авторизує відправника листа, DKIM перевіряє криптографічну підпис на повідомленні, а DMARC оцінює відповідність між автентифікованою ідентичністю та адресою, яку бачить одержувач. Наявність лише DNS-запису не означає, що кожне легітимне повідомлення пройде перевірку.

Аудит домену з Node.js

Кінцева точка аудиту безпеки та доставки доменних листів, яка розміщена на платформі RapidAPI, приймає запити типу GET та POST у форматі JSON. Копіюйте справжню адресу хоста з прикладу на платформі замість того, щоб жорстко вказувати замінник.

const domain = "example.com"; const selectors = ["google", "selector1"]; const params = new URLSearchParams({ domain, dkim_selectors: selectors.join(","), }); const response = await fetch( `https://${process.env.RAPIDAPI_HOST}/api/v1/mail-security/audit?${params}`, { headers: { "x-rapidapi-key": process.env.RAPIDAPI_KEY, "x-rapidapi-host": process.env.RAPIDAPI_HOST, }, }, ); if (!response.ok) { const body = await response.text(); throw new Error(`Mail-security audit failed (${response.status}): ${body}`); } const audit = await response.json(); console.log({ domain: audit.domain, score: audit.score, summary: audit.summary, findings: audit.findings, });

Захистання облікових даних: зберігайте ключ RapidAPI у змінній середовища або менеджері секретів. Ніколи не зберігайте його у коді чи не використовуйте у JavaScript браузера.

У відповідях наводяться домен, час виконання, оцінка та класифікація, окремі перевірки, підсумок та результати за пріоритетом — достатньо структури для панелей керування, процедур ознайомлення, запланованих моніторингів та заявок на усунення проблем.

Чому DKIM потребує особливого підходу

SPF розташований у верхньому рівні домену, а DMARC — у адресі _dmarc.example.com. DNS-імена DKIM містять селектор:

selector._domainkey.example.com

Селектори обирає оператор доставки чи адміністратор пошти. DNS не надає універсального каталогу всіх використовуваних селекторів, тому аудитор не може створити повний список.

Якщо відомий постачальник, передавайте з запитом правдоподібні селектори — Google Workspace часто використовує google; інші системи можуть використовувати selector1, selector2 або назви з датою.

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

Перетворіть результати на план виправлення

Чистий експорт DNS — це не план усунення проблем. Виконуйте дії в такому порядку:

1. Спочатку відновіть маршрутизацію електронної пошти. Пошкоджені або відсутні записи MX заважають звичайній доставці.
2. Виправте синтаксис та авторизацію SPF. Зберігайте лише один запис SPF, видаляйте застарілі елементи та дотримуйтесь обмежень на пошук.

Оприлюдніть DMARC та поступово посилюйте правила. Почніть із звітності за потреби, визначте легітимні джерела, а потім переходьте до карантину чи відхилення, коли ситуація стабілізується.

Підтвердіть DKIM для кожного активного відправника. Врахуйте другорядні платформи, а не лише основний ESP.

Додайте MTA-STS та TLS-RPT одночасно. Політика може вимагати безпечної передачі даних; звітність допомагає пояснити причини невдач.

Використовуйте BIMI як необов’язковий останній рівень захисту. Він передбачає сильну аутентифікацію та може потребувати додаткової роботи з брендом чи сертифікатами.

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

Використовуйте оцінку як сигнал, а не вирок

Оцінки допомагають порівнювати домени, відстежувати прогрес конфігурації та реагувати на слабкі результати. Вони не підтверджують доставку повідомлень у поштову скриньку.

Розміщення повідомлень також залежить від репутації, скарг, відхилень, змісту, частоти надсилання, рівня взаємодії та відповідності кожного повідомлення певним стандартам — усього цього не може побачити загальнодоступний DNS чи запит MTA-STS HTTPS. Описаний тут аудит не відкриває сеанси SMTP, не надсилає запитів, не читає приватні консолі постачальників та не рекурсивно аналізує всі значення SPF. Перш ніж робити висновки щодо доставки, поєднуйте дані конфігурації з заголовками, телеметрією постачальника та контрольованими випробувальними надсиланнями.

Практичні способи використання результатів

• Аудити агентств: встановлення повторюваної базової лінії перед рекомендаціями щодо змін.
• Інтеграція SaaS: попередження клієнтів про відсутність автентифікації перед підключенням домену для надсилання.
• Перевірка постачальників: виявлення слабких чи неповних механізмів безпеки електронної пошти.

Плановий моніторинг: виявлення зниклих записів чи регресій у правилах.

Триаж підтримки: додавання структурованих доказів та послідовних рішень до заявки.

Для моніторів необхідно зберігати як ідентифікатори стабільних результатів, так і сирі дані доказів. Формувати сповіщення при реальних змінах ситуації, а не при незначних коливаннях балу.

Часто ставлені запитання щодо перевірки SPF, DKIM та DMARC

Що перевіряє інструмент SPF, DKIM та DMARC?

Як мінімум, він здійснює пошук публічних DNS-даних для авторизації, підписів та правил. Більш повна перевірка також може аналізувати маршрутизацію MX, MTA-STS, TLS-RPT та BIMI, після чого надавати зібрані докази разом із послідовними рекомендаціями.

Чи може інструмент автоматично знайти всі записи DKIM?

Ні. Кожен пошук вимагає налаштованого селектора з боку системи надсилання, а публічна деревоподібна структура DNS не містить переліку всіх використовуваних селекторів. Спробуйте селектори, описані у документації вашого постачальника, або прочитайте заголовок DKIM-Signature з вже отриманого повідомлення.

Чи гарантує наявність SPF, DKIM та DMARC можливість доставки електронних листів?

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

Чи можу я автоматизувати перевірки за допомогою API?

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

Розпочніть із безкоштовної перевірки безпеки електронної пошти вашого домену

Той самий хостований аудит об’єднує весь набір інструментів керування в один виклик. Безкоштовний базовий ліміт (п’ятдесят викликів на місяць) достатній для перевірки повної структури відповіді перед тим, як обрати платний тариф.

Використовуйте безкоштовний план RapidAPI, щоб здійснити виклик до кінцевої точки, переглянути докази, прикріплені до кожної перевірки, та визначати пріоритети усунення проблем на основі результатів перевірки, а не лише числового рейтингу.