چطور از اپ خود ایمیل بفرستیم (و به صندوق ورودی برسیم)

برای ارسال مطمئن ایمیل از اپ، به‌جای صندوق ایمیل شخصی از یک سرویس ارسال ایمیل استفاده کنید، از آدرسی روی دامنه خودتان بفرستید، و رکوردهای DNS را که سرویس می‌دهد اضافه کنید تا SPF، DKIM و DMARC همه تأیید شوند. ایمیل تراکنشی؛ مثل بازنشانی رمز، رسید و تأییدیه را از ایمیل بازاریابی جدا نگه دارید، هر کدام را فقط برای کسانی بفرستید که انتظارش را دارند، و برگشتی‌ها (bounce) و لغو اشتراک را مدیریت کنید. احراز هویت را اول درست کنید؛ این شایع‌ترین دلیل است که ایمیل اپ به هرزنامه می‌رود.

ایمیل تراکنشی در برابر ایمیل بازاریابی

این دو نوع ایمیل در کد شبیه‌اند، اما صندوق‌های ورودی و قانون با آن‌ها خیلی متفاوت رفتار می‌کنند.

این دو را از هم جدا نگه دارید. اگر یک کمپین بازاریابی شکایت هرزنامه بگیرد، نباید بازنشانی رمزهای تراکنشی از همان جریان به خاطر آن آسیب ببیند. یک روش رایج استفاده از زیردامنه‌های جدا است؛ مثلاً mail.example.com برای ایمیل حساب کاربری و news.example.com برای خبرنامه. بعضی سرویس‌ها این دو را داخلی هم جدا می‌کنند؛ برای نمونه Postmark می‌گوید «جریان‌های پیام» تراکنشی و انتشار را روی زیرساخت ارسال جدا اجرا می‌کند (از سپتامبر ۲۰۲۶).

انتخاب سرویس ارسال

اپ شما نباید خودش از سرور خودش ایمیل بفرستد. سرویس‌های ارسال، زیرساخت، اعتبار IP، تلاش مجدد و پردازش برگشتی‌ها را مدیریت می‌کنند. گزینه‌های شناخته‌شده شامل Postmark، Resend، SendGrid، Amazon SES و Mailgun هستند؛ همه API مبتنی بر HTTP و دسترسی SMTP دارند. قیمت‌ها و طرح‌ها تغییر می‌کنند، پس آن‌ها را در سایت خودشان مقایسه کنید.

مواردی که باید مقایسه کنید:

• تمرکز. بعضی سرویس‌ها روی ایمیل تراکنشی تمرکز دارند؛ بعضی تراکنشی و بازاریابی را با هم ارائه می‌کنند.
• تجربه توسعه‌دهنده. API واضح، کتابخانه‌های رسمی برای زبان شما، و لاگ‌های مفید که نشان می‌دهند هر پیام تحویل شده، برگشت خورده یا به هرزنامه علامت خورده است.
• وب‌هوک برای برگشتی‌ها، شکایت‌ها و تحویل‌ها تا اپ بتواند واکنش نشان دهد.
• قالب‌ها: یا در خود سرویس ذخیره شوند، یا در کد خودتان. نگه‌داشتن آن‌ها در کد، نسخه‌بندی و تست‌پذیری‌شان را آسان می‌کند.
• منطقه و مدیریت داده، اگر الزاماتی درباره محل پردازش داده دارید.
• هزینه در حجم شما، از جمله آنچه وقتی از سطح رایگان رد می‌شوید اتفاق می‌افتد.

برای خبرنامه به یک فهرست، یک ابزار اختصاصی خبرنامه یا بازاریابی ایمیلی اغلب بهتر از ساختن قابلیت‌های کمپین داخل اپ است.

راه‌اندازی دامنه ارسال

از دامنه خودتان بفرستید؛ مثل hello@example.com، نه یک آدرس Gmail یا Outlook. ایمیلی که از یک آدرس صندوق رایگان و از طریق سرویس شخص ثالث فرستاده شود، بررسی احراز هویت را رد می‌کند و احتمالاً فیلتر می‌شود.

به یک زیردامنه فقط برای ارسال فکر کنید. برای نمونه Resend توصیه می‌کند از زیردامنه‌هایی مثل updates.example.com ارسال کنید تا اعتبار ارسال ایزوله شود (از سپتامبر ۲۰۲۶). این کار رکوردهای DNS ایمیل را هم از سایت اصلی‌تان جدا نگه می‌دارد.

سپس سرویس، رکوردهای DNS را می‌دهد تا در جایی که DNS دامنه شما مدیریت می‌شود اضافه کنید. اگر DNS برایتان تازه است، دامنه‌ها و DNS چطور کار می‌کنند ابتدا رکوردها را توضیح می‌دهد.

SPF

SPF (Sender Policy Framework) یک رکورد TXT است که فهرست می‌کند کدام سرورها اجازه ارسال ایمیل برای دامنه شما را دارند. گیرنده بررسی می‌کند آیا سرور فرستنده در این فهرست است.

• یک دامنه باید فقط یک رکورد SPF داشته باشد. اگر سرویس جدیدی اضافه می‌کنید، آن را در رکورد موجود ادغام کنید، نه اینکه رکورد دوم بسازید.
• هنگام ارزیابی، SPF حداکثر ۱۰ جستجوی DNS مجاز دارد؛ زنجیره‌های بلند از ورودی‌های include: ممکن است از این حد بگذرند و خطا ایجاد کنند.
• بسیاری از سرویس‌ها SPF را روی یک زیردامنه مسیر بازگشت (return-path) تنظیم می‌کنند که از شما می‌خواهند بسازید، پس شاید اصلاً به رکورد SPF اصلی دامنه‌تان دست نزنید.

DKIM

DKIM (DomainKeys Identified Mail) امضای رمزنگاری‌شده‌ای به هر پیام اضافه می‌کند. سرویس با یک کلید خصوصی امضا می‌کند و شما کلید عمومی متناظر را به‌صورت رکورد DNS منتشر می‌کنید (TXT یا CNAME، بسته به سرویس). گیرنده امضا را بررسی می‌کند تا مطمئن شود پیام از فرستنده مجاز آمده و در مسیر تغییر نکرده است.

مرحله «تأیید دامنه» سرویس عمدتاً مربوط به DKIM است. آن را رد نکنید.

DMARC

DMARC این دو را به هم وصل می‌کند. یک رکورد TXT در _dmarc.yourdomain.com است که به گیرنده‌ها می‌گوید:

• هم‌راستایی: دامنه‌ای که در نشانی From قابل‌مشاهده است باید با دامنه‌ای که SPF یا DKIM را گذرانده یکی باشد.
• سیاست: با پیام‌های ناموفق چه کنند؛ p=none (فقط گزارش)، p=quarantine (مشکوک فرض کن، اغلب هرزنامه) یا p=reject.
• گزارش‌ها: گزارش‌های تجمیعی را کجا بفرستند (rua=) تا ببینید چه کسانی به نام دامنه شما ارسال می‌کنند.

مسیر منطقی این است که با p=none و یک آدرس گزارش شروع کنید، مطمئن شوید پیام‌های مشروع شما عبور می‌کنند، بعد به quarantine و در نهایت reject برسید. یک سیاست سخت‌گیرانه جعل دامنه شما را برای دیگران هم بسیار سخت‌تر می‌کند.

الزامات Gmail

از سپتامبر ۲۰۲۶، راهنمای فرستندگان گوگل می‌گوید:

• همه فرستنده‌ها به حساب‌های شخصی Gmail به SPF یا DKIM، رفت‌وبرگشت DNS معتبر برای سرورهای ارسال، TLS، و نرخ هرزنامه کمتر از ۰٫۳٪ در Postmaster Tools نیاز دارند.
• فرستنده‌های انبوه (بیش از ۵٬۰۰۰ پیام در روز به Gmail) به SPF و DKIM، یک رکورد DMARC (سیاست p=none مجاز است)، هم‌راستایی دامنه From، و لغو اشتراک با یک کلیک به‌علاوه یک لینک لغو اشتراک قابل‌مشاهده در پیام‌های بازاریابی و پیام‌های اشتراکی نیاز دارند.

سرویس ارسال بخش‌های سمت سرور را انجام می‌دهد. رکوردهای DNS و مدیریت لغو اشتراک با خودتان است. حتی اگر به ۵٬۰۰۰ پیام در روز نزدیک نیستید، رعایت قوانین فرستنده انبوه ساده‌ترین راه برای امن ماندن است.

ساخت ارسال در اپ

وقتی دامنه تأیید شد:

1. کلید API را به‌عنوان یک راز سمت سرور ذخیره کنید؛ هرگز در کد سمت کلاینت. رازها و متغیرهای محیطی چه هستند را ببینید.
2. از سرور ارسال کنید، بعد از اینکه عملی که ایمیل را فعال می‌کند موفق شد.
3. کاربر را منتظر ایمیل نگذارید. برای هر اپی فراتر از ساده‌ترین حالت، ارسال را در صف بگذارید و در خطاهای موقت دوباره تلاش کنید، تا پاسخ کند سرویس ارسال، ثبت‌نام را کند نکند.
4. نتیجه را ثبت کنید، یعنی شناسه پیام و وضعیت سرویس، بدون ثبت کلید یا متن کامل پیام‌هایی که داده شخصی دارند.
5. وب‌هوک‌ها را برای برگشتی‌ها و شکایت‌ها مدیریت کنید: به نشانی‌هایی که برگشت دائمی دارند یا شما را هرزنامه علامت می‌زنند دیگر ایمیل نفرستید.

یک پرامپت که اصول را پوشش می‌دهد:

ایمیل تراکنشی را با [PROVIDER] و با استفاده از راز سرور [ENV_NAME] بفرست، از «Acme hello@mail.acme.com». بعد از ثبت‌نام یک ایمیل خوش‌آمد و بعد از ذخیره رزرو یک تأییدیه رزرو بفرست. قالب‌ها را در کد نگه دار، همراه با نسخه متنی ساده در کنار HTML. ارسال‌ها را در صف بگذار و خطاهای موقت را تا سه بار دوباره امتحان کن. خطاها را با پیام خطای سرویس ثبت کن، اما هرگز کلید API را ثبت نکن. یک نقطه پایانی وب‌هوک اضافه کن که با برگشت دائمی و شکایت، نشانی را غیرقابل‌تحویل علامت بزند و در ارسال‌های بعدی از آن نشانی‌ها رد شو.

ایمیل‌های حساب کاربری؛ مثل لینک تأیید، لینک ورود و بازنشانی رمز، بخشی از ورود هستند. چطور ورود را به اپ خود اضافه کنیم توضیح می‌دهد این جریان‌ها چطور به هم وصل می‌شوند؛ این لینک‌ها را یک‌بار مصرف و با عمر کوتاه نگه دارید.

عادت‌های تحویل‌پذیری

احراز هویت باعث می‌شود ایمیل شما بررسی شود. رفتار شما باعث می‌شود در صندوق ورودی بماند.

• فقط چیزی بفرستید که مردم انتظارش را دارند. ثبت‌نام‌های تأییدشده، رضایت صریح برای بازاریابی، و بدون فهرست خریداری‌شده.
• لغو اشتراک را آسان کنید برای هر چیزی که کاملاً تراکنشی نیست، و فوراً به آن عمل کنید.
• دامنه‌های جدید را گرم کنید. دامنه‌ای که در روز اول هزاران پیام می‌فرستد مشکوک به نظر می‌رسد. با ایمیل تراکنشی شروع کنید و حجم را کم‌کم بالا ببرید.
• فهرست‌ها را تمیز نگه دارید. برگشت‌های دائمی را فوراً حذف کنید و به حذف کسانی که مدت زیادی چیزی را باز نکرده‌اند فکر کنید.
• مثل یک انسان بنویسید. موضوع واضح، نام From قابل‌شناسایی، بخش متن ساده، تصاویر کم و لینک‌هایی به دامنه خودتان. از کوتاه‌کننده لینک‌ها پرهیز کنید.
• پایش کنید. دامنه‌تان را در Google Postmaster Tools ثبت کنید و گاه‌به‌گاه گزارش‌های DMARC را بخوانید.
• یک نشانی پاسخ واقعی بگذارید که کسی آن را می‌خواند. پاسخ‌ها نشانه خوبی هستند و بازخورد مفید می‌دهند.

آزمایش بدون اسپم کردن کسی

• در صورت وجود، از حالت آزمایشی یا محیط تست سرویس استفاده کنید، یا به نشانی‌هایی بفرستید که خودتان مالک آن‌ها هستید.
• در توسعه، به یک صندوق تست همه‌پذیر بفرستید، نه به کاربران واقعی؛ پایگاه داده‌ای پر از نشانی‌های شبیه واقعی راهی آسان برای ایمیل زدن ناخواسته به غریبه‌هاست.
• هر قالب را در چند کلاینت بررسی کنید: Gmail در وب، برنامه ایمیل گوشی، Outlook، و همچنین در حالت تیره.
• سرآیند پیام‌های آزمایشی را نگاه کنید؛ آن‌ها نشان می‌دهند SPF، DKIM و DMARC گذشته‌اند یا نه.

مبانی حقوقی

قوانین در هر کشور متفاوت است. به‌طور کلی، ایمیل بازاریابی در بسیاری از جاها به رضایت نیاز دارد، باید فرستنده را معرفی کند و باید یک لغو اشتراک کارا ارائه دهد؛ ایمیل تراکنشی جور دیگری در نظر گرفته می‌شود، اما نباید برای گنجاندن بازاریابی استفاده شود. اگر نشانی‌ها را از یک صفحه لیست انتظار جمع می‌کنید، روشن کنید چه ایمیل‌هایی می‌فرستید و هر فرد کی و چطور ثبت‌نام کرده است. در شک، قوانین مکانی که کاربرانتان در آن هستند را بررسی کنید.

چک‌لیست ایمیل

• سرویس ارسال انتخاب شده؛ کلید API به‌عنوان راز سرور ذخیره شده
• ارسال از دامنه یا زیردامنه خودتان، نه صندوق رایگان
• رکوردهای SPF، DKIM و DMARC اضافه شده و تأیید می‌شوند
• ایمیل تراکنشی و بازاریابی از هم جدا هستند
• ارسال‌ها در صف و با تلاش مجدد؛ نتایج ثبت شده‌اند
• وب‌هوک‌های برگشتی و شکایت مدیریت شده‌اند
• لغو اشتراک در ایمیل غیرتراکنشی، و فوراً اعمال می‌شود
• قالب‌ها در چند کلاینت تست شده‌اند؛ ایمیل تست هرگز به کاربران واقعی نمی‌رسد

ارسال ایمیل از یک اپ Mythex

Mythex برای اپ‌هایی که می‌سازید سرویس ارسال ایمیل داخلی ندارد، پس خودتان یک سرویس مثل Resend، SendGrid یا Postmark را می‌آورید. کلید API آن را به‌عنوان راز پروژه ذخیره کنید؛ عامل می‌تواند با یک کارت رازها در چت از شما بخواهد، و ایمیل‌هایی که لازم دارید را با زبان ساده درخواست کنید. مستندات یک پرامپت شروع در ارسال ایمیل از اپ دارد. اگر دامنه‌تان را در طرح Pro از طریق Mythex خریده‌اید، می‌توانید رکوردهای TXT و CNAME سرویس را در تنظیمات DNS دامنه اضافه کنید؛ دامنه‌های سفارشی را ببینید.

پرسش‌ها