Розберіть файл .eml: заголовки, ланцюжок Received, посилання, хеші вкладень, невідповідності відправника.
Перевірка автентифікації пошти
Сам інструмент доступний англійською мовою; на цій сторінці наведено пояснення вашою мовою.
Використовуйте Перевірка автентифікації пошти
Як це працює
Введіть домен, щоб побачити, наскільки добре він захищений від підробки відправника: дерево include у SPF із кількістю DNS-запитів, політику DMARC, розміри ключів DKIM, MTA-STS, TLS-RPT, BIMI та MX.
DNS-імена, які ви шукаєте, надсилаються до ретранслятора DNS PhishDestroy (/api/dns-resolve.php), який звертається до Cloudflare або Google DNS через HTTPS.
Як користуватися Перевірка автентифікації пошти
- Введіть домен. Введіть домен, адресу електронної пошти або URL. Інструмент залишає лише домен, прибирає www. на початку URL і відкидає префікси на кшталт _dmarc.
- Додайте селектори DKIM. Якщо у вас є лист від цього домену, скопіюйте значення s= з його заголовка DKIM-Signature у поле селекторів. Перевіряється до 10 селекторів.
- Запустіть перевірку. Натисніть Check (перевірити) або Try common DKIM selectors (спробувати поширені селектори DKIM), щоб перевірити 15 частих назв. Лічильник показує, скільки DNS-запитів використано.
- Прочитайте таблицю Summary. Кожен запис отримує pass, warn, fail, info або error з однорядковим висновком. Розділи нижче показують сирі записи та дерево include у SPF.
- Скористайтеся результатом. Домен без SPF і без DMARC-політики, що застосовується, легко підробити. Майте це на увазі, оцінюючи лист, який нібито надійшов від нього.
Приклад
Домен, що не надсилає пошту
example.comChecked example[.]com · 6 DNS queries through the relay (Cloudflare)
Summary
RECORD STATUS FINDING
SPF pass "v=spf1 -all": no server may send mail as example[.]com, so any message from it is forged
DMARC warn p=reject, sp=reject
DKIM info Not checked: DKIM keys can only be found by selector (see the DKIM-Signature s= of a message)
MTA-STS info No MTA-STS record (optional): senders may deliver over unencrypted or unverified TLS
TLS-RPT info No TLS-RPT record (optional): no reports about TLS delivery failures
BIMI info No BIMI record (optional). DMARC is at enforcement
MX info Null MX "0 .": the domain accepts no mail (RFC 7505)
SPF
DNS-QUERYING TERMS
0 of 10
VOID LOOKUPS
0 of 2
UNLISTED SENDERS GET
fail (-all)
v=spf1 -all
Include and redirect tree (lookups are numbered in evaluation order; include, a, mx, ptr, exists and redirect count, RFC 7208 §4.6.4)
example[.]com · 0 lookups here, 0 in this branch
fail -all
DMARC
Found at _dmarc.example[.]com
v=DMARC1;p=reject;sp=reject;adkim=s;aspf=s
warn no rua: the owner receives no aggregate reports
TAG VALUE MEANING
v DMARC1 version
p reject policy for the domain itself — reject: failing mail is refused
sp reject policy for subdomains (default: p) — reject: failing mail is refused
adkim s DKIM alignment: r = same organization, s = exact domain (default r)
aspf s SPF alignment: r = same organization, s = exact domain (default r)
DKIM
DNS cannot list DKIM keys: each one sits under a selector chosen by the sender (selector._domainkey.example[.]com). Enter the s= value from a message's DKIM-Signature header, or press “Try common
…SPF v=spf1 -all, DMARC p=reject та нульовий MX (0 .): домен заявляє, що він не надсилає й не отримує пошту, тому будь-яке повідомлення від нього є підробленим. DMARC позначено як «warn» лише тому, що запис не містить адреси rua=, тому власник не отримує зведених звітів; сама політика (p=reject, sp=reject) виконується в повному обсязі.
Що перевіряється
| Сигнал | Що це означає |
|---|---|
| Запис SPF | Відсутній запис — це fail. +all пропускає будь-який сервер, а ?all або відсутність all не дає захисту; очікуване значення — -all або ~all. |
| Кількість DNS-запитів і порожніх запитів SPF | Include, a, mx, ptr, exists і redirect коштують по одному DNS-запиту. Понад 10 запитів або понад 2 запити без результату ламають SPF з помилкою permerror. |
| Політика DMARC | p=none лише спостерігає, quarantine відправляє листи, що не пройшли перевірку, у спам, а reject їх відхиляє. Попередження також стосуються pct менше 100, sp=none і відсутньої адреси rua. |
| Успадкований DMARC | Якщо піддомен не має запису, читається запис організаційного домену, і його позначено як успадкований. |
| Ключ DKIM | Показано для кожного селектора з типом і розміром. RSA менше 1024 біт — це fail, менше 2048 — попередження, а порожній p= означає, що ключ відкликано. |
| MTA-STS і TLS-RPT | Необов'язкові записи, які просять відправників використовувати перевірений TLS і повідомляти про збої. Якщо їх немає, ви отримаєте примітку, а не помилку. |
| BIMI | Необов'язковий запис із логотипом бренду. Він має значення лише тоді, коли DMARC має політику quarantine або reject з pct=100. |
| MX | Перелік поштових серверів. Нульовий MX (0 .) означає, що домен не приймає пошту; NXDOMAIN означає, що домену не існує. |
Ще кілька прикладів
URL замість домену
https://www.example.net/loginПримітка, що www.example.net перевіряється як example.net, далі 6 DNS-запитів: SPF pass для "v=spf1 -all", DMARC warn для p=reject, sp=reject без адреси rua, DKIM не перевірено, немає записів MTA-STS, TLS-RPT чи BIMI, і нульовий MX.
Домен, якого не існує
nothing.exampleSPF fail (немає запису SPF), DMARC fail (немає запису DMARC) і MX fail, бо nothing.example не існує (NXDOMAIN). У рядку BIMI зазначено, що DMARC не в режимі примусового застосування.
Ім'я запису DKIM
google._domainkey.example.orgСелектор google потрапляє в поле селекторів, і перевіряється example.org. У рядку DKIM написано "google: revoked" (відкликано), бо запис ключа має порожній p=.
Часті запитання
Що перевіряє Email Authentication Checker?
Запис SPF і кожен include та redirect, які він підтягує, рахуючи терміни, що роблять DNS-запити, відносно ліміту 10, а порожні запити (void lookups) — відносно ліміту 2 (RFC 7208). Також він читає запис DMARC, за потреби переходячи до організаційного домену, ключі DKIM для вказаних вами селекторів і записи MTA-STS, TLS-RPT, BIMI та MX.
Чого перевірка не бачить?
DNS не дає змоги отримати перелік ключів DKIM: кожен розміщено під селектором, який обирає відправник, тож введіть значення s= із заголовка DKIM-Signature листа або спробуйте поширені селектори; якщо ключ не знайдено, це нічого не доводить. Файл політики MTA-STS і логотип BIMI не завантажуються, а макроси SPF, що залежать від відправника, не розгортаються.
Що надсилається мережею?
Лише DNS-імена, утворені з введеного вами домену, як-от _dmarc.example.com; вони надходять до DNS-ретранслятора PhishDestroy, який запитує Cloudflare або Google через DNS over HTTPS. Одна перевірка використовує приблизно від 5 до 25 запитів; ретранслятор дозволяє 60 на хвилину.
Чи означає добрий результат, що лист від цього домену справжній?
Ні. Інструмент читає опубліковану політику домену, а не конкретний лист. Щоб побачити, чи пройшов окремий лист SPF, DKIM і DMARC, відкрийте його вихідний код в EML Analyzer.
Чому DMARC позначено як warn навіть із p=reject?
Попередження також стосуються налаштувань, що послаблюють охоплення або звітність: немає адреси rua для зведених звітів, pct менше 100 або sp=none для піддоменів. Сама політика reject усе одно діє.
Що таке порожній запит (void lookup)?
DNS-запит під час перевірки SPF, який не повертає придатних записів, наприклад термін a: або mx:, для імені якого немає адрес чи поштових серверів. SPF дозволяє два такі запити; третій спричиняє помилку permerror.