SPF, DKIM და DMARC: რატომ ხვდება შენი ფოსტა სპამში

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

ჯერ ერთი რამ, რადგან ის ცვლის, რას უნდა კითხულობდე: RE:NODE ელფოსტას არ უმასპინძლებს. არც საფოსტო ყუთები, არც MX, არც SMTP relay და არც DNS ზონები - ქვემოთ მოცემული ჩანაწერები იქმნება იქ, სადაც შენი დომენის nameserver-ები მიუთითებს, ჩვეულებრივ რეგისტრატორთან. ჩვენ ვმასპინძლობთ აპლიკაციას ან საიტს, რომელიც ფოსტას აგზავნის, და ეს ნაწილი ბოლოშია განხილული.

ორი From მისამართი და რატომ არის ეს მთელი პრობლემა#

SMTP შეტყობინებას ორი გამგზავნი აქვს და მათ ერთმანეთს ემთხვევა არ ევალებათ.

Envelope sender არის ის, რასაც გამგზავნი სერვერი SMTP საუბრისას MAIL FROM ბრძანებაში აცხადებს. იქ მიდის bounce-ები, ის Return-Path header-შია ჩაწერილი და საფოსტო კლიენტში მას არავინ ხედავს. ფორმის გამგზავნზე ის ხშირად რაღაც bounces@sendgrid.net ან www-data@server42.hostingco.net-ს ჰგავს.

Header From არის ხაზი შეტყობინების შიგნით, რომელიც ამბობს From: Anna <anna@example.com>. მხოლოდ ამას კითხულობს ადამიანი და სწორედ ამის კონტროლი უნდა ფიშერს.

SPF ამოწმებს envelope sender-ს. DKIM ხელს აწერს შეტყობინებას და ასახელებს ხელმომწერ დომენს. არცერთი მათგანი თავისთავად არაფერს ამბობს მისამართზე From: ხაზში - რომელსაც სწორედ ბოროტად იყენებენ. DMARC ამ ხარვეზს ხურავს: ის მოითხოვს, რომ ორი გავლილი შემოწმებიდან ერთ-ერთი ხილულ From:-ის იმავე დომენზე მიუთითებდეს, და გაძლევს საშუალებას გამოაქვეყნო, რა უნდა მოხდეს, როცა არცერთი არ მიუთითებს.

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

SPF არის ერთი TXT ჩანაწერი შენი დომენის apex-ზე, რომელიც ჩამოთვლის ყველა წყაროს, რომელსაც შეუძლია შენი დომენი envelope sender-ში ჩასვას.

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

წაიკითხე მარცხნიდან მარჯვნივ. მიმღები თითოეულ მექანიზმს ამოწმებს დამაკავშირებელი სერვერის IP მისამართზე და პირველ დამთხვევაზე ჩერდება.

all-ის წინ მდგარი კვალიფიკატორი ვერდიქტია ყველაფრისთვის, რაც არ დაემთხვა: -all მკაცრი უარია, ~all რბილი უარი, ?all ნეიტრალური, ხოლო +all ნიშნავს "ნებისმიერს შეუძლია ჩემი სახელით გაგზავნა", რაც უარესია, ვიდრე ჩანაწერის საერთოდ არქონა.

ოთხი წესი წყვეტს, მუშაობს თუ არა SPF ჩანაწერი:

1. ერთი ჩანაწერი დომენზე. ორი TXT ჩანაწერი, რომელიც v=spf1-ით იწყება, მუდმივ შეცდომას იძლევა და ყველაფერი ვარდება. თუ პროვაიდერს ამატებ, არსებული ჩანაწერი შეასწორე; მეორეს ნუ შექმნი.
2. ათი DNS lookup სულ. include, a, mx, exists, ptr და redirect თითო ჯდება, და ყოველი include საკუთარ თავში კიდევ ხარჯავს. ათს ზემოთ შედეგი permerror-ია, რომელსაც მიმღებთა უმეტესობა უარად თვლის. ჩანაწერი ოთხი საფოსტო პროვაიდერით ჩვეულებრივ უკვე გადაჭარბებულია. რაც შეგიძლია, შეცვალე ip4: დიაპაზონებით, ან, თუ გჭირდება, გამოიყენე flattening სერვისი.
3. `ptr` მექანიზმი მოძველებულია. წაშალე. ის ნელია, არასანდო და RFC 7208 მიმღებებს ეუბნება, რომ შეუძლიათ გამოტოვონ.
4. SPF გადამისამართებას ვერ უძლებს. როცა უნივერსიტეტის alias შენს ფოსტას აგრძელებს, გადამგზავნის სერვერი საბოლოო დანიშნულებას უკავშირდება, envelope-ში შენი დომენით, მისამართიდან, რომელიც არასოდეს ჩაგიწერია. SPF ვარდება და ამის გაკეთება არაფერი შეგიძლია. ეს შენი კონფიგურაციის ხარვეზი არ არის - სწორედ ამიტომ არსებობს DKIM.

დაიწყე ~all-ით, სანამ ჯერ კიდევ ადგენ, ვინ აგზავნის შენი სახელით, და -all-ზე გადადი მხოლოდ მაშინ, როცა DMARC ანგარიშები გაჩვენებს, რომ ყველა იპოვე.

DKIM: ხელმოწერა, რომელიც შეტყობინებასთან ერთად მოგზაურობს#

გამგზავნი სერვერი ჰეშავს სხეულს და header-ების არჩეულ ნაკრებს, ჰეშს კერძო გასაღებით აწერს ხელს და ამატებს DKIM-Signature header-ს, რომელიც ასახელებს ხელმომწერ დომენს (d=) და გასაღების selector-ს (s=).

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com;  s=s1; h=from:to:subject:date:message-id; bh=47DEQpj8HBSa...;  b=Xk9pLm2Qv8...

მიმღები იღებს d=-სა და s=-ს, ეძებს s1._domainkey.example.com-ს და პოულობს საჯარო გასაღებს:

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...

პრაქტიკაში მნიშვნელოვანი წერტილები:

• უმეტეს შემთხვევაში ამას თავად არ აგენერირებ. შენი საფოსტო პროვაიდერი ქმნის გასაღებების წყვილს, კერძო ნახევარს ინახავს და გაძლევს TXT ჩანაწერს გამოსაქვეყნებლად. Google Workspace, Microsoft 365, Postmark, Mailgun და დანარჩენები ყველა ასე მუშაობს და თითოეულს თავისი selector აქვს.
• ყოველ გამგზავნს საკუთარი selector სჭირდება. ტრანზაქციული ფოსტა შენი აპლიკაციიდან, მარკეტინგული ფოსტა კამპანიის ინსტრუმენტიდან და ჩვეულებრივი ფოსტა შენი საფოსტო ყუთებიდან სამი განსხვავებული ხელმოწერის გასაღებია სამ განსხვავებულ selector-ზე, ყველა ერთსა და იმავე ზონაში. ისინი ერთმანეთს არ ეწინააღმდეგებიან.
• 2048-ბიტიანი გასაღები ერთ DNS სტრიქონში არ ეტევა. TXT ჩანაწერი შედგება არაუმეტეს 255 სიმბოლოიანი ნაწილებისგან, ამიტომ გასაღები უნდა გაიყოს. თითქმის ყველა DNS რედაქტორი ამას ჩუმად აკეთებს; ზოგი გაიძულებს, თავად გაჰყო ბრჭყალებით. თუ გამოქვეყნება წარმატებული ჩანს, მაგრამ შემოწმება ვარდება, ეს პირველი, რასაც უნდა შეამოწმო.
• DKIM გადამისამართებას უძლებს, სანამ რამე შეტყობინებას არ შეცვლის. საფოსტო სია, რომელიც footer-ს ამატებს ან თემას პრეფიქსს უკეთებს, ცვლის ბაიტებს, რომლებსაც ხელი ეწერა, და ხელმოწერა ირღვევა. სწორედ ამისთვის გამოიგონეს ARC header-ები და გამგზავნის ხელში ეს აღარ არის.
• ხანდახან გადაატრიალე გასაღებები. გამოაქვეყნე ახალი selector, გადართე გამგზავნი მასზე, დაელოდე ერთ კვირას გზაში მყოფი ფოსტისთვის, შემდეგ წაშალე ძველი ჩანაწერი.

DMARC: პოლიტიკა, რომელიც ორივეს აკავშირებს#

DMARC არის ერთი TXT ჩანაწერი _dmarc-ზე შენი დომენის ქვეშ.

v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=r; aspf=r; pct=100

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

rua-ზე მისული აგრეგირებული ანგარიშები gzip-ით შეკუმშული XML-ია, თითო მიმღებზე დღეში თითო, და თვალით წასაკითხად არ არის განკუთვნილი. მიაწოდე ისინი ნებისმიერ DMARC ანგარიშების parser-ს - უფასოც არსებობს - და მიიღებ ცხრილს გამგზავნი IP-ებისა, მათი SPF და DKIM შედეგებისა და იმისა, დაემთხვა თუ არა თითოეული. ეს ცხრილი მთელი წამოწყების აზრია.

Alignment არის ნაწილი, რომელიც ხალხს იჭერს#

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

DMARC გადის, როცა SPF-ისა ან DKIM-ის სულ მცირე ერთი გადის და დომენი, რომლისთვისაც გავიდა, ხილულ From: header-ში მდგარ დომენს ემთხვევა. ორივე ნაწილი სავალდებულოა. შეტყობინებას შეუძლია SPF სუფთად გაიაროს და მაინც DMARC-ზე ჩავარდეს, და ეს კომბინაცია ამ მთელ თემაში ყველაზე გავრცელებული support ბილეთია.

ასე ხდება. შენი საკონტაქტო ფორმა ტრანზაქციულ პროვაიდერზე გადის. პროვაიდერი envelope sender-ს აყენებს bounce@mail.provider.net, რადგან bounce-ები მათ უბრუნდებათ. SPF მოწმდება provider.net-ზე და გადის - მათი ჩანაწერი კარგია. მაგრამ From: header ამბობს hello@example.com. provider.net example.com არ არის, ამიტომ ეს გავლა aligned არ არის და DMARC-ს არაფერს ამატებს. თუ DKIM-იც d=provider.net-ით აწერს ხელს, DMARC სრულად ვარდება და შენი p=reject საკუთარ საკონტაქტო ფორმას აგდებს.

გამოსავალი ერთ-ერთია ორიდან და ყველა სერიოზული პროვაიდერი ორივეს გთავაზობს:

• Custom return path. აქვეყნებ CNAME-ს, მაგალითად bounces.example.com, რომელიც პროვაიდერის ინფრასტრუქტურაზე მიუთითებს, ისინი მას envelope დომენად იყენებენ და SPF ახლა გადის example.com-ის ქვედომენზე. relaxed alignment-ის ქვეშ - ნაგულისხმევი - ქვედომენი მშობელს ემთხვევა, ამიტომ DMARC კმაყოფილია.
• DKIM, რომელსაც შენი დომენი აწერს ხელს. აქვეყნებ პროვაიდერის selector-ს example.com-ის ქვეშ და ისინი d=example.com-ით აწერენ ხელს. ეს ორიდან უფრო მტკიცეა, რადგან გადამისამართებასაც უძლებს.

Relaxed alignment (r) იღებს ორგანიზაციული დომენის ნებისმიერ ქვედომენს: mail.example.com ემთხვევა example.com-ს. Strict (s) ზუსტ დამთხვევას მოითხოვს. ორივე relaxed დატოვე, თუ კონკრეტული მიზეზი არ გაქვს, რადგან strict alignment custom return path-ებს ტეხს ისეთი უსაფრთხოების სარგებლის გარეშე, რომელიც ამ დონეზე მნიშვნელობას იძენს.

გაშვება ფოსტის დაკარგვის გარეშე#

თანმიმდევრობას მნიშვნელობა აქვს. p=reject-ის გამოქვეყნება პირველ დღეს დომენზე, რომლის გამგზავნებიც არ აგიღია ინვენტარში, ნიშნავს, რომ შენი ინვოისები აღარ მიდის და არავინ გეუბნება.

1. ჩამოთვალე ყველა გამგზავნი. საფოსტო ყუთები, საიტის საკონტაქტო ფორმა, აპლიკაციის პაროლის აღდგენა, ინვოისების ინსტრუმენტი, CRM, newsletter, helpdesk, მონიტორინგის გაფრთხილებები და რაც სამი წლის წინ ბუღალტერიაში ვიღაცამ დააყენა. ეს ნაბიჯი ყველა დანარჩენზე მეტს გრძელდება.
2. გამართე SPF და DKIM თითოეულისთვის. ერთი SPF ჩანაწერი, რომელიც ყველას ფარავს ათი lookup-ის ბიუჯეტში; ერთი DKIM selector თითო გამგზავნზე, შენი დომენით ხელმოწერილი ყველგან, სადაც პროვაიდერი იძლევა.
3. გამოაქვეყნე `p=none` `rua` მისამართით. დატოვე ორიდან ოთხ კვირამდე და წაიკითხე ანგარიშები.
4. შეასწორე, რასაც ანგარიშები აჩვენებს. იქნება გამგზავნი, რომელიც დაგავიწყდა. ყოველთვის არის.
5. გადადი `p=quarantine`-ზე. გამოიყენე pct=25, შემდეგ pct=100, თუ უფრო რბილი ზრდა გინდა. კიდევ ორი კვირა უყურე ანგარიშებს.
6. გადადი `p=reject`-ზე. განაგრძე ანგარიშების კითხვა. ეს რამ არ არის, რასაც დაასრულებ.

ორი დამატება, რომლის ცოდნაც ღირს: მიმღები მხარე შეიძლება გამაგრდეს MTA-STS-ით, რომელიც გამგზავნებს ეუბნება, რომ შენი დომენი TLS-ს მოითხოვს, ხოლო BIMI ჩანაწერი - რომელიც ზოგ კლიენტში ფოსტის გვერდით ლოგოს აჩენს - მხოლოდ იმ დომენებზე მოქმედებს, რომლებიც უკვე p=quarantine ან p=reject-ზეა. არცერთი საწყისი წერტილი არ არის.

შემოწმება გარედან#

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

$ dig TXT example.com +short$ dig TXT s1._domainkey.example.com +short$ dig TXT _dmarc.example.com +short$ dig MX example.com +short

Windows-ზე იმავე საქმეს აკეთებს Resolve-DnsName example.com -Type TXT. თუ ჩანაწერი, რომელიც ახლახან გამოაქვეყნე, არ ჩანს, ის ქეშშია - პასუხი იმდენად ძველია, რამდენსაც TTL აძლევდა უფლებას. მის გასავლელად პირდაპირ ჰკითხე შენს ავტორიტეტულ nameserver-ს, როგორც აღწერილია nameserver-ები თუ DNS ჩანაწერებში, ხოლო რატომ არის ქეში ყოველთვის დამაბნეველი ნაწილი, იხილე DNS ჩანაწერები ახსნილი.

შემოწმების მეორე ნახევარია გაუგზავნო შეტყობინება ანგარიშზე, რომელსაც აკონტროლებ, და წაიკითხო header-ები. Gmail-ში Show original ვერდიქტებს ზემოთ ბეჭდავს; უმეტეს კლიენტში ეძებე Authentication-Results header:

Authentication-Results: mx.google.com;  spf=pass (google.com: domain of bounces.example.com designates  203.0.113.10 as permitted sender) smtp.mailfrom=bounces.example.com;  dkim=pass header.i=@example.com header.s=s1;  dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=example.com

სამი გავლა და header.from, რომელიც შენს დომენს ემთხვევა, დასრულებული მდგომარეობაა. ყველაფერი სხვა გეუბნება, სამიდან რომელს დაუბრუნდე.

კიდევ რა წყვეტს სპამის საქაღალდეს#

ავთენტიფიკაცია გაგიხილავს. მიწოდებას არ გარანტირებს. როცა SPF, DKIM და DMARC გადის, ფოსტას სპამში მაინც აგდებს:

• გამგზავნი IP-ისა და დომენის რეპუტაცია. ახალი გამგზავნი დომენები არაფრით იწყებენ და სიფრთხილით ეპყრობიან. გააგზავნე ნელი, მდგრადი მოცულობა რამდენიმე კვირა და არა ათი ათასი შეტყობინება პირველ დღეს.
• Reverse DNS. გამგზავნ IP-ს უნდა ჰქონდეს PTR ჩანაწერი, რომელიც უკან იმ სახელზე გადაიწყვეტა, რომელსაც სერვერი HELO-ში იყენებს. გაზიარებული relay-ები ამას აგვარებენ; სერვერს, რომელიც თავად გაამართე, ხშირად არა.
• საჩივრების მაჩვენებელი. Gmail-ის გამოქვეყნებული ზღვარი bulk გამგზავნებისთვის სპამზე საჩივრების მაჩვენებელია 0.3%-ზე ქვემოთ, 0.1% კი მიზანია. ერთი ცუდი სიის ყიდვა დომენს თვეებით აფუჭებს.
• გამოწერის გაუქმების დამუშავება. 2024-დან გამგზავნებმა, რომლებიც დღეში 5,000-ზე მეტ შეტყობინებას აგზავნიან Gmail-ზე ან Yahoo-ზე, სარეკლამო ფოსტაზე ერთი კლიკით გამოწერის გაუქმება უნდა უჭერდნენ მხარს და ორ დღეში დაიცვან, SPF-ის, DKIM-ისა და DMARC ჩანაწერის გარდა.
• Bounce-ების დამუშავება. თუ იმ მისამართებზე აგზავნი, რომლებიც hard bounce-ს იძლევა, ყველა მიმღებს ეუბნები, რომ შენი სიის მოვლა არ გცოდნია.
• შიგთავსი და ბმულები. შემოკლებული ბმულები, ერთი დიდი სურათი ტექსტის გარეშე და ცუდი რეპუტაციის მქონე ბმულის დომენები შენს წინააღმდეგ ითვლება.

ფოსტის გაგზავნა აპლიკაციიდან, რომელსაც ჰოსტავ#

თუ შენს Node, Python, PHP ან Laravel აპლიკაციას პაროლის აღდგენისა და შეკვეთის დადასტურების გაგზავნა სჭირდება, სერვერს თავად ნუ აქცევ საფოსტო სერვერად. გამავალი პორტი 25 ქსელების უმეტესობაში დაბლოკილია, ახალ IP-ს რეპუტაცია არ აქვს და შენ სპამის ფილტრაციას, რიგებს და bounce-ების დამუშავებას გვერდითი პროექტის სახით აიღებდი.

გამოიყენე ტრანზაქციული პროვაიდერი SMTP submission-ით - პორტი 587 STARTTLS-ით, ან 465 implicit TLS-ით - ან მათი HTTP API. გამართე ის custom return path-ითა და შენი საკუთარი DKIM selector-ით ზემოთ მოცემული alignment-ის განყოფილებიდან, რომ DMARC გავიდეს. credentials repository-ში კი არ დატოვო, არამედ პანელის environment ცვლადებში, როგორც environment ცვლადები და საიდუმლოებები-შია; Git-ში ჩაკომიტებული SMTP პაროლი ერთ-ერთი ყველაზე სწრაფი გზაა, რომ შენი დომენი სპამის გასაგზავნად გამოიყენონ.

RE:NODE-ზე ეს საზღვარია, რომლის შესახებაც პირდაპირ უნდა ითქვას: ჩვენ ვმასპინძლობთ აპლიკაციას ან საიტს, რომელიც ფოსტას აგზავნის, app და web გეგმებზე reverse-proxy სლოტით, environment ცვლადებით Startup tab-ზე და მონაცემთა ბაზის სლოტებით პანელში. ჩვენ არ ვმასპინძლობთ საფოსტო ყუთებს, არ ვუშვებთ MX-ს, არ ვაწარმოებთ SMTP relay-ს და არ ვმასპინძლობთ DNS ზონებს. შენი MX ჩანაწერი შენს საფოსტო პროვაიდერზე მიუთითებს, A ჩანაწერი - ჩვენზე და ორივე დამოუკიდებელია - რაც ასევე პასუხია კითხვაზე "გატეხავს თუ არა ჩემი საიტის გადატანა ჩემს ფოსტას". არ გატეხავს, სანამ მხოლოდ იმ ჩანაწერებს ცვლი, რომლებიც საიტს ეხება. Nameserver-ები თუ DNS ჩანაწერები განმარტავს, რომელი ჩანაწერებია ესენი, ხოლო თუ თავად საიტი WordPress-ის ინსტალაციაა, WordPress-ის უსაფრთხოების გამაგრება განიხილავს plugin-ს, რომელიც ჩვეულებრივ ფოსტას აგზავნის.

FAQ#

მჭირდება სამივე ჩანაწერი?

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

შეაჩერებს თუ არა DMARC ჩანაწერი ჩემი დომენის გაყალბებას?

ის აჩერებს ფოსტას, რომელიც შენი დომენიდან მოსულად აცხადებს თავს იმ მიმღებებთან, რომლებიც DMARC-ს იცავენ, რაც ახლა ყველა დიდ საფოსტო პროვაიდერს მოიცავს. ის არაფერს აკეთებს მსგავს დომენებზე, display-name გაყალბებაზე ან გატეხილ ანგარიშზე, რომელიც ნამდვილად ავთენტიფიცირებულ ფოსტას აგზავნის. ის ერთ კარს ხურავს და ეს კარი ყველაზე ხშირად გამოიყენება.

რატომ გადის ჩემი ფოსტა SPF-ზე, მაგრამ ვარდება DMARC-ზე?

Alignment. SPF გავიდა envelope დომენისთვის, რომელიც შენს გამგზავნ პროვაიდერს ეკუთვნის და არა ხილულ From: header-ში მდგარი დომენისთვის. დააყენე custom return path შენი დომენის ქვედომენზე, ან სთხოვე პროვაიდერს DKIM-ს შენი დომენით მოაწერონ ხელი და გავლა დაემთხვევა.

რამდენ ხანში იწყებს ცვლილება მოქმედებას?

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

შემიძლია ელფოსტას იმავე გეგმაზე ვმასპინძლო, რაზეც ჩემი საიტია?

აქ არა. RE:NODE ვებსაიტს ან აპლიკაციას მასპინძლობს; საფოსტო ყუთები, MX და SMTP relay სხვისი სერვისია. ეს გამიჯვნა ნორმალურია და მოხერხებულიც: საიტი ჰოსტებს შორის ისე გადაგაქვს, რომ არც ერთ საფოსტო ჩანაწერს არ ეხები.

რას აკეთებს p=none სინამდვილეში?

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