# Проверка на Reverse DNS: как да запитате и настроите PTR запис

> Как да проверите Reverse DNS записа на един IP адрес с dig, host и nslookup, да го зададете при доставчика и да изпълните правилата за пощенски сървъри.

Quelle: https://whovisit.app/bg/blog/reverse-dns-proverka-ptr-zapis-nastrojka
Veröffentlicht: 2026-11-07
Herausgeber: Whovisit (ARAVILO, Innsbruck)

Който управлява пощенски сървър, рано или късно среща съобщението за грешка „no reverse DNS“ или „PTR missing“. Има се предвид Reverse DNS записът на адреса на Вашия сървър. Тази статия показва как да го запитате, какво трябва да постига при пощенските сървъри и как да го наредите да бъде настроен. Как от име на хост да заключите към фирма, е описано в [PTR запис: как от име на хост става фирма](https://whovisit.app/blog/ptr-rueckwaertssuche-firma).

## Какво е Reverse DNS

Обикновеният DNS превежда име в адрес. Reverse DNS прави обратното: към един IP адрес връща име. За това има PTR записът. Заявката върви през специален домейн. При IPv4 това е `in-addr.arpa`, при IPv6 `ip6.arpa`. Адресът се обръща при това. От `192.0.2.10` се получава `10.2.0.192.in-addr.arpa`. При IPv6 отделните шестнадесетични цифри се обръщат, както описва [RFC 3596](https://www.rfc-editor.org/rfc/rfc3596).

## Запитване на PTR запис

Всички команди в примера питат за `193.0.6.139`, адреса на RIPE NCC. Заменете го със своя.

| Инструмент | Команда | Добре е да знаете |
|---|---|---|
| dig (macOS, Linux) | `dig -x 193.0.6.139 +short` | Обръща адреса сам. Без `+short` виждате и статуса. |
| host (macOS, Linux) | `host 193.0.6.139` | Най-кратък изход: „domain name pointer …“ |
| nslookup (всички системи) | `nslookup 193.0.6.139` | Има го и под Windows. |

Ако не дойде отговор, няма запис (статус `NXDOMAIN`) или отговорният сървър за имена не отговаря (`SERVFAIL`, изтичане на времето). За IPv6 важи същият начин на писане, например `dig -x 2001:db8::25 +short` с адрес от областта за документация. Който няма конзола, използва онлайн заявка от уебсайтове с DNS инструменти. Наскоро променените записи заради кеширането (TTL) често стигат навсякъде едва след известно време.

## Защо пощенските сървъри го изискват

Приемащите пощенски сървъри обичат да проверяват дали подателят е настроен чисто. Част от тази проверка е Reverse DNS. Основната идея на специализиран език се нарича *forward-confirmed reverse DNS*:

1. За адреса на подателя се запитва PTR записът. Резултат: име на хост.
2. За това име на хост се запитва A записът (при IPv6 AAAA).
3. Ако адресът съвпада с първоначалния, веригата е затворена.

Google изисква за подателите изрично валидни преки и обратни записи. В [насоките за подателите](https://support.google.com/a/answer/81126) е записано, че адресът на подателя трябва да съвпада с адреса на името на хоста, посочено в PTR записа. И [RFC 1912](https://www.rfc-editor.org/rfc/rfc1912) препоръчва в раздел 2.1 PTR и A записите да си съответстват, а PTR записът да не сочи към CNAME. Дали друг получател проверява строго, е записано в неговата собствена документация. Смятайте, че липсващ или неподходящ запис води до отхвърлени имейли или такива, попаднали в папката за спам.

## Как да го наредите да бъде настроен

PTR записа не задавате в собственото си управление на домейни. Той стои в зоната, която принадлежи на адресния блок. Нея управлява този, на когото е разпределен блокът. По правило това е Вашият доставчик или хостинг.

1. Изберете името на хост, под което трябва да се явява Вашият пощенски сървър, например `mail.beispiel-firma.example`.
2. Създайте във Вашата собствена DNS зона A записа: `mail.beispiel-firma.example` сочи към `192.0.2.10`.
3. Въведете в клиентския портал на доставчика Reverse DNS записа за `192.0.2.10`. При много хостинги това е поле до IP адреса. Иначе е достатъчно запитване до поддръжката с адреса и желаното име.
4. Проверете с `dig -x` и после с `dig mail.beispiel-firma.example +short` дали двете посоки си съответстват.
5. Уверете се, че името съответства и на поздрава (HELO/EHLO) на Вашия пощенски сървър.

Ако имате собствен адресен блок, регистърът пренасочва зоната към Вашите сървъри за имена. За блокове, по-малки от /24, процедурата описва [RFC 2317](https://www.rfc-editor.org/rfc/rfc2317). В такъв случай първо попитайте Вашия доставчик.

Два препъникамъка са чести. Ако сървърът има няколко адреса, всеки се нуждае от собствен запис. И с динамични адреси, каквито имат частните връзки, по правило не получавате свободно избрано име. Който изпраща оттам имейли, по-добре да използва услуга за препращане (Relay).

## Когато проверката се провали

| Наблюдение | Възможна причина |
|---|---|
| Няма запис | Доставчикът не е задал нищо, записът липсва за този адрес |
| Записът сочи към събирателно име на доставчика | Собствено име никога не е заявявано |
| Името не се разрешава към същия адрес | A записът липсва или сочи към стар адрес |
| Работи само IPv4 | За IPv6 записът липсва, Google посочва това в документацията си |
| Промяната не се вижда | Кеш, изчакайте или питайте директно сървъра за имена на доставчика |

Reverse DNS не заменя автентикацията на имейли. SPF, DKIM и DMARC са отделни теми. Но без подходящ PTR запис един пощенски сървър бързо остава под радара на получателите.

## Какво Reverse DNS не доказва

Записът е доброволен и се поддържа от мрежовия оператор. Той не казва кой използва един адрес. Затова е подходящ като указание, а не като доказателство, ако искате да знаете [на кого е един IP адрес](https://whovisit.app/blog/ip-adresse-inhaber-herausfinden). За това мрежовият регистър е по-надеждният източник. Взаимодействието на двата пътя обяснява [Reverse IP Lookup, обяснен просто](https://whovisit.app/blog/reverse-ip-lookup-erklaert).

## Често задавани въпроси

**Трябва ли всеки IP адрес да има PTR запис?** Не, той е доброволен. За сървъри, които изпращат имейли, на практика е задължителен, защото получателите го проверяват.

**Мога ли сам да променя PTR записа?** Само ако управлявате обратната зона на адреса. При адреси на Вашия доставчик или хостинг той задава записа, най-често през клиентския портал или при поискване.

**Каква е разликата между Reverse DNS и Whois?** Reverse DNS връща име на хост и се задава от мрежовия оператор. Whois или RDAP назовава собственика на адресния диапазон. Това са различни бази данни с различна цел.