چرا ایمیل‌های تجاری شما در اسپم قرار می‌گیرند (و چگونه SPF، DKIM و DMARC آن را حل می‌کنند)

شما روی دکمه ارسال برای یادآوری صورتحساب، یک قیمت‌نامه یا خبرنامه ماهانه خود کلیک می‌کنید — و مشتری شما هرگز آن را نمی‌بیند. هیچ پیام خطا، هیچ بازگشتی، فقط سکوت. آن به اسپم رفت.

اگر این برای شما آشنا است، شما تنها نیستید. جیمیل، یاهو و آوت‌لوک اکنون ایمیل‌ها را از دامنه‌هایی که سه رکورد DNS را تنظیم نکرده‌اند، رد می‌کنند یا به پوشه اسپم منتقل می‌کنند: SPF، DKIM و DMARC. از فوریه ۲۰۲۴، فرستنده‌های عمده (تقریباً ۵,۰۰۰ یا بیشتر پیام در روز به حساب‌های جیمیل) باید با هر سه احراز هویت کنند، گزینه لغو اشتراک یک‌کلیکی ارائه دهند و شکایت‌های اسپم را زیر ۰.۳٪ نگه دارند. اجرای این قوانین در سال ۲۰۲۵ افزایش یافت، و در سال ۲۰۲۶ حتی فرستنده‌های تجاری با حجم کم تأثیر آن را حس می‌کنند: بدون احراز هویت، قیمت‌نامه‌ها، صورتحساب‌ها و تأییدهای قرار ملاقات شما بسیار بیشتر احتمال دارد که پرچم شوند.

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

SPF، DKIM و DMARC در واقع چه کاری انجام می‌دهند​

این سه رکورد را به عنوان بررسی‌های هویت برای ایمیل خود تصور کنید. هر یک به یک سؤال متفاوت که سرور دریافت‌کننده قبل از تحویل پیام شما می‌پرسد، پاسخ می‌دهد.

SPF: کدام سرورها مجاز به ارسال برای دامنه شما هستند​

SPF (سیاست چارچوب فرستنده) یک رکورد TXT در DNS دامنه شما است که لیستی از هر سروری که مجاز به ارسال ایمیل به عنوان شما است را فهرست می‌کند. وقتی جیمیل پیامی را که ادعا می‌کند از [email protected] است دریافت می‌کند، رکورد SPF شما را جستجو می‌کند و بررسی می‌کند که آیا IP سرور فرستنده در لیست است یا نه.

مثال رکورد SPF برای کسب‌وکاری که از Google Workspace و یک ابزار صدور صورتحساب استفاده می‌کند:

v=spf1 include:_spf.google.com include:servers.mcsv.net ~all

• v=spf1 رکورد را به عنوان SPF شناسایی می‌کند.
• هر include: سرورهای یک فراهم‌کننده را مجاز می‌کند.
• ~all (شکست نرم) به دریافت‌کنندگان می‌گوید که سرورهای غیرلیستی را با سوءظن رفتار کنند؛ -all (شکست سخت) به آنها می‌گوید که قاطعانه رد کنند.

SPF به تنهایی کافی نیست، زیرا فقط فرستنده پاکت (Return-Path پنهان) را اعتبارسنجی می‌کند، نه آدرسی که مشتری شما در فیلد From می‌بیند. انتقال (forwarding) نیز SPF را شکست می‌کند. به همین دلیل به DKIM نیز نیاز دارید.

DKIM: امضای ضدتغییر روی هر پیام​

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

برخلاف SPF، DKIM از انتقال عبور می‌کند، که آن را سیگنال پایدارتر از این دو می‌سازد. گوگل برای فرستنده‌های عمده الزام می‌کند که هم SPF و هم DKIM موفق باشند، با حداقل یکی از آنها هماهنگ با دامنه From.

راه‌اندازی DKIM معمولاً شامل:

1. فعال کردن امضای DKIM در فراهم‌کننده شما (Google Workspace، Microsoft 365، Mailchimp و ابزارهای مشابه همه یک مرحله فعال‌سازی یک‌کلیکی دارند).
2. کپی کردن رکورد TXT که آنها به شما می‌دهند (یک انتخابگر به همراه یک کلید عمومی بلند) به DNS شما.
3. انتظار برای انتشار، سپس بررسی در داشبورد فراهم‌کننده.

DMARC: سیاست شما برای وقتی که بررسی‌ها شکست می‌خورند​

DMARC (احراز هویت پیام مبتنی بر دامنه، گزارش‌دهی و انطباق) SPF و DKIM را به هم پیوند می‌دهد. این یک رکورد TXT در _dmarc.yourdomain.com است که به سرورهای دریافت‌کننده می‌گوید وقتی پیامی که ادعا می‌کند از شماست در احراز هویت شکست می‌خورد چه کاری انجام دهند — و کجا گزارش‌ها را برای شما بفرستند.

یک رکورد DMARC شروع‌کننده در حالت نظارت:

v=DMARC1; p=none; rua=mailto:[email protected]; pct=100;

• p=none به این معناست که هنوز هیچ اقدامی نگیرید، فقط گزارش‌ها را بفرستید. از اینجا شروع کنید.
• rua= مکانی است که گزارش‌های تجمیعی به آنجا می‌روند. از یک صندوق پستی استفاده کنید که واقعاً بررسی می‌کنید.
• پس از اینکه ایمیل مشروع به طور مداوم موفق شد، به p=quarantine (ارسال شکست‌ها به اسپم) بروید، سپس به p=reject (مسدود کردن آنها). این پیشرفت همان چیزی است که جعل‌سازان را از تقلید دامنه شما باز می‌دارد.

DMARC همچنین انطباق را الزام می‌کند: دامنه در هدر From باید با دامنه‌ای که SPF یا DKIM را موفق کرده‌است مطابقت داشته باشد. این مرحله‌ای است که بسیاری از کسب‌وکارها از دست می‌دهند — SPF و DKIM هر دو می‌توانند "موفق" نشان دهند در حالی که DMARC هنوز شکست می‌خورد زیرا دامنه‌ها هماهنگ نیستند.

قوانین جیمیل و یاهو که باید رعایت کنید​

حتی اگر هرگز ۵,۰۰۰ پیام در روز نفرستید، این موارد را به عنوان خط پایه خود در نظر بگیرید. جیمیل تمام ایمیل‌ها از همان دامنه اصلی (شامل زیردامنه‌ها) را به سمت آستانه عمده حساب می‌کند، وضعیت عمده هرگز پس از اختصاص منقضی نمی‌شود، و هر فرستنده — عمده یا غیر — انتظار دارد که احراز هویت کند.

در اینجا چک‌لیست عملی برای سال ۲۰۲۶ است:

• احراز هویت با SPF یا DKIM حداقل؛ اگر عمده هستید، هر دو. فرستنده‌های عمده به SPF و DKIM به علاوه یک رکورد DMARC منتشر (حداقل p=none) با انطباق دامنه From نیاز دارند.
• شکایت‌های اسپم را زیر ۰.۳٪ نگه دارید. ابزارهای Postmaster گوگل نرخ شما را نشان می‌دهد؛ نرخ‌های مداوم بالای ۰.۳٪ فیلتر را فعال می‌کنند. هدف را زیر ۰.۱٪ نگه دارید.
• لغو اشتراک را در ایمیل بازاریابی آسان کنید. یک هدر List-Unsubscribe قابل‌دید که لغو اشتراک یک‌کلیکی را حمایت کند شامل کنید و درخواست‌ها را ظرف دو روز احترام کنید.
• از DNS مستقیم و معکوس معتبر و یک دامنه From ثابت استفاده کنید. ایمیل تجاری را از آدرس‌های صندوق پستی رایگان یا نام‌های From متغیر نفرستید.
• هدرهای جیمیل را تقلید نکنید یا لیست‌ها را نخرید. ایمیل ناخواسته شکایت‌هایی را ایجاد می‌کند که سریع‌ترین راه برای خراب کردن اعتبار شماست.

یاهو و آوت‌لوک تقریباً همان مجموعه را اجرا می‌کنند، بنابراین یک تنظیم صحیح هر سه را پوشش می‌دهد.

تنظیم همه چیز در حدود یک ساعت​

شما لازم نیست فنی باشید تا این کار را انجام دهید — فقط به دسترسی به میزبان DNS خود (جایی که دامنه را خریده‌اید یا جایی که nameserverهای شما اشاره می‌کنند) و دسترسی مدیر به فراهم‌کننده ایمیل خود نیاز دارید.

مرحله ۱: فهرست کسانی که ایمیل به عنوان شما می‌فرستند​

هر خدمتی که با استفاده از دامنه شما ایمیل می‌فرستد را فهرست کنید: فراهم‌کننده صندوق پستی شما، فرم تماس وب‌سایت شما، سیستم صدور صورتحساب یا رزرو شما، ابزار خبرنامه شما، CRM شما. هر یک باید در SPF باشد یا با امضای DKIM خاص خود پوشش شود. اگر یکی را از دست بدهید، ایمیل آن شروع به شکست می‌کند.

مرحله ۲: انتشار SPF بدون شکستن حد ۱۰ جستجو​

SPF یک حد سخت ۱۰ جستجوی DNS دارد. هر include: می‌تواند چندین را فعال کند، و انباشتن فراهم‌کننده‌ها (صندوق پستی + بازاریابی + helpdesk + صدور صورتحساب) می‌تواند به طور خاموش شما را بالای حد ببرد — در آن نقطه SPF یک خطا برمی‌گرداند و دریافت‌کنندگان آن را به عنوان شکست تلقی می‌کنند.

• از رکورد توصیه‌شده فراهم‌کننده خود شروع کنید؛ قطعه‌های تصادفی از مقالات وبلاگ را ترکیب نکنید.
• تمام منابع ارسال را در یک رکورد SPF TXT واحد در دامنه ریشه نگه دارید. چندین رکورد SPF همه آنها را نامعتبر می‌کند.
• اگر نزدیک حد هستید، از فراهم‌کننده‌ها برای includes مسطح بخواهید یا خدماتی که دیگر استفاده نمی‌کنید را حذف کنید.
• با یک بررسی‌کننده SPF رایگان قبل از ادامه اعتبارسنجی کنید.

تنظیم رایج SPF:

مرحله ۳: فعال کردن DKIM در هر جایی که می‌فرستید​

امضای DKIM را در هر پلتفرم ارسال فعال کنید و هر رکورد انتخابگر که به شما می‌دهند را منتشر کنید. یک دامنه معمولاً با چندین انتخابگر DKIM پایان می‌یابد (یکی برای هر فراهم‌کننده) — این طبیعی است. هر یک را بررسی کنید تا در کنسول فراهم‌کننده فعال نشان دهد، و یک تست به یک آدرس جیمیل بفرستید تا تأیید کنید هدر Authentication-Results dkim=pass نشان می‌دهد.

کلیدها را وقتی فراهم‌کننده شما prompt می‌کند بچرخانید؛ چرخش‌های شکسته به عنوان کاهش تدریجی قابلیت تحویل ظاهر می‌شوند، بنابراین قبل از حذف کلید قدیمی تأیید کنید که کلید جدید اعتبارسنجی می‌کند.

مرحله ۴: انتشار DMARC در حالت نظارت، سپس اجرا​

1. _dmarc را با p=none و یک آدرس rua= منتشر کنید.
2. گزارش‌های تجمیعی را برای دو تا چهار هفته تماشا کنید. خوانندگان رایگان گزارش DMARC XML را به جداول خواندنی تبدیل می‌کنند که نشان می‌دهند کدام سرورها موفق و کدام شکست می‌کنند.
3. هر منبع مشروع که شکست می‌کند را رفع کنید (معمولاً یک امضای DKIM گمشده یا یک ناهماهنگی انطباق).
4. به p=quarantine بروید، یک چرخه دیگر تماشا کنید، سپس به p=reject بروید.

پرش مستقیم به p=reject از روز اول شایع‌ترین قطع سرویس خودساخته در این کل فرآیند است — صورتحساب‌ها و رسیدهای مشروع مسدود می‌شوند چون یک فرستنده نادیده‌شده هرگز احراز هویت نکرده‌است.

۷ اشتباه که کسب‌وکارهای کوچک را در اسپم نگه می‌دارند​

۱. هیچ SPF، DKIM یا DMARC در اصل وجود ندارد. هنوز شایع‌ترین یافته در دامنه‌های کسب‌وکار کوچک است. با هر تست‌کننده احراز هویت رایگان بررسی کنید قبل از فرض اینکه فراهم‌کننده شما "آن را حل کرده‌است." ۲. دو رکورد SPF. DNS فقط یکی را اجازه می‌دهد. همه چیز را در یک رکورد TXT واحد که با v=spf1 شروع می‌شود ادغام کنید. ۳. SPF بالای حد جستجو. تعداد زیادی includes باعث خطای SPF می‌شود. سالانه بررسی کنید و فراهم‌کننده‌های مرده را حذف کنید. ۴. DKIM در برنامه فعال شده اما هرگز در DNS منتشر نشده‌است. سوییچ امضا بدون رکورد TXT هیچ کاری انجام نمی‌دهد. ۵. DMARC به خاطر انطباق شکست می‌خورد. SPF یا DKIM موفق است اما تحت یک دامنه متفاوت از آدرس From شما — معمول وقتی خبرنامه‌ها از دامنه فراهم‌کننده به جای شما ارسال می‌شوند. یک دامنه ارسال سفارشی تنظیم کنید تا انطباق موفق شود. ۶. هیچکس گزارش‌های DMARC را نمی‌خواند. صندوق پستی rua= پر می‌شود، هشدارها درباره یک ابزار جدید شکست‌دهنده نادیده می‌شوند، و مشکل فقط وقتی ظاهر می‌شود که مشتریان شکایت می‌کنند. ۷. بهداشت لیست و محتوا احراز هویت خوب را خنثی می‌کنند. لیست‌های خریده، بدون پیوند لغو اشتراک، خطوط موضوع گمراه‌کننده و ایمیل‌های فقط تصویری شکایت‌هایی را ایجاد می‌کنند که حتی با DNS کامل اعتبار را خراب می‌کنند.

چگونه بفهمید که کار کرد​

• ایمیل تست به آدرس‌های جیمیل، یاهو و آوت‌لوک بفرستید (شامل یک حساب جدید که هرگز با شما تعامل نکرده‌است) و تأیید کنید که در صندوق ورودی قرار می‌گیرد، نه اسپم.
• هدرها را بررسی کنید. در جیمیل، پیام را باز کنید، "نمایش اصلی" را انتخاب کنید و تأیید کنید spf=pass، dkim=pass و dmarc=pass با دامنه شما هماهنگ است.
• در Google Postmaster Tools ثبت نام کنید. دامنه خود را اضافه کنید، مالکیت را تأیید کنید و نرخ اسپم، نرخ‌های موفق احراز هویت و اعتبار را در هفته‌های بعدی تماشا کنید.
• شاخص‌های واقعی را پیگیری کنید. نرخ‌های باز، نرخ‌های پاسخ و — مهم‌ترین — شکایت‌های مشتری "من هرگز صورتحساب شما را نگرفتم" قبل و بعد تغییر را مقایسه کنید.

این چه ارتباطی با دفتر شما دارد​

قابلیت تحویل ایمیل یک مشکل جریان نقدی است که به عنوان یک کار فنی مبدل شده‌است. وقتی صورتحساب‌ها در اسپم فرود می‌آیند، مشتریان بدون تقصیر خود دیر پرداخت می‌کنند، روزهای فروش معوق شما افزایش می‌یابد و شما ساعت‌ها برای پیگیری پرداخت‌هایی که هرگز دیده نشده‌اند تلف می‌کنید. همین امر در مورد قیمت‌نامه‌هایی که هرگز پاسخ داده نشده‌اند و دنباله‌های یادآوری پرداخت که به نیستی شلیک می‌شوند صدق می‌کند.

دامنه‌های ارسال احراز هویت‌شده را به همان طور که با تطبیق بانکی رفتار می‌کنید درمان کنید: یک کنترل ملال‌آور که پول را در حرکت نگه می‌دارد. یادداشت کنید کدام فراهم‌کننده چه چیزی می‌فرستد (صورتحساب‌ها، رسیدها، بازاریابی) تا هر جریان احراز هویت بماند، و پرداخت‌های دیر را در برابر تاریخی که مشتری واقعاً صورتحساب را دید — نه فقط تاریخی که سیستم شما آن را فرستاد — پیگیری کنید. سوابق تحویل تمیز هر دو پیگیری شما و دفتر شما را صادق‌تر می‌سازد.

برای بیشتر در مورد نگه‌داشتن حساب‌های دریافتی، به راهنماهای /docs/ در مورد جریان‌های کاری صدور صورتحساب و نماهای داشبورد /fava/ که موجودی‌های معوق را در یک نگاه نشان می‌دهند مراجعه کنید.

مدیریت مالی خود را ساده کنید​

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