ელფოსტის ავთენტიფიკაცია: SPF, DKIM, DMARC

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

რატომ ხვდება ჩემი ელფოსტები სპამში?

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

სამი ჩანაწერი, სამი სხვადასხვა კითხვა

სამივე ერთმანეთს ავსებს. მხოლოდ SPF-ის გამართვა მესამედი დაცვაა.

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

SPF (Sender Policy Framework) DNS TXT ჩანაწერია, რომელიც ჩამოთვლის, რომელ სერვერებს შეუძლიათ თქვენი დომენის სახელით ელფოსტის გაგზავნა.

მარტივი მაგალითი:

v=spf1 include:_spf.google.com include:sendgrid.net ~all

ეს ჩანაწერი ამბობს: „Google Workspace-სა და SendGrid-ს ჩემი სახელით გაგზავნა შეუძლიათ; სხვისგან მოსულ წერილებს ეჭვით მოეკიდეთ.“

ბოლოში მდგომი ნიშანი მნიშვნელოვანია:

• ~all (softfail): სიაში არმყოფი სერვერიდან მოსული წერილი მიიღება, მაგრამ მოინიშნება. გარდამავალ პერიოდში გამოიყენება.
• -all (hardfail): სიაში არმყოფი უარიყოფა. გამართვის დალაგების შემდეგ მიზანი ეს არის.
• +all: ყველას უშვებს. არასდროს გამოიყენოთ, SPF-ს უაზროს ხდის.

SPF-ში ორი ყველაზე ხშირი შეცდომა

1. ერთზე მეტი SPF ჩანაწერი. ერთ დომენს მხოლოდ ერთი SPF ჩანაწერი შეიძლება ჰქონდეს. თუ ორი ცალკე v=spf1 სტრიქონია, სტანდარტის მიხედვით ჩანაწერი ბათილად ითვლება და ვერიფიკაცია მთლიანად იშლება. ახალი სერვისის დამატებისას ახალი ჩანაწერი არ გახსნათ, არსებულ ჩანაწერში include: დაამატეთ.

2. ათი მოთხოვნის ლიმიტის გადაჭარბება. SPF-ის შეფასებისას მაქსიმუმ 10 DNS მოთხოვნა შეიძლება შესრულდეს. ყოველი include: მინიმუმ ერთ მოთხოვნას ხარჯავს და ზოგი პროვაიდერის include თავის თავში სხვა include-ებს შეიცავს. ლიმიტის გადაჭარბებისას ჩანაწერი permerror-ს იძლევა და არ მუშაობს.

თუ ხუთ-ექვს სხვადასხვა სერვისს იყენებთ (ელფოსტის პროვაიდერი, საინფორმაციო ბიულეტენის ხელსაწყო, CRM, ინვოისების სისტემა, ფორმების სერვისი), ამ ლიმიტს დიდი ალბათობით შეეჯახებით. პირველი გამოსავალი გამოუყენებელი სერვისების ჩანაწერიდან ამოღებაა.

DKIM: შეიცვალა თუ არა წერილი გზაში

DKIM (DomainKeys Identified Mail) ყოველ გამავალ წერილს უხილავ ხელმოწერას ამატებს. მიმღები სერვერი ამ ხელმოწერას თქვენს DNS-ში გამოქვეყნებული საჯარო გასაღებით ამოწმებს. თუ ხელმოწერა ემთხვევა, წერილი გზაში არ შეცვლილა და მართლა თქვენი სერვერიდან გამოვიდა.

გამართვა პროვაიდერზეა დამოკიდებული: თქვენი ელფოსტის პროვაიდერი გაძლევთ სელექტორს (selector) და საჯარო გასაღებს, თქვენ კი მას DNS-ში TXT ჩანაწერად ამატებთ:

selector1._domainkey.alanadiniz.com   TXT   "v=DKIM1; k=rsa; p=MIGfMA0GCS..."

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

საყურადღებო წერტილი: ელფოსტის პროვაიდერის შეცვლისას ძველი DKIM ჩანაწერები გაასუფთავეთ. გამოუყენებელი გასაღებები ღიად დატოვებული კარებია.

DMARC: წესი და ანგარიშგება

DMARC ამბობს, რა უნდა მოხდეს, როცა SPF და DKIM ჩაიშლება. გარდა ამისა — და ეს მისი მთავარი სარგებელია, რომელსაც უმეტესობა გამოტოვებს — გიგზავნით ანგარიშს, ვინ აგზავნის თქვენი სახელით წერილებს.

_dmarc.alanadiniz.com   TXT   "v=DMARC1; p=none; rua=mailto:[email protected]; pct=100"

პოლიტიკა (p=) სამ მნიშვნელობას იღებს:

• none: არაფერი გააკეთო, მხოლოდ ანგარიში გამოგზავნე. საწყისი წერტილი ეს არის.
• quarantine: ჩაშლილი წერილები სპამის საქაღალდეში გადააგდე.
• reject: ჩაშლილი წერილები მთლიანად უარყავი.

ეტაპობრივი გადასვლა აუცილებელია

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

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

1. p=none-ით დაიწყეთ, ანგარიშები შეაგროვეთ.
2. ანგარიშებში გამოჩენილი ყველა ლეგიტიმური გამგზავნი SPF-სა და DKIM-ში დაამატეთ.
3. რამდენიმე კვირის შემდეგ p=quarantine დააყენეთ; შეგიძლიათ pct=25-ის მსგავსი ეტაპობრივი პროპორციით დაიწყოთ.
4. თუ ყველაფერი სუფთაა, p=reject-ზე გადადით.

ეს გადასვლა ტიპურად 4-8 კვირას გრძელდება. აჩქარების ფასი ის არის, რომ გამავალი ინვოისები კლიენტამდე არ მივა.

შეამოწმეთ თქვენი მიმდინარე მდგომარეობა

თქვენი ჩანაწერების სისწორის სანახავად ჩვენს ელფოსტის ჯანმრთელობის შემოწმების ხელსაწყოში დომენი შეიყვანეთ: ის თქვენს SPF, DKIM და DMARC ჩანაწერებს წაიკითხავს და ხარვეზებსა და შეცდომებს ჩამოთვლის.

თუ ნედლი DNS ჩანაწერების ნახვა გსურთ, DNS შემოწმების ხელსაწყო TXT ჩანაწერებს ისე აჩვენებს, როგორც არის.

საკონტროლო სია

• დომენზე ერთი SPF ჩანაწერია
• SPF-ში გამოუყენებელი სერვისი არ არის, 10 მოთხოვნის ლიმიტი არ ჭარბდება
• SPF ~all-ით ან -all-ით მთავრდება (+all არ არის)
• ყოველი გამგზავნი სერვისისთვის DKIM სელექტორია განსაზღვრული
• ძველი/გამოუყენებელი DKIM გასაღებები გასუფთავებულია
• DMARC ჩანაწერი არსებობს და rua მისამართი კონტროლდება
• DMARC პოლიტიკა ეტაპობრივად მკაცრდება
• დომენის მფლობელობის გადაცემისას ჩანაწერები გადახედილია

ხშირად დასმული კითხვები

ჩანაწერები რამდენ ხანში ამოქმედდება? DNS-ის გავრცელება ჩვეულებრივ რამდენიმე წუთიდან რამდენიმე საათამდეა; TTL მნიშვნელობაზეა დამოკიდებული.

მაქვს დომენი, საიდანაც ელფოსტას საერთოდ არ ვაგზავნი — მაინც საჭიროა? დიახ, უფრო მეტადაც. არაგამგზავნი დომენები გაყალბებისთვის იდეალურია. ასეთ დომენებს v=spf1 -all და p=reject მიეცით — ვერავინ შეძლებს იმ დომენის სახელით წერილის გაგზავნას.

ქვედომენებიც იფარება? DMARC-ში sp= პარამეტრით ქვედომენის პოლიტიკა ცალკე განისაზღვრება. თუ არ არის მითითებული, ძირითადი პოლიტიკა მოქმედებს.

ანგარიშების კითხვა

როცა DMARC ჩანაწერში rua= მისამართს წერთ, მიმღები სერვერები დღიურ XML ანგარიშებს გიგზავნიან. ნედლი სახით წაუკითხავია, მაგრამ შიგნით არსებული ინფორმაცია ღირებულია:

• რომელი IP მისამართები აგზავნიან თქვენი დომენის სახელით წერილებს
• ამ გაგზავნებიდან რამდენი გადის SPF-ისა და DKIM-ის ვერიფიკაციას
• ვერგამვლელები რომელი სერვისიდან მოდის

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

ანგარიშის მისამართი კორპორატიულ ელფოსტაზე კი არა, ცალკე ყუთზე მიმართოთ; დღიური მოცულობა შეიძლება მაღალი იყოს.

SPF ჩანაწერი გავრცელებულ პროვაიდერებთან

თუ არ იცით თქვენი სერვისის include: მნიშვნელობა, ის პროვაიდერის დოკუმენტაციაში „SPF record“ სათაურის ქვეშ მოიძებნება. ხშირად გამოყენებულები:

ამათ ერთ ჩანაწერში აერთიანებთ:

v=spf1 include:_spf.google.com include:sendgrid.net ~all

თუ თქვენი ჰოსტინგ პროვაიდერის სერვერიდანაც მიდის წერილები (მაგალითად, საკონტაქტო ფორმის შეტყობინებები), მისი IP მისამართიც უნდა დაამატოთ: ip4:203.0.113.10 ფორმატით.

BIMI: თქვენი ლოგო შემოსულებში

თუ DMARC quarantine ან reject დონეზე გაქვთ, კიდევ ერთი ნაბიჯი შეგიძლიათ გადადგათ. BIMI (Brand Indicators for Message Identification) თქვენი ბრენდის ლოგოს მიმღების შემოსულების ყუთში აჩენს.

მოთხოვნები:

• DMARC პოლიტიკა მინიმუმ quarantine
• ლოგოს SVG Tiny PS ფორმატით გამოქვეყნება
• ზოგი პროვაიდერისთვის დამოწმებული ბრენდის სერტიფიკატი (VMC)

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

დომენის გადაცემა და მიგრაცია

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

1. ახალი პროვაიდერი SPF ჩანაწერში დაამატეთ (ძველი ჯერ არ ამოიღოთ).
2. ახალი DKIM სელექტორი გამოაქვეყნეთ.
3. გაგზავნა ახალ პროვაიდერზე გადაიტანეთ.
4. რამდენიმე დღე ანგარიშებს ადევნეთ თვალი.
5. ძველი პროვაიდერი SPF-დან და ძველი DKIM ჩანაწერი DNS-დან ამოიღეთ.

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

შემოწმების ავტომატიზაცია

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

სწრაფი შემოწმებისთვის ელფოსტის ჯანმრთელობის შემოწმების ხელსაწყოში დომენის შეყვანა საკმარისია; SPF-ის, DKIM-ისა და DMARC-ის მდგომარეობას ერთ ეკრანზე ნახავთ.

ამ სამი ჩანაწერის გამართვა ერთჯერადია, მაგრამ არასწორად გაკეთებისას ჩუმად აზიანებს: რომ თქვენი ელფოსტები არ მიდის, ჩვეულებრივ მაშინ ამჩნევთ, როცა კლიენტი გეუბნებათ „მოგწერეთ“.

თქვენი დომენის მიმდინარე მდგომარეობა ელფოსტის ჯანმრთელობის შემოწმებით შეგიძლიათ შეამოწმოთ.