MX ჩანაწერები ახსნილი: პრიორიტეტი, სარეზერვო MX და null MX

MX ჩანაწერი დანარჩენ ინტერნეტს ეუბნება, რომელი ჰოსტი იღებს ფოსტას შენი დომენისთვის. ის ორ რამეს ინახავს: პრიორიტეტის ნომერს და ფოსტის სერვერის სახელს. როცა ვინმე anna@example.com-ზე აგზავნის, მისი სერვერი example.com-ის MX ჩანაწერებს ეძებს, ჯერ ყველაზე დაბალი ნომრის მქონე ჰოსტს ცდის, და თუ დაკავშირება ვერ მოახერხა, თანმიმდევრობით დანარჩენებზე გადადის. მთელი მექანიზმი ესაა. ყველაფერი, რაც MX ჩანაწერებთან არასწორად მიდის, ოთხი წესიდან მოდის, რომლებსაც უმეტესობა არასოდეს კითხულობს: სამიზნე უნდა იყოს ჰოსტის სახელი და არასოდეს IP მისამართი; ეს ჰოსტის სახელი არ უნდა იყოს CNAME; დაბალი ნომერი იმარჯვებს; და დომენი, რომელსაც MX საერთოდ არ აქვს, მაინც იღებს ფოსტას თავის A ჩანაწერზე, თუ სხვა რამეს არ იტყვი.

ეს პოსტი აღწერს სინტაქსს, რას აკეთებენ გამგზავნები რეალურად პრიორიტეტებთან, ღირს თუ არა სარეზერვო MX-ის ქონა (ჩვეულებრივ არა), null MX-ს იმ დომენებისთვის, რომლებმაც ფოსტა არასოდეს უნდა მიიღონ, და dig ბრძანებებს, რომლებიც გეუბნება, რას ხედავს მსოფლიო.

ჩანაწერი და მისი ორი ველი#

example.com.   3600  IN  MX  10 mail.example.com.example.com.   3600  IN  MX  20 mail2.example.com.mail           3600  IN  A   203.0.113.25mail2          3600  IN  A   198.51.100.40

პირველი რიცხვი MX-ის შემდეგ არის preference - რომელსაც ხშირად პრიორიტეტს უწოდებენ. ეს 16-ბიტიანი მნიშვნელობაა, ანუ ნებისმიერი 0-დან 65535-მდე. დაბალს ენიჭება უპირატესობა. რიცხვებს აბსოლუტური მნიშვნელობა არ აქვს; მხოლოდ მათი თანმიმდევრობაა მნიშვნელოვანი. 10 და 20 ზუსტად ისე იქცევა, როგორც 1 და 2 ან 100 და 200. ჩვეულებრივ შუალედებს ტოვებენ, რომ მოგვიანებით შუაში ჰოსტის ჩასმა გადანომვრის გარეშე შეძლო.

მეორე ველი არის exchange: სერვერის ჰოსტის სახელი, რომელიც SMTP-ს პორტ 25-ზე იღებს. ზონის ფაილში ბოლო წერტილი მას სრულად კვალიფიცირებულ სახელად აღნიშნავს; ვებ DNS რედაქტორების უმეტესობა მას შენთვის ამატებს.

ჩანაწერი ცხოვრობს იმ სახელზე, რომელზეც ფოსტა მიემართება. ფოსტა @example.com-ისთვის იყენებს MX-ს example.com-ზე (apex, ბევრ რედაქტორში ნაჩვენები როგორც @). ფოსტა @support.example.com-ისთვის იყენებს MX-ს support.example.com-ზე, რაც ცალკე ჩანაწერია - ქვედომენები მშობლის MX-ს არ იმემკვიდრებენ.

წესები, რომლებიც ფოსტას ანგრევს#

ეს სტანდარტებშია, და მიმღებები მათ სხვადასხვა ხარისხით აღასრულებენ, რაც თანმიმდევრულ აღსრულებაზე უარესია, რადგან გატეხილ დაყენებას შეუძლია ნახევრად იმუშაოს.

1. exchange უნდა იყოს ჰოსტის სახელი და არა IP მისამართი. MX 10 203.0.113.25 არავალიდურია. ზოგი გამგზავნი 203.0.113.25-ის სახელად გადაწყვეტას შეეცდება და ჩავარდება; ზოგი გამოიცნობს, რას გულისხმობდი. შექმენი A ჩანაწერი ჰოსტისთვის და MX სახელზე მიუთითე.
2. exchange არ უნდა იყოს CNAME. RFC 2181 ამბობს, რომ MX სამიზნეს საკუთარი მისამართის ჩანაწერები უნდა ჰქონდეს. ბევრი გამგზავნი CNAME-ს ითმენს, ზოგი არა, და ისინი, ვინც არ ითმენს, შენს ფოსტას დააბრუნებს შეცდომებით, რომლებსაც ვერასოდეს დაინახავ. თუ ფოსტის პროვაიდერი ჰოსტის სახელს გაძლევს, პირდაპირ ის გამოიყენე.
3. exchange უნდა იხსნებოდეს. MX, რომელიც A ან AAAA ჩანაწერის არმქონე სახელზე მიუთითებს, შავი ხვრელია. გამგზავნები ამას დროებით შეცდომად თვლიან და დღეების განმავლობაში ცდიან ხელახლა, სანამ წერილს დააბრუნებენ.
4. MX სახელს შეუძლია სხვა ჩანაწერების ქონა, მაგრამ CNAME მათ გვერდით ვერ დადგება. apex ისედაც ვერ იქნება CNAME; იგივე წესი ნიშნავს, რომ CNAME-ს ვერ დააყენებ ვერცერთ სახელზე, რომელსაც MX-იც სჭირდება.

რას აკეთებს გამგზავნი სერვერი სინამდვილეში#

RFC 5321-ის 5.1 სექცია ძებნას აღწერს, და მისი ნაბიჯ-ნაბიჯ ცოდნა ღირს, რადგან ის ყველა სიმპტომს ხსნის.

1. გამგზავნი მიმღების დომენისთვის MX-ს ითხოვს.
2. ის პასუხებს preference-ით ალაგებს, ყველაზე დაბლიდან. ერთნაირი preference-ის მქონე ჰოსტები შემთხვევითი თანმიმდევრობით იცდება, რაც დატვირთვას მათ შორის ანაწილებს.
3. ის თითოეულ exchange-ს მისამართებად წყვეტს და პორტ 25-ს უკავშირდება, და თუ ერთი ჰოსტი მიუწვდომელია ან დროებით შეცდომას აბრუნებს, შემდეგს ცდის.
4. თუ ყველა ჰოსტი დროებით ჩავარდა, წერილი გამგზავნის რიგში რჩება და ხელახლა იცდება. RFC 5321 გვთავაზობს, უარი მხოლოდ ოთხი-ხუთი დღის შემდეგ ითქვას, და სერვერების უმეტესობა ამასთან ახლოს მოქმედებს, თავდაპირველ გამგზავნს კი რამდენიმე საათის შემდეგ დაყოვნების გაფრთხილებას უგზავნის.
5. მუდმივი შეცდომა - 5xx პასუხი, მაგალითად "ასეთი მომხმარებელი არ არსებობს" - მცდელობას მაშინვე ასრულებს. მუდმივი უარყოფისას გამგზავნი შემდეგ MX-ს არ ცდის.

ეს ბოლო პუნქტი ხალხს აკვირვებს: სარეზერვო MX-ს მხოლოდ მაშინ მიმართავენ, როცა მთავარი მიუწვდომელია ან დროებით ვერ მუშაობს, და არა მაშინ, როცა ის წერილს უარყოფს.

არსებობს სარეზერვო ქცევაც, როცა MX საერთოდ არ არსებობს. თუ MX მოთხოვნა ჩანაწერებს არ აბრუნებს, მაგრამ დომენს A ან AAAA ჩანაწერი აქვს, გამგზავნი თავად დომენს ნაგულისხმევ MX-ად თვლის preference-ით 0 და ამ მისამართზე აწვდის. სწორედ ამიტომ შეუძლია დომენს, რომელიც მხოლოდ ვებსაიტს მასპინძლობს, მაინც მიიღოს ფოსტა ვებ სერვერის IP-ზე, თუ იქ პორტ 25-ზე რამე უსმენს - და სწორედ ამიტომ უნდა გამოაქვეყნო null MX იმ დომენებისთვის, რომლებმაც ფოსტა არასოდეს უნდა მიიღონ.

ერთნაირი პრიორიტეტები, failover და დატვირთვა#

ორი ჩანაწერი ერთნაირი preference-ით შემომავალ ფოსტას შემთხვევითად ინაწილებს:

example.com.  IN  MX  10 mx1.example.com.example.com.  IN  MX  10 mx2.example.com.

ეს დატვირთვის განაწილებაა და არა სიჭარბე იმ გაგებით, რასაც ხალხი ელის. ორივე სერვერმა ფოსტა ყველა საფოსტო ყუთისთვის უნდა მიიღოს, რაც ნიშნავს, რომ ან საცავს იზიარებენ, ან ერთი მეორეზე გადაამისამართებს. ერთი საკუთარი სერვერისთვის ეს არ გჭირდება.

განსხვავებული preference-ები დალაგებულ failover-ს იძლევა. მეორადი ჰოსტი ფოსტას მხოლოდ მაშინ იღებს, როცა მთავარი მიუწვდომელია. სწორედ აქ ჩამოთვლიან ფოსტის ჰოსტინგის პროვაიდერები თავიანთ რამდენიმე სერვერს - Google Workspace-ის მიმდინარე დაყენება ერთი smtp.google.com ჩანაწერია, მაშინ როცა ძველი ინსტრუქციები ხუთ ჰოსტს ჩამოთვლიდა preference-ებით 1, 5, 5, 10 და 10. გამოიყენე ზუსტად ის, რასაც შენი პროვაიდერი გეუბნება, და გადასვლისას ძველი პროვაიდერის ჩანაწერები მთლიანად წაშალე.

სარეზერვო MX: რატომ არის ის დღეს ჩვეულებრივ ცუდი იდეა#

სარეზერვო MX ოცი წლის წინ სტანდარტული რჩევა იყო: თუ შენი სერვერი გათიშული იყო, მეორადი ფოსტას მიიღებდა და შეინახავდა, სანამ ის დაბრუნდებოდა. დღეს ის ძირითადად პრობლემებს ქმნის, სამი მიზეზით.

• გამგზავნები ისედაც რიგში აყენებენ. ყველა ფოსტის სერვერი დღეების განმავლობაში ცდის ხელახლა. თუ შენი მთავარი სერვერი ერთი ნაშუადღევით გაითიშა, ფოსტა გამგზავნების მხარეს ელოდება და მოვა, როცა დაბრუნდები. სარეზერვო არაფერს ამატებს, რასაც გამგზავნი უკვე არ აკეთებს.
• spammer-ები სარეზერვო MX ჰოსტებს უმიზნებენ. ისინი განზრახ უკავშირდებიან ყველაზე მაღალი ნომრის MX-ს, რადგან სარეზერვოებს ხშირად სუსტი ფილტრაცია აქვთ და ფოსტას ნებისმიერი მისამართისთვის იღებენ. შემდეგ სარეზერვო ამ spam-ს შენს მთავარ სერვერს გადასცემს, რომელიც მას ენდობა.
• Backscatter. სარეზერვო, რომელმაც შენი ვალიდური საფოსტო ყუთები არ იცის, ფოსტას არარსებული მისამართებისთვის იღებს, შემდეგ კი მოგვიანებით უნდა დააბრუნოს - გაყალბებულ გამგზავნის მისამართებზე. ეს შენს სარეზერვოს უდანაშაულო მესამე პირებისთვის spam-ის წყაროდ აქცევს და blocklist-ზე ახვედრებს.

სარეზერვო MX-ის გაშვება მხოლოდ მაშინ ღირს, თუ მას მთავარის იგივე მიმღებების სია აქვს (რომ უცნობი მომხმარებლები SMTP საუბრისას უარყოს), იგივე spam ფილტრაცია და იგივე ავთენტიფიკაციის შემოწმებები. ამ ეტაპზე უკვე ორ ფოსტის სერვერს მართავ. პატარა დომენისთვის ერთი კარგად მოვლილი სერვერი და გამგზავნების საკუთარი ხელახლა ცდის რიგები უკეთესი დიზაინია.

Null MX დომენებისთვის, რომლებიც ფოსტას არასოდეს იღებენ#

RFC 7505 განსაზღვრავს გზას, რომ თქვა "ეს დომენი ფოსტას არ იღებს":

example.net.   3600  IN  MX  0 .

ერთი MX preference-ით 0 და exchange-ით . (root). გამგზავნი, რომელიც მას ხედავს, მაშინვე ჩავარდება მუდმივი შეცდომით, ნაცვლად იმისა, რომ დომენის A ჩანაწერი სცადოს ან დღეების განმავლობაში რიგში დაელოდოს. გამოაქვეყნე ის:

• დომენებზე, რომლებიც მხოლოდ ვებსაიტებისთვის ან გადამისამართებებისთვის გამოიყენება.
• პარკირებულ დომენებსა და ძველი ბრენდის დომენებზე, რომლებსაც დაცვისთვის ინახავ.
• ქვედომენებზე, რომლებსაც A ჩანაწერები აქვთ, მაგრამ ფოსტის დანიშნულების ადგილი არასოდეს უნდა იყვნენ, მაგალითად www ან api, თუ საფუძვლიანი გინდა იყო.

დააწყვილე ის SPF ჩანაწერთან v=spf1 -all და DMARC ჩანაწერთან p=reject-ით იმ დომენებზე, რომლებიც ასევე არასოდეს აგზავნიან. ერთად ისინი ამბობენ "ამ დომენზე და ამ დომენიდან არაფერია ნამდვილი", რაც მას გაყალბების სამიზნედ აღარ ტოვებს. null MX ამ სახელზე ერთადერთი MX ჩანაწერი უნდა იყოს; მისი ნამდვილ MX ჩანაწერებთან შერწყმა არავალიდურია.

MX ჩანაწერების შემოწმება dig-ით#

# MX ნაკრები ისე, როგორც შენი resolver ხედავს$ dig +short MX example.com10 mail.example.com.20 mail2.example.com.# ჰკითხე საჯარო resolver-ს, რომ საკუთარ ქეშს აარიდო თავი$ dig @1.1.1.1 +short MX example.com# დაადასტურე, რომ სამიზნე CNAME არ არის და მისამართი აქვს$ dig +short CNAME mail.example.com$ dig +short A mail.example.com# შემდეგ დაადასტურე, რომ პორტ 25-ზე რაღაც პასუხობს$ nc -vz mail.example.com 25

Windows-ზე - Resolve-DnsName example.com -Type MX ან nslookup -type=MX example.com 1.1.1.1.

ცარიელი CNAME პასუხი და მისამართი A მოთხოვნაზე - სწორედ ეს გინდა. თუ CNAME მოთხოვნა რამეს აბრუნებს, გაასწორე. თუ nc-ს შენი ქსელის გარედან დრო ეწურება, DNS წესრიგშია და პორტი მიუწვდომელია - firewall, ან ჰოსტინგის სერვერზე პორტი 25 ჯერ არ არის გადამისამართებული. ტესტირება ქსელიდან, რომელიც გამავალ პორტ 25-ს ბლოკავს (სახლის კავშირების უმეტესობა), ასევე დროის ამოწურვით დასრულდება, ამიტომ ტესტი სერვერიდან გაუშვი, ან ვებზე დაფუძნებული SMTP შემმოწმებელი გამოიყენე.

როგორ გამოიყურება MX-ის გავრცელებული შეცდომები

დაბრუნებული წერილი, რომელსაც გამგზავნი იღებს, ჩვეულებრივ პრობლემას ასახელებს, თუ მისი წაკითხვა იცი.

• "Domain not found" ან `NXDOMAIN` - მიმღების დომენი DNS-ში საერთოდ არ არსებობს. შეცდომა მისამართში, ან დომენი, რომლის რეგისტრაციასაც ვადა გაუვიდა.
• "No MX or A records" ან "unrouteable address" - დომენი არსებობს, მაგრამ არც MX აქვს და არც მისამართი, რომელზეც სარეზერვოდ გადავიდოდა. ჩვეულებრივ ახლად დარეგისტრირებული დომენი, რომლის ჩანაწერებიც არასოდეს შექმნილა.
• "Host not found" exchange-ისთვის - MX მიუთითებს სახელზე A ჩანაწერის გარეშე, ხშირად იმიტომ, რომ ფოსტის ჰოსტს სახელი გადაერქვა და MX არ განახლდა.
• მიწოდება დაყოვნდა, კავშირის დრო ამოიწურა - MX იხსნება, მაგრამ პორტ 25-ზე არაფერი პასუხობს. სერვერი გათიშულია, firewall-ს მიღმაა, ან პორტი გადამისამართებული არ არის. გამგზავნი ხელახლა ცდას აგრძელებს, ამიტომ ეს ჯერ დაყოვნების გაფრთხილებად ჩანს, დღეების შემდეგ კი დაბრუნებად.
• `550 5.1.1` user unknown - DNS და სერვერი წესრიგშია; საფოსტო ყუთი არ არსებობს იმ სერვერზე, რომელზეც MX მიუთითებს. პროვაიდერის შეცვლის შემდეგ ეს ხშირად ნიშნავს, რომ MX ჯერ კიდევ ძველ პროვაიდერზე მიუთითებს, სადაც საფოსტო ყუთი წაიშალა.
• `554 5.7.1` relay access denied - მიმღები სერვერი თავს შენს დომენზე პასუხისმგებლად არ თვლის. დომენი ფოსტის სერვერს არასოდეს დაემატა, ან MX მიუთითებს სერვერზე, რომელიც სხვას ეკუთვნის.

იმის გარჩევა, რომელი მათგანი გაქვს, გეუბნება, გაასწორო DNS, ქსელი თუ თავად ფოსტის სერვერი, და ეს დიაგნოზის უმეტესი ნაწილია.

სრული სურათისთვის, როგორ მუშაობს ძებნა და ქეშირება, იხილე DNS ჩანაწერები ახსნილი; TXT ჩანაწერებისთვის, რომლებიც MX-ის გვერდით დგას, იხილე SPF, DKIM და DMARC ახსნილი.

ფოსტის პროვაიდერის შეცვლა ფოსტის დაკარგვის გარეშე#

MX-ის გადატანა ყველაზე სარისკო DNS ცვლილებაა, რომელსაც ხალხის უმეტესობა აკეთებს, რადგან გადართვისას გაგზავნილი ფოსტა ნებისმიერ მხარეს შეიძლება მოხვდეს.

1. დაწიე MX-ის TTL 300-მდე სულ მცირე ერთი ძველი TTL-ის პერიოდით ადრე - ერთი დღით ადრე, თუ ის 86400 იყო.
2. ჯერ ახალი სერვერი სრულად დააყენე: დომენი, საფოსტო ყუთები, DKIM გასაღებები ახალი სელექტორებით გამოქვეყნებული. გადართვამდე შეამოწმე, პირდაპირ მასზე გაგზავნით.
3. შეცვალე MX ჩანაწერები ახალ სერვერზე. ძველები მთლიანად წაშალე; ძველი პროვაიდერის უფრო მაღალ ნომერზე დატოვება ნიშნავს, რომ ფოსტის ნაწილი იქ წავა, როცა ახალი სერვერი წაიბორძიკებს.
4. ძველი საფოსტო ყუთები ღია დატოვე სულ მცირე რამდენიმე დღით. გამგზავნები ქეშირებული MX პასუხებით იქ მიწოდებას გააგრძელებენ, სანამ მათ TTL არ ამოეწურებათ. შეამოწმე ისინი და გადაიტანე ყველაფერი, რაც მოვა.
5. განაახლე SPF ახალი გაგზავნის გზისთვის, და მხოლოდ ამის შემდეგ წაშალე ძველი პროვაიდერის include.
6. დააკოპირე ძველი ფოსტა IMAP-ით. ელფოსტის გადატანა საკუთარ სერვერზე აღწერს imapsync-ს და ოპერაციების თანმიმდევრობას.

გაითვალისწინე, რომ MX-ის შეცვლა მხოლოდ შემომავალ ფოსტას გადაიტანს. გამავალი ფოსტა მიდის იქ, სადაც შენი კლიენტები და აპლიკაციები მას აწვდიან, რაც თითოეულ მათგანში ცალკე კონფიგურირდება.

როგორ ერგება ეს RE:NODE-ის Mail Server-ს#

Mail Server გეგმაზე შენი დომენის MX მიუთითებს ჰოსტის სახელზე, რომელსაც შენს სერვერს აძლევ, A ჩანაწერით, რომელიც პანელში ნაჩვენებ მისამართს ინახავს. ამ ჩანაწერებს ქმნი იქ, სადაც შენი DNS-ია განთავსებული - ჩვენს მხარეს ზონის რედაქტორი არ არის - ხოლო Stalwart-ის ვებ ადმინისტრირების პანელი აჩვენებს სრულ ნაკრებს, რომელსაც თითოეული დომენისთვის ელის. MX მხოლოდ მაშინ მუშაობს, როცა პორტი 25 სერვერამდე აღწევს, რასაც support მოთხოვნისამებრ აყენებს; ერთ მისამართზე ერთი ფოსტის სერვერია, რადგან მოცემულ IP-ზე პორტ 25-ზე მიღება მხოლოდ ერთ სერვერს შეუძლია. Stalwart ფოსტის სერვერის დაყენება პირველი საათის დანარჩენ ნაწილს აღწერს.

FAQ#

რომელი პრიორიტეტის ნომერი გამოვიყენო?

ნებისმიერი. ერთი ფოსტის სერვერით ჩვეულებრივ 10-ს იყენებენ. რამდენიმესთან მხოლოდ თანმიმდევრობაა მნიშვნელოვანი, ამიტომ შუალედები დატოვე (10, 20, 30), რომ მოგვიანებით ცვლილებები გაგიადვილდეს. გამოიყენე ზუსტად ის მნიშვნელობები, რომლებსაც ჰოსტინგის პროვაიდერი გაძლევს.

შეუძლია MX ჩანაწერს IP მისამართზე მიუთითოს?

არა. ის უნდა მიუთითებდეს ჰოსტის სახელზე, რომელსაც საკუთარი A ან AAAA ჩანაწერი აქვს. შექმენი mail.example.com მისამართით და MX ამ სახელზე მიუთითე.

რატომ მიდის ფოსტა ისევ ჩემს ძველ პროვაიდერთან MX-ის შეცვლის შემდეგ?

გამგზავნებმა ძველი MX მისი TTL-ის ხანგრძლივობით დაიქეშეს. ჩანაწერს, რომელიც 86400 წამზე იდგა, შეუძლია ფოსტა ძველ სერვერზე ერთი დღის განმავლობაში აგზავნინოს. ძველი საფოსტო ყუთები ღია დატოვე, სანამ TTL გავა, და შეამოწმე ისინი.

მჭირდება MX ჩანაწერი, თუ მხოლოდ ფოსტას ვაგზავნი?

ტექნიკურად არა, მაგრამ დაბრუნებული წერილები და პასუხები შენს დომენზე მოდის, ამიტომ მათი მიღება ალბათ გინდა. თუ დომენი მართლა არაფერს იღებს, გამოაქვეყნე null MX, რომ გამგზავნები სწრაფად ჩავარდნენ და შენი ვებ სერვერი არ სცადონ.

იყენებს ქვედომენი მშობელი დომენის MX-ს?

არა. ფოსტა user@news.example.com-ისთვის MX-ს news.example.com-ზე ეძებს. თუ იქ არ არის, ის ამ ქვედომენის A ჩანაწერზე გადადის და არა მშობლის MX-ზე.