رایانامه از دامنهٔ خودتان
ربات میتواند به مشتریان شما رایانامه بفرستد — از نشانیای روی دامنهٔ خودتان، مثل noreply@example.com. اما خود نامه را سرور ما میفرستد. به همین سبب پیش از نخستین ارسال باید یک بار سه رکورد به DNS دامنه بیفزایید. در ادامه: چرا لازم است، دقیقاً چه چیزی افزوده میشود و پس از آن چه رخ میدهد.
چرا بدون رکوردهای DNS نامهها نمیرسند
از دید سمت گیرنده نگاه کنید — Gmail، Outlook یا سرور رایانامهٔ مشتری شما. نامهای میرسد که مدعی است از دامنهٔ شماست، اما از سروری میآید که به آن دامنه تعلق ندارد. این دقیقاً تصویر جعل است: فیشینگ همینگونه کار میکند.
گیرنده تنها یک راه برای تشخیص دارد: از خود دامنه بپرسد «آیا این فرستنده واقعاً از سوی شما عمل میکند؟» پاسخ را شما در DNS دامنهٔ خود منتشر میکنید، چون DNS تنها جایی است که فقط شما بر آن تسلط دارید — و از همین رو تنها جایی است که گیرنده باورش میکند.
تا وقتی این پاسخ نباشد، سرور رایانامهٔ درستکردار ناچار است نامه را مشکوک بشمارد. در بهترین حالت به «هرزنامه» میرود و در بدترین حالت رد میشود و گیرنده هرگز از وجودش باخبر نمیشود.
پس این سه رکورد نه تشریفاتاند و نه تیک زدن در یک صفحه. آنها اجازهٔ شما هستند.
سه رکورد و کار هر یک
DKIM — امضایی که اصالت را ثابت میکند
DKIM امضایی رمزنگارانه است که به هر نامهٔ خروجی میچسبد. پلتفرم برای دامنهٔ شما یک جفت کلید میسازد: کلید خصوصی نزد ما میماند و نامهها را امضا میکند، کلید عمومی را شما در DNS منتشر میکنید. گیرنده کلید عمومی را از DNS شما برمیدارد و امضا را میسنجد. اگر بخواند، یعنی نامه را دارندهٔ کلید خصوصی فرستاده و متن در راه دستکاری نشده است.
بدون DKIM: چیزی برای سنجش امضا وجود ندارد. نامه بیامضا و بیاعتبار به نظر میرسد و هیچ تنظیم دیگری جبرانش نمیکند. DKIM مهمترین این سه است.
SPF — کدام سرورها میتوانند از سوی شما بفرستند
SPF به پرسشی دیگر پاسخ میدهد: اصلاً از چه سرورهایی نامهای از این دامنه پذیرفتنی است. این فهرستی از منابع است — سرورهای رایانامهٔ میزبانی شما، سرویسهای ارسالی که هماکنون به کار میبرید، و برای آنکه ربات بتواند بنویسد، سرورهای ارسال ما.
بدون SPF: نامه از سروری میآید که دامنهٔ شما «نمیشناسدش». برای پالایه این نشانهٔ کلاسیک جعل است و به همهٔ شکهای دیگر افزوده میشود.
DMARC — گیرنده هنگام شکست بررسیها چه کند
DKIM و SPF به پرسش «آیا نامه اصیل است» پاسخ میدهند. DMARC به پرسش بعدی پاسخ میدهد: اگر نبود چه کنیم. این دستور شما به گیرنده است — کاری نکن و فقط گزارش بفرست، به هرزنامه بینداز، یا رد کن. همچنین DMARC نشانیای است که گیرندگان گزارشهای تجمیعی دربارهٔ نامههای بهنام شما، از جمله تلاش دیگران برای جعل، را به آن میفرستند.
با نرمترین سیاست آغاز کنید، یعنی «فقط گزارش». سختگیری را بعدتر بیفزایید، وقتی مطمئن شدید همهٔ فرستندگان قانونی شما (حسابداری، CRM، خبرنامهها، همین ربات) بررسیها را میگذرانند. سیاست سختگیرانهای که زود روشن شود، نخست نامههای خود شما را میبُرد.
بدون DMARC: هر گیرنده به سلیقهٔ خود تصمیم میگیرد و شما هرگز نمیدانید بر سر نامههای بهنام شما چه میآید.
چه رکوردهایی بیفزاییم
نخست دامنه را در پنل ثبت کنید: بخش Email ← «Sending domains» ← دکمهٔ «Add domain». در پنجره سه فیلد هست: خودِ دامنه (مثلاً shop.example.com)، بخش محلی نشانی (آنچه پیش از @ میآید، معمولاً noreply) و نام فرستنده که گیرنده بهجای نشانی میبیند. پس از ذخیره، رکوردهای DNS شما روی صفحه پدیدار میشوند.
هر سه رکورد از نوع TXT در DNS دامنهٔ شما هستند. همانجا که دامنه را مدیریت میکنید افزوده میشوند: پنل ثبتکننده یا ارائهدهندهٔ DNS.
مقادیر زیر با نمونهٔ example.com نشان داده شدهاند — دامنهٔ خود را بگذارید. مقادیر دقیق دامنهٔ شما روی کارت دامنه در پنل نمایش داده میشود؛ از همانجا کپی کنید، بهویژه DKIM: مقدارش کلید عمومی خود شماست، برای هر دامنه متفاوت است و از مستندات برداشتنی نیست.
روی صفحه هر رکورد به دو فیلد جدا تقسیم شده است — «Host» و «Value» — که هرکدام دکمهٔ «Copy» خود را دارند. آنها را یکییکی در فیلدهای متناظر نزد ارائهدهندهٔ DNS کپی کنید: این دو بخش یکجا چسبانده نمیشوند.
| نوع | نام رکورد (host) | مقدار |
|---|---|---|
| TXT | mybot._domainkey.example.com | v=DKIM1; k=rsa; p= و سپس کلید بلند از پنل |
| TXT | example.com (ریشهٔ دامنه) | v=spf1 include:esp.getmybot.dev ~all |
| TXT | _dmarc.example.com | v=DMARC1; p=none; rua=mailto:dmarc@example.com |
دو جایی که بیش از همه اشتباه رخ میدهد:
- بسیاری از پنلها خودشان دامنه را به نام رکورد میچسبانند. اگر در فیلد نام از پیش «.example.com» نوشته شده، تنها
mybot._domainkeyرا وارد کنید نه نام کامل را؛ وگرنهmybot._domainkey.example.com.example.comمیشود. - مقدار DKIM بلند است و درون کلید نباید شکست خط یا فاصله باشد. آن را با دکمهٔ کپی بردارید، نه با کشیدن ماوس.
اگر دامنه از پیش رکورد SPF دارد
هر دامنه تنها میتواند یک رکورد SPF داشته باشد. اگر هماکنون از راه میزبانی، CRM یا سرویس خبرنامهٔ دیگری نامه میفرستید، آن رکورد وجود دارد. دومی نسازید — به رکورد موجود، پیش از ~all پایانی، یک include دیگر بیفزایید:
v=spf1 include:spf.yourprovider.ir include:esp.getmybot.dev ~all
دو رکورد SPF روی یک دامنه همان خطای نداشتن هیچ رکوردی است: بررسی نمیگذرد، چون گیرنده نمیداند کدامیک را باور کند.
توجه: «پوشش» از راه رکورد دیگری کافی نیست. حتی اگر ارائهدهندهٔ کنونی شما ما را در SPF خودش بیاورد، include ما باید مستقیماً در رکورد شما باشد — دلیلش در بخش تأیید دامنه در ادامه آمده است.
چرا در SPF بهجای نشانی IP از include استفاده میشود
رایجترین خطا چسباندن نشانی IP دیدهشده در سرایند نامه یا نوشتهای در انجمن است. چنین نکنید.
include:esp.getmybot.dev ارجاعی است به فهرست سرورهای ارسال خودمان که خودمان نگهداریاش میکنیم. امروز پشت این نام یک سرور بازپخش هست. فردا شاید بیشتر شوند، جابهجا شوند یا عوض شوند. آنگاه ما فهرست را در سمت خود بهروز میکنیم و رکورد شما بیآنکه چیزی را دست بزنید کار میکند. همهٔ معنایش همین است: نشانی در یک جا عوض میشود، نه در DNS تکتک مشتریان.
نشانی IP دستی درست در همان لحظه از واقعیت جدا میشود. نامهها بدون هیچ هشداری در SPF مردود میشوند — نه خطایی در پنل، نه اعلانی. از مشتریانی خبردار میشوید که میگویند «چیزی دریافت نکردیم».
دقیقاً include:esp.getmybot.dev را بنویسید و چیزی به آن نیفزایید.
تأیید دامنه
تأیید دامنه یعنی پلتفرم خودش به DNS دامنهٔ شما سر میزند و مطمئن میشود هر سه رکورد درستاند. اگر هر سه بگذرند، دامنه وضعیت تأییدشده میگیرد و ارسال مجاز میشود. تا وقتی یکی نگذرد، دامنه در انتظار میماند.
آنچه بررسی میشود فراتر از «رکورد وجود دارد» است:
| رکورد | واقعاً چه چیزی بررسی میشود |
|---|---|
| DKIM | رکورد منتشر شده و کلید عمومی خودِ شما را دارد. DKIM دیگری یا کهنه از کلید پیشین نمیگذرد. |
| SPF | رکورد وجود دارد و مستقیماً شامل include:esp.getmybot.dev است. مقادیر شبیه به آن مانند include:esp.getmybot.dev.other-domain.example به حساب نمیآیند. |
| DMARC | رکوردی منتشر شده و با v=DMARC1 آغاز میشود. خود سیاست (p=، rua=) بررسی نمیشود — آن تصمیم شماست، نه اجازهای برای ما. |
چرا DMARC نرمتر بررسی میشود: به گیرندگان میگوید با نتیجهٔ DKIM و SPF چه کنند، اما به ما حق ارسال از سوی شما را نمیدهد. آن حق تنها از دو رکورد نخست میآید و هر دو بهطور کامل از نظر محتوا بررسی میشوند.
include دیگری به حساب نمیآید
include:esp.getmybot.dev باید در رکورد SPF خودِ شما باشد. اگر SPF شما ارائهدهندهای ثالث را در بر بگیرد و رکورد او هم ما را در بر بگیرد، تأیید آن را نمیپذیرد: پلتفرم زنجیرهٔ include دیگران را باز نمیکند. دلیلش ساده است — اینگونه پاسخ پرسش «آیا همین دامنه به ما اجازه داده» بیابهام میماند.
در عمل: حتی اگر مطمئناید «از راه ارائهدهنده پوشش دارید»، include ما را مستقیماً به رکورد خودتان بیفزایید. همین را خود صفحه هم در توضیح رکورد SPF میگوید: اگر دامنه از پیش رکورد SPF دارد، مقدار include:... را به آن بیفزایید و کل رکورد را جایگزین نکنید، چون ممکن است دامنه از راههای دیگری هم نامه بفرستد. این یادداشت همیشه روی صفحه هست و فقط پس از یک بررسی ناموفق ظاهر نمیشود.
DNS بیدرنگ بهروز نمیشود. پس از ذخیره نزد ثبتکننده، رکوردها باید میان سرورهای نام پخش شوند: معمولاً چند دقیقه، گاهی چند ساعت، بهندرت تا یک شبانهروز. به ارائهدهنده و مقدار TTL بستگی دارد. این عادی است و در اختیار ما نیست.
با این حال لازم نیست منفعل منتظر بمانید. پلتفرم دامنههای در انتظار را خودش هر ساعت یک بار بازبینی میکند، اما روی کارت دامنه دکمهٔ «Verify now» هست — همان بررسی که بیدرنگ اجرا میشود و نتیجهاش فوراً روی صفحه میآید. بیدرنگ پس از ذخیرهٔ رکوردها بزنیدش: اگر جایی غلط تایپی باشد، در یک ثانیه میفهمید نه پس از یک ساعت. هر چند بار که بخواهید میتوانید بزنید.
وضعیت دامنه روی کارت دیده میشود: «Pending verification»، «Verified» یا «Not verified». تا وقتی دامنه تأیید نشده، روی کارت این هشدار هم هست: «Sending from this domain is disabled until it is verified.»
نتیجه فقط «نگذشت» نیست. هر یک از سه رکورد روی صفحه وضعیت خود را دارد — «Passing»، «Not passing» یا «Not checked yet» — و سطری از آنِ خود که میگوید ایراد کجاست.
برای SPF صفحه دو وضعیت را از هم جدا میکند و این مهمترین تمایز در کل مسیر است:
- دامنه اصلاً رکورد SPF ندارد. یکی را با مقدار جدول بالا منتشر کنید.
- رکورد SPF هست اما include ما در آن نیست. include را به رکورد موجود بیفزایید: دومی نسازید و کل رکورد را جایگزین نکنید. همین پیام حالت زنجیرهای را هم صریح پوشش میدهد: اگر include تنها از راه رکورد SPF ارائهدهندهای دیگر به ما برسد، به حساب نمیآید، چون زنجیرهها باز نمیشوند.
حالت دوم گیجکنندهترین لحظهٔ کل مسیر است: رکورد از پیش آنجاست، همین حالا خودتان دوباره خواندیدش، و تأیید باز هم رد میکند. پیام خطا اکنون دقیقاً همان چیزی را میگوید که یادداشت همیشگی کنار رکورد میگوید: include ما را به آنچه داری بیفزا.
اگر تأیید نگذشت:
- بخوانید کدامیک از سه رکورد «Not passing» خورده و در توضیحش چه آمده، و بر همان اساس عمل کنید.
- مطمئن شوید رکوردها واقعاً منتشر شدهاند — بسیاری از پنلها زدن جداگانهٔ «اعمال تغییرات» را میخواهند.
- نام رکورد را از نظر تکرار دامنه بررسی کنید (بالا را ببینید).
- بررسی کنید رکورد SPF تنها یکی باشد و include ما درون همان رکورد باشد.
- کمی صبر کنید و دوباره بررسی کنید: شاید تغییر هنوز پخش نشده باشد.
تا پیش از تأیید، ارسال کار نمیکند — و این عمدی است
تا وقتی دامنه تأیید نشده، نامهها فرستاده نمیشوند. نه «فرستاده میشوند و به هرزنامه میافتند» — اصلاً بیرون نمیروند: تلاش با خطای دامنهٔ تأییدنشده پایان مییابد و در گزارش دیده میشود.
این عمدی است و خرابی نیست. نامه از دامنهای که ضامن خودش نشده به شکایت هرزنامه بدل میشود، و شکایتها آبروی زیرساخت ارسالی را میبرند که میان همهٔ مشتریان پلتفرم مشترک است. نفرستادن یک نامه ارزانتر از فرستادن آن و سپس شش ماه بیرونآمدن از فهرستهای سیاه است. از این رو اینجا ممنوعیت است نه هشدار.
اگر این خطا را دیدید، پیش از نوشتن به پشتیبانی، رکوردهای DNS را بررسی و دکمهٔ بررسی را بزنید. در اکثریت قاطع موارد، مشکل غلط تایپی در نام یک رکورد است.
لغو اشتراک، شکایتها و شکست تحویل
سه قاعده که اگر از پیش ندانید شگفتزدهتان میکنند.
هر نامهٔ بازاریابی لغو اشتراک یککلیکی دارد. پلتفرم خودش پیوند لغو اشتراک را در پاورقی نامه و سرایندهای فنیای میافزاید که برنامهٔ رایانامه با آنها دکمهٔ «لغو اشتراک» را کنار نشانی فرستنده میکشد. برداشتنش شدنی نیست — نه با تنظیم و نه با چیدمان نامه. لغو اشتراک بیدرنگ اثر میکند، بدون بازکردن نامه و بدون گام تأیید. Gmail و دیگر ارائهدهندگان بزرگ همین را از فرستندگان انبوه میخواهند: نامهٔ بدون آن قطعاً به هرزنامه میرود.
لغو اشتراک قطعی است و از رابط کاربری برگشتپذیر نیست. نشانیای که لغو کرده دیگر نامهای از این ربات نمیگیرد. نه دکمهٔ «بازگردانی» هست و نه راه دور زدنی از طریق واردکردن دوبارهٔ فهرست: لغو اشتراک هرگز از بالای سر شخص باطل نمیشود. تنها خودش میتواند بازگردد — با گذاشتن دوبارهٔ نشانیاش در فرم اشتراک شما.
حالت سختگیرانهتری هم هست: اگر کسی در برنامهٔ رایانامه «این هرزنامه است» را بزند، نشانی برای همیشه بسته میشود. حتی اشتراک تازه از راه فرم شما هم بازش نمیکند — چون ما از پیش میدانیم تلاش گذشته چگونه پایان یافت، و نوشتن به چنین نشانیهایی سریعترین راه نابودی آبروی دامنه است. نشانیهایی که به درخواست حقوقی دستی بسته شدهاند نیز همین رفتار را دارند.
برگشت قطعی، نشانی را برای همیشه میبندد. اگر سرور گیرنده پاسخ دهد چنین صندوقی وجود ندارد، نشانی «تحویلناپذیر» علامت میخورد و از ارسالهای بعدی کنار گذاشته میشود. این وضعیتی موقت نیست: کوبیدن پیوسته بر در صندوقی ناموجود کوتاهترین راه افتادن در پالایههای هرزنامه است، همراه با همهٔ نشانیهای دیگر.
برگشتهای موقت (صندوق پر، سرور موقتاً در دسترس نیست) نشانی را نمیبندند و ارسال ادامه مییابد.
چرا «بازشدنها» کمتر از واقعیت است
در آمار رایانامه عدد بازشدن هست و همیشه کمتر از واقعیت است. این خطای شمارش نیست، بلکه به شیوهٔ اندازهگیری بازشدن برمیگردد.
بازشدن وقتی ثبت میشود که برنامهٔ رایانامه هنگام نمایش نامه، تصویر ردیاب بسیار کوچکی را از سرور بار کند. برنامههای امروزی بهطور پیشفرض تصاویر دوردست را بار نمیکنند؛ و آنها که بار میکنند (Apple Mail و سازوکارهای مشابه حریم خصوصی) این کار را از پیش و بهجای همه انجام میدهند، از جمله کسانی که نامه را هرگز باز نکردهاند. در حالت نخست بازشدن گم میشود و در حالت دوم به کسی نسبت مییابد که آنجا نبوده. راهی برای شمارش دقیقتر بازشدنها نیست — نه نزد ما و نه نزد هیچکس دیگر.
از این رو در رابط کاربری کنار این عدد توضیحی هست: این یک کران پایین است نه عددی دقیق. از آن برای مقایسهٔ نامهها با یکدیگر استفاده کنید، جایی که همان خطا بر همه اثر میگذارد، اما نه بهعنوان پاسخ به «چند نفر نامه را خواندند».
اگر سنجهای مطمئن برای تعامل میخواهید، به «Link clicks» نگاه کنید. کلیک روی پیوند کنش واقعی انسانی واقعی است؛ کسی آن را از پیش بهجای او انجام نمیدهد. «Delivered»، «Unsubscribes»، «Complaints» و «Bounces» نیز دقیق شمرده میشوند: آنها را سرورهای رایانامه گزارش میکنند، نه تصویری درون نامه. همهٔ اینها در بلوک «Sending stats» روی همان صفحهٔ Email هستند.