ცოდნის ბაზა

გაგზავნეთ ელფოსტა თქვენივე დომენიდან, თქვენივე ანგარიშიდან

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

თქვენს კლიენტებს გამოგზავნილი ყველა შეტყობინება — ინვოისები, პაროლის აღდგენა, თაიქეთების პასუხები, პროექტის განახლებები — საფოსტო სერვისის გავლით იგზავნება. ნაგულისხმევად ეს სერვისი ჩვენია, „From“ ველში მითითებულია Zinn Digital® და მის საფასურს ჩვენ ვიხდით.

თუ სარგებლობთ agency ან reseller გეგმით, შეგიძლიათ ნაცვლად ამისა საკუთარი საფოსტო სერვისი დააკავშიროთ. ამის შემდეგ თქვენი კლიენტები „From“ ველში თქვენს დომენს დაინახავენ, პასუხები თქვენთან მოვა, ხოლო შეტყობინებები თქვენი პროვაიდერის მიერ თქვენი ანგარიშიდან გაიგზავნება.

მისი კონფიგურაცია შესაძლებელია თქვენს სამართავ პანელში, Email sending განყოფილებაში.

რომელ პროვაიდერს უნდა მივანიჭო უპირატესობა?

ნებისმიერი მათგანი იმუშავებს. შეარჩიეთ ის, რომლის ანგარიშიც უკვე გაქვთ.

| პროვაიდერი | საუკეთესოა, თუ | ინსტრუქცია | | --- | --- | --- | | Mailgun | გჭირდებათ API და გაგზავნის დიდი მოცულობები | Mailgun-ის კონფიგურაცია | | SendGrid | მას უკვე იყენებთ მარკეტინგული წერილებისთვის | SendGrid-ის კონფიგურაცია | | Postmark | მხოლოდ ტრანზაქციული წერილებია, უზრუნველყოფს მიტანის საუკეთესო მაჩვენებელს | Postmark-ის კონფიგურაცია | | Amazon SES | უკვე სარგებლობთ AWS-ით და გსურთ ყველაზე დაბალი ფასი | Amazon SES-ის კონფიგურაცია | | Resend | გჭირდებათ ყველაზე მარტივი კონფიგურაცია | Resend-ის კონფიგურაცია | | თქვენი საკუთარი SMTP სერვერი | მართავთ საკუთარ საფოსტო ინფრასტრუქტურას | SMTP-ის კონფიგურაცია |

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

ჯერ DNS დააკონფიგურეთ. ეს სამუშაოს ძირითადი ნაწილია.

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

SPFTXT ჩანაწერი თქვენს დომენზე, რომელიც აფიქსირებს, თუ ვინ არის უფლებამოსილი გამოგზავნოს წერილები თქვენი სახელით. თუ ის უკვე გაქვთ, ასწორებთ მას და მეორეს არ ამატებთ. დომენი ორი SPF ჩანაწერით მთლიანად აბათილებს SPF-ს, რაც არაფრის ქონაზე უარესია.

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

Return-path (bounce) დომენი — როგორც წესი, CNAME. ის ადგენს დაუსწრებელ კონვერტის მისამართს, რომელსაც პროვაიდერი მიტანის შეცდომების (bounce) შესაგროვებლად იყენებს. მის გარეშე შეცდომის შეტყობინებები ისეთ ადგილას მიდის, რომელსაც ვერ ხედავთ, ხოლო თქვენი დომენის რეპუტაცია ისე ილახება, რომ ამის შესახებ არც კი იცით.

DMARCTXT ჩანაწერი მისამართზე _dmarc.yourdomain.com, რომელიც მიმღებ სერვერებს ეუბნება, როგორ მოიქცნენ, როდესაც SPF და DKIM არ ეთანხმება თქვენს „From“ ხაზს. დაიწყეთ p=none-ით, სანამ შეამოწმებთ, რომ ყველაფერი წარმატებით გადის, შემდეგ კი გადადით p=quarantine-სა და p=reject-ზე.

⚠️ DNS-ის ცვლილებები მყისიერად არ აისახება. დაუთმეთ მას ერთ საათამდე დრო, სანამ დაასკვნით, რომ რაღაც რიგზე ვერ არის.

გამოიყენეთ ქვედომენი გაგზავნისთვის

გააგზავნეთ mail.yourdomain.com ან notifications.yourdomain.com მისამართიდან და არა თავად yourdomain.com-იდან.

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

Send from this domain ველში მაინც დომენს უთითებთ და არა მისამართს. ნაწილი სიმბოლოთი @-მდე ირჩევა თითოეული შეტყობინებისთვის: ქვითრები იგზავნება როგორც billing@, პაროლის აღდგენა — როგორც no-reply@, ხოლო თაიქეთის პასუხები — როგორც support@.

როგორ მუშაობს კონფიგურაცია

  1. შეარჩიეთ თქვენი პროვაიდერი და ჩასვით მისი ავტორიზაციის მონაცემები.
  2. დააჭირეთ ღილაკს Send test message. ჩვენ ვგზავნით რეალურ წერილს თქვენი პროვაიდერის გავლით თქვენ მიერ მითითებულ შემოსულ წერილების ყუთში, რომელსაც კოდი ახლავს თან.
  3. წაიკითხეთ კოდი ამ ყუთიდან და შეიყვანეთ ის.

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

ტესტირებისთვის გამოიყენეთ შემოსული წერილების ყუთი სხვა დომენზე — იდეალურია Gmail-ის ან Outlook-ის მისამართი. შეტყობინება, რომელიც არასდროს ტოვებს თქვენს საკუთარ სერვერს, ბევრად ნაკლებს ამტკიცებს, ვიდრე ის, რომელიც ინტერნეტს გასცდა და ვინმე სხვისი სპამის ფილტრი წარმატებით გაიარა.

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

იმიტომ, რომ პროვაიდერი, რომელიც იღებს შეტყობინებას და შემდეგ უხმაუროდ აგდებს მას, ზუსტად ისე გამოიყურება, როგორც მომუშავე პროვაიდერი. სრულიად ახალი Amazon SES ანგარიში იმყოფება სანდო გარემოში (sandbox), მიიღებს თქვენს შეტყობინებას და არსად გააგზავნის. Mailgun-ის დომენი, რომლის DNS-იც არ გავრცელებულა, ზუსტად იგივეს აკეთებს. ისევე როგორც SMTP რელე, რომელიც პასუხობს 250-ით და ანადგურებს წერილს.

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

რა ხდება, თუ ჩემი პროვაიდერი მუშაობას შეწყვეტს

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

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

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

რა მოხდება, თუ არაფერს გავაკეთებ?

არაფერი ირღვევა. თქვენი შეტყობინებები ჩვენი დომენიდან — Zinn Digital®-ის სახელით — ისევ იგზავნება და მათ საფასურსაც ჩვენ ვიხდით. თქვენი კლიენტები უბრალოდ ჩვენს სახელს დაინახავენ თქვენი სახელის ნაცვლად.

წაშლა

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

ისევ გაჭედილი ხართ?

მხარდაჭერა შედის ყველა გეგმაში და პასუხები თქვენს საკუთარ ენაზე გაიცემა.

მხარდაჭერასთან დაკავშირება ყველა სტატია