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

DMARC-ის დანერგვა სამი პოლიტიკაა და მათ შორის შეგროვებული მტკიცებულებები. აქვეყნებ p=none-ს rua მისამართით, ორიდან ოთხ კვირამდე აგროვებ ყოველდღიურ aggregate ანგარიშებს დიდი მიმღებებისგან, ასწორებ ყველა ლეგიტიმურ გამგზავნს, რომელიც alignment-ზე ვარდება, შემდეგ გადადიხარ p=quarantine-ზე და ბოლოს p=reject-ზე, და ყოველ ნაბიჯზე ანგარიშებს კითხულობ. მთავარი ანგარიშებია. ეს ერთადერთი ხედვაა, რომელსაც იღებ იმაზე, ვინ აგზავნის ფოსტას შენი დომენით From: ხაზში მთელ ინტერნეტში - შენი საკუთარი სერვერები, სერვისები, რომლებიც დაგავიწყდა, გადამგზავნები და ადამიანები, რომლებიც შენს სახელს ითვისებენ. პირდაპირ p=reject-ზე გადასვლა მათი წაკითხვის გარეშე ზუსტად ის გზაა, რომლითაც ორგანიზაციები აღმოაჩენენ, რომ მათი ინვოისების სისტემა არასოდეს ყოფილა ავთენტიფიცირებული - იმ დღეს, როცა კლიენტები ინვოისების მიღებას წყვეტენ.

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

ჩანაწერი, ტეგ-ტეგ, დანერგვისთვის#

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; fo=1

ტეგები, რომლებსაც დანერგვისას მნიშვნელობა აქვს:

fo=1 ითხოვს ჩავარდნის ანგარიშებს მაშინ, როცა რომელიმე მექანიზმი ვარდება, და არა მხოლოდ მაშინ, როცა ყველა ვარდება. ის მხოლოდ ruf ანგარიშებზე მოქმედებს, რომლებსაც დიდი მიმღებების უმეტესობა კონფიდენციალურობის მიზეზით არ აგზავნის, ამიტომ ზიანი თითქმის არ მოაქვს და ზოგჯერ გეხმარება.

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

რას შეიცავს aggregate ანგარიში#

Aggregate ანგარიშები ელფოსტის მიმაგრებული ფაილებით მოდის - gzip-ით ან zip-ით შეკუმშული XML, თითო მიმღებისგან დღეში ერთი, და მათ აგზავნიან Google, Microsoft, Yahoo და ბევრი პატარა პროვაიდერი. თითოეული აღწერს ფოსტას, რომელიც ამ მიმღებმა შენი დომენის სახელით დაინახა, დაჯგუფებულს გამგზავნი IP-ისა და შედეგის მიხედვით. მთავარამდე შემოკლებული:

<feedback>  <report_metadata>    <org_name>google.com</org_name>    <date_range><begin>1791331200</begin><end>1791417599</end></date_range>  </report_metadata>  <policy_published>    <domain>example.com</domain><p>none</p><adkim>r</adkim><aspf>r</aspf>  </policy_published>  <record>    <row>      <source_ip>203.0.113.25</source_ip>      <count>412</count>      <policy_evaluated>        <disposition>none</disposition><dkim>pass</dkim><spf>pass</spf>      </policy_evaluated>    </row>    <identifiers><header_from>example.com</header_from></identifiers>    <auth_results>      <dkim><domain>example.com</domain><selector>s2026a</selector><result>pass</result></dkim>      <spf><domain>example.com</domain><result>pass</result></spf>    </auth_results>  </record></feedback>

ყოველი record წინადადებასავით წაიკითხე: "IP 203.0.113.25-დან 412 წერილი From: example.com-ით; DKIM გავიდა aligned, SPF გავიდა aligned; მათ არაფერი დავუშავეთ, რადგან პოლიტიკა none-ია." policy_evaluated ბლოკი იძლევა aligned DMARC ვერდიქტებს. auth_results ბლოკი იძლევა SPF-ისა და DKIM-ის ნედლ შედეგებს იმ დომენთან ერთად, რომლისთვისაც თითოეული იყო - ასე ხედავ, რომ SPF გავიდა, მაგრამ bounces.provider.example-ისთვის, რომელიც aligned არ არის.

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

ანგარიშებისთვის ცალკე მისამართი გამოიყენე. დატვირთული დომენი დღეში ათობით ანგარიშს იღებს, და ეს ის არ არის, რაც ადამიანს თავის inbox-ში უნდა.

აღმოჩენილი გამგზავნების დახარისხება#

ორი კვირის ანგარიშების შემდეგ გექნება წყარო IP-ების სია. თითოეული ოთხი ჯგუფიდან ერთ-ერთში ხვდება, და თითოეულს თავისი მოქმედება სჭირდება.

1. შენი საკუთარი ინფრასტრუქტურა, aligned. შენი საფოსტო სერვერი, რომელიც DKIM-ს შენი დომენით გადის. არაფერია გასაკეთებელი.
2. ლეგიტიმური სერვისები, არა aligned. საინფორმაციო ბიულეტენის პლატფორმა, CRM, helpdesk, ბილინგის სისტემა, რეკრუტინგის ხელსაწყო - აგზავნიან შენი დომენის სახელით, მაგრამ SPF-სა და DKIM-ს მხოლოდ საკუთარი დომენებისთვის გადიან, ან საერთოდ არ გადიან. ნამდვილი სამუშაო ესენია. პროვაიდერი IP-ის reverse DNS-ით ან IP ძებნით გაარკვიე, შემდეგ მის პარამეტრებში ჩართე DKIM შენი დომენით და, სადაც შესაძლებელია, საკუთარი return-path დომენი.
3. გადამგზავნები. უნივერსიტეტის ალიასები, ძველი მისამართები, რომლებიც Gmail-ზე გადაამისამართებენ, საფოსტო სიები. SPF ვარდება, რადგან გადამგზავნის IP შენი არ არის; DKIM ხშირად მაინც გადის, თუ წერილი არ შეცვლილა. ამათ ვერ გაასწორებ, და როცა DKIM გადის, არც გჭირდება.
4. სხვის სახელს მითვისებულები. IP-ები, რომლებსაც შენთან კავშირი არ აქვთ, ყველაფერზე ვარდებიან და ხშირად იმ ქვეყნებში არიან, საიდანაც არ აგზავნი. სწორედ მათთვის არსებობს DMARC-ის აღსრულება. ჩაინიშნე და გააგრძელე.

მოცულობა პრიორიტეტების დალაგებაში გეხმარება. ლეგიტიმურ სერვისს, რომელიც თვეში 3,000 წერილს აგზავნის aligned-ის გარეშე, მნიშვნელობა აქვს; გადამგზავნს, რომელმაც ექვსი წერილი გადასცა - არა.

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

უცნობი IP-ის ამოცნობა

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

# Reverse DNS often names the provider outright$ dig +short -x 198.51.100.77# Who holds the address block$ whois 198.51.100.77 | grep -iE 'orgname|org-name|netname|descr'

შემდეგ შეხედე DKIM-ის domain-სა და selector-ს ანგარიშის იმავე სტრიქონში: ხელმოწერა d=sendgrid.net-ით ან selector, როგორიცაა pm, სერვისს გეტყვის მაშინაც, როცა IP არაფერს ამბობს. თუ IP დიდ ღრუბლოვან პროვაიდერს ეკუთვნის და არცერთი ხელმოწერა სერვისს არ ასახელებს, კოლეგებს ჰკითხე, იქ რა მუშაობს, სანამ ჩათვლი, რომ ის მტრულია.

მაგალითი: გამგზავნები, რომლებიც არავის ჩამოუთვლია#

პატარა კომპანია საკუთარი საფოსტო სერვერით აქვეყნებს p=none-ს და rua-ს ანგარიშების საფოსტო ყუთზე მიუთითებს. სამი კვირის შემდეგ დამუშავებული ანგარიშები აჩვენებს ხუთ წყაროს, რომლებიც example.com-ის სახელით აგზავნიან:

1. მათი საკუთარი საფოსტო სერვერი, 6,200 წერილი, DKIM და SPF ორივე aligned. ყველაფერი რიგზეა.
2. Helpdesk პლატფორმა, 900 წერილი, SPF გადის პლატფორმის bounce დომენისთვის, DKIM ხელმოწერილია პლატფორმის საკუთარი დომენით. არცერთი არ არის aligned - p=reject-ის პირობებში ტიკეტზე ყოველი პასუხი უარყოფილი იქნებოდა.
3. საბუღალტრო პროგრამა, 140 წერილი, ყველა თვის ბოლო ორ დღეს, DKIM საერთოდ არ აქვს, SPF ვარდება. IT-ში არავინ იცოდა, რომ ის ფოსტას აგზავნიდა; ფინანსებს ის ისე ჰქონდათ მორგებული, რომ ინვოისები accounts@example.com-ის სახელით გაეგზავნა.
4. ერთი თანამშრომლის უნივერსიტეტის გადამისამართების მისამართი, 30 წერილი, SPF ვარდება, DKIM გადის. არაფერია გასაკეთებელი.
5. თორმეტი IP სამ ქვეყანაში, 2,000 წერილი, ყველაფერზე ვარდება. სხვისი სახელის მითვისება.

გასწორებებს ერთი შუადღე სჭირდება. Helpdesk გთავაზობს DKIM-ს საკუთარი დომენით: ორი CNAME ჩანაწერი, დადასტურების ერთი დაწკაპუნება, და მისი ხელმოწერები ახლა d=example.com-ს ატარებს. საბუღალტრო პროგრამა ხელს ვერ აწერს, მაგრამ SMTP სერვერით გაგზავნა შეუძლია, ამიტომ ფინანსები მას კომპანიის საკუთარი საფოსტო სერვერის submission პორტზე მიუთითებენ ცალკე ანგარიშით, და ინვოისებს ახლა Stalwart აწერს ხელს, როგორც დანარჩენ ყველაფერს.

ერთი კვირის შემდეგ ანგარიშები აჩვენებს, რომ 1-დან 3-მდე წყაროები aligned არის. კომპანია გადადის p=quarantine-ზე, შემდეგ ერთი თვის მერე p=reject-ზე. მე-5 ჯგუფის მითვისება ანგარიშებში ისევ ჩნდება - ახლა ყოველ წერილზე reject დისპოზიციით. ეს ბოლო სტრიქონი მთელი ამ სამუშაოს შედეგია.

Alignment ზუსტად#

DMARC გადის, თუ SPF ან DKIM გადის და დომენი, რომლისთვისაც გავიდა, From:-ში მყოფ დომენთან aligned არის.

• DKIM aligned არის, როცა ხელმოწერის d= დომენი From: დომენს ემთხვევა.
• SPF aligned არის, როცა envelope sender-ის დომენი (MAIL FROM, ჩანს როგორც Return-Path) From: დომენს ემთხვევა.

რბილ რეჟიმში (r, ნაგულისხმევი) "ემთხვევა" ნიშნავს იმავე ორგანიზაციულ დომენს: mail.example.com aligned არის example.com-თან, და ორივე aligned არის news.example.com-თან. ორგანიზაციული დომენი Public Suffix List-ით დგინდება, და ამიტომ მუშაობს example.co.uk სწორად, ხოლო co.uk ერთ ორგანიზაციად არასოდეს ითვლება. მკაცრ რეჟიმში (s) დომენები იდენტური უნდა იყოს.

ორივე რბილზე დატოვე. მკაცრი alignment აფუჭებს საკუთარ return-path ქვედომენებს, რომლებიც მესამე მხარის გამგზავნებისთვის SPF-ს aligned ხდის, და სანაცვლოდ არაფერს იძლევა, რასაც დომენების უმეტესობისთვის მნიშვნელობა აქვს.

დანერგვა ნაბიჯ-ნაბიჯ#

1. გამოაქვეყნე `p=none` `rua`-თი. დაელოდე ორიდან ოთხ კვირამდე. ჩართე სულ მცირე ერთი თვის ბოლო, თუ შენი ორგანიზაცია ინვოისებს აგზავნის.
2. გაასწორე ყველა ლეგიტიმური არა-aligned გამგზავნი, რომელსაც ანგარიშები აჩვენებს. ყოველი გასწორებიდან ერთი კვირის შემდეგ ანგარიშები ხელახლა შეამოწმე, რომ დარწმუნდე, ცვლილება ამოქმედდა.
3. გადადი `p=quarantine`-ზე. თუ ნერვიულობ, გამოიყენე pct თანდათანობით გამოსაყენებლად: pct=25 ჩავარდნილი ფოსტის მეოთხედს სპამში აგზავნის და დანარჩენს none-ად ეპყრობა. ერთი-ორი კვირის შემდეგ, თუ საჩივრები არ ყოფილა, pct=100-მდე აწიე.
4. `quarantine`-ზე დარჩი სულ მცირე ორი კვირა, ისე, რომ არაფერი ლეგიტიმური არ ვარდებოდეს.
5. გადადი `p=reject`-ზე. ჩავარდნილი ფოსტა ახლა SMTP საუბრის დროს უარიყოფა, ამიტომ არასწორად მორგებული გამგზავნი bounce-ს იღებს და ჩუმად სპამში არ ხვდება - რაც დიაგნოსტიკისთვის quarantine-ზე უკეთესია.
6. `rua` მისამართი დატოვე. ახალი სერვისები ემატება, ვიღაც პროვაიდერს ცვლის, გასაღების როტაცია ცუდად მიდის. ანგარიშები ის საშუალებაა, რომლითაც ამას ერთ დღეში გაიგებ და არა ერთ თვეში.

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

ქვედომენები მე-5 ნაბიჯამდე ფიქრს იმსახურებს. sp= ქვედომენების პოლიტიკას აყენებს, ნაგულისხმევად კი დომენის საკუთარ p-ს იღებს. თუ ქვედომენებიდან აგზავნი, მაგალითად news.example.com-დან, ანგარიშებში ისინიც შეამოწმე. თუ ქვედომენებიდან არასოდეს აგზავნი, ადრეულ ეტაპზე sp=reject მითვისების საყვარელ ხრიკს მცირე რისკით კეტავს.

რა ფუჭდება p=reject-ზე#

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

• საფოსტო სიები, რომლებიც წერილებს ცვლიან. სია, რომელიც თემას პრეფიქსს ან ფუტერს უმატებს, DKIM-ს აფუჭებს, ხოლო სიის სერვერის IP შენი დომენისთვის SPF-ზე ვარდება. თანამედროვე სიების პროგრამების უმეტესობა DMARC-ს უვლის გვერდს: p=reject დომენებიდან პოსტების ავტორებისთვის From:-ს სიის საკუთარ მისამართად გადაწერს, ხოლო ARC (Authenticated Received Chain) სიებს საშუალებას აძლევს, თავდაპირველი ვერდიქტი გადასცენ იმ მიმღებებს, რომლებიც მათ ენდობიან. ძველმა სიებმა შეიძლება შენი წევრების პოსტები მაინც დააბრუნონ.
• გადამისამართება, რომელიც წერილებს ცვლის. უბრალო გადამისამართება ჩვეულებრივ DKIM-ის წყალობით გადარჩება. გადამისამართება უსაფრთხოების gateway-ით, რომელიც ბმულებს გადაწერს - არა.
• მოწყობილობები და სკრიპტები, რომლებიც პირდაპირ აგზავნიან. ოფისის სკანერი, რომელიც PDF-ებს აგზავნის ელფოსტით, NAS, რომელიც შეტყობინებებს აგზავნის, cron job დავიწყებულ სერვერზე, რომელიც ანგარიშს აგზავნის - თითოეული შენი დომენის სახელით პირდაპირ მიმღებთან აგზავნის, ხელმოუწერლად. ისინი, როგორც წესი, შიდა მისამართებზე აგზავნიან, ამიტომ Google-ის ან Microsoft-ის ანგარიშებში შეიძლება არასოდეს გამოჩნდნენ, და ჩუმად ფუჭდებიან. თითოეული მიუთითე შენი საკუთარი საფოსტო სერვერის submission პორტზე საკუთარი ანგარიშით, რომ მათი ფოსტაც ისევე იყოს ხელმოწერილი, როგორც ყველა დანარჩენის.

არცერთი მათგანი არ არის მიზეზი, რომ სამუდამოდ p=none-ზე დარჩე. ისინი მიზეზია, რომ აღსრულების შემდეგაც კითხულობდე ანგარიშებს და იცოდე, რა უთხრა კოლეგას, რომლის პოსტიც ძველ საფოსტო სიაში დაბრუნდა.

რად ღირს ეს ყველაფერი: მიმღებების მოთხოვნები#

2024 წლის თებერვლიდან Google და Yahoo ყველასგან, ვინც მათ მომხმარებლებს დღეში დაახლოებით 5,000-ზე მეტ წერილს უგზავნის, მოითხოვენ DMARC ჩანაწერის გამოქვეყნებას (სულ მცირე p=none), გავლილი და aligned SPF-ით და DKIM-ით. Microsoft-მა მსგავსი მოთხოვნები Outlook.com-ის მისამართებზე მაღალი მოცულობის გამგზავნებისთვის 2025 წელს გამოაცხადა. პატარა გამგზავნებს უფრო მსუბუქი სტანდარტით აფასებენ, მაგრამ დომენს, რომელსაც DMARC საერთოდ არ აქვს, სულ უფრო ხშირად საეჭვოდ თვლიან. ხოლო დომენი p=reject-ზე მითვისებისთვის გაცილებით ნაკლებად მიმზიდველია, რადგან მითვისებულ ფოსტას ყველა მსხვილი მიმღები უარყოფს. პოსტი რატომ ხვდება ელფოსტა სპამში DMARC-ს იმ ყველაფრის კონტექსტში განიხილავს, რასაც მიმღებები ამოწმებენ.

DMARC RE:NODE-ის Mail Server-თან#

Mail Server გეგმაზე Stalwart შენს გამავალ ფოსტას ხელს აწერს DKIM გასაღებებით, რომლებსაც მისი ვებ ადმინკა ყოველი დომენისთვის აგენერირებს, რაც პირველივე დღიდან გაძლევს aligned DKIM-ს შენი საკუთარი სერვერიდან. თავად DMARC ჩანაწერის გამოქვეყნება შენი საქმეა, MX-თან, SPF-თან და DKIM-თან ერთად, იქ, სადაც შენი DNS-ია განთავსებული - ჩვენს მხარეს ზონის რედაქტორი არ არის. იმავე სერვერზე მყოფი საფოსტო ყუთი ანგარიშებისთვის ბუნებრივი rua დანიშნულებაა. სამუშაოს დანარჩენი ნაწილი - სხვა სერვისების პოვნა და გასწორება, რომლებიც შენი დომენის სახელით აგზავნიან - ერთნაირია, სადაც არ უნდა ცხოვრობდეს შენი ფოსტა. ხელმოწერის მხარე აღწერილია პოსტში DKIM გასაღებები და როტაცია.

FAQ#

რამდენ ხანს დავრჩე p=none-ზე?

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

რატომ არ ვიღებ არცერთ DMARC ანგარიშს?

შეამოწმე rua-ს სინტაქსი (mailto: აუცილებელია), შეამოწმე, რომ ჩანაწერი _dmarc.example.com-ზეა, და თუ მისამართი სხვა დომენზეა, შეამოწმე, რომ ეს დომენი ავტორიზაციის ჩანაწერს აქვეყნებს. ანგარიშების მოსვლის დაწყებას ასევე ერთი-ორი დღე სჭირდება, და დომენმა, რომელიც ცოტას აგზავნის, შეიძლება ცოტა მიიღოს.

რატომ არასოდეს ვიღებ ruf ჩავარდნის ანგარიშებს?

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

Quarantine reject-ზე უსაფრთხოა?

შეცდომის მიმართ უფრო რბილია, რადგან ჩავარდნილი ფოსტა სპამში მიდის და არ ბრუნდება. მაგრამ არასწორად მორგებული გამგზავნის შემჩნევა quarantine-ის პირობებში უფრო რთულია, რადგან bounce-ს არავინ იღებს. Quarantine ეტაპად განიხილე და არა საბოლოო დანიშნულებად.

DMARC მჭირდება დომენებზე, რომლებიც ფოსტას არასოდეს აგზავნიან?

კი, და პირდაპირ p=reject-ზე გადადი v=spf1 -all-თან და null MX-თან ერთად. გასაფუჭებელი ლეგიტიმური არაფერია, ხოლო პარკირებული დომენები მითვისებისთვის საყვარელი სამიზნეა.