Jika anda mempunyai pelayan mel anda sendiri atau bercadang untuk mencipta senarai mel daripada domain anda sendiri, adalah amat penting bagi anda untuk melindungi diri anda daripada fakta bahawa penerima tidak menganggap surat anda sebagai apa yang dipanggil spam.

Hakikatnya ramai perkhidmatan pos untuk mengurangkan jumlah yang tidak diingini dan berbahaya surat-menyurat elektronik(iaitu, ini sangat spam) semak rekod PTR pengirim. Dan untuk memastikan bahawa e-mel anda tidak dianggap sebagai spam, dan nama domain anda tidak termasuk dalam kategori penghantar yang tidak diingini, perkara pertama yang perlu anda lakukan ialah menyediakan rekod PTR untuk pelayan mel anda.

Nama rekod jenis ini berasal dari perkataan Latin penunjuk, yang bermaksud "penunjuk". Pada asasnya, ia mengaitkan alamat IP dengan nama domain anda, bermakna rekod PTR sangat serupa dengan rekod A untuk pelayan DNS. Jika yang pertama menghubungkan domain dengan alamat IP lokasi tapak, maka yang kedua, sebaliknya, menghubungkan alamat IP dengan domain.

Cara menyemak rekod PTR secara online

Apabila surat daripada senarai mel tiba di pelayan mel, ia menyemaknya sebelum memberikan surat-menyurat yang diterima kepada folder "Peti Masuk" atau "Spam". Peringkat pertama ialah menyemak rekod PTR untuk IP dari mana surat itu datang. Jika rekod itu wujud dan sepadan dengan data domain pengirim, maka ini boleh menjadi salah satu faktor penentu dalam kelulusan surat-menyurat dan penghantarannya ke peti masuk.
Jika rekod PTR tidak sepadan atau hilang sama sekali, maka terdapat kebarangkalian tinggi bahawa surat itu akan berakhir di Spam. Walau bagaimanapun, jika tiada rekod ini, pelayan akan menyemak surat-menyurat mengikut beberapa kriteria lain, tetapi pengesahan akan menjadi sangat ketat.

Bagaimana untuk menyemak rekod PTR untuk pelayan mel?

Menyemak rekod PTR dalam talian melibatkan pelaksanaan permintaan dalam domain in-addr.arpa, dan respons datang tulis balik PTR. Sebagai contoh, jika alamat hos anda ialah 111.222.333.444, maka ia diterjemahkan dalam susunan terbalik dan kelihatan seperti 444.333.222.111.in-addr.arpa.
Secara umum, terdapat beberapa cara untuk menyemak rekod PTR anda. Mari lihat yang paling mudah daripada mereka.
Pilihan pertama ialah menyemak dalam talian menggunakan perkhidmatan whois khas. Bagaimanakah saya boleh menyemak rekod Ptr untuk pelayan mel dengan cara ini? Selalunya, cukup dengan hanya memasukkan IP dalam baris pengesahan. Sebagai contoh, anda boleh menggunakan perkhidmatan daripada RigWEB untuk ini dan dalam beberapa saat menerima semua maklumat yang diperlukan, termasuk rekod yang anda cari.
Pilihan kedua ialah menyemak rekod PTR menggunakan baris arahan. Untuk Windows ini dilakukan seperti berikut:

1. Klik Mula dan pilih Jalankan.
2. Taip cmd.
3. Dalam baris arahan yang terbuka, masukkan nslookup -type=PTR IP, dengan IP ialah alamat IP anda.
4. Lihat laporan yang diterima - di dalamnya anda akan menemui rekod PTR yang anda perlukan.

Untuk keluarga sistem Unix, skema tindakan adalah berbeza sedikit: buka terminal atau konsol dan masukkan perintah dig -x IP, dengan IP ialah alamat IP anda. Hasil daripada melaksanakan arahan, anda akan ditunjukkan laporan di mana anda juga boleh melihat rekod PTR.
Sebagai alternatif, anda boleh menjalankan semakan rekod PTR dalam talian. Adakah semakan mendedahkan ketiadaan rekod PTR? Kemudian ia mesti didaftarkan.

Bagaimana untuk menambah rekod PTR untuk pelayan mel

Jika anda tidak tahu cara mendaftar rekod PTR untuk pelayan mel, maka anda mungkin akan yakin dengan fakta bahawa ia sangat mudah dilakukan. Untuk melakukan ini, anda hanya perlu menghubungi pemilik alamat IP yang dipautkan tapak anda. Hanya hantar ISP anda permintaan untuk menambah rekod PTR kerana anda memerlukannya untuk alamat IP anda. Untuk pengehosan maya, anda biasanya tidak perlu mendaftar apa-apa, kerana entri ini paling kerap sudah wujud.
Adakah anda menyewa pelayan khusus maya dan ingin tahu cara mendaftar rekod PTR untuk VDS? Dalam kes ini anda perlu pergi ke panel pentadbiran, pergi ke bahagian perkhidmatan pengehosan, dan kemudian pilih "Tukar rekod DNS terbalik", dan kemudian sahkan pilihan anda.
Seperti yang anda lihat, tiada yang rumit. Perkara lain ialah banyak dalam situasi ini bergantung pada penyedia pengehosan, atau lebih tepat lagi, pada kelajuan tindak balas sokongan teknikalnya. Oleh itu, adalah berfaedah untuk menjadi sangat teliti dalam memilih hoster dari awal lagi. Dan jika anda ingin menggunakan pengehosan profesional dengan keadaan yang paling mudah dan sesuai, maka anda harus memberi perhatian kepada perkhidmatan yang disediakan oleh RigWEB.
Menggunakan hosting kami, anda tidak akan risau tentang cara mencipta rekod PTR, kerana kami mengambil berat tentang keselesaan pelanggan kami dan cuba memberikan yang terbaik perkhidmatan yang berkualiti. Bergantung pada apa yang anda pilih pelan tarif, kami bersedia untuk memberikan anda pelbagai perkhidmatan, termasuk menyediakan rekod PTR, jika anda memerlukannya. daripada pemindahan biasa laman web kami pengehosan maya sebelum ini penyesuaian penuh Pelayan VDS masuk secepat mungkin– kami akan berbesar hati membantu anda menyelesaikan sebarang masalah.
Di samping itu, kami menjamin anda:

• Operasi yang stabil dan UpTime 99.9%

Terima kasih kepada penggunaan peralatan berkualiti tinggi yang ditempatkan di dalam yang lengkap perkataan terakhir teknologi di pusat data di bawah penyeliaan 24 jam oleh pakar berpengalaman, kami menyediakan setinggi mungkin keadaan moden Pelayan UpTime dan kerja yang stabil tapak anda.

• Sokongan teknikal yang pantas dan berkelayakan

Anda boleh bertanya kepada pakar kami sebarang soalan berkaitan pengendalian pengehosan kami. Sokongan teknikal RigWEB berfungsi 24/7/365 dan bertindak balas dalam masa 30 minit dari saat tiket dihantar, jadi anda pasti keputusan segera masalah awak. Jadi jika anda tidak tahu cara membuat rekod PTR menggunakan pengehosan kami, anda boleh bertanya soalan ini kepada pakar kami dengan selamat.

• Tarif yang adil dan harga yang telus

Tiada yuran tersembunyi! Anda akan sentiasa tahu apa yang anda bayar, dan sebagai balasannya anda akan menerima 100% daripada sumber pelayan kami yang anda bayar.
Gunakan pengehosan profesional daripada RigWEB dan nikmatilah mengerjakan projek anda, kerana anda sentiasa boleh mengharapkan terma kerjasama yang paling selesa dan menguntungkan dengan kami!

Dalam bahan kami sebelum ini, kami telah melihat untuk menyediakan zon DNS untuk operasi yang betul pelayan mel, serta peranan rekod DNS individu. Walau bagaimanapun, seperti yang ditunjukkan oleh amalan, tidak semua pentadbir memahami dengan betul mekanisme operasi sistem E-mel dengan rekod DNS. Oleh itu, kami memutuskan untuk menumpukan artikel berasingan untuk isu ini, di mana kami akan menganalisisnya dengan lebih mendalam dan membincangkannya secara perbandingan Teknologi baru SPF

Masalah utama moden sistem pos- spam. Terdapat banyak teknik yang berbeza melawannya, tetapi yang utama adalah analisis pengirim, memandangkan semua maklumat yang diperlukan tersedia dalam surat itu.

Mari kita lukiskan analogi dengan mel biasa. Sampul surat atau bungkusan sentiasa mengandungi alamat pengirim, alamat penerima dan setem pejabat pos yang dilawatinya. mel. Dengan cara yang sama, e-mel mengandungi maklumat tentang pengirim, penerima dan tanda teknikal dalam pengepalanya. pelayan mel yang mengambil bahagian dalam pemprosesan mel.

Katakan anda menerima bungkusan yang kelihatan sangat mencurigakan di pejabat pos, kononnya daripada datuk tercinta anda Konstantin Makarovich, tetapi atas sebab tertentu setem penghantar tidak menunjuk ke pejabat pos kampung Makarovka, tetapi ke ladang Gadyukino di seberang. sebelah negara. Adakah anda akan membuka bungkusan sedemikian, mempertaruhkan mencari spora antraks dan bukannya balang epal jem syurga, atau adakah anda akan menghantarnya kembali, keluar dari bahaya?

Perkara yang sama berlaku untuk sistem e-mel. Jika anda menerima surat daripada datuk anda [e-mel dilindungi] , tetapi pelayan penghantar atas sebab tertentu mail.spam.com, maka ini adalah sebab untuk tidak menerima surat sedemikian, kerana ia kemungkinan besar adalah spam.

Bagaimana kita melaksanakan cek ini? Sangat mudah, lihat pada setem Pejabat Pos penghantar dan membandingkannya dengan alamat pemulangan. Sebagai contoh, pada sampul surat tertulis bahawa pengirim berada di bandar Moscow, tetapi setem pejabat pengirim mengandungi indeks 683000, yang menunjukkan Petropavlovsk-Kamchatsky. Oleh itu, kami tidak akan menerima surat sedemikian, kerana ia tidak melepasi pengesahan pengirim.

Keadaannya sama dengan melalui emel, hanya sebagai ganti indeks jabatan penghantaran ia digunakan rekod PTR. Jadi, setelah menerima surat daripada datuk, kami akan lakukan Permintaan PTR dan ketahui bahawa pelayan penghantar adalah milik kami mail.spam.com, manakala mengikut maklumat yang dihantar semasa sambungan perlu ada mail.example.com. Semuanya jelas, surat itu pergi ke spam.

Walau bagaimanapun, jika pengepala menunjukkan bahawa pelayan penghantaran adalah milik kami mail.spam.com, maka surat tersebut berjaya akan diuji Oleh rekod PTR, walaupun pada hakikatnya domain pelayan penghantar tidak sepadan domain mel surat.

Kenapa ini terjadi? Kerana menyemak oleh rekod PTR membenarkan anda untuk menentukan hanya bahawa pelayan penghantar adalah benar-benar siapa yang didakwanya. Tetapi sama sekali tidak menentukan kesahihan pengirim itu sendiri. Itu. merujuk kepada contoh mel biasa kami hanya menyemak sama ada alamat pemulangan dan poskod pejabat pengirim adalah sama; jika tempat berlepas adalah Moscow, dan poskod menghala ke Petropavlovk-Kamchatsky, kemudian semak melalui PTR surat seperti itu tidak dilalui, tetapi jika tempat berlepas dan indeks sepadan, maka semuanya baik-baik saja dan kini tugas anda adalah untuk memikirkan apa yang dilakukan oleh datuk tercinta anda di Petropavlovsk-Kamchatsky.

Salah faham tentang perkara ini membawa kepada fakta bahawa rekod PTR ternyata dikonfigurasikan dengan salah dan, akibatnya, kebanyakan mel yang dihantar tidak sampai ke penerima. Ini amat penting untuk difahami apabila menyediakan pelayan yang menyediakan berbilang domain. Dalam kes ini rekod PTR mesti menunjuk kepada nama hos mel (yang dihantar sebagai sebahagian daripada sesi SMTP), walaupun jika ia terletak dalam domain yang berbeza.

Mari kita lihat contoh mudah.

Pelayan mail.example.com menghantar e-mel untuk domain yang dilayaninya contoh.org. Pelayan penerima membuat permintaan rekod PTR dan memastikan bahawa alamat 123.123.123.123 sungguh mail.example.com, oleh itu surat sedemikian akan diterima, walaupun domain pengirim surat dan domain pelayan pengirim tidak sepadan.

Dan sekarang keadaannya berbeza.

Pentadbir telah mengkonfigurasi zon DNS dengan salah dengan menentukan hos yang salah masuk rekod PTR. Pelayan penerima, setelah menyemak rekod PTR akan menolak surat kami kerana pelayan penghantar tidak sepadan dengan hasil pertanyaan DNS terbalik.

Ketiadaan rekod PTR hampir selalu membawa kepada penolakan surat itu, kerana terdapat perjanjian yang tidak dinyatakan bahawa pengirim bona fide mempunyai zon pulangan yang dikonfigurasikan dengan betul.

Mari kita kembali kepada datuk kita. Katakan dia memberitahu anda bahawa pada musim panas dia akan meninggalkan kampung Makarovka ke kampung jiran Ivanovka, kepada Marfa Vasilievna tertentu, dan berhasrat untuk menghantar surat-menyurat kepada anda dari sana. Dalam kes ini, anda akan selamat menerima surat daripada datuk anda dari Makarovka dan dari Ivanovka, tetapi anda akan menolak surat datuk yang sepatutnya dari Petropavlovsk-Kamchatsky.

Teknologi serupa dalam sistem e-mel dilaksanakan menggunakan teknologi SPF. Pendek kata, kemudian teknologi ini membolehkan anda mencipta rekod DNS khas yang akan menunjukkan siapa sebenarnya yang berhak menghantar mel bagi pihak domain anda. Dalam sangat versi mudah entri akan kelihatan seperti:

Contoh.com. DALAM TXT "v=spf1 +a +mx -semua"

Apakah maksudnya? Hakikat bahawa untuk mel domain example.com boleh dihantar oleh nod yang dinyatakan dalam rekod A (+a) dan rekod MX (+mx), semua mel lain harus ditolak (-semua).

Walau bagaimanapun, tidak semuanya begitu cerah. Pertama, sokongan SPF masih bukan standard de facto dan tidak ada Rekod SPF Domain pengirim tidak mempunyai sebab untuk menolak surat tersebut. Masalah kedua ialah memajukan pelayan atau kes apabila mel dihantar oleh pelayan yang tidak disenaraikan dalam rekod A atau MX, malah terletak di domain lain. Ini mungkin disebabkan oleh seni bina sistem IT perusahaan dan penggunaan pelayan orang lain untuk penghantaran apabila anda memautkan domain anda kepada pembekal atau perkhidmatan awam. Dalam kes kedua, anda perlu berhati-hati terutamanya dan sangat dinasihatkan untuk berunding dengan sokongan perkhidmatan.

Mari kita pertimbangkan situasi lain.

Syarikat anda, sebagai tambahan kepada pelayan mel utama anda mail.example.com, menggunakan perkhidmatan perkhidmatan pihak ketiga, yang boleh menghantar mel kepada pelanggan syarikat bagi pihaknya. Ini boleh menjadi perkhidmatan mel ekspres yang akan memberitahu pelanggan bagi pihak anda tentang status penghantaran, dsb.

Dalam contoh kami, mel tersebut akan dihantar bagi pihak [e-mel dilindungi] daripada pelayan mail.web-service.com, kerana pelayan ini tidak disenaraikan dalam rekod MX domain example.com, kemudian, mengikut apa yang kami nyatakan dalam Rekod SPF Sebagai peraturan, surat sedemikian akan ditolak oleh penerima.

Selain itu, tingkah laku pelayan penerima akan menjadi jelas, kerana kami sendiri telah menyatakan dengan jelas bahawa mel daripada pengirim lain tidak boleh diterima. Oleh itu, jika anda tidak pasti bahawa semua mel akan datang secara eksklusif daripada pelayan anda, maka anda harus menentukan peraturan yang lebih lembut:

contoh.org. DALAM TXT "v=spf1 +a +mx ~semua"

Tidak seperti -semua(gagal) ~semua(gagal lembut) menunjukkan bahawa pengirim selain daripada yang dinyatakan secara jelas tidak dibenarkan menghantar mel, tetapi tidak mengandungi keperluan untuk menolak mel tersebut. Selalunya, mel sedemikian diterima, ditandakan sebagai tidak diingini.

Anda juga boleh menggunakan awalan neutral:

contoh.org. DALAM TXT "v=spf1 +a +mx ?semua"

Dalam kes ini, peraturan menyatakan bahawa hos yang dinyatakan dalam A- dan Rekod MX, tiada maklumat tentang nod yang tinggal. Penerimaan mel daripada nod yang tidak dibenarkan secara jelas adalah mengikut budi bicara pelayan penerima; selalunya mel tersebut akan diterima tanpa sebarang tanda.

Apa yang perlu kita lakukan dalam kes kita? Penyelesaian yang paling betul ialah menambah kemasukan SPF satu lagi peraturan:

contoh.org. DALAM TXT "v=spf1 +a +mx +mx:web-service.com -all"

contoh.org. DALAM TXT "v=spf1 +a +mx +a:mail.web-service.com -all"

dalam kes pertama, kami akan membenarkan penerimaan mel juga daripada semua pelayan yang disenaraikan dalam rekod MX domain web-service.com, dalam kes kedua hanya untuk pelayan mail.web-service.com.

Akhir sekali, mari kita pertimbangkan kes apabila mel untuk domain anda disampaikan oleh pelayan yang terletak di domain lain. Sebagai contoh mail.example.com juga menghantar mel untuk domain contoh.org. Dalam keadaan ini, adalah betul untuk digunakan untuk domain contoh.org peraturan yang sama seperti untuk example.com. Untuk melakukan penggunaan ini jenis khas penyertaan:

contoh.org. DALAM TXT "v=spf1 redirect=example.com"

Ini akan membolehkan anda menukar rekod sekali sahaja, jika perlu, untuk domain utama dan membebaskan pentadbir domain lain yang diterima daripada perlu memantau dan membuat perubahan pada rekod DNS.

• Tag:

Sila dayakan JavaScript untuk melihat

Untuk operasi yang betul pelayan mel, adalah penting untuk dikonfigurasikan dengan betul zon DNS, yang mesti mengandungi rekod A, MX dan PTR. Jika semuanya lebih atau kurang jelas dengan dua yang pertama, maka sediakan rekod PTR ( zon terbalik, apabila perlu menyemak nama pelayan mengetahui alamat IPnya) sering menyebabkan kesukaran untuk memahami di mana ia harus didaftarkan dan siapa yang bertanggungjawab untuknya. Tanpa rekod PTR, sesetengah pelayan mel akan enggan menerima mel daripada pelayan anda, menghantar anda kembali sesuatu seperti ini:

550-Tiada rekod terbalik (PTR) ditemui untuk hos anda atau rekod A tidak 550 sepadan dengan rekod PTR (sebagai balasan kepada arahan RCPT TO) 550-Pencarian DNS songsang gagal. Jika anda rasa ini salah, hubungi 550 tuan pos. (sebagai balasan kepada arahan RCPT TO) 550 5.7.1 Relaying ditolak. Nama IP dipalsukan (PTR dan rekod A tidak sepadan) untuk ###.###.###.### (sebagai balasan kepada arahan MAIL FROM)

Jadi apa sebenarnya kesukaran? Pertama, terdapat salah faham tentang cara DNS distrukturkan dan berfungsi, dan kedua, keengganan sesetengah penyedia untuk memenuhi tanggungjawab langsung mereka atau ketidakcekapan "pakar teknikal", seperti orang bodoh sendiri. Malangnya, ini juga berlaku. Tetapi mari kita cuba memikirkannya.

Mari kita pertimbangkan situasi biasa. Atas sebab tertentu, anda tidak lagi mempunyai keupayaan yang mencukupi untuk pelayan mel yang disediakan oleh pengehosan tempat tapak web anda berada (atau anda hanya mendaftar domain dan ingin menyediakan pelayan mel anda). Daripada pembekal anda yang anda terima alamat ip statik(atau pun subnet kecil) dan rekod A dan MX yang didaftarkan pada pengehosan yang menunjukkan pengirim anda (alamat IP yang sama yang diperuntukkan kepada anda oleh pembekal anda).

Tetapi kemudian timbul kekeliruan tentang siapa yang harus mengehoskan rekod PTR tentang pelayan mel anda - hoster (orang yang menjalankan pelayan DNS yang bertanggungjawab untuk domain anda) atau penyedia (orang yang mengeluarkan alamat IP statik kepada anda). Untuk menentukan nama hos dengan alamat IPnya, terdapat khas zon domain dalam-addr.arpa.

Jadi, sesiapa yang memberi anda alamat IP statik menulis rekod PTR pada pelayan DNS mereka untuk pelayan mel anda dalam zon in-addr.arpa. Untuk melakukan ini, anda perlu menghantar permintaan kepada orang yang memberi anda alamat IP statik dengan permintaan untuk mendaftar rekod PTR untuk domain anda.

Nota: jika alamat domain dan pelayan mel tidak sepadan, maka rekod PTR mesti dibuat khusus untuk rekod MX.

Rekod DNS in-addr.arpa untuk pelayan mel mail.mydomain.ru dengan alamat 123.45.67.89 kelihatan seperti ini:

123.45.67.89.in-addr.arpa. DALAM PTR mail.mydomain.ru.

Semak rekod PTR dihidupkan pelayan DNS anda boleh menggunakan arahan nslookup atau perkhidmatan dalam talian yang serupa (contohnya http://www.nslookup.su). Pada baris arahan yang kami panggil nslookup dan tulis:

>jenis set=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 >

Dalam medan `nama` kita melihat nama salah satu pelayan mel Yandex. Pada tetapan yang betul zon terbalik, medan ini harus memaparkan nama pelayan mel anda pada alamat IP yang sepadan.

Terdapat banyak jenis rekod DNS dan mungkin sukar bagi pemula untuk memahami apa fungsi rekod DNS ini atau cara mengkonfigurasinya. Dalam pelajaran ini anda akan mempelajari apa itu rekod PTR dan cara menyemak sama ada ia dikonfigurasikan untuk alamat IP.

Apakah rekod PTR?

Rekod PTR adalah seperti versi terbalik rekod A. Rekod A mengaitkan nama domain dengan alamat IP, dan rekod PTR mengaitkan alamat IP dengan nama hos. Walau bagaimanapun, kedua-dua entri ini adalah bebas antara satu sama lain..21.128.xx, manakala 23.23.128.xx boleh dikaitkan dengan nama hos yang berbeza sama sekali.

Mengapa rekod PTR perlu?

Ia berguna untuk pelayan mel keluar. Entri ini meningkatkan kebolehpercayaan pelayan penghantaran dan membenarkan respons pulangan untuk mengesahkan nama hos melalui alamat IP. ini cara yang amat baik perlindungan terhadap semua jenis spammer yang menggunakan nama domain penipuan untuk menghantar spam. Itulah sebabnya beberapa pembekal besar Perkhidmatan mel seperti yahoo.com, gmail.com melakukan carian DNS terbalik sebelum menerima e-mel masuk.

Sebelum anda memulakan panduan ini, anda memerlukan yang berikut:

• Akses kepada konsol komputer anda (pilihan)

Kaedah 1 - Menyemak PTR menggunakan nslookup atau dig

Windows, Unix dan seumpamanya OS(Linux, MacOS) mempunyai alatan terbina dalam untuk semakan DNS rekod. Jika anda adalah pengguna Windows, ikut langkah-langkah ini:

1. Masukkan menu Mulakan Windows , masuk cmd dan klik MASUK.
2. Tingkap hitam akan muncul ( baris arahan tingkap).

1. Masukkan arahan berikut untuk mendapatkan nama hos alamat IP (tukar IP_ADDESS kepada IP yang anda perlukan):

nslookup IP_ADDRESS

1. Contohnya, jika anda ingin menyemak rekod PTR untuk 54.243.154.xx, anda akan melihat hasil yang serupa:

C:\Users\Tom>nslookup 54.243.154.xxx Pelayan: server1.yourisp.com Alamat: 121.91.3.xx Nama: Alamat: 54.243.154.xx

Seperti yang dapat dilihat daripada keputusan, rekod PTR adalah ec2-54-243-154-49.hostinger.com.

Untuk pengguna Linux atau proses Mac serupa:

1. Pada MacOS, log masuk ke terminal menggunakan ( F4). Majoriti Pengedaran Linux membolehkan anda membuka terminal dengan pintasan papan kekunci Ctrl+Alt+T.
2. Gunakan arahan ini untuk menyemak rekod PTR (tukar IP_ADDRESS kepada IP yang anda perlukan):

gali -x IP_ADDRESS

1. Sebagai contoh, berikut ialah hasil semakan rekod PTR untuk alamat IP 54.243.154.xx:

dmins-Mac-mini:~ domantas$ dig -x 54.243.154.xx ;<<>> DiG 9.8.3-P1<<>> -x 54.243.154.xx ;; pilihan global: +cmd ;; Dapat jawapan: ;; ->>TAJUK<<- opcode: QUERY, status: NOERROR, id: 26997 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;xx.154.243.54.in-addr.arpa. IN PTR ;; ANSWER SECTION: xx.154.243.54.in-addr.arpa. 250 IN PTR ec2-54-243-154-49.hostinger.com ;; Query time: 34 msec ;; SERVER: 351.91.3.242#53(151.91.3.242) ;; WHEN: Fri Dec 30 11:38:29 2016 ;; MSG SIZE rcvd: 99

Dari bahagian BAHAGIAN JAWAPAN anda boleh mengetahui nilai PTR sesuatu rekod - ec2-54-243-154-49.hostinger.com

Kaedah 2 - Menggunakan Alat Dalam Talian

Cara lain untuk mendapatkan maklumat tentang nama hos alamat IP ialah menggunakan alat carian terbalik MxToolBox. Apa yang anda perlu lakukan ialah memasukkan alamat IP dalam medan dan klik butang Carian Terbalik.

Kesimpulan

Malangnya, jika carian mendedahkan bahawa entri tidak dikonfigurasikan untuk alamat IP, dalam kebanyakan kes anda perlu menghubungi pengehosan atau ISP anda untuk menciptanya. Walau bagaimanapun, kini anda tahu apa itu rekod PTR dan cara menyemak sama ada ia mempunyai alamat IP. Ini berguna jika anda menghadapi ralat DNS dan melantun semasa cuba menghantar e-mel, kerana ia akan membantu anda menyelesaikan masalah tersebut.

Semua pelayan mel yang membuat sambungan ke pelayan mel mesti mempunyai rekod DNS songsang yang sah dan bermakna.

Alamat rDNS yang dikonfigurasikan dengan betul diperlukan untuk menghantar mesej daripada pelayan anda sendiri. Hampir semua pelayan mel akan menolak mesej pada permulaan sesi jika alamat IP pelayan anda tidak mempunyai entri dalam zon DNS terbalik. Sebab kegagalan oleh pelayan mel jauh mungkin seperti berikut:

550-"Alamat IP tidak mempunyai rekod PTR (alamat kepada nama) dalam DNS, atau apabila rekod PTR tidak mempunyai rekod A (nama ke alamat) yang sepadan. Sila semak dan betulkan rekod DNS anda." 550-Tiada PTR yang sepadan untuk alamat IP anda (alamat IP), iaitu 550 diperlukan. Maaf, selamat tinggal. 550 IP anda tidak mempunyai Rekod PTR

Nombor 550 dalam ketiga-tiga kes ialah kod standard pelayan mel SMTP, melaporkan ralat kritikal yang menghalang kerja selanjutnya dalam sesi mel ini. Secara umum, semua ralat siri 500 adalah kritikal dan adalah mustahil untuk meneruskan penghantaran mel selepas ia muncul. Teks tersebut menerangkan sebab penolakan dengan lebih terperinci dan menyatakan bahawa pentadbir pelayan mel penerima telah mengkonfigurasinya untuk menyemak sama ada pelayan mel menghantar mempunyai entri dalam zon DNS terbalik (rDNS) dan jika ia tiada, penerima pelayan bertanggungjawab untuk menolak sambungan pengirim (ralat siri SMTP- 5XX).

Menyediakan rDNS

Hanya pemilik blok alamat IP yang sepadan yang sepadan dengan zon ini mempunyai hak untuk mengkonfigurasi zon DNS terbalik. Sebagai peraturan, pemilik ini adalah pembekal, yang memiliki sistem autonominya sendiri.

Untuk mendaftar zon DNS terbalik, pengendali blok alamat IP mesti mendaftarkan objek jenis "domain" dalam akaun peribadinya di tapak web RIPE, menunjukkan alamat pelayan DNS yang akan menyokong zon rDNS dan mengkonfigurasi sokongan untuk zon bentuk 3.2.1.in-addr.arpa pada mereka. Penunjuk, rekod PTR, bertanggungjawab untuk sumber di zon songsang. Permintaan untuk menyelesaikan alamat IP dan nama hos pergi ke sana (lihat di bawah untuk penerangan tentang prinsip membina rekod PTR).

Jika anda tidak memiliki sistem autonomi, maka menyediakan rDNS untuk alamat IP atau alamat pelayan mel boleh diselesaikan dengan meminta sokongan daripada pembekal atau hoster anda.

Dalam kedua-dua kes, nama alamat IP pelayan mel, dan terutamanya pelayan mel korporat, harus diberikan secara bermakna.

Contoh nama baik untuk pelayan mel:

Mail.domain.ru mta.domain.ru mx.domain.ru

Contoh nama buruk:

Host-192-168-0-1.domain.ru customer192-168-0-1.domain.ru vpn-dailup-xdsl-clients.domain.ru

Nama sedemikian berkemungkinan besar akan ditapis sebagai diberikan kepada komputer klien yang mana pelayan mel tidak boleh dipasang, dan oleh itu spam berkemungkinan dihantar daripada mereka.

Anda boleh dan harus berjaya menggunakan pertanyaan untuk membalikkan zon DNS serta-merta selepas memulakan pelayan mel. Untuk melakukan ini, anda hanya perlu membuat beberapa pelarasan perisian kecil. Dalam pelayan mel yang berbeza, menyediakan semakan rDNS dilakukan secara berbeza:

Dalam Postfix anda perlu mendayakan pilihan

Tolak_unknown_client

Sahkan = reverse_host_lookup

Semakan zon DNS terbalik: http://remote.12dt.com
Masukkan alamat IP anda, jika domain anda dipaparkan - tetapan adalah betul

PTR

rekod PTR(dari penuding Inggeris - penunjuk) menghubungkan IP hos dengan nama kanoniknya. Permintaan dalam domain in-addr.arpa kepada IP hos dalam bentuk terbalik akan mengembalikan nama hos ini.

Untuk mengurangkan jumlah spam, menerima pelayan e-mel menyemak rekod PTR untuk hos dari mana e-mel itu dihantar. Dalam kes ini, rekod PTR untuk alamat IP mesti sepadan dengan nama pelayan mel penghantaran yang mana ia dibentangkan semasa sesi SMTP.

dalam-addr.arpa- zon domain khas yang direka untuk menentukan nama hos dengan alamat IPv4nya menggunakan rekod PTR. Alamat hos AAA.BBB.CCC.DDD diterjemahkan dalam tatatanda terbalik dan menjadi DDD.CCC.BBB.AAA.in-addr.arpa. Terima kasih kepada model pengurusan nama hierarki, adalah mungkin untuk mewakilkan pengurusan zon kepada pemilik julat alamat IP. Untuk melakukan ini, rekod pelayan DNS yang berwibawa menunjukkan bahawa pelayan yang berasingan bertanggungjawab untuk zon CCC.BBB.AAA.in-addr.arpa (iaitu rangkaian AAA.BBB.CCC/24).

Contohnya, jika IP pelayan mel anda ialah 78.56.158.23. Kemudian anda perlu menambah rekod DNS berikut pada rekod NS bagi tetapan pelayan atau hoster (IP ditulis dalam susunan terbalik).