ყველა სტატია

SPF, DKIM და DMARC: რომ საქმიანი წერილები ადრესატამდე მივიდეს

გამოქვეყნდა · კითხვის დრო: 7 წთ

სტატიის მოსმენა · კითხულობს ხელოვნური ინტელექტის ხმა

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

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

რატომ ხვდება წერილი სპამში: გამგზავნი დადასტურების გარეშე

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

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

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

SPF არის დომენის TXT ჩანაწერი, რომელიც v=spf1-ით იწყება და ჩამოთვლის სერვერებს, რომლებსაც ამ დომენის სახელით წერილის გაგზავნა შეუძლიათ. მიმღები სერვერი გამგზავნ სერვერს ამ სიას ადარებს. ასე ჩანს esn.ge-ის SPF ჩანაწერი:

v=spf1 mx include:_spf.webhosting.systems include:_spf.protonmail.ch -all

ჩანაწერი სამი მექანიზმისგან შედგება:

  • mx ანიჭებს უფლებას იმ სერვერებს, რომლებიც დომენის MX ჩანაწერებშია მითითებული;
  • include: ამატებს სხვა დომენის დაშვებულ სერვერებს, მაგალითად include:_spf.protonmail.ch;
  • -all აცხადებს, რომ ყველა დანარჩენი სერვერი შემოწმებას ვერ გაივლის.

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

პრაქტიკული მაგალითი: თუ თქვენი ვებ-აპლიკაცია წერილებს კონტეინერიდან აგზავნის, წერილი იმავე საფოსტო სერვერიდან უნდა გავიდეს, რომელსაც SPF, DKIM და DMARC ჩანაწერები მოიცავს. epicsoft-ის ღია კოდის smarthost (Postfix Alpine-ზე) სწორედ ამისთვისაა: ის SMTP-რელეა გამავალი წერილებისთვის. აპლიკაციები წერილს მას გადასცემენ, ის კი ავთენტიფიკაციითა და TLS-ით აწვდის კომპანიის საფოსტო სერვერს. მისი პარამეტრი SMARTHOST_FORCE_FROM ცვლის მხოლოდ ხილულ From: სათაურს და არა კონვერტის გამგზავნს.

DKIM: ყოველი წერილის ხელმოწერა

SPF ამოწმებს, საიდან მოდის წერილი. DKIM ამოწმებს, ხელმოწერილია თუ არა თვითონ წერილი. გამგზავნი სერვერი ყოველ წერილს პირადი გასაღებით აწერს ხელს და ხელმოწერას DKIM-Signature სათაურში ამატებს. ამ სათაურში მითითებულია დომენი (d=) და სელექტორი (s=). მიმღები სერვერი ამ ორი მონაცემით პოულობს საჯარო გასაღებს თქვენი დომენის TXT ჩანაწერში, რომლის სახელია <სელექტორი>._domainkey.<დომენი>, და ხელმოწერას ამოწმებს.

თავად ჩანაწერს ასეთი ფორმა აქვს. ქვემოთ მხოლოდ მაგალითია, ადგილმჭერებით: სელექტორი mail და დომენი your-company.ge ნამდვილი მონაცემები არ არის.

mail._domainkey.your-company.ge   TXT   "v=DKIM1; k=rsa; p=<საჯარო გასაღები>"

გასაღების სიგრძეც მნიშვნელოვანია. Google-ის მოთხოვნით, პირად Gmail-ის ანგარიშებზე გასაგზავნად საჭიროა 1024 ბიტის ან უფრო გრძელი DKIM გასაღები. თუ საფოსტო სერვისი ამ ჩანაწერს თქვენთვის ქმნის, გასაღების სიგრძე მაინც გადაამოწმეთ.

DMARC: რა ემართება წერილს მოქმედი დადასტურების გარეშე და ანგარიშები

SPF და DKIM მხოლოდ შედეგს იძლევა. DMARC განსაზღვრავს, რა უნდა გაკეთდეს ამ შედეგით. ის დომენის TXT ჩანაწერია სახელით _dmarc.<დომენი>.

წერილი DMARC-ს გადის, როცა SPF ან DKIM გავიდა და მისი დომენი თანხვედრაშია (ინგლ. alignment) From: მისამართის დომენთან. სხვა სიტყვებით, ნებისმიერი დომენის დადასტურება არ კმარა: დადასტურებული დომენი ის დომენი უნდა იყოს, რომელსაც ადრესატი წერილში ხედავს.

პოლიტიკა სამგვარია:

  • p=none მხოლოდ ანგარიშებს აგროვებს და წერილებს არ ეხება;
  • p=quarantine მიმღებს სთხოვს, შემოწმებაში ჩავარდნილი წერილი საეჭვოდ მიიჩნიოს, მაგალითად სპამში მოათავსოს;
  • p=reject მიმღებს სთხოვს, ასეთი წერილი უარყოს.

ანგარიშების მისამართებიც ჩანაწერშივე მიეთითება. rua ასახელებს, სად გაიგზავნოს აგრეგირებული ანგარიშები, ruf კი იმ მისამართს, სადაც წარუმატებლობის ანგარიშები მივა. ასე გაიგებთ, რომელი სერვერები აგზავნიან წერილებს თქვენი დომენის სახელით, მათ შორის იმათაც, რომლებიც არ იცით.

DMARC-ს ახალი სპეციფიკაცია აქვს. RFC 9989 2026 წლის 19 მაისს გამოქვეყნდა და ძალადაკარგულად აცხადებს RFC 7489-ს (DMARC, 2015) და ექსპერიმენტულ RFC 9091-ს. მასთან ერთად გამოვიდა RFC 9990 (აგრეგირებული ანგარიშები) და RFC 9991 (წარუმატებლობის ანგარიშები). საზოგადოებაში მას DMARCbis ეძახიან. DMARC ინფორმაციული სტატუსიდან IETF-ის სტანდარტების ხაზზე წარდგენილ სტანდარტად (Proposed Standard) გადავიდა. არსებული ჩანაწერები კვლავ მუშაობს; რა შეიცვალა, ქვემოთ, მეექვსე ნაწილში ვწერთ.

რას ითხოვენ Google და Yahoo გამგზავნებისგან

Google-მა მოთხოვნები 2024 წლის 1 თებერვლიდან გააქტიურა. ისინი ორ ჯგუფადაა გაყოფილი.

ყველა გამგზავნი, ვინც Gmail-ის ანგარიშებზე წერს (2024 წლის 1 თებერვლიდან):

  • გამგზავნ დომენებზე SPF ან DKIM უნდა იყოს მოწყობილი;
  • Postmaster Tools-ში ნაჩვენები სპამის მაჩვენებელი 0,3%-ზე დაბლა უნდა დარჩეს. მონიტორინგის ნაწილი რეკომენდაციას იძლევა, რომ 0,10%-ზე დაბლა დარჩეს და არასდროს მიაღწიოს 0,30%-ს ან უფრო მეტს.

გამგზავნები, ვინც დღეში 5000-ზე მეტ წერილს უგზავნის Gmail-ის ანგარიშებს (ასევე 2024 წლის 1 თებერვლიდან):

  • დომენზე SPF და DKIM ორივე უნდა იყოს მოწყობილი;
  • DMARC უნდა იყოს მოწყობილი; პოლიტიკა შეიძლება იყოს none;
  • პირდაპირი წერილისთვის From: სათაურის დომენი SPF-ის ან DKIM-ის დომენთან თანხვედრაში უნდა იყოს, რაც DMARC-ის თანხვედრის გასავლელად აუცილებელია;
  • მარკეტინგული და გამოწერილი წერილები ერთი დაწკაპუნებით გამოწერის გაუქმებას უნდა უჭერდეს მხარს და წერილის ტექსტში თვალსაჩინო ბმული უნდა შეიცავდეს. ერთი დაწკაპუნებით გაუქმება მუშაობს სათაურებით List-Unsubscribe-Post: List-Unsubscribe=One-Click და List-Unsubscribe (RFC 2369, RFC 8058).

Yahoo-ს გამგზავნის მოთხოვნების აღსრულება 2024 წლის თებერვალში დაიწყო და, მისივე სიტყვებით, თანდათან გაფართოვდა, ვინაიდან შესაბამისობას წლის პირველი ნახევრის განმავლობაში აკვირდებოდნენ. მინიმუმად Yahoo ითხოვს SPF-ის ან DKIM-ის დანერგვას.

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

ეტაპობრივი დანერგვა: p=none-დან p=quarantine-ის გავლით p=reject-მდე

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

  1. p=none. ჩანაწერი მხოლოდ ანგარიშებს აგროვებს. წაიკითხეთ ისინი და გაარკვიეთ, რომელი სერვერები წერენ თქვენი დომენის სახელით.
  2. p=quarantine. როცა ყველა კანონიერი გამგზავნი SPF-ში ან DKIM-ში შესულია, შემოწმებაში ჩავარდნილი წერილები საეჭვოდ მოინიშნება.
  3. p=reject. საბოლოო ეტაპზე მიმღებს ეთხოვება, წერილი, რომელიც შემოწმებას ვერ გადის, უარყოს.

esn.ge ამჟამად p=quarantine პოლიტიკას იყენებს და ყველა მნიშვნელობას პირდაპირ აცხადებს; ტეგები წერტილ-მძიმით არის გამოყოფილი, ჰარის გარეშე. ეს ჩანაწერია _dmarc.esn.ge-ზე:

v=DMARC1;p=quarantine;sp=quarantine;pct=100;rua=mailto:dmarc@reports.epicsoft.email;ruf=mailto:dmarc@reports.epicsoft.email;ri=86400;aspf=r;adkim=r;fo=1;rf=afrf;

თითოეული ნაწილი:

  • v=DMARC1 არის ვერსია;
  • p=quarantine არის პოლიტიკა დომენისთვის;
  • sp=quarantine იგივე პოლიტიკაა ქვედომენებისთვის;
  • pct=100 ნიშნავს, რომ პოლიტიკა ყველა წერილზე ვრცელდება;
  • rua=mailto:dmarc@reports.epicsoft.email არის მისამართი აგრეგირებული ანგარიშებისთვის;
  • ruf=mailto:dmarc@reports.epicsoft.email არის მისამართი წარუმატებლობის ანგარიშებისთვის;
  • ri=86400 ანგარიშების ინტერვალის ტეგია;
  • aspf=r და adkim=r ნიშნავს მსუბუქ (relaxed) თანხვედრას SPF-ისა და DKIM-ისთვის;
  • fo=1 ითხოვს წარუმატებლობის ანგარიშს, როცა რომელიმე შემოწმება ვერ გაიარა;
  • rf=afrf ანგარიშის ფორმატის ტეგია.

რა შეიცვალა RFC 9989-ში: ახალმა სპეციფიკაციამ ტეგები pct, rf და ri ამოიღო, ანუ esn.ge-ის ჩანაწერის სამივე ეს ტეგი მოძველებულია. ახალ ჩანაწერებში მათ აღარ გირჩევთ. pct-ის ადგილას მოდის ტეგი t (ტესტირების რეჟიმი), რომელსაც მხოლოდ ორი მდგომარეობა აქვს: ყველაფერი (100%) ან არაფერი (0%). დაემატა ტეგი np (პოლიტიკა არარსებული ქვედომენებისთვის; თუ ის გამოტოვებულია, მოქმედებს sp) და psd (საჯარო სუფიქსის დომენი). ორგანიზაციის დომენს ახლა Public Suffix List-ის ნაცვლად DNS Tree Walk პოულობს.

ჩანაწერები ისევ v=DMARC1-ით იწყება, ამიტომ, როგორც ერთი ანალიტიკური წყარო წერს, უმეტეს მოქმედ ჩანაწერს დაუყოვნებლივი ცვლილება არ სჭირდება.

დამატებით: MTA-STS ტრანსპორტის დაშიფვრისთვის

SPF, DKIM და DMARC წერილის ავთენტურობას ამოწმებს, მაგრამ ტრანსპორტის დაშიფვრას არ განსაზღვრავს. ამას MTA-STS ემსახურება: დომენი აცხადებს, რომ მისთვის განკუთვნილი წერილი მხოლოდ TLS-ით, მოქმედი სერტიფიკატით უნდა მიიტანონ. TXT ჩანაწერი _mta-sts.<დომენი> შეიცავს v=STSv1-ს და id-ს, რომელიც პოლიტიკის ყოველი ცვლილებისას იცვლება. თავად პოლიტიკა ფაილია /.well-known/mta-sts.txt, რომელიც HTTPS-ით ხელმისაწვდომია დომენის mta-sts ქვედომენზე, რეჟიმებით enforce, testing ან none.

esn.ge-ზე _mta-sts.esn.ge CNAME ჩანაწერია და _mta-sts.epicsoft.email-ზე მიუთითებს. იქ TXT ჩანაწერი ასეთია:

v=STSv1;id=20261012084000

ანუ esn.ge MTA-STS ჩანაწერს საფოსტო დომენიდან epicsoft.email იღებს.

როგორ აწყობს ამას epicsoft

epicsoft networks-ის საფოსტო სერვისის დაყენებისას საფოსტო ყუთებს და თქვენი დომენის MX, SPF, DKIM და DMARC ჩანაწერებს ჩვენ ვქმნით. დომენის შენარჩუნება შეგიძლიათ: ჩანაწერებს ან თქვენთან ერთად ვაწყობთ თქვენს DNS პროვაიდერთან, ან დომენის DNS-ს ჩვენ ვმართავთ. წერილები ინახება epicsoft-ის საკუთარ საფოსტო სერვერებზე ფინეთსა და გერმანიაში. დეტალები: ელფოსტა თქვენი დომენით. ყველა სერვისი იხილეთ მთავარ გვერდზე.

წყაროები

სხვა სტატიები

მზად ხართ შემდეგი ნაბიჯისთვის?

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

დაგვიკავშირდით