Ikiwa una seva yako ya barua pepe au unakusudia kuunda Orodha ya barua kutoka kwa kikoa chako mwenyewe, ni muhimu sana kwako kujilinda kutokana na ukweli kwamba wapokeaji hawazingatii barua zako kama kinachojulikana kama barua taka.
Ukweli ni kwamba wengi huduma za posta kupunguza kiasi cha zisizohitajika na madhara mawasiliano ya kielektroniki(yaani, barua taka hii) angalia rekodi ya PTR ya mtumaji. Na ili kuhakikisha kuwa barua pepe zako hazizingatiwi barua taka, na jina la kikoa chako halijajumuishwa katika kategoria ya watumaji wasiotakikana, jambo la kwanza unahitaji kufanya ni kuweka rekodi ya PTR kwa seva yako ya barua.
Jina la aina hii ya rekodi linatokana na neno la Kilatini pointer, ambalo linamaanisha "pointer". Kimsingi, inahusisha anwani ya IP na jina la kikoa chako, kumaanisha rekodi ya PTR ni sawa na rekodi A kwa seva ya DNS. Ikiwa wa kwanza anaunganisha kikoa na anwani ya IP ya eneo la tovuti, basi pili, kinyume chake, inaunganisha anwani ya IP na kikoa.
Jinsi ya kuangalia rekodi ya PTR mtandaoni
Barua kutoka kwa orodha ya barua inapofika kwenye seva ya barua, inaikagua kabla ya kukabidhi barua iliyopokelewa kwenye folda ya "Kikasha" au "Barua taka". Hatua ya kwanza ni kuangalia rekodi ya PTR ya IP ambayo barua hiyo ilitoka. Ikiwa rekodi ipo na inalingana na data ya kikoa cha mtumaji, basi hii inaweza kuwa mojawapo ya vipengele muhimu katika uidhinishaji wa mawasiliano na utumaji wake kwenye kikasha.
Ikiwa rekodi ya PTR hailingani au haipo kabisa, basi kuna uwezekano mkubwa kwamba barua itaishia kwenye Barua Taka. Walakini, kwa kukosekana kwa rekodi hii, seva itaangalia mawasiliano kulingana na idadi ya vigezo vingine, lakini uthibitishaji utakuwa mkali sana.
Jinsi ya kuangalia rekodi ya PTR kwa seva ya barua?
Kuangalia rekodi ya PTR mtandaoni kunahusisha kutekeleza ombi katika kikoa cha in-addr.arpa, na jibu linakuja. andika tena PTR. Kwa mfano, ikiwa anwani yako ya mwenyeji ni 111.222.333.444, basi inatafsiriwa kwa mpangilio wa kinyume na inaonekana kama 444.333.222.111.in-addr.arpa.
Kwa ujumla, kuna njia kadhaa za kuangalia rekodi yako ya PTR. Wacha tuangalie rahisi zaidi kati yao.
Chaguo la kwanza ni kuangalia mtandaoni kwa kutumia huduma maalum za whois. Ninawezaje kuangalia rekodi ya Ptr kwa seva ya barua kwa njia hii? Mara nyingi, inatosha tu kuingiza IP kwenye mstari wa uthibitishaji. Kwa mfano, unaweza kutumia huduma kutoka kwa RigWEB kwa hili na ndani ya sekunde chache kupokea taarifa zote muhimu, ikiwa ni pamoja na rekodi unayotafuta.
Chaguo la pili ni kuangalia rekodi ya PTR kwa kutumia mstari wa amri. Kwa Windows hii inafanywa kama ifuatavyo:
- Bonyeza Anza na uchague Run.
- Andika cmd.
- Katika mstari wa amri unaofungua, ingiza nslookup -type=PTR IP, ambapo IP ni anwani yako ya IP.
- Angalia ripoti iliyopokelewa - ndani yake utapata rekodi ya PTR unayohitaji.
Kwa familia ya Unix ya mifumo, mpango wa vitendo ni tofauti kidogo: fungua terminal au console na uingize amri dig -x IP, ambapo IP ni anwani yako ya IP. Kama matokeo ya kutekeleza amri, utaonyeshwa ripoti ambapo unaweza pia kuona rekodi ya PTR.
Vinginevyo, unaweza kuendesha hundi Rekodi za PTR mtandaoni. Je, hundi ilionyesha kutokuwepo kwa rekodi ya PTR? Kisha lazima iandikishwe.
Jinsi ya kuongeza rekodi ya PTR kwa seva ya barua
Ikiwa hujui jinsi ya kusajili rekodi ya PTR kwa seva ya barua, basi labda utahakikishiwa na ukweli kwamba ni rahisi sana kufanya. Ili kufanya hivyo, unahitaji tu kuwasiliana na mmiliki wa anwani ya IP ambayo tovuti yako imeunganishwa. Tuma ISP wako ombi la kuongeza rekodi ya PTR kwani unahitaji moja kwa anwani yako ya IP. Kwa mwenyeji wa kawaida, kwa kawaida hauitaji kusajili chochote, kwani ingizo hili mara nyingi tayari lipo.
Je, unakodi seva maalum iliyojitolea na unataka kujua jinsi ya kusajili rekodi ya PTR kwa VDS? Katika kesi hii, unahitaji kwenda jopo la utawala, nenda kwenye sehemu ya huduma za upangishaji, kisha uchague "Badilisha rekodi ya reverse DNS", na kisha uthibitishe chaguo lako.
Kama unaweza kuona, hakuna kitu ngumu. Jambo lingine ni kwamba mengi katika hali hii inategemea mtoaji mwenyeji, au kwa usahihi, kwa kasi ya majibu ya msaada wake wa kiufundi. Kwa hivyo, inafaa kuwa mwangalifu sana katika kuchagua mwenyeji tangu mwanzo. Na ikiwa unataka kutumia mwenyeji wa kitaaluma na hali rahisi zaidi na nzuri, basi unapaswa kuzingatia huduma zinazotolewa na RigWEB.
Kwa kutumia mwenyeji wetu, hutahangaika kuhusu jinsi ya kuunda rekodi ya PTR, kwa sababu tunajali kuhusu faraja ya wateja wetu na kujaribu kutoa zaidi. huduma bora. Kulingana na kile unachochagua mpango wa ushuru, tuko tayari kukupa anuwai ya huduma, ambayo ni pamoja na kuweka rekodi ya PTR, ikiwa unahitaji. Kutoka uhamisho wa kawaida tovuti yetu mwenyeji wa kawaida kabla ubinafsishaji kamili Seva za VDS ndani haraka iwezekanavyo- tutafurahi kukusaidia kutatua shida zozote.
Kwa kuongeza, tunakuhakikishia:
- Uendeshaji thabiti na UpTime 99.9%
Shukrani kwa utumiaji wa vifaa vya hali ya juu vilivyowekwa katika vifaa kamili neno la mwisho teknolojia katika kituo cha data chini ya usimamizi wa saa-saa wa wataalamu wenye uzoefu, tunatoa ya juu iwezekanavyo hali ya kisasa Seva za UpTime na kazi imara tovuti zako.
- Msaada wa kiufundi wa haraka na uliohitimu
Unaweza kuuliza wataalamu wetu maswali yoyote kuhusiana na uendeshaji wa mwenyeji wetu. Usaidizi wa kiufundi wa RigWEB hufanya kazi 24/7/365 na hujibu ndani ya dakika 30 kutoka wakati tiketi inatumwa, ili uweze kuwa na uhakika uamuzi wa haraka tatizo lako. Kwa hivyo ikiwa hujui jinsi ya kutengeneza rekodi ya PTR kwa kutumia upangishaji wetu, unaweza kuwauliza wataalamu wetu swali hili kwa usalama.
- Ushuru wa haki na bei ya uwazi
Hakuna ada zilizofichwa! Utajua kila wakati unacholipa, na kwa kurudi utapokea 100% ya rasilimali za seva zetu ulizolipia.
Tumia upangishaji wa kitaalamu kutoka kwa RigWEB na ufurahie kufanya kazi kwenye miradi yako, kwa sababu unaweza kutegemea masharti mazuri na yanayofaa zaidi ya ushirikiano nasi!
Katika nyenzo zetu zilizopita, tayari tuliangalia kusanidi eneo la DNS operesheni sahihi seva ya barua, pamoja na jukumu la rekodi za DNS za kibinafsi. Walakini, kama inavyoonyesha mazoezi, sio wasimamizi wote wanaelewa kwa usahihi utaratibu wa uendeshaji wa mifumo Barua pepe na rekodi za DNS. Kwa hivyo, tuliamua kutoa nakala tofauti kwa suala hili, ambalo tutalichambua kwa undani zaidi na kulizungumza kwa kulinganisha. teknolojia mpya SPF
Tatizo kuu la kisasa mifumo ya posta- barua taka. Wapo wengi mbinu mbalimbali kupigana nayo, lakini moja kuu ni uchambuzi wa mtumaji, kutokana na kwamba taarifa zote muhimu zinapatikana katika barua.
Wacha tuchore mlinganisho na barua ya kawaida. Bahasha ya posta au kifurushi daima huwa na anwani ya mtumaji, anwani ya mpokeaji na mihuri ya ofisi za posta ilizotembelea. kutuma barua. Vile vile, barua pepe ina katika vichwa vyake habari kuhusu mtumaji, mpokeaji na alama za kiufundi. seva za barua ambao walishiriki katika usindikaji wa barua.
Wacha tuseme ulipokea kifurushi cha kutiliwa shaka sana kwenye ofisi ya posta, inayodaiwa kutoka kwa babu yako mpendwa Konstantin Makarovich, lakini kwa sababu fulani muhuri wa mtumaji hauelekezi kwa ofisi ya posta ya kijiji cha Makarovka, lakini kwa shamba la Gadyukino kwa upande mwingine. upande wa nchi. Je, utafungua kifurushi kama hicho, ukihatarisha kupata spora za kimeta badala ya mtungi wa tufaha za jamu ya paradiso, au utakirudisha, bila kudhuru?
Vile vile ni kweli kwa mifumo ya barua pepe. Ikiwa ulipokea barua kutoka kwa babu yako [barua pepe imelindwa] , lakini seva ya kutuma kwa sababu fulani mail.spam.com, basi hii ni sababu ya kutokubali barua hiyo, kwa kuwa kuna uwezekano mkubwa wa barua taka.
Tumetekeleza vipi hundi hii? Rahisi sana, angalia muhuri ofisi ya Posta mtumaji na kuilinganisha na anwani ya kurudi. Kwa mfano, kwenye bahasha imeandikwa kwamba mtumaji yuko katika jiji la Moscow, lakini muhuri wa ofisi ya kutuma ina index 683000, ambayo inaonyesha Petropavlovsk-Kamchatsky. Kwa hivyo, hatutakubali barua kama hiyo, kwani haijapitisha uthibitishaji wa mtumaji.
Hali ni sawa na kwa barua pepe, badala ya index ya idara ya kutuma hutumiwa Rekodi ya PTR. Kwa hivyo, baada ya kupokea barua kutoka kwa babu, tutafanya ombi la PTR na ujue kuwa seva inayotuma ni yetu mail.spam.com, wakati kulingana na habari iliyopitishwa wakati wa unganisho inapaswa kuwa mail.example.com. Kila kitu kiko wazi, barua huenda kwa barua taka.
Walakini, ikiwa kichwa kinaonyesha kuwa seva inayotuma ni yetu mail.spam.com, basi barua kama hiyo inafanikiwa itajaribiwa Na Rekodi za PTR, licha ya ukweli kwamba kikoa cha seva ya mtumaji hakilingani kikoa cha barua barua.
Kwa nini hii inatokea? Kwa sababu kuangalia na Rekodi za PTR hukuruhusu kubainisha tu kwamba seva inayotuma ni kweli inadai kuwa. Lakini kwa njia yoyote huamua uhalisi wa mtumaji mwenyewe. Wale. akimaanisha mfano barua ya kawaida tunaangalia tu kwamba anwani ya kurudi na msimbo wa posta wa ofisi ya mtumaji ni sawa; PTR barua kama hiyo haikupitia, lakini ikiwa mahali pa kuondoka na mechi ya index, basi kila kitu ni sawa na sasa kazi yako ni kufikiria nini babu yako mpendwa anafanya huko Petropavlovsk-Kamchatsky.
Kutokuelewana kwa jambo hili kunasababisha ukweli kwamba Rekodi ya PTR inageuka kuwa imeundwa vibaya na, kwa sababu hiyo, barua nyingi zinazotumwa hazifikii mpokeaji. Hii ni muhimu kuelewa wakati wa kusanidi seva zinazohudumia vikoa vingi. Kwa kesi hii Rekodi ya PTR lazima ielekeze kwa jina la mpangishi wa barua (ambalo hutuma kama sehemu ya kipindi cha SMTP), hata ikiwa iko katika kikoa tofauti.
Hebu tuangalie mfano rahisi.
Seva mail.example.com hutuma barua pepe kwa kikoa kinachohudumia mfano.org. Seva inayopokea inatoa ombi Rekodi za PTR na inahakikisha kwamba anwani 123.123.123.123 kweli ni mail.example.com, kwa hivyo barua kama hiyo itakubaliwa, ingawa kikoa cha mtumaji wa barua na kikoa cha seva ya kutuma hazifanani.
Na sasa hali ni tofauti.
Msimamizi amesanidi eneo la DNS vibaya kwa kubainisha mwenyeji asiye sahihi Rekodi za PTR. Seva inayopokea, baada ya kuangalia Rekodi ya PTR itakataa barua yetu kwa sababu seva inayotuma hailingani na matokeo ya hoja ya kinyume cha DNS.
Kutokuwepo Rekodi za PTR karibu kila mara husababisha kukataliwa kwa barua, kwa sababu kuna makubaliano ambayo hayajasemwa kwamba mtumaji wa bona fide ana eneo la kurudi lililowekwa kwa usahihi.
Turudi kwa babu yetu. Wacha tuseme alikuambia kuwa katika msimu wa joto ataondoka katika kijiji cha Makarovka kwenda kijiji jirani cha Ivanovka, kwa Marfa Vasilievna fulani, na anatarajia kukutumia barua kutoka hapo. Katika kesi hii, utakubali kwa usalama barua kutoka kwa babu yako kutoka Makarovka na kutoka Ivanovka, lakini utakataa barua ya babu inayodaiwa kutoka Petropavlovsk-Kamchatsky.
Teknolojia sawa katika mifumo ya barua pepe inatekelezwa kwa kutumia teknolojia SPF. Kwa kifupi, basi teknolojia hii hukuruhusu kuunda rekodi maalum ya DNS ambayo itaonyesha ni nani haswa ana haki ya kutuma barua kwa niaba ya kikoa chako. Katika sana toleo rahisi kiingilio kitaonekana kama:
Example.com. KATIKA TXT "v=spf1 +a +mx -yote"
Ina maana gani? Ukweli kwamba kwa barua ya kikoa cha example.com inaweza kutumwa na nodi zilizobainishwa katika rekodi A (+a) na rekodi za MX (+mx), barua zingine zote zinapaswa kukataliwa (-zote).
Walakini, sio kila kitu ni cha kupendeza sana. Kwanza, msaada wa SPF bado sio kiwango cha ukweli na hakuna Rekodi za SPF Kikoa cha mtumaji hakina sababu ya kukataa barua. Tatizo la pili ni kusambaza seva au kesi wakati barua inatumwa na seva ambazo hazijaorodheshwa katika rekodi za A au MX, au hata ziko katika vikoa vingine. Hii inaweza kuwa kutokana na usanifu wa mfumo wa IT wa biashara na matumizi ya seva za watu wengine kutuma unapounganisha kikoa chako kwa mtoa huduma au huduma ya umma. Katika kesi ya mwisho, unahitaji kuwa makini hasa na inashauriwa sana kushauriana na usaidizi wa huduma.
Hebu tuchunguze hali nyingine.
Kampuni yako, pamoja na seva yako kuu ya barua mail.example.com, hutumia huduma huduma za mtu wa tatu, ambaye anaweza kutuma barua kwa wateja wa kampuni kwa niaba yake. Hii inaweza kuwa huduma ya barua pepe ya haraka ambayo itawajulisha wateja kwa niaba yako kuhusu hali ya uwasilishaji, nk.
Katika mfano wetu, barua kama hiyo itatumwa kwa niaba ya [barua pepe imelindwa] kutoka kwa seva mail.web-service.com, kwa sababu seva hii haijaorodheshwa katika rekodi za MX za kikoa mfano.com, basi, kulingana na kile tulichoonyesha Rekodi za SPF Kama sheria, barua kama hiyo itakataliwa na mpokeaji.
Kwa kuongezea, tabia ya seva inayopokea haitakuwa na utata, kwani sisi wenyewe tumeonyesha wazi kuwa barua kutoka kwa watumaji wengine haipaswi kukubaliwa. Kwa hivyo, ikiwa huna uhakika kwamba barua zote zitatoka kwa seva zako pekee, basi unapaswa kutaja sheria laini zaidi:
mfano.org. KATIKA TXT "v=spf1 +a +mx ~all"
Tofauti -yote(kushindwa) ~wote(soft fail) inaonyesha kuwa watumaji mbali na wale waliobainishwa waziwazi hawaruhusiwi kutuma barua, lakini haina sharti la kukataa barua hizo. Mara nyingi, barua kama hiyo inakubaliwa, iliyowekwa alama kama zisizohitajika.
Unaweza pia kutumia kiambishi awali cha upande wowote:
mfano.org. KATIKA TXT "v=spf1 +a +mx ?wote"
Katika kesi hii, sheria inasema kwamba majeshi yaliyotajwa katika A- na rekodi za MX, hakuna habari kuhusu nodi zilizobaki. Mapokezi ya barua kutoka kwa nodi zisizoidhinishwa ni kwa hiari ya seva inayopokea mara nyingi barua kama hiyo itakubaliwa bila alama zozote.
Tunapaswa kufanya nini katika kesi yetu? Suluhisho sahihi zaidi itakuwa kuongeza Kuingia kwa SPF kanuni moja zaidi:
mfano.org. KATIKA TXT "v=spf1 +a +mx +mx:web-service.com -yote"
mfano.org. KATIKA TXT "v=spf1 +a +mx +a:mail.web-service.com -yote"
katika kesi ya kwanza, tutaruhusu kupokea barua pia kutoka kwa seva zote zilizoorodheshwa kwenye rekodi za MX za kikoa web-service.com, katika kesi ya pili tu kwa seva mail.web-service.com.
Hatimaye, hebu tuzingatie kesi wakati barua za kikoa chako zinatumwa na seva iliyo katika kikoa kingine. Kwa mfano mail.example.com pia hutuma barua kwa kikoa mfano.org. Katika hali hii, itakuwa sahihi kutumia kwa kikoa mfano.org sheria sawa na kwa mfano.com. Ili kufanya matumizi haya aina maalum maingizo:
mfano.org. KATIKA TXT "v=spf1 redirect=example.com"
Hii itakuruhusu kubadilisha rekodi mara moja tu, ikiwa ni lazima, kwa kikoa kikuu na kuwaondoa wasimamizi wa vikoa vingine vinavyokubalika kutokana na kufuatilia na kufanya mabadiliko kwenye rekodi za DNS.
Lebo:
Kwa operesheni sahihi seva ya barua, ni muhimu kuiweka vizuri Ukanda wa DNS, ambayo lazima iwe na rekodi za A, MX na PTR. Ikiwa kila kitu kiko wazi zaidi au kidogo na mbili za kwanza, basi weka rekodi ya PTR ( ukanda wa nyuma, wakati ni muhimu kuangalia jina la seva kujua anwani yake ya IP) mara nyingi husababisha matatizo katika kuelewa ambapo inapaswa kusajiliwa na ni nani anayehusika nayo. Bila rekodi ya PTR, baadhi ya seva za barua zitakataa kupokea barua kutoka kwa seva yako, na kukutumia kitu kama hiki:
550-Hakuna rekodi ya kinyume (PTR) iliyopatikana kwa mwenyeji wako au Rekodi hailingani 550 na rekodi ya PTR (kwa kujibu amri ya RCPT TO) 550-Reverse DNS utafutaji umeshindwa. Ikiwa unafikiri hii si sawa, wasiliana na 550 postmaster. (kwa kujibu amri ya RCPT TO) 550 5.7.1 Uwasilishaji umekataliwa. Jina la IP limeghushiwa (PTR na rekodi zisizolingana) za ###.###.###.### (kwa kujibu MAIL FROM amri)
Kwa hivyo ugumu ni nini hasa? Kwanza, kuna kutokuelewana kwa jinsi DNS inavyoundwa na kufanya kazi, na pili, kusitasita kwa baadhi ya watoa huduma kutekeleza majukumu yao ya moja kwa moja au uzembe wa "wataalamu wa kiufundi", kama vile wapumbavu wenyewe. Kwa bahati mbaya, hii pia hutokea. Lakini hebu jaribu kufikiri.
Hebu fikiria hali ya kawaida. Kwa sababu fulani, huna tena uwezo wa kutosha wa seva ya barua iliyotolewa na mwenyeji ambapo tovuti yako iko (au umesajili kikoa tu na unataka kusanidi seva yako ya barua). Kutoka kwa mtoa huduma wako uliyepokea anwani ya ip tuli(au hata mtandao mdogo) na rekodi za A na MX zilizosajiliwa kwenye mwenyeji zikionyesha mtumaji wako (anwani sawa ya IP uliyopewa na mtoa huduma wako).
Lakini basi kuna mkanganyiko kuhusu ni nani anayepaswa kupangisha rekodi ya PTR kuhusu seva yako ya barua - mwenyeji (yule anayeendesha seva za DNS zinazohusika na kikoa chako) au mtoaji (aliyekupa anwani ya IP tuli). Kuamua jina la mwenyeji kwa anwani yake ya IP, kuna maalum eneo la kikoa katika-addr.arpa.
Kwa hiyo, yeyote aliyekupa anwani ya IP tuli huandika rekodi za PTR kwenye seva yao ya DNS kwa seva yako ya barua katika eneo la in-addr.arpa. Ili kufanya hivyo, unahitaji kutuma ombi kwa mtu ambaye alikupa anwani ya IP tuli na ombi la kusajili rekodi ya PTR kwa kikoa chako.
Kumbuka: ikiwa anwani za seva ya kikoa na barua hazilingani, basi rekodi ya PTR lazima iundwe mahsusi kwa rekodi ya MX.
Rekodi ya DNS in-addr.arpa ya seva ya barua mail.mydomain.ru yenye anwani 123.45.67.89 inaonekana kama hii:
123.45.67.89.in-addr.arpa. KATIKA PTR mail.mydomain.ru.
Angalia rekodi ya PTR ikiwa imewashwa Seva ya DNS unaweza kutumia amri kuangalia au huduma sawa ya mtandaoni (kwa mfano http://www.nslookup.su). Kwenye mstari wa amri tunaita kuangalia na kuandika:
>weka aina=PTR<-- установили тип ресурсной записи > 93.158.134.89 <-- интересующий ip-адрес ----- полученный ответ ----- Не заслуживающий доверия ответ: 89.134.158.93.in-addr.arpa name = mx.yandex.ru 134.158.93.in-addr.arpa nameserver = ns1.yandex.net 134.158.93.in-addr.arpa nameserver = ns2.yandex.net ns1.yandex.net internet address = 213.180.193.1 ns2.yandex.net internet address = 93.158.134.1 >
Katika uwanja wa `jina` tunaona jina la moja ya seva za barua za Yandex. Katika mpangilio sahihi ukanda wa nyuma, sehemu hii inapaswa kuonyesha jina la seva yako ya barua kwenye anwani ya IP inayolingana.
Kuna aina nyingi Rekodi za DNS na inaweza kuwa vigumu kwa wanaoanza kuelewa kazi ya rekodi hii ya DNS ni nini au jinsi ya kuisanidi. Katika somo hili utajifunza rekodi ya PTR ni nini na jinsi ya kuangalia ikiwa imesanidiwa kwa anwani ya IP.
Rekodi ya PTR ni nini?
Rekodi ya PTR ni kama toleo la kinyume la rekodi A. Rekodi A huhusisha jina la kikoa na anwani ya IP, na rekodi ya PTR inahusisha anwani ya IP na jina la mwenyeji. Hata hivyo, maingizo haya mawili yanajitegemea..21.128.xx, ilhali 23.23.128.xx inaweza kuhusishwa na jina la mpangishi tofauti kabisa.
Kwa nini rekodi ya PTR inahitajika?
Ni muhimu kwa seva za barua zinazotoka. Ingizo hili huboresha uaminifu wa seva inayotuma na huruhusu jibu la kurejesha ili kuthibitisha jina la mpangishaji kupitia anwani ya IP. Hii njia kuu ulinzi dhidi ya aina zote za watumaji taka wanaotumia majina ya kikoa ya ulaghai kutuma barua taka. Ndio maana wengine watoa huduma wakubwa Huduma za barua kama vile yahoo.com, gmail.com hutafuta upya DNS kabla ya kukubali barua pepe zinazoingia.
Kabla ya kuanza mwongozo huu, utahitaji zifuatazo:
- Ufikiaji wa koni ya kompyuta yako (si lazima)
Njia ya 1 - Kuangalia PTR kwa kutumia nslookup au kuchimba
Windows, Unix na sawa Mfumo wa Uendeshaji(Linux, MacOS) zina vifaa vya kujengwa vya Hundi za DNS kumbukumbu. Kama wewe ni Mtumiaji wa Windows, fuata hatua hizi:
- Ingiza menyu Anza Windows , ingia cmd na bonyeza INGIA.
- Dirisha nyeusi inapaswa kuonekana ( mstari wa amri madirisha).
- Ingiza amri ifuatayo ili kupata jina la mwenyeji wa anwani ya IP (badilisha IP_ADDESS kuwa IP unayohitaji):
- Kwa mfano, ikiwa unataka kuangalia rekodi ya PTR ya 54.243.154.xx, utaona matokeo sawa:
Kama inavyoonekana kutoka kwa matokeo, rekodi ya PTR ni ec2-54-243-154-49.hostinger.com.
Kwa Watumiaji wa Linux au Mchakato wa Mac sawa:
- Kwenye MacOS, ingia kwenye terminal ukitumia ( F4) Wengi Usambazaji wa Linux hukuruhusu kufungua terminal na njia ya mkato ya kibodi Ctrl+Alt+T.
- Tumia amri hii kuangalia rekodi ya PTR (badilisha IP_ADDRESS kuwa IP unayohitaji):
- Kwa mfano, haya ni matokeo ya kuangalia rekodi ya PTR kwa anwani ya IP 54.243.154.xx:
Kutoka kwa sehemu SEHEMU YA MAJIBU unaweza kujua thamani ya PTR ya rekodi - ec2-54-243-154-49.hostinger.com
Njia ya 2 - Kutumia Zana za Mtandaoni
Njia nyingine ya kupata habari kuhusu jina la mwenyeji wa anwani ya IP ni kutumia zana ya kuangalia nyuma ya MxToolBox. Unachohitaji kufanya ni kuingiza anwani ya IP kwenye uwanja na bonyeza kitufe Reverse Lookup.
Hitimisho
Kwa bahati mbaya, ikiwa utafutaji utaonyesha kuwa ingizo halijasanidiwa kwa anwani ya IP, mara nyingi itabidi uwasiliane na mwenyeji wako au ISP ili kuunda moja. Walakini, sasa unajua rekodi ya PTR ni nini na jinsi ya kuangalia ikiwa ina anwani ya IP. Hii ni muhimu ikiwa utapata hitilafu za DNS na bounces unapojaribu kutuma barua pepe, kwani itakusaidia kutatua tatizo.
Seva zote za barua zinazounganisha kwenye seva za barua lazima ziwe na rekodi halali na za maana za kubadili DNS.
Anwani za rDNS zilizosanidiwa kwa usahihi zinahitajika ili kutuma ujumbe kutoka kwa seva yako mwenyewe. Takriban seva zote za barua zitakataa ujumbe mwanzoni mwa kipindi ikiwa anwani ya IP ya seva yako haina ingizo katika ukanda wa DNS wa kinyume. Sababu ya kushindwa kwa seva ya barua pepe ya mbali inaweza kuwa kama ifuatavyo:
550-"Anwani ya IP haina rekodi ya PTR (anwani ya jina) katika DNS, au wakati rekodi ya PTR haina rekodi inayolingana ya A (jina la kushughulikia). Pls angalia na urekebishe rekodi yako ya DNS." 550-Hakuna PTR inayolingana ya anwani yako ya IP (IP-anwani), ambayo inahitajika 550. Samahani, kwaheri. 550 IP yako haina Rekodi ya PTR.
Nambari 550 katika visa vyote vitatu ni msimbo wa kawaida wa seva ya barua ya SMTP, ikiripoti hitilafu kubwa ambayo inazuia kazi zaidi ndani ya kipindi hiki cha barua. Kwa ujumla, makosa yote katika mfululizo wa 500 ni muhimu na haiwezekani kuendelea kutuma barua baada ya kuonekana. Maandishi yanaeleza sababu ya kukataa kwa undani zaidi na inasema kwamba msimamizi wa seva ya barua pepe ya mpokeaji ameisanidi ili kuangalia ikiwa seva ya barua inayotuma ina ingizo katika ukanda wa nyuma wa DNS (rDNS) na ikiwa haipo, mpokeaji. seva inalazimika kukataa muunganisho wa mtumaji (makosa ya mfululizo wa SMTP- 5XX).
Inaweka rDNS
Mmiliki pekee wa kizuizi kinacholingana cha anwani za IP ambazo eneo hili linalingana ndiye ana haki ya kusanidi ukanda wa DNS wa kinyume. Kama sheria, mmiliki huyu ndiye mtoaji, ambaye anamiliki mfumo wake wa uhuru.
Ili kusajili ukanda wa reverse DNS, opereta wa kizuizi cha anwani ya IP lazima asajili kitu cha aina ya "kikoa" katika akaunti yake ya kibinafsi kwenye wavuti ya RIPE, aonyeshe anwani ya seva za DNS ambazo zitasaidia eneo la rDNS na kusanidi usaidizi wa eneo. ya fomu 3.2.1.in-addr.arpa juu yao. Kielelezo, rekodi ya PTR, inawajibika kwa rasilimali katika ukanda wa nyuma. Maombi ya kusuluhisha anwani ya IP na jina la mwenyeji huenda kwake (tazama hapa chini kwa maelezo ya kanuni ya kuunda rekodi ya PTR).
Ikiwa humiliki mfumo unaojiendesha, basi kusanidi rDNS kwa anwani ya IP au anwani za seva ya barua kunaweza kutatuliwa kwa kuomba usaidizi kutoka kwa mtoa huduma au mwenyeji wako.
Katika visa vyote viwili, jina la anwani ya IP ya seva ya barua, na haswa seva ya barua ya kampuni, inapaswa kutolewa kwa maana.
Mifano ya majina mazuri kwa seva ya barua:
Mail.domain.ru mta.domain.ru mx.domain.ru
Mifano ya majina mabaya:
Mpangishi-192-168-0-1.domain.ru mteja192-168-0-1.domain.ru vpn-dailup-xdsl-clients.domain.ru
Majina kama haya yana uwezekano mkubwa wa kuchujwa kama yametumwa kwa kompyuta za mteja ambazo seva ya barua haiwezi kusakinishwa, na kwa hivyo barua taka zinaweza kutumwa kutoka kwao.
Unaweza na unapaswa kutumia maswali kwa mafanikio kubadilisha kanda za DNS mara tu baada ya kuanzisha seva ya barua. Ili kufanya hivyo, unahitaji tu kufanya marekebisho madogo ya programu. Katika seva tofauti za barua, kusanidi ukaguzi wa rDNS hufanywa kwa njia tofauti:
Katika Postfix unahitaji kuwezesha chaguo
Kataa_mteja_asiyejulikana
Thibitisha = reverse_host_lookup
Badilisha ukaguzi wa eneo la DNS: http://remote.12dt.com
Ingiza anwani yako ya IP, ikiwa kikoa chako kinaonyeshwa - mpangilio ni sahihi
PTR
Rekodi ya PTR(kutoka kwa pointer ya Kiingereza - pointer) huunganisha IP ya mwenyeji na jina lake la kisheria. Ombi katika kikoa cha in-addr.arpa kwa IP ya seva pangishi katika mfumo wa kinyume litarudisha jina la seva pangishi hii.
Ili kupunguza kiasi cha barua taka, seva zinazopokea barua pepe angalia rekodi ya PTR kwa mwenyeji ambaye barua pepe inatumwa. Katika hali hii, rekodi ya PTR ya anwani ya IP lazima ilingane na jina la seva ya kutuma barua ambayo inawasilishwa wakati wa kipindi cha SMTP.
katika-addr.arpa- eneo maalum la kikoa iliyoundwa kuamua jina la mwenyeji kwa anwani yake ya IPv4 kwa kutumia rekodi ya PTR. Anwani ya mwenyeji AAA.BBB.CCC.DDD imetafsiriwa kwa nukuu ya kinyume na kuwa DDD.CCC.BBB.AAA.in-addr.arpa. Shukrani kwa muundo wa usimamizi wa jina la kihierarkia, inawezekana kukabidhi usimamizi wa eneo kwa mmiliki wa anuwai ya anwani za IP. Ili kufanya hivyo, rekodi zilizoidhinishwa za seva ya DNS zinaonyesha kuwa seva tofauti inawajibika kwa eneo la CCC.BBB.AAA.in-addr.arpa (yaani, mtandao wa AAA.BBB.CCC/24).
Kwa mfano, ikiwa IP ya seva yako ya barua ni 78.56.158.23. Kisha unahitaji kuongeza rekodi ifuatayo ya DNS kwenye rekodi ya NS ya seva au mipangilio ya mwenyeji (IP imeandikwa kwa utaratibu wa reverse).
