Defaults.Exposed › Поправки › Обратен DNS (PTR)

Как да поправите Обратен DNS (PTR)

Обратният DNS е лентата за самоличност на сървъра, който изпраща бизнес имейлите ви. Когато получаващ доставчик като Gmail или Microsoft 365 търси кой стои зад изпращащия адрес и получи потвърдено ниме, вашата поща изглежда легитимна. Когато няма лента — или нимето и номерът не съвпадат — вашите напълно реални фактури и оферти се третират като подозрителни и тихо се изхвърлят или отхвърлят.

Заключение за вашия бизнес: Вашите фактури, оферти и отговори до клиенти тихо попадат в спам или никога не пристигат — сделките спират, плащанията закъсняват и клиентите смятат, че ги игнорирате, нито едно от тях не се появява като грешка, която бихте забелязали.

Какво може да ви струва това

• Изпращате оферта на горещ потенциален клиент, тя попада в спама им и те избират конкурента, който 'действително е отговорил' — и вие никога не разбирате, че имейлът не е пристигнал.
• Фактурите до клиенти изчезват в нежелана поща, плащанията пристигат седмици по-късно и вашият паричен поток поема удара, защото никой никога не е видял имейла.
• Клиент се оплаква, че никога не сте отговорили — но сте го направили; техният пощенски доставчик тихо е изхвърлил вашия отговор, защото изпращащият сървър не е могъл да докаже кой е.
• Вашият домейн преминава успешно проверката за сигурност на нов клиент по всичко друго, след което бива маркиран, защото вашият пощенски сървър няма правилна самоличност — малко нещо, което ви кара да изглеждате небрежни.
• Преминахте към евтин VPS или нов инструмент за изпращане на вашите бюлетини и фактури и за нощ процентът на доставка пада — защото новият изпращащ сървър няма лента за обратен DNS и големите доставчици вече не му доверяват.

Защо има значение. Всеки голям имейл доставчик проверява самоличността на сървъра, изпращащ вашата поща, и го прави при всяко съобщение. Ако този сървър не може да докаже кой е — или ако неговото ниме и неговият номер си противоречат — вашият истински бизнес имейл се обработва като потенциален спам. Губите отговори, плащания и доверие, и тъй като нищо не се връща, обикновено никога не разбирате защо.

Кратката версия

Когато вашият бизнес изпраща имейл, той излиза от пощенски сървър и всеки сървър в интернет има числов адрес — неговия IP. Обратният DNS (PTR запис) е лентата за ниме на този сървър: позволява на всеки, който вижда числото, да намери правилното ниме зад него, като mail.yourcompany.com.

Големите получаващи доставчици — Gmail, Microsoft 365, Yahoo — проверяват тази лента при всяко съобщение, което изпращате. Сървър, който може да се именува и при който нимето и числото съвпадат помежду си, изглежда като легитимен пощенски сървър. Сървър без лента или с лента, която не съвпада, изглежда точно като анонимните, еднократни машини, използвани от спамърите. Така вашите истински фактури и оферти започват всеки разговор под съмнение — и много от тях губят.

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

Какво може да ви струва това

Това са ежедневните начини, по които липсващ или несъвпадащ запис за обратен DNS се превръща в пари и доверие, излизащи от вратата. Никога не назоваваме реален бизнес — това са модели, които виждаме в данните.

• Офертата, която никога не е пристигнала. Изпращате подробна оферта на потенциален клиент, който е поискал такава онзи ден. Техният доставчик не може да провери изпращащия ви сървър, така че слага съобщението в спама. Те не ровят из нежелана поща. Следобед са взели офертата на конкурента — тази, която „действително се е появила.” Вие го приписвате на бавен потенциален клиент; в действителност имейлът ви никога не е бил видян.
• Фактурата в нищото. Издавате фактура на добър клиент. Тя попада в нежелана поща. Тридесет дни по-късно преследвате просрочено плащане без тяхна вина — и сега има неудобен разговор, напрегнати отношения и пропаст в паричния поток, която е напълно предотвратима.
• “Никога не сте отговорили.” Клиент е разраздразнен, че сте игнорирали въпроса му. Не сте го направили — отговорихте същия ден. Техният пощенски доставчик тихо е изхвърлил отговора ви, защото изпращащият ви сървър е изглеждал ненадежден. Вие изглеждате непрофесионално за нещо, което всъщност сте направили правилно.
• DIY изпращащият сървър, който тихо отрови всичко. За да спестите пари, вашата поща (или само бюлетините и автоматизираните фактури) е започнала да излиза чрез евтин VPS или ново приложение за изпращане. Този сървър никога не е получил лента за обратен DNS. За нощ процентът на доставка е спаднал навсякъде — и тъй като няма съобщение за грешка, отне месеци дори да се подозира причината.
• Флагът от проверка за сигурност. IT екипът на по-голям клиент прави рутинна проверка на вашия домейн при въвеждането. Всичко друго е наред, но вашият пощенски сървър няма правилна самоличност. Технически е маловажен въпрос, но се чете като небрежност — и сега го поправяте под натиск от краен срок или го обяснявате, когато домейнът на конкурент просто е преминал.

Нишката, минаваща между всичко това: разходите падат върху вас, невидими са докато се случват, и поправката е безплатна.

Какво всъщност представлява

Нормалният DNS превръща ниме в число: въвеждате yourcompany.com и DNS ви дава IP адреса за свързване. Обратният DNS прави обратното — превръща число обратно в ниме. Даден IP 203.0.113.10, обратното търсене (PTR запис) отговаря mail.yourcompany.com.

Защо получателите се интересуват: когато вашият пощенски сървър се свързва с Gmail за доставка на съобщение, Gmail вижда свързващия IP. Първото нещо, което сериозен пощенски филтър прави, е да попита „кой е тази машина?” — като прави обратно търсене на този IP. Реален бизнес пощенски сървър има отговор (mail.yourcompany.com). Еднократна спам машина обикновено няма или има общо ниме, присвоено от доставчика, като host-203-0-113-10.someisp.net. Така присъствието и качеството на лентата е един от самите първи сигнали за доверие, приложени към вашата поща — преди SPF, DKIM или съдържанието на съобщението дори да бъдат погледнати.

Проверява пощенския сървър, не вашия уебсайт. Това обърква хората. Адресът на вашия уебсайт често е зад CDN или прокси (като Cloudflare) и никога няма да има съвпадаща лента — и това е нормално, защото обратният DNS за имейл е за IP на MX пощенския сървър, напълно отделна машина. Тази проверка правилно търси основния пощенски сървър на вашия домейн (MX записът с най-нисък приоритет), разрешава го до неговия IP и проверява лентата на този IP.

Половината, която повечето настройки грешат: трябва да съвпада в двете посоки. Наличието на ниме не е достатъчно само по себе си. Gmail и другите големи филтри правят нещо по-строго, наречено forward-confirmed reverse DNS (FCrDNS):

1. Търсете IP → получете ниме (например mail.yourcompany.com).
2. Сега търсете обратно нимето → трябва да разрешава до същия IP, от който сте започнали.

Ако двете посоки съвпадат, сървърът е потвърден и изцяло доверен. Ако има ниме, но то сочи другаде (или никъде), сървърът е само наполовина доверен — лента, която не издържа втори поглед, се третира като по-слаба, отколкото бихте се надявали. PTR, сочещ към ниме, контролирано от нападателя, което не разрешава обратно, е в известен смисъл по-лошо от никакъв PTR.

Точно така тази проверка го оценява:

• Forward-confirmed (FCrDNS): IP именува хост и хостът сочи обратно към същия IP. Пълни точки — това е правилна конфигурация и е това, на което получателите се доверяват.
• Лентата съществува, но не потвърждава: има PTR запис, но нимето не разрешава обратно до IP на пощенския сървър. Само частично признание — изглежда конфигурирано, но големите филтри няма да му се доверят напълно.
• Никаква лента изобщо: няма PTR запис на IP на пощенския сървър. Без признание и разходите за доставяне са реални.

Бележка за теглото: в методологията това е оценена проверка за сигурност на имейл (стойност 25 точки, артикул с приоритет P2). Не е единствената най-тежка проверка за имейл — тя е SPF и DMARC, които спират истинска имперсонация — но е реална, оценена part от вашата имейл позиция и едната от малкото, зависещи от доставчика да направи нещо правилно, а не от вас. Ако изпращате само чрез Google Workspace или Microsoft 365, почти сигурно вече я преминавате; бизнесите, които се провалят, са тези, изпращащи чрез свои собствени или сървъри на трети страни.

Как изглежда „добро”: IP на основния ви пощенски сървър има PTR запис, сочещ към реално ниме, което притежавате, и това ниме разрешава директно обратно до същия IP — двете посоки съвпадат (FCrDNS потвърдено).

Как да го поправите (безплатно, ~10 минути от нечие време)

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

Стъпка 1 — Намерете IP на изпращащия пощенски сървър. Идентифицирайте основния MX хост на домейна (пощенския сървър с най-нисък приоритетен номер) и го разрешете до неговия IP адрес:

dig MX yourcompany.com        # намерете основния (с най-нисък приоритет) MX хост
dig A mail.yourcompany.com    # разрешете хоста до неговия IP

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

Стъпка 2 — Помолете собственика на IP да зададе PTR записа. Обратният DNS се намира при когото контролира IP блока, така че заявката отива при:

• Google Workspace / Gmail: управлява се автоматично за собствените пощенски сървъри на Google — ако домейн, изпращащ само чрез Google, по някакъв начин показва като неуспешен, докладвайте го на поддръжката на Google. (На практика тези преминават.)
• Microsoft 365: по подобен начин управлява се автоматично за сървърите на Microsoft.
• Самостоятелно хостван или VPS пощенски сървър: отворете тикет при вашия хостинг доставчик или центъра за данни, като ги помолите да зададат PTR (обратен DNS) за вашия IP до вашето ниме за поща. Повечето доставчици излагат това в контролния им панел под “Reverse DNS,” “rDNS” или “PTR.” На големите облаци е едно поле настройка (например AWS изисква кратка заявка-форма за активиране на rDNS на Elastic IP; повечето VPS хостове ви позволяват да го зададете незабавно).
• Приложение за изпращане от трета страна (бюлетин / фактуриране / CRM инструмент): ако изпраща от собствените си споделени сървъри, доставчикът обработва обратния DNS — няма нищо, което да зададете, и можете да игнорирате това за този трафик. Ако изпраща от специален IP, закупен от тях, помолете ги да зададат PTR на него.

Кажете им записа, който искате, например: 203.0.113.10 → mail.yourcompany.com.

Стъпка 3 — Направете го forward-confirmed (тази стъпка е тази, която повечето хора пропускат). Нимето в PTR трябва също да разрешава обратно до същия IP чрез нормален A запис, който контролирате в собствения си DNS. Така:

• PTR казва 203.0.113.10 → mail.yourcompany.com (вашият доставчик го задава).
• A записът казва mail.yourcompany.com → 203.0.113.10 (вие го задавате в своя DNS, например Cloudflare → DNS → добавете A запис, Ниме mail, съдържание 203.0.113.10).

И двете посоки трябва да сочат една към друга. Само тогава е forward-confirmed и напълно доверено.

Стъпка 4 — Проверете повторно вашия домейн. Потвърдете, че пощенският сървър вече показва forward-confirmed обратен DNS и проверката преминава. DNS промените се разпространяват в рамките на минути до няколко часа.

Чести грешки

• Задаване на лентата на IP на уебсайта вместо на IP на пощенския сървър. Обратният DNS за имейл е за MX сървъра. Поставянето на PTR на вашия уеб/CDN адрес не прави нищо за доставяемостта — грешната машина получава лентата.
• Спиране на “PTR съществува”. Ниме само по себе си печели само частично доверие. Ако не разрешава обратно до същия IP, строгите филтри (Gmail, M365, Yahoo) няма да му се доверят напълно. Винаги завършвайте forward-потвърждението (Стъпка 3).
• Забравяне на A записа след като доставчикът зададе PTR. Доставчикът задава обратната половина; вие трябва да зададете предната половина в собствения си DNS. Хората правят едното и приемат, че са готови.
• Питане на грешната страна. Изпращането на заявката до регистратора на вашия домейн или DNS хост вместо до собственика на IP ви получава „не можем да го направим” — защото наистина не могат. Трябва да отиде при когото притежава IP.
• Общи ниме на доставчика. PTR като host-203-0-113-10.someisp.net технически съществува, но не прави нищо за вашата марка или доверие. Използвайте реално ниме на собствения си домейн, което forward-потвърждава.

Къде се вписва това

Обратният DNS е самоличността на сървъра; SPF, DKIM и DMARC са слоят за оторизация и защита срещу имперсонация на домейна. Те отговарят на различни въпроси и големите доставчици проверяват всички. SPF изброява кои услуги могат да изпращат като вас; DKIM криптографски подписва вашите съобщения, за да не могат да бъдат манипулирани; DMARC свързва двете заедно и казва на получателите какво да правят с поща, която се проваля — и защитава видимото „from” ниме, което вашите клиенти действително виждат. Обратният DNS седи под всичко това, потвърждавайки, че машината, извършваща изпращането, е реален, именован пощенски сървър на първо място. Направете SPF, DKIM и DMARC правилно за най-силна защита срещу имперсонация; направете обратния DNS правилно, за да не бъде нов или самостоятелно хостван изпращащ сървър тихо недоверен, преди останалото дори да получи шанс. Всяка от тези поправки е безплатна.

ЧЗВ