Гарын авлагууд

Аппаасаа имэйл хэрхэн илгээх вэ (inbox-д хүрдэг байх арга)

Аппаасаа имэйлийг найдвартай илгээхийн тулд өөрийн шуудангийн хайрцгийн оронд имэйл илгээх провайдерыг ашиглаж, өөрийн домэйн дээрх хаягаас илгээ, мөн провайдерын өгсөн DNS бичлэгүүдийг нэмснээр SPF, DKIM, DMARC гурав бүгд амжилттай шалгагдах ёстой. Transactional имэйл — нууц үг сэргээх, баримт, баталгаажуулалт — гэдгийг marketing имэйлээс тусад нь байлга, тус бүрийг зөвхөн хүлээж буй хүмүүст илгээ, мөн bounce болон unsubscribe-ийг зохицуул. Эхлээд баталгаажуулалтаа зөв болго; энэ нь аппын имэйл spam руу орох хамгийн түгээмэл шалтгаан юм.

Transactional ба marketing имэйл

Эдгээр хоёр төрлийн имэйл кодонд адилхан харагдах ч inbox провайдерууд болон хуулиар маш өөр хандаж байдаг.

TransactionalMarketing (олон руу)
ҮүсгэгчХэрэглэгчийн хийсэн үйлдэлТаны хуваарь эсвэл кампанит ажил
ЖишээБүртгэлийн баталгаажуулалт, нууц үг сэргээх, magic link, баримт, захиалгын сануулга, «хэн нэгэн хариулсан»Мэдээллийн товхимол, бүтээгдэхүүний зарлал, урамшуулал, идэвхгүй хэрэглэгчийг эргүүлэн татах
Хүлээн авагчидНэг хүн тус бүртОлон хүнд нэгэн зэрэг
ЗөвшөөрөлҮйлдлээс нь шууд ойлгогдоноЗөвшөөрөл шаардана, амархан unsubscribe-тэй байх
ХугацааСекундын дотор хүрэх ёстойМинут ч болно
Хаанаас илгээх вэТаны апп, API-аарМэдээллийн товхимлийн хэрэгсэл эсвэл провайдерийн broadcast функц

Тэднийг салга. Хэрэв marketing кампанит ажилд spam гомдол ирвэл нэг урсгалаас илгээсэн нууц үг сэргээх имэйлүүд хамт хохирох нь ойлгомжтой. Түгээмэл арга бол тусдаа дэд домэйнүүд, жишээ нь бүртгэлийн имэйлд mail.example.com, мэдээллийн товхимолд news.example.com. Зарим провайдер хоёрыг дотооддоо тусгаарладаг. Жишээ нь Postmark нь transactional болон broadcast «message stream»-үүдээ 2026 оны 9-р сарын байдлаар тусдаа илгээх дэд бүтцэд ажилладаг гэж тайлбарладаг.

Провайдер сонгох

Аппаас имэйлийг өөрийн серверээс шууд илгээх ёсгүй. Илгээх провайдерууд дэд бүтэц, IP нэр хүнд, дахин оролдлого, bounce боловсруулалтыг хариуцдаг. Алдартай сонголтууд: Postmark, Resend, SendGrid, Amazon SES, Mailgun. Тус бүр HTTP API болон SMTP-тэй; үнэ, төлөвлөгөө өөрчлөгддөг тул тэдгээрийн сайтад тус бүрээр нь харьцуулаарай.

Харьцуулах зүйлс:

  • Төвлөрөл. Зарим провайдер transactional имэйлд төвлөрдөг, зарим нь transactional ба marketing-ийг хослуулдаг.
  • Developer туршлага. Тодорхой API, таны хэлэнд зориулсан албан ёсны сангууд, мессеж хүрсэн, bounce хийсэн эсвэл spam гэж тэмдэглэгдсэнийг харуулдаг хэрэгтэй логууд.
  • Webhook-ууд bounce, гомдол, хүргэлтийн тухай, таны апп хариу үйлдэл хийх боломжтой байхын тулд.
  • Загварууд — провайдерт хадгалагдсан эсвэл таны кодонд. Кодонд хадгалвал хувилбаржуулж, туршиж болно.
  • Бүс нутаг ба өгөгдлийн харилцаа, өгөгдөл хаана боловсрогдох тухай шаардлага байвал.
  • Таны эзлэхүүнд тохирох үнэ, үнэгүй түвшнээс хэтэрвэл юу болохыг оруулан.

Жагсаалтад мэдээллийн товхимол илгээхэд тусгай мэдээллийн товхимлийн эсвэл имэйл маркетингийн хэрэгсэл аппдаа кампанит ажлын функц бүтээхээс ихэвчлэн илүү тохиромжтой.

Илгээх домэйнээ тохируулах

Өөрийн домэйнээс илгээ — hello@example.com, Gmail эсвэл Outlook хаягаас биш. Гуравдагч талын үйлчилгээгээр илгээсэн үнэгүй шуудангийн хаяг баталгаажуулалтын шалгалтанд унаж, шүүгдэх магадлалтай.

Зөвхөн илгээхэд зориулсан дэд домэйн авахыг бодоорой. Жишээ нь Resend илгээх нэр хүндээ тусгаарлахын тулд updates.example.com зэрэг дэд домэйнээс илгээхийг зөвлөдөг (2026 оны 9-р сарын байдлаар). Мөн энэ нь имэйлийн DNS бичлэгүүдийг таны үндсэн сайтын бичлэгээс тусад нь байлгана.

Провайдер таны домэйны DNS-ийг удирддаг газар нэмэх DNS бичлэгүүдийг өгнө. Хэрэв DNS танд шинэ бол домэйн болон DNS хэрхэн ажилладаг вэ эхлээд бичлэгүүдийг тайлбарласан.

SPF

SPF (Sender Policy Framework) нь таны домэйны нэрийн өмнөөс имэйл илгээж болох серверүүдийг жагсаасан TXT бичлэг юм. Хүлээн авагч тэр сервер жагсаалтад байгаа эсэхийг шалгана.

  • Домэйн дээр зөвхөн нэг SPF бичлэгтэй байх ёстой. Провайдер нэмэхдээ хоёр дахь бичлэг нэмэхийн оронд одоо байгаа бичлэгтэйгээ нэгтгэ.
  • SPF үнэлэгдэх үед DNS-ийн дээд тал нь 10 lookup зөвшөөрдөг; урт include: гинжин холбоос алдаа үүсгэж болно.
  • Олон провайдер таны үндсэн SPF-д хүрэхгүйгээр, таны үүсгэхийг хүссэн return-path дэд домэйн дээр SPF тохируулдаг.

DKIM

DKIM (DomainKeys Identified Mail) нь мессеж бүрт криптограф гарын үсэг нэмдэг. Провайдер хувийн түлхүүрээр гарын үсэг зурдаг; та харгалзах нийтийн түлхүүрийг DNS бичлэг (TXT эсвэл CNAME, провайдераас хамаарна) болгон нийтэлнэ. Хүлээн авагч гарын үсгийг шалгаж, мессеж эрх бүхий илгээгчээс ирсэн эсэх болон замдаа өөрчлөгдөөгүйг баталгаажуулна.

DKIM нь провайдерын «домэйн баталгаажуулах» алхамын гол хэсэг юм. Үүнийг бүү алгас.

DMARC

DMARC нь бусад хоёрыг холбодог. Энэ нь _dmarc.yourdomain.com дээрх TXT бичлэг бөгөөд хүлээн авагчдад дараахыг хэлдэг:

  • Тохируулга (alignment): харагдах From хаягийн домэйн нь SPF эсвэл DKIM-ээр амжилттай шалгагдсан домэйнтой таарах ёстой.
  • Бодлого: амжилтгүй мессеж дээр юу хийхийг — p=none (зөвхөн тайлагна), p=quarantine (сэжигтэй гэж үзэж, ихэвчлэн spam), эсвэл p=reject.
  • Тайлан: aggregate тайланг хаашаа илгээхийг (rua=), ингэснээр таны домэйныг хэн ашиглан илгээж байгаагаа харж болно.

Маш ухаалаг арга бол p=none болон тайлангийн хаягаар эхлээд, зөв мессеж нь амжилттай шалгагдаж байгааг баталгаажуулаад, дараа нь quarantine, эцэст нь reject руу шилжих. Хатуу бодлого нь бусдад таны домэйныг хуурамчаар илгээхийг улам хэцүү болгодог.

Gmail юу шаарддаг вэ

2026 оны 9-р сарын байдлаар Google-ийн илгээгчийн удирдамж дараахыг хэлдэг:

  • Бүх илгээгчид Gmail хувийн хаягууд руу SPF эсвэл DKIM, илгээгч серверүүдийн хүчинтэй forward болон reverse DNS, TLS, мөн Postmaster Tools дээрх spam хувь 0.3%-аас доош байх ёстой.
  • Олон тооны илгээгчид (Gmail руу өдөрт 5,000-аас олон мессеж) SPF болон DKIM, DMARC бичлэг (p=none бодлого зөвшөөрөгдөнө), From домэйны тохируулга, мөн нэг товшилтоор unsubscribe, marketing ба идэвхтэй мессежүүд дээр харагдах unsubscribe линк шаардлагатай.

Таны провайдер серверийн талын хэсгийг хариуцна. DNS бичлэгүүд болон unsubscribe-ийн зохицуулалт нь таных. Өдөрт 5,000-д огт хүрээгүй ч гэсэн олон тооны илгээгчийн дүрмийг биелүүлэх нь хамгийн энгийн аюулгүй арга юм.

Илгээлтийг аппдаа оруулах

Домэйн баталгаажсаны дараа:

  1. API түлхүүрээ хадгал серверийн талын нууц мэдээлэл болгон — хэзээ ч front-end кодонд бүү хий. Үүнийг орчны хувьсагч болон нууцууд гэж юу вэ дээрээс үзнэ үү.
  2. Серверээс илгээ, имэйлийг өдөөсөн үйлдэл амжилттай болсны дараа.
  3. Хэрэглэгчийг имэйлд хүлээлгэж болохгүй. Энгийн аппаас илүү бүх зүйлд илгээлтийг дарааллаар ажиллуулж, түр алдаанд дахин оролд, ингэснээр провайдерын удаан хариу бүртгэлийг удаашруулахгүй.
  4. Үр дүнг логло — провайдерын мессеж ID болон статус — түлхүүр эсвэл хувийн мэдээлэлтэй мессежийн агуулгыг логлохгүйгээр.
  5. Bounce ба гомдлын webhook-уудыг зохицуул: hard bounce хийсэн эсвэл spam гэж тэмдэглэсэн хаягууд руу илгээхээ зогсоо.

Үндсэн зүйлсийг хамарсан үүрэг өгөх загвар:

Серверийн нууц [ENV_NAME]-ийг ашиглан [PROVIDER]-ээр transactional имэйл илгээ, илгээгч «Acme hello@mail.acme.com». Бүртгүүлсний дараа тавтай морилно уу имэйл, захиалга хадгалагдсаны дараа захиалгын баталгаажуулалт илгээ. Загваруудыг кодод хадгалж, HTML-ийн хажуугаар энгийн текст хувилбартай байлга. Илгээлтийг дарааллаар ажиллуулж, түр алдаанд гурван удаа дахин оролд. Алдааг провайдерын алдааны мэдээллээр логло, гэхдээ API түлхүүрийг хэзээ ч бүү логло. Hard bounce болон гомдлын үед хаягийг илгээх боломжгүй гэж тэмдэглэдэг webhook endpoint нэм, ирээдүйд тэдгээр хаягуудыг алгас.

Бүртгэлийн имэйлүүд — баталгаажуулах линк, magic link, нууц үг сэргээх — нэвтрэлтийн нэг хэсэг юм. Аппдаа нэвтрэлт хэрхэн нэмэх вэ нь эдгээр урсгалууд хэрхэн холбогддогийг тайлбарласан; эдгээр линкийг нэг удаагийн, богино хугацаатай болго.

Deliverability-ийн зуршлууд

Баталгаажуулалт таныг анхаарал татахад тусалдаг. Харин зан байдал нь таныг inbox-д байлгадаг.

  • Хүмүүсийн хүлээж буйг л илгээ. Баталгаажсан бүртгэлүүд, marketing-д тодорхой opt-in, худалдаж авсан жагсаалтгүй.
  • Unsubscribe-ийг амар болго яг transactional биш бүх имэйл дээр, мөн тэр даруй биелүүл.
  • Шинэ домэйнуудыг дулаацуул. Шинэ домэйн эхний өдөртөө мянга мессеж илгээвэл сэжигтэй харагдана. Transactional шуудангаасаа эхэлж, эзлэхүүнээ аажмаар нэмэгдүүл.
  • Жагсаалтаа цэвэр байлга. Hard bounce-уудыг тэр даруй арилга, удаан хугацаанд юу ч нээгээгүй хүмүүсийг арилгахыг бодоорой.
  • Хүн шиг бич. Тодорхой гарчиг, танигдахуйц From нэр, энгийн текст хэсэг, цөөн зураг, өөрийн домэйн рүү линкүүд. Линк богиносгогчоос зайл.
  • Хянах. Домэйнээ Google Postmaster Tools-д бүртгүүлж, DMARC тайлангуудыг үе үе уншаарай.
  • Жинхэнэ reply-to ашигла, хэн нэгэн уншдаг. Хариу нь сайн дохио, хэрэгтэй санал хүсэлт.

Хэнийг ч spam хийхгүйгээр туршилт хийх

  • Боломжтой бол провайдерынхаа test mode эсвэл sandbox-ийг ашигла, эсвэл өөрийн эзэмшдэг хаягууд руу илгээ.
  • Хөгжүүлэлтийн үед бодит хэрэглэгчдийн оронд catch-all туршилтын хайрцаг руу илгээ; бодит мэт харагдах хаягаар дүүрсэн өгөгдлийн сан нь санамсаргүйгээр бусдад имэйл илгээх хамгийн амар арга.
  • Загвар бүрийг хэд хэдэн клиентээр шалга — вэб дээрх Gmail, утасны имэйл апп, Outlook — мөн dark mode-оор.
  • Туршилтын имэйлийн header-ийг хар: SPF, DKIM, DMARC амжилттай шалгагдсаныг харуулна.

Хуулийн үндэс

Дүрэм улс орноос хамаарна. Ерөнхийдөө marketing имэйл олон газар зөвшөөрөл шаарддаг, илгээгчээ танилцуулах ёстой, ажилладаг unsubscribe-тэй байх ёстой; transactional имэйл өөрөөр хандагддаг ч marketing-ийг нууж оруулах ёсгүй. Хэрэв та хүмүүсийн имэйлийг хүлээлтийн жагсаалтын хуудас-аас цуглуулж байгаа бол юу илгээх, хадгалах, хэзээ, хэрхэн бүртгүүлсэнийг нь тодорхой хэл. Эргэлзвэл хэрэглэгчдийнхээ газрын дүрмийг шалга.

Имэйлийн шалгах хуудас

  • Илгээх провайдер сонгогдсон; API түлхүүр серверийн нууц болгон хадгалагдсан
  • Өөрийн домэйн эсвэл дэд домэйнээс илгээж байна, үнэгүй шуудангийн хаягаас биш
  • SPF, DKIM, DMARC бичлэгүүд нэмэгдсэн бөгөөд амжилттай шалгагдаж байна
  • Transactional ба marketing шуудан тусгаарлагдсан
  • Илгээлтүүд дарааллаар, дахин оролдлоготой; үр дүн логлогдсон
  • Bounce ба гомдлын webhook-ууд зохицуулагдсан
  • Transactional биш имэйл дээр unsubscribe, тэр даруй биелүүлж байна
  • Загварууд хэд хэдэн клиентээр туршигдсан; туршилтын шуудан бодит хэрэглэгчдэд хүрдэггүй

Mythex аппаас имэйл илгээх

Mythex нь таны бүтээсэн аппуудад зориулсан шууд имэйл илгээх үйлчилгээг агуулдаггүй тул Resend, SendGrid, Postmark зэрэг провайдер хэрэгтэй. Түүний API түлхүүрийг төслийн нууц болгон хадгал — агент чатанд нууцын карт ашиглан асууж болно — мөн шаардлагатай имэйлүүдээ энгийн үгээр хүс. Баримт бичигт аппаасаа имэйл илгээх гэсэн эхлэх подсказ байгаа. Хэрэв домэйноо Pro дээр Mythex-ээр худалдан авсан бол провайдерын TXT болон CNAME бичлэгүүдийг домэйны DNS тохиргоонд нэмж болно; custom domain-ийг үзнэ үү.

Асуултууд

Transactional ба marketing имэйлийн ялгаа юу вэ?

Transactional имэйл нь хэрэглэгчийн хийсэн үйлдлээс үүсч, хүлээгдсэн байдаг. Жишээ нь нууц үг сэргээх, баримт эсвэл захиалгын баталгаажуулалт. Marketing имэйлийг таны хуваарийн дагуу олон хүнд илгээдэг, жишээ нь мэдээллийн товхимол, зарлал. Тэдгээрийн зөвшөөрлийн дүрэм өөр тул тусдаа урсгал эсвэл дэд домэйнээс илгээх нь зүйтэй.

Яагаад аппынхаа имэйл spam руу орж байна вэ?

Ихэвчлэн илгээх домэйн дээр SPF, DKIM, DMARC тохируулаагүй, Gmail зэрэг үнэгүй хаягаас гуравдагч талын үйлчилгээгээр илгээж байгаа, шинэ домэйн ямар ч нэр хүндгүй, эсвэл агуулга болон линк нь spam шиг харагдаж байгаа зэрэг шалтгаантай. Эхлээд баталгаажуулалтыг засаад, дараа нь агуулга болон эзлэхүүнийг шалга.

Аппынхаа имэйлийг Gmail хаягаасаа илгээж болох уу?

Цөөн тооны хувийн туршилтын мессежд болох ч бодит аппад огт болохгүй. Өөрийн домэйнтэй имэйл илгээх провайдер ашиглаж, тэдний өгсөн DNS бичлэгүүдийг тохируулаад, тэр домэйн дээрх хаягаас илгээ.

DMARC хэрэгтэй юу?

Практикт тийм. 2026 оны 9-р сараас эхлэн Google өдөрт 5,000-аас олон мессеж Gmail хаягууд руу илгээгчдэд DMARC шаарддаг, мөн DMARC бичлэг нь таны домэйныг хуурамчаар илгээхээс хамгаалдаг. Тайлангаа шалгах явцад p=none бодлогоор эхэлбэл зүгээр.

Mythex · Pricing · AI-аар юуг ч бүтээ · Вэбсайт болон аппын загварууд · Mythex-ийн харьцуулалт · AI-аар апп бүтээх тайлбар толь · AI-аар апп бүтээх үнэгүй хэрэгслүүд · English

English አማርኛ العربية Български বাংলা Bosanski Català Čeština Dansk Deutsch Ελληνικά Español Español (España) Eesti فارسی Suomi Français Français (Canada) ગુજરાતી हिन्दी Hrvatski Magyar Հայերեն Bahasa Indonesia Íslenska Italiano 日本語 ქართული Қазақ тілі ಕನ್ನಡ 한국어 Lietuvių Latviešu Македонски മലയാളം मराठी Bahasa Melayu မြန်မာ Norsk bokmål Nederlands ਪੰਜਾਬੀ Polski Português (Brasil) Português (Portugal) Română Русский Slovenčina Slovenščina Soomaali Shqip Srpski Svenska Kiswahili தமிழ் తెలుగు ไทย Tagalog Türkçe Українська اردو Tiếng Việt 简体中文 繁體中文(香港) 繁體中文(台灣)