კორპორატიული ელფოსტა საკუთარ დომენზე: MX, SPF, DKIM და DMARC მარტივად

მისამართი info@თქვენი-კომპანია.ge კლიენტს უფრო მეტ ნდობას უნერგავს, ვიდრე უფასო საფოსტო სერვისის მისამართი. ამავე დროს ის თქვენს კონტროლშია: როცა თანამშრომელი მიდის, მისამართი კომპანიაში რჩება. ამ სტატიაში მარტივად ავხსნით, რას ნიშნავს ელფოსტა საკუთარ დომენზე და რისთვის არის საჭირო ოთხი აბრევიატურა: MX, SPF, DKIM და DMARC.

რა არის კორპორატიული ელფოსტა

თქვენ გაქვთ დომენი, მაგალითად your-company.ge. საფოსტო ყუთებს კი ამ დომენზე ამუშავებს სერვისი, ყველაზე ხშირად Microsoft 365 (Exchange Online) ან Google Workspace (Gmail). დომენი და საფოსტო სერვისი ორი ცალკე რამეა. მათ ერთმანეთთან აკავშირებს DNS ჩანაწერები, ანუ დომენის პარამეტრები. DNS-ს შეგიძლიათ წარმოიდგინოთ როგორც ინტერნეტის სამისამართო წიგნი: აქ წერია, საით წავიდეს თქვენი დომენის ფოსტა და ვის აქვს უფლება, თქვენი სახელით გაგზავნოს წერილი.

მნიშვნელოვანი დეტალი: ეს ჩანაწერები იცვლება იქ, სადაც თქვენი დომენის DNS არის მართული, ანუ დომენის რეგისტრატორთან ან DNS-ის მომსახურების პროვაიდერთან. Microsoft-ის დოკუმენტაცია პირდაპირ აღნიშნავს, რომ Microsoft 365-ში არ არსებობს SPF ჩანაწერების სამართავი პორტალი ან PowerShell ბრძანება. ასეთი ჩანაწერი რეგისტრატორთან ან DNS ჰოსტინგთან იქმნება.

MX: საით წავიდეს შემოსული წერილი

როცა ვინმე წერილს გამოგიგზავნით, გამგზავნის სისტემა ამოწმებს თქვენი დომენის MX ჩანაწერებს და იქიდან იგებს, სად უნდა მიიტანოს წერილი. Google Workspace-ის დახმარების გვერდის მიხედვით, მისი MX მნიშვნელობაა smtp.google.com. თუ Google Workspace 2023 წლამდე გამოგიყენებიათ, თქვენს დომენზე შეიძლება სხვა მნიშვნელობები იყოს, რომლებიც „aspmx“-ით იწყება. Microsoft 365-ში MX მნიშვნელობა თითოეული დომენისთვის ინდივიდუალურია. მას ადმინისტრატორის ცენტრიდან იღებთ და ის ასე გამოიყურება: რაღაცა.mail.protection.outlook.com.

პრაქტიკული წესები MX-ისთვის:

• ახალი ჩანაწერის დამატების შემდეგ ძველი MX ჩანაწერები წაშალეთ. Google-ის ინსტრუქციის მიხედვით, ძველი ან არასწორი ჩანაწერების დატოვებისას ფოსტა შეიძლება არასწორად იმუშაოს.
• Microsoft-ის დოკუმენტაცია გირჩევთ ერთ MX ჩანაწერს, რომელიც ერთ საფოსტო სისტემაზე მიუთითებს. რამდენიმე ჩანაწერმა შეიძლება მიწოდების პრობლემები გამოიწვიოს.
• ცვლილება მაშინვე არ ვრცელდება. Microsoft წერს, რომ DNS ცვლილება ჩვეულებრივ დაახლოებით 15 წუთში აქტიურდება, მაგრამ ზოგჯერ უფრო დიდხანს სჭირდება. Google კი გვაფრთხილებს, რომ ახალი MX ჩანაწერის ამოცნობას 72 საათამდე შეიძლება დასჭირდეს.

SPF: ვის აქვს თქვენი სახელით გაგზავნის უფლება

SPF არის TXT ტიპის ჩანაწერი, რომელშიც ჩამოთვლილია სერვერები და სერვისები, რომლებსაც თქვენი დომენის სახელით ფოსტის გაგზავნა შეუძლიათ. ამით მიმღები სისტემა ამოწმებს, ხომ არ გაიგზავნა წერილი თქვენი სახელით უცხო წყაროდან. მთავარი წესი: დომენზე უნდა იყოს მხოლოდ ერთი SPF ჩანაწერი. თუ გარდა Microsoft-ის ან Google-ისა სხვა სერვისიც გიგზავნით წერილებს თქვენი დომენიდან, მაგალითად ახალი ამბების გაგზავნის პლატფორმა ან CRM, ყველა წყარო ერთ ჩანაწერში უნდა გაერთიანდეს. Microsoft ასევე გვირჩევს, რთულ ორგანიზაციებში, სადაც ყველა წყაროს გამოვლენა ძნელია, სწრაფად დაიწყოთ DKIM-ის და DMARC-ის მონიტორინგის რეჟიმში.

DKIM: წერილის ციფრული ხელმოწერა

DKIM თქვენი სახელით გასულ წერილს ციფრულ ხელმოწერას ამატებს, მიმღები კი ამ ხელმოწერას DNS-ში გამოქვეყნებული გასაღებით ამოწმებს. Microsoft-ის დოკუმენტაცია გვირჩევს DKIM-ის გამართვას ყველა იმ საკუთარ დომენსა და ქვედომენზე, საიდანაც ფოსტა იგზავნება. ზუსტ ჩანაწერებს, რომლებიც DNS-ში უნდა დაამატოთ, თქვენი საფოსტო სერვისის ადმინისტრატორის პანელი გაჩვენებთ. DKIM მარტო საკმარისი არ არის თქვენი დომენის გაყალბებისგან დასაცავად. მას SPF-თან და DMARC-თან ერთად სჭირდება.

DMARC: რა მოუვიდეს წერილს, რომელიც შემოწმებას ვერ გაივლის

DMARC აკავშირებს SPF-სა და DKIM-ს იმ მისამართთან, რომელსაც მიმღები „გამომგზავნის“ ველში ხედავს. მასში წერია, როგორ მოიქცეს მიმღები სისტემა, თუ შემოწმება ვერ გაიარა: არაფერი ქნას და მხოლოდ ანგარიში გამოგიგზავნოს, წერილი საეჭვოდ მონიშნოს თუ უარყოს. Microsoft-ის დოკუმენტაციის მიხედვით, საკუთარი დომენებისთვის DMARC ჩანაწერიც DNS-ში იქმნება და არა Microsoft 365-ის პორტალში. DMARC ჩანაწერი ავტომატურად ფარავს ქვედომენებსაც, თუ მათ საკუთარი DMARC ჩანაწერი არ აქვთ. თუმცა თითოეულ ქვედომენს DMARC-ისთვის SPF და DKIM მაინც სჭირდება.

სწორი თანმიმდევრობა

Microsoft-ის ოფიციალური ინსტრუქციების მიხედვით, ჯერ SPF-ს ამართავთ, შემდეგ DKIM-ს, ბოლოს კი DMARC-ს. DMARC-ს დასაწყისში „არაფრის გაკეთების“ რეჟიმში ამუშავებთ, ანუ მხოლოდ დაკვირვებისთვის. ანგარიშებში ნახავთ, რომელი წყაროები აგზავნის ფოსტას თქვენი დომენის სახელით და ვინ გაივლის შემოწმებას. მკაცრ რეჟიმზე გადასვლა მხოლოდ მაშინ ღირს, როცა დარწმუნდებით, რომ ყველა კანონიერი გამგზავნი სწორად არის გამართული. თორემ რეალური წერილები შეიძლება დაიკარგოს.

მოკლე ჩეკლისტი გაშვებამდე

• გაარკვიეთ, სად არის თქვენი დომენის DNS მართული და ვის აქვს მასზე წვდომა.
• შეინახეთ არსებული DNS ჩანაწერების ასლი, განსაკუთრებით MX და TXT ჩანაწერებისა.
• ჩამოწერეთ ყველა სერვისი, რომელიც თქვენი დომენიდან აგზავნის წერილებს: ბუღალტრია, ონლაინ მაღაზია, საიტის ფორმები, სააგენტოები.
• დომენის დამადასტურებელი TXT ჩანაწერი ფოსტის მიმართულებას არ ცვლის. წერილების მიმართულება იცვლება მხოლოდ მაშინ, როცა MX ჩანაწერს ცვლით. ამიტომ MX-ის შეცვლა დაგეგმეთ ისეთ დროს, როცა ყველა მზადაა.
• შეცვლის შემდეგ ორივე მიმართულებით გამოსცადეთ: გაგზავნეთ წერილი გარე მისამართზე და მიიღეთ გარედან.
• DKIM-ის ჩართვის შემდეგ შეამოწმეთ, გადის თუ არა თქვენი გაგზავნილი წერილების SPF და DKIM შემოწმებას. შემდეგ გამოაქვეყნეთ DMARC მონიტორინგის რეჟიმში.

ხშირი შეცდომები

• ორი SPF ჩანაწერის შექმნა, ერთი Microsoft-ისთვის და მეორე სხვა სერვისისთვის. სწორია ერთი გაერთიანებული ჩანაწერი.
• ძველი MX ჩანაწერის დატოვება, რის გამოც ფოსტა ნაწილობრივ ძველ სისტემაში აღწევს.
• DMARC-ის მკაცრ რეჟიმში ჩართვა სხვა ორი ჩანაწერის შემოწმებამდე.
• ქვედომენების დავიწყება: თითოეულ ქვედომენს, საიდანაც ფოსტა იგზავნება, თავისი SPF და DKIM სჭირდება.

კორპორატიული ელფოსტის გამართვა რთული არ არის, მაგრამ დეტალებს ყურადღება უნდა. თუ გირჩევნიათ, რომ ეს ქართველმა IT გუნდმა გააკეთოს, Appy.ge-ს შეუძლია დაგეხმაროთ. Appy არის Microsoft-ის ოფიციალური CSP პარტნიორი და ასევე ამართავს Google Workspace-ს.

წყაროები:
• Set up MX records for Google Workspace - Google Workspace Admin Help — https://support.google.com/a/answer/6150791?hl=en
• External Domain Name System records for Microsoft 365 - Microsoft Learn — https://learn.microsoft.com/en-us/microsoft-365/enterprise/external-domain-name-system-records?view=o365-worldwide
• Set up SPF to identify valid email sources for your Microsoft 365 domain - Microsoft Learn — https://learn.microsoft.com/sr-Latn-RS/defender-office-365/email-authentication-spf-configure
• How to use DKIM for email in your custom domain - Microsoft Learn — https://learn.microsoft.com/en-us/defender-office-365/email-authentication-dkim-configure
• Set up DMARC to validate email in Microsoft 365 - Microsoft Learn — https://learn.microsoft.com/en-us/defender-office-365/email-authentication-dmarc-configure