Reviewed 4 November 2026English Русский Українська العربية Deutsch Español Français Italiano 日本語 한국어 Polski Português ภาษาไทย Türkçe Tiếng Việt 简体中文

How we check your email

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

Де потрапив електронний лист

Ви надсилаєте електронний лист із власної системи надсилання на вибрані тестові адреси. Ми шукаємо його копію у кожного провайдера та зберігаємо його папку та час виявлення. Це стосується окремих поштових скриньок; він не передбачає всю кампанію.

Вхідні, Спам, інші папки: Копію було знайдено в цій папці. Рекламні оголошення та інформаційні бюлетені зараховуються як отримані, але не як основна папка "Вхідні".
Електронна пошта не знайдена: Успішний пошук не знайшов відповідної копії під час перевірки. Це не доводить відхилення доставки чи розміщення спаму.
Не вдалося перевірити: Не вдалося прочитати поштову скриньку або недостатньо доказів. Ми не замінюємо спам або папку "Вхідні" на невідомий результат.

Як обчислюється відсоток папки "Вхідні".

Основна папка «Вхідні» ÷ отримані зовнішні копії × 100

Наприклад: 3 Вхідні + 6 Спам + 1 не знайдено = 10 вибраних поштових скриньок. Отримано 9 примірників; частка вхідних становить 3/9, або 33%. Завжди читайте чисельник, знаменник і охоплення спостереження.

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

Технічні стани та копіювання

В API підтверджений пошук без копії placement=not_received, provider_availability.status=доступний, reason=mailbox_read_succeeded. measured_at записує час читання.

Збережений результат not_received із підтвердженою помилкою читання стає seed_unavailable із reason=mailbox_read_failed. Незавершений результат залишається в очікуванні з помилками читання в provider_availability. Відсутність доказів прочитання не свідчить про завершеність пошуку.

Delivery history and a failed service-control delivery do not override a saved measurement. Кожна копія зберігає свого постачальника, час отримання та доступний ідентифікатор повідомлення. One report may contain different From domains: this is a difference between copies, not proof that an unrelated message was found. Matching depends on identifiers and the available search. An IMAP UID is tied to its mailbox and UIDVALIDITY; moving a message can change its UID. Microsoft Graph has its own identity rules. A bounded search may miss a copy.

24-hour observations

Початковий результат і подальші перевірки

Початковий збір зазвичай завершується приблизно через десять хвилин. Кожна отримана зовнішня копія має власне 24-годинне вікно, починаючи з моменту її першого підтвердженого виявлення. Пізніші перевірки спостерігають ту саму копію; ми не надсилаємо нових електронних листів для створення діаграми.

Спостереження проводяться щогодини. Компактна діаграма відображає вибрані контрольні точки на 0/3/6/12/18/24 години. Колір підтверджує папку лише під час збереженого часу вимірювання. Розташування між перевірками невідоме, навіть якщо суміжні результати збігаються.

Майбутні точки, прогалини та помилки залишаються різними станами. Пізніша помилка не стирає попередню підтверджену папку, але й не підтверджує поточну папку. Завершене вікно не означає, що кожне вимірювання виконано успішно.

Сповіщення про зміни та остаточний електронний лист залежать від увімкнених налаштувань і підтвердження одержувача. Their status is shown in the report. Unsubscribed recipients do not receive notifications.

Що означають позначки часу на діаграмі

A scheduled attempt is not a successful measurement. Черги, обмеження постачальника та помилки можуть затримати або пропустити перевірку. Підтверджені бали на діаграмі та повний список спроб є різними підрахунками. Невідомий графік не свідчить про відсутність фактичних спостережень.

Перше виявлення в спамі не означає раннє розміщення в папці "Вхідні". Між перевірками виявлено зміну папки; його точний час і причина можуть бути невідомі. Остаточний результат зберігає останню підтверджену папку та її час, включаючи неповні спостереження; успішне вимірювання рівно о 24:00 не гарантується.

Відправник і сервер

Надсилання тестів відбувається з однієї збереженої копії: спочатку діагностична копія LDM із відповідним ідентифікатором, інакше відповідна зовнішня копія. Якщо надійна відповідність недоступна, вибрана копія позначається як непевна. Деталі ідентифікують джерело, час, відправника та доступну IP-адресу. Ми не заповнюємо відсутні результати пропусками з інших копій.

Аутентифікація з домену

Від – адреса, вказана в повідомленні. Отримання копії та відповідність адреси, введеної для тесту, не підтверджують її автентичність. Ми показуємо автентифікацію з домену окремо, лише якщо достатні докази пов’язують успішну перевірку DMARC з цією копією. Це не перевіряє конкретну поштову скриньку чи особу.

SPF: Перевіряє, чи IP-адреса авторизована для надсилання для домену конверта SMTP, який використовується для зворотної адреси. It may differ from From.
DKIM: Checks a signature and the integrity of the signed message parts. The signing domain may differ from From. Відсутність підпису та підпис, який не пройшов перевірку, є різними результатами.
DMARC: Потрібна успішна перевірка SPF або DKIM із доменом, узгодженим із видимим полем «Від». Політика p=none означає моніторинг, а не помилку автентифікації.

Якщо перевірки не автентифікують домен, ми показуємо його як неперевірений. Якщо доказів недостатньо, результат залишається невідомим. Різниця між введеним доменом і відправником позначається окремо. Успішна автентифікація не гарантує розміщення папки "Вхідні".

Джерела доказів, зведення та версії уточнення

Ми використовуємо збережену локальну перевірку вихідного повідомлення або надійного результату з сервера прийому. Довільний заголовок Authentication-Results не є доказом. Походження SMTP має значення: IP-адреса в Received може належати ретранслятору; конверт SMTP і HELO не можна відновити лише за видимим From. Для автентифікації потрібен успішний результат DMARC, прив’язаний до того самого домену копії; старіші записи без достатньої прив'язки залишаються невідомими.

Технічне резюме вимагає успішних перевірок SPF, DKIM, DMARC і PTR, відомих джерельних даних і виконаних запитів у списку блокувань без звернень. Підтверджена проблема дає Виявлені проблеми; відсутні докази або помилки yield Не вдалося перевірити. Проблеми та неповні докази можуть співіснувати. Конфліктні результати для того самого домену та IP залишаються видимими.

Доступність SPF, DKIM і DMARC не залежить: відсутність доказів SMTP для SPF не робить доступну перевірку підпису DKIM недійсною. Кожен метод зберігає свій точний результат і причину доступності. Це зведені угоди перевірки, а не мінімальні вимоги кожного постачальника. Окремий результат автентифікації домену потребує власного підтверджуючого доказу. SPF зберігає проходження, невдачу, м’яку помилку, нейтральність, відсутність і помилки; нульовий зворотний шлях SMTP використовує ідентифікатор HELO. Для пошуку ключа DKIM потрібен свій селектор; невідомий селектор не встановлює зламаний DKIM.

Суворе узгодження DMARC вимагає ідентичних доменів; невимушене узгодження використовує організаційну область за правилами оцінювача. Поточна специфікація – RFC 9989, яка застаріла RFC 7489 і RFC 9091. Збережені локальні результати використовували mailauth 4.6.8 і його правила оцінки домену; відкриття звіту не перераховує їх відповідно до нової специфікації.

Збережена версія методу: 2026-10-01; поточна версія інтерпретації результатів: 2026-11-04. Версія оцінювача відображається лише там, де вона була збережена; відсутня версія в старішому звіті не замінюється сьогоднішньою датою. Ми використовуємо консервативні правила версії: недостатні докази залишаються невідомими. Підтверджені відтворювані випадки розширюють версійні правила лише після регресійних тестів; непідтримувані випадки залишаються невідомими. Правила не вивчаються автоматично з результатів тестування. Дата перегляду цього документа не змінює версію двигуна чи історичні результати.

PTR, DNS і списки блокувань

IP → PTR → A/AAAA →той же IP

PTR передається, коли IP-адреса вказує на ім’я хоста, чиї записи A/AAAA містять ту саму IP-адресу. Ім’я хосту не обов’язково збігається з доменом From. Відсутній запис або невідповідність IP не проходять перевірку; помилка пошуку або відсутність доказів означає, що його неможливо перевірити.

Результати PTR і списку блокувань описують заявлену IP-адресу під час перевірки. Деталі показують джерело IP; адреса з заголовків може належати ретранслятору. Ці результати не автентифікують домен From.

Перевірки списку заблокованих IP-адрес використовують IP-адресу, визначену для вибраної збереженої копії повідомлення. Показуємо IP та його джерело. Адреса із заголовків повідомлень може належати ретранслятору й сама по собі не ідентифікує відправника. Якщо IP-адреса недоступна, результат залишається невідомим; ми не замінюємо MX-адресу, адресу, отриману з From, або IP-адресу іншої копії. We query a limited set of IP blocklists. «Не внесено до перевірених списків блокування» означає лише те, що завершені іменовані перевірки не знайшли жодного списку в зареєстрований час. Переліки, помилки та неповні тести відображаються окремо. Domain checks do not replace IP checks. Відсутність списків не гарантує гарної репутації чи розміщення в папці "Вхідні".

Це збережені результати: відкриття звіту не запускає нову перевірку. Час отримання копії не залежить від часу перевірки чорного списку. Якщо час перевірки не було збережено, ми зазначаємо це явно.

Хто налаштовує PTR і чим відрізняється HELO

Власник IP-адреси або служба надсилання налаштовує PTR. Для вашого власного сервера попросіть постачальника IP встановити PTR для імені хоста, наприклад mail.example.org, а потім вказати A/AAAA цього імені хоста на той самий IP. Запис PTR у звичайній зоні домену не налаштовує зворотну зону IP. Платформа-відправник керує PTR для своїх власних серверів.

Прямий пошук перевіряє перше повернуте ім’я хоста PTR: A для IPv4, AAAA для IPv6. Якщо повертається кілька імен, інші не вважаються перевіреними; їх кількість зберігається в деталях. HELO/EHLO — це ім’я, яке представляє сервер SMTP. Його конфігурація та додаткові вимоги до постачальника є окремими від результату PTR. Якщо ім'я або його перевірка відсутні, збіг не вважається.

A DNS record is a published setting, not a successful message check. An SPF TXT record, a DKIM key or a DMARC policy alone does not authenticate this copy. MX identifies incoming mail servers and does not establish the outgoing IP. Перевірки збережених звітів не є свіжими пошуками DNS кожного разу, коли ви відкриваєте сторінку.

Вміст електронної пошти

A delivery test analyzes the received copy; the separate draft checker analyzes uploaded content. Original MIME from an external copy can support local authentication. Технічно вміст MIME можна проаналізувати без повного підтвердження SMTP, але результати вмісту, SpamAssassin і Rspamd відображаються, лише якщо ці перевірки дійсно виконано. Available MIME alone does not mean these checks ran. У звіті розрізняють завершені, пропущені та недоступні перевірки. Оцінки аналізатора не є відсотком папки "Вхідні" чи встановленою причиною спаму.

SpamAssassin і Rspamd використовують різні правила та порогові значення; їхні результати не усереднюються для ймовірності доставки. Збережений знімок екрана показує повідомлення в його захопленому контексті, а не тест кожного поштового клієнта. Відсутній знімок екрана не робить вимірювання папки недійсним.

Отримана копія

Ми аналізуємо доступну копію повідомлення. Неповні, зашифровані або недоступні частини не вважаються успішно перевіреними.