رکورد SPF را برای ایمیل اپلیکیشن چگونه بررسی کنیم؟

از هویتی شروع کنید که SPF واقعاً بررسی می‌کند

بررسی SPF به سه ورودی نیاز دارد: نشانی IP کلاینت SMTP، دامنه‌ای که سیاست مجوز آن ارزیابی می‌شود و هویت فرستنده. برای ایمیل معمولی اپلیکیشن، این دامنه از نشانی SMTP MAIL FROM گرفته می‌شود که به آن فرستنده envelope یا return path هم می‌گویند. این نشانی می‌تواند با نشانی‌ای که کاربران در هدر From پیام می‌بینند متفاوت باشد. اگر MAIL FROM خالی باشد، که معمولاً برای اعلان وضعیت تحویل (DSN) چنین است، SPF برای بررسی MAIL FROM از هویت HELO استفاده می‌کند. پیش از lookup در DNS، IP واقعی اتصال و هویت envelope را از یک پیام آزمایشی دریافت‌شده یا از پیکربندی ارائه‌دهنده ارسال ثبت کنید. وقتی اپلیکیشن در واقع با MAIL FROM روی bounce.provider.test یا bounces.example.test ارسال می‌کند، بررسی example.test صرفاً به این دلیل که در From آمده است نتیجه قطعی نمی‌دهد.

رکورد TXT را دقیقاً روی دامنه MAIL FROM کوئری بگیرید

رکورد TXT را در DNS دقیقاً روی دامنه‌ای که در گام اول انتخاب شد کوئری بگیرید. RFC 7208 الزام می‌کند سیاست‌های SPF نسخه 1 به‌صورت رکورد TXT روی همان نام مالکی منتشر شوند که بر آن حاکم‌اند. مقادیر TXT نامرتبط را نادیده بگیرید و رکوردهایی را انتخاب کنید که بخش نسخه‌شان دقیقاً v=spf1 است. اگر هیچ رکوردی انتخاب نشود، نتیجه SPF برابر none است. اگر بیش از یک رکورد SPF انتخاب شود، نتیجه permerror است؛ انتشار رکوردهای جداگانه برای ارائه‌دهندگان مختلف راه معتبری برای ترکیب آن‌ها نیست. ابزارهای DNS ممکن است یک رکورد منبع TXT را به چند رشته کاراکتری داخل گیومه تقسیم کنند، اما این رشته‌ها پیش از parse شدن SPF بدون درج فاصله به هم متصل می‌شوند. پاسخ کامل، resolver، زمان کوئری و TTL را ثبت کنید تا بتوان بررسی را پس از هر تغییر تکرار کرد.

نحو را اعتبارسنجی و اجزا را از چپ به راست ارزیابی کنید

رکورد SPF یک سیاست ترتیب‌دار است، نه فهرستی بی‌ترتیب از ارائه‌دهندگان. پس از v=spf1، مکانیزم‌ها از چپ به راست ارزیابی می‌شوند تا یکی تطبیق پیدا کند. qualifier ابتدای هر مکانیزم نتیجه را تعیین می‌کند: + یعنی pass و پیش‌فرض است، - یعنی fail، ~ یعنی softfail و ? یعنی neutral. مکانیزم‌های ip4 و ip6 نشانی کلاینت را با یک نشانی یا شبکه مقایسه می‌کنند. مکانیزم‌های a و mx به DNS مراجعه می‌کنند، در حالی که include سیاست SPF دامنه دیگری را ارزیابی می‌کند و فقط طبق قواعد include تطبیق می‌یابد. exists یک آزمون مبتنی بر DNS انجام می‌دهد. all همیشه تطبیق می‌یابد و معمولاً رکورد را خاتمه می‌دهد. خطای نحوی در هر جای رکورد پیش از ارزیابی عادی به permerror منجر می‌شود. یک ابزار بررسی مفید باید گزارش دهد کدام مکانیزم تطبیق یافت، qualifier آن چه بود و هر دامنه گسترش‌یافته چیست، نه اینکه فقط یک نشان رنگی برگرداند.

include و redirect را دنبال کنید، بدون اینکه آن‌ها را نام مستعار بدانید

هر include و redirect را در همان زمینه ارزیابی دنبال کنید. include یک مکانیزم است: می‌پرسد آیا سیاست گنجانده‌شده برای کلاینت و فرستنده فعلی pass برمی‌گرداند یا نه، و اگر تطبیق نیابد، ارزیابی در رکورد اصلی ادامه می‌یابد. redirect یک modifier است که پس از تطبیق نیافتن مکانیزم‌های رکورد فعلی در نظر گرفته می‌شود؛ ارزیابی را با حفظ IP کلاینت و فرستنده به سیاست دیگری منتقل می‌کند. اگر all در هر جای رکورد وجود داشته باشد، redirect نادیده گرفته می‌شود. این تفاوت‌ها در مهاجرت‌ها اهمیت دارند. جایگزین کردن include:vendor.test با redirect=vendor.test ممکن است کل سیاست پشتیبان مالک دامنه را جایگزین کند، نه اینکه فقط یک ارائه‌دهنده اضافه کند. حلقه‌ها، مقصدهای ناموجود، مقصدهای نامعتبر و خطاهای دائمی یا گذرای تودرتو را شناسایی کنید و زنجیره وابستگی را در نتیجه نگه دارید تا تغییر سیاست در سمت ارائه‌دهنده قابل‌مشاهده باشد.

کل بودجه کوئری‌های DNS را بشمارید

اجزایی را که کوئری DNS ایجاد می‌کنند در کل ارزیابی بازگشتی بشمارید، نه فقط در رکورد سطح بالا. RFC 7208 تعداد اجزای include، a، mx، ptr، exists و redirect را در یک ارزیابی SPF به ده محدود می‌کند؛ عبور از این حد باید به permerror منجر شود. مکانیزم‌های all، ip4 و ip6 از این بودجه مصرف نمی‌کنند. پردازش MX و PTR محدودیت‌های اضافی برای کوئری نشانی دارد. RFC همچنین توصیه می‌کند void lookupها، یعنی پاسخ‌های موفق خالی یا خطاهای نام، به دو محدود شوند و در صورت عبور از این حد permerror تولید شود. استفاده از مکانیزم ptr توصیه نمی‌شود، چون کند و غیرقابل‌اعتماد است. یک رکورد ممکن است کوتاه به نظر برسد اما includeهای ارائه‌دهندگان به‌قدری جزء تودرتو گسترش یابند که ارزیابی شکست بخورد؛ بنابراین مجموع، تک‌تک اجزای مؤثر، void lookupها و شاخه دقیق پیموده‌شده برای IP آزمایش‌شده را گزارش کنید.

نتیجه SPF را بدون اغراق تفسیر کنید

از واژگان استاندارد نتایج استفاده کنید. pass یعنی کلاینت آزمایش‌شده مجاز به استفاده از هویت SMTP بررسی‌شده است. fail یعنی یک مجوز منفی منطبق یافت شده است. softfail یک اظهار منفی ضعیف است، در حالی که neutral می‌گوید دامنه درباره آن کلاینت ادعایی ندارد. none یعنی هیچ رکورد SPF انتخاب نشده است. temperror نشان‌دهنده یک مشکل گذرا در ارزیابی است که معمولاً از DNS ناشی می‌شود؛ permerror نشان‌دهنده سیاستی است که نمی‌توان آن را به‌درستی ارزیابی کرد. اگر هیچ مکانیزمی تطبیق نیابد و redirect هم اعمال نشود، نتیجه neutral است که معادل یک ?all ضمنی است. نتیجه را همراه با هویت، IP کلاینت، جزء تطبیق‌یافته، ردگیری DNS و زمان گزارش کنید. pass را به معنای پیام امن، ایمیل خواسته‌شده، پذیرش توسط ارائه‌دهنده، تحویل به صندوق ایمیل یا رسیدن به صندوق ورودی تعبیر نکنید، زیرا SPF درباره این نتایج تصمیم نمی‌گیرد.

یک پیام واقعی را بررسی کنید، نه فقط رکورد منتشرشده را

بررسی ایستای رکورد فقط نشان می‌دهد که آیا سیاست قابل‌کشف و parse است یا نه. ثابت نمی‌کند که اپلیکیشن از دامنه MAIL FROM یا IP خروجی موردانتظار استفاده کرده است. یک پیام کنترل‌شده را از هر مسیر واقعی محیط عملیاتی به حساب گیرنده‌ای که مدیریتش با شماست بفرستید و سپس هدرهای دریافت‌شده را بررسی کنید. IP اتصال، فرستنده envelope و ورودی Authentication-Results گیرنده را با ارزیابی DNS مقایسه کنید. این کار را برای هر ارائه‌دهنده، region، استخر IP اختصاصی یا اشتراکی، مسیر پشتیبان و دسته پیامی که می‌تواند return path را تغییر دهد تکرار کنید. هدرها را در فضای ذخیره‌سازی با دسترسی محدود نگه دارید، چون نشانی‌ها و جزئیات مسیریابی می‌توانند حساس باشند. اگر داشبورد ارائه‌دهنده و پیام دریافت‌شده با هم نخوانند، پیام شاهد قوی‌تری از مسیری است که واقعاً اجرا شده است، هرچند نتیجه یک گیرنده واحد را نباید به رفتار تحویل در همه‌جا تعمیم داد.

هم‌راستایی DMARC را در گامی جداگانه ارزیابی کنید

SPF ممکن است برای یک دامنه return-path متعلق به ارائه‌دهنده pass شود، در حالی که DMARC همچنان نتواند از آن نتیجه استفاده کند. قواعد فعلی DMARC دامنه RFC5321.MailFrom احراز هویت‌شده با SPF موفق را با دامنه نویسنده در فیلد قابل‌مشاهده RFC5322.From مقایسه می‌کنند. هم‌راستایی strict به همان دامنه DNS نیاز دارد. هم‌راستایی relaxed دامنه‌هایی را مجاز می‌داند که طبق قواعد کشف DMARC به یک دامنه سازمانی واحد برسند. برای مثال، bounces.example.test و example.test در حالت relaxed می‌توانند هم‌راستا باشند، اما bounce.provider.test و example.test نه. نتیجه DMARC می‌تواند در عوض به یک امضای DKIM تأییدشده و هم‌راستا تکیه کند، پس نتیجه SPF ناهم‌راستا به‌تنهایی به معنای شکست DMARC نیست. احراز هویت و هم‌راستایی را جداگانه گزارش کنید و به‌جای مقایسه سخت‌کدشده دو برچسب آخر، از روش فعلی کشف دامنه استفاده کنید.

پیکربندی MAIL FROM مخصوص هر ارائه‌دهنده را آزمایش کنید

تنظیمات ارائه‌دهنده تعیین می‌کند کدام هویت SPF روی شبکه ظاهر شود. برای نمونه، Amazon SES یک دامنه MAIL FROM سفارشی را مستند کرده است که به رکورد MX و رکورد TXT از نوع SPF مخصوص خود نیاز دارد. وقتی MX دامنه سفارشی اشتباه پیکربندی شده باشد، SES بسته به رفتار پیکربندی‌شده ممکن است به یک دامنه MAIL FROM وابسته به region روی amazonses.com برگردد یا ارسال را رد کند. این بازگشت می‌تواند هم‌راستایی DMARC را تغییر دهد، حتی اگر نشانی From قابل‌مشاهده تغییری نکرده باشد. برای هر ارائه‌دهنده، دامنه return-path پیکربندی‌شده، مقادیر DNS لازم، رفتار بازگشت، regionهای ارسال و مالکیت را ثبت کنید. پس از هر تغییر در DNS یا ارائه‌دهنده، صبر کنید تا پاسخ‌های کش‌شده مرتبط منقضی شوند، سپس ارزیابی DNS و ارسال‌های کنترل‌شده را تکرار کنید. include یک ارائه‌دهنده را در دامنه From قابل‌مشاهده کپی نکنید، مگر اینکه واقعاً هویت همان باشد و فهرست کامل فرستندگان دامنه آن را تأیید کند.

هنگام تغییرات از ممیزی تکرارپذیر SPF استفاده کنید

برای هر مسیر ارسال یک ردیف نگه دارید، شامل مالک، اپلیکیشن، دسته پیام، دامنه From قابل‌مشاهده، دامنه MAIL FROM، دامنه HELO، بازه‌های مبدأ موردانتظار، وابستگی به ارائه‌دهنده و زمان آخرین آزمون کنترل‌شده. هر بررسی SPF را همراه با رکورد انتخاب‌شده، ردگیری بازگشتی، تعداد کوئری‌های DNS، مکانیزم تطبیق‌یافته، نتیجه، تصمیم هم‌راستایی و یک شناسه آزمایشی غیرحساس ذخیره کنید. در حین مهاجرت، منابع مشروع قدیمی و جدید را فقط در بازه انتقال لازم مجاز نگه دارید، مسیر جدید را تأیید کنید و سپس مجوزهای کهنه را آگاهانه حذف کنید. خطاهای دائمی و گذرای احراز هویت را پایش کنید، نه اینکه فقط به ردشدن‌ها واکنش نشان دهید. پس از تغییر ارائه‌دهنده، جابه‌جایی استخر IP، تغییر دامنه، ویرایش DNS یا اضافه شدن اپلیکیشن جدید، ممیزی را دوباره اجرا کنید. این گردش‌کار هم سیاست‌های بیش از حد محدود را که مسیرهای مشروع را مسدود می‌کنند شناسایی می‌کند و هم سیاست‌های بیش از حد گسترده را که مجوزهای بلااستفاده را نگه می‌دارند.

SendHQ را با همان استاندارد شواهد بررسی کنید

SendHQ مستند می‌کند که ارسال مستقیم باید از یک نشانی روی دامنه تأییدشده فضای کاری استفاده کند. این کار هویت فرستنده را تأیید می‌کند، اما جای ارزیابی SPF را نمی‌گیرد. یک پیام کنترل‌شده SendHQ همچنان به همان trace DNS، بررسی هدر دریافت‌شده، نتیجه SPF و بررسی هم‌راستایی DMARC که در بالا توضیح داده شد نیاز دارد.

پرسش‌های متداول

منابع

• RFC 7208: چارچوب سیاست فرستنده (SPF) — IETF
• RFC 5321: پروتکل ساده انتقال ایمیل (SMTP) — IETF
• RFC 9989: احراز هویت، گزارش‌دهی و انطباق پیام مبتنی بر دامنه (DMARC) — RFC Editor
• استفاده از دامنه MAIL FROM سفارشی در Amazon SES — Amazon Web Services
• قرارداد OpenAPI در SendHQ — SendHQ