از یک دامنه تا زیرساخت ایمیل شخصی من
چطور برای دامنهام یک زیرساخت ایمیل راهاندازی کردم، آن را روی Gmail موبایل استفاده کردم و همان سیستم را به OTP اپلیکیشنها متصل کردم.
Case Study · Email Infrastructure · [X] min read

مدتی بود که یک دامنه داشتم، اما برای استفاده واقعی از آن هنوز به سرویس ایمیل دیگری وابسته بودم. در نهایت تصمیم گرفتم ایمیل را فقط بهعنوان یک آدرس روی دامنه نبینم و یک زیرساخت کوچک و شخصی برای آن راهاندازی کنم. هدف خیلی پیچیدهای نداشتم: بتوانم با دامنه خودم ایمیل بفرستم و دریافت کنم، آن را روی موبایلم مثل هر mailbox دیگری در Gmail داشته باشم و در صورت نیاز از همان زیرساخت برای ارسال ایمیلهای OTP از اپلیکیشنها استفاده کنم. این نوشته بیشتر از اینکه یک tutorial باشد، گزارشی است از چیزی که ساختم، معماری آن و چیزهایی که در این مسیر یاد گرفتم.
چیزی که ساختم

در سادهترین شکل، جریان سیستم من این است:
mohsen.info → DNS → Email Server → Mailbox → Gmail Mobile Application → SMTP → Email Server → Delivery / Mailbox
در این setup، دامنه هویت ایمیل را مشخص میکند، DNS مشخص میکند ایمیلها کجا باید تحویل داده شوند و mail server وظیفه ارسال، دریافت و نگهداری mailbox را بر عهده دارد.
از دامنه شروع میشود

راهاندازی ایمیل فقط نصب یک mail server نیست. اول باید دامنه را برای email آماده کرد. DNS جایی است که مشخص میشود چه سروری مسئول دریافت ایمیلهای دامنه است و سرویسهای مقصد چطور میتوانند اعتبار ایمیلهای خروجی را بررسی کنند.
در setup من، این بخش شامل رکوردهایی مانند MX برای مسیریابی ایمیل، A/AAAA برای resolve شدن hostname، PTR برای reverse DNS، SPF برای مشخص کردن فرستندگان مجاز، DKIM برای امضای پیامها و DMARC برای سیاست احراز هویت و گزارشگیری بود.
یکی از چیزهایی که در عمل فهمیدم این بود که فرستادن یک ایمیل با SMTP با قابلاعتماد بودن آن ایمیل برای سرویس مقصد یکی نیست.
Google برای ارسال ایمیل به حسابهای شخصی Gmail روی احراز هویت دامنه، forward و reverse DNS معتبر و TLS تأکید دارد؛ برای فرستندگان حجیم نیز الزامات SPF، DKIM و DMARC سختگیرانهتر است.
SMTP برای ارسال، IMAP برای دریافت
یکی از تفاوتهایی که در عمل اهمیت زیادی پیدا میکند، نقش متفاوت SMTP و IMAP است.
SMTP مسیر ارسال ایمیل را مدیریت میکند؛ IMAP برای دسترسی و همگامسازی mailbox توسط mail client استفاده میشود.
Sending: Application → SMTP → Recipient Mail Server Receiving: Sender → MX / DNS → My Mail Server → Mailbox → IMAP → Gmail
استفاده از ایمیل دامنه شخصی داخل Gmail

یکی از قسمتهای جالب این setup برای من این بود که لازم نبود برای خواندن ایمیلها یک client جدید روی موبایلم پیدا کنم. اپ Gmail امکان اضافه کردن حسابهای non-Gmail از طریق IMAP را دارد؛ بنابراین میتوان یک mailbox روی دامنه شخصی را به Gmail متصل کرد.
در این setup، Gmail ارائهدهنده mailbox من نیست؛ کلاینتی است که به mailbox شخصی من متصل میشود.
همان زیرساخت برای OTP

قسمت جالبتر زمانی شروع شد که همین زیرساخت را به اپلیکیشنها متصل کردم. اپلیکیشن میتواند از طریق SMTP به mail server متصل شود و ایمیل OTP را از همان دامنه ارسال کند.
جریان کلی به این شکل است: User → Request OTP → Generate Code → Store OTP + Expiration → Send via SMTP → Email Delivered → Verify → Invalidate
اینجا خود ایمیل فقط بخشی از مسئله است. OTP باید عمر محدودی داشته باشد، بعد از استفاده دیگر قابل استفاده نباشد و endpoint درخواست OTP هم در برابر abuse و درخواستهای بیش از حد محافظت شود.
در implementation من، جریان OTP روی Next.js و Prisma اجرا میشود. اپلیکیشن یک کد چهاررقمی یکبارمصرف تولید میکند و فقط هش SHA-256 آن را همراه با challenge در دیتابیس نگه میدارد. هر challenge دو دقیقه اعتبار دارد، حداکثر پنج بار قابل بررسی است و ارسال مجدد همان OTP نیز cooldown شصتثانیهای دارد. درخواستهای OTP برای هر شماره و هر IP به هشت درخواست در روز محدود شدهاند و بررسی OTP نیز بهصورت جداگانه rate limit میشود. پس از تأیید موفق، challenge مصرف میشود و دوباره قابل استفاده نیست. ارسال ایمیل از mail abstraction برنامه انجام میشود که در صورت تنظیم SMTP از Nodemailer استفاده میکند.
چیزی که انتظار نداشتم
بخش سختتر از خود setup، deliverability بود.
روی کاغذ، ارسال ایمیل ساده به نظر میرسد: یک SMTP server، یک domain و تمام. اما در عمل، سرویس مقصد باید بتواند تشخیص دهد این پیام از طرف چه کسی آمده و آیا میتواند به آن اعتماد کند.
SPF، DKIM، DMARC، reverse DNS و TLS در همین نقطه اهمیت پیدا میکنند. یکی از بزرگترین درسهای این پروژه برای من این بود:
Running an email server is one problem. Making email trustworthy is another.
Pros & Cons

چرا از آن راضیام
کنترل بیشتر: دامنه، mailbox و مسیر ارسال را خودم مدیریت میکنم.
یادگیری واقعی: ایمیل دیگر یک black box نیست و اجزای زیرساختی آن را در عمل دیدم.
یک setup برای چند کاربرد: همان زیرساخت میتواند برای mailbox شخصی و پیامهای application استفاده شود.
چه چیزی را باید در نظر گرفت
Maintenance: وقتی سرویس را خودت میزبانی میکنی، نگهداری آن هم مسئولیت خودت است.
Deliverability: موفق بودن SMTP به معنی تضمین inbox placement نیست.
Security & Abuse: یک mail system عمومی باید مانند هر سرویس اینترنتی دیگری محافظت و مانیتور شود.
Scale: برای استفاده شخصی یا پروژه کوچک میتواند منطقی باشد؛ برای حجم بالا ممکن است سرویس تخصصی ایمیل انتخاب عملیتری باشد.
آیا دوباره همین کار را میکردم؟
بله؛ اما نه به این دلیل که self-hosted email همیشه بهترین راهحل است. برای من، ارزش اصلی این پروژه در کنترل و فهمیدن چیزی بود که قبلاً یک سرویس آماده آن را پشت پرده انجام میداد.
اگر از ابتدا شروع میکردم، توجه بیشتری به monitoring، deliverability و backup میگذاشتم و قبل از استفاده در workload بزرگتر، این بخشها را جدیتر ارزیابی میکردم.
Final Note
این پروژه برای من بیشتر از «داشتن یک ایمیل با دامنه شخصی» بود. با راهاندازی آن، یک سرویس روزمره را به یک مسئله واقعی مهندسی تبدیل کردم: DNS، authentication، mail delivery، mailbox access، mobile client و application integration در یک سیستم کوچک کنار هم قرار گرفتند.
و شاید جذابترین قسمت همین بود؛ اینکه چیزی که هر روز ساده به نظر میرسد، وقتی تصمیم میگیری خودت آن را اجرا کنی، لایههای زیادی پشت خودش دارد.

FAQ
آیا میتوانم ایمیل دامنه شخصیام را داخل Gmail استفاده کنم؟
بله. اپ Gmail امکان اضافه کردن حسابهای non-Gmail از طریق IMAP را روی Android، iPhone و iPad فراهم میکند.
آیا برای داشتن ایمیل روی دامنه شخصی حتماً باید Gmail داشته باشم؟
خیر. در این setup، Gmail فقط mail client است و mailbox روی زیرساخت ایمیل شخصی قرار دارد.
تفاوت SMTP و IMAP چیست؟
SMTP برای ارسال ایمیل استفاده میشود و IMAP برای دسترسی و همگامسازی mailbox.
چرا SPF، DKIM و DMARC مهم هستند؟
این سازوکارها به سرویسهای مقصد کمک میکنند هویت و اصالت پیامهای ارسالی از دامنه را ارزیابی کنند. برای Gmail نیز Google روی احراز هویت ایمیل و تنظیمات زیرساختی مرتبط تأکید دارد.
آیا self-hosted email بهتر از سرویسهای آماده است؟
نه همیشه. self-hosting کنترل و تجربه فنی بیشتری میدهد، اما نگهداری، امنیت و deliverability را نیز بر عهده خودت میگذارد.
آیا میتوان از همین زیرساخت برای OTP استفاده کرد؟
بله. application میتواند از SMTP برای ارسال OTP استفاده کند، اما expiration، one-time use، rate limiting و منطق امنیتی در خود application باقی میمانند.


