اصطلاح · سینتکس رکورد SPF
سینتکس رکورد SPF چیست و چه اثری بر ایمیل‌های برنامه دارد؟
سینتکس رکورد SPF یک سیاست TXT در DNS با عبارتهای جداشده با فاصله است که با v=spf1 شروع میشود و پس از آن مکانیزم‌هایی میآیند که منابع ارسال مجاز را تطبیق می‌دهند، به‌همراه یک modifier اختیاری redirect یا explanation. هر مکانیزم میتواند یکی از +، -، ~ یا ? را بهعنوان qualifier نتیجه داشته باشد؛ مکانیزمهای رایج شامل ip4، ip6، a، mx، include، exists و all هستند. ترتیب اهمیت دارد، چون ارزیابی با اولین مکانیزم منطبق متوقف میشود. برای هر دامنه دقیق فقط یک سیاست SPF منتشر کنید، عبارت‌هایی را که باعث کوئری DNS میشوند در محدوده پروتکل نگه دارید، همه فرستندگان envelope واقعی را آزمایش کنید و به یاد داشته باشید که SPF هویت SMTP را احراز میکند، نه بهطور خودکار دامنه From قابلمشاهده یا رسیدن به صندوق ورودی را.
رکورد SPF یک عبارت سیاستی مرتب است
RFC 7208 رکورد SPF را یک رشته TXT در DNS تعریف میکند که اولین عبارت آن v=spf1 است. بقیه عبارتهای جداشده با فاصله، مکانیزم‌ها (که می‌توانند منطبق شوند) و modifierها (که پردازش را تغییر می‌دهند) هستند. ارزیابی از چپ به راست پیش می‌رود و با اولین مکانیزم منطبق متوقف میشود، بنابراین ترتیب بیانگر سیاست است. یک رکورد معمول ممکن است دو بازه نشانی ثابت را مجاز کند، سیاست یک ارائه‌دهنده را include کند و سپس با -all تمام شود. این الگو را بدون تغییر کپی نکنید: رکورد درست به هویت‌های دقیق SMTP MAIL FROM یا HELO و منابع ارسال واقعی بستگی دارد. ابتدا ارائه‌دهندگان برنامه، سرورهای ایمیل، ابزارهای پشتیبانی، پلتفرم‌های هویت، سیستم‌های بازاریابی، مسیرهای forwarding و فرستندگان بازیابی از فاجعه را فهرست کنید. سیاست را در دامنه‌ای که ارزیابی میشود منتشر کنید، نه بهطور خودکار در دامنه From قابلمشاهده. یک رکورد با سینتکس معتبر همچنان میتواند منابع اشتباه را مجاز کند، یک جریان production را از قلم بیندازد یا از محدودیت‌های ارزیابی DNS فراتر رود.
qualifierها تطابق یک مکانیزم را به نتیجه SPF نگاشت میکنند
هر مکانیزم میتواند با یک qualifier شروع شود: + برای pass، - برای fail، ~ برای softfail یا ? برای neutral. اگر qualifier نیاید، + فرض میشود. qualifier فقط وقتی اعمال میشود که آن مکانیزم منطبق شود. وقتی مکانیزم منطبق نشود، تغییری در ارزیابی عبارتهای بعدی ایجاد نمی‌کند. تیم‌ها اغلب روی عبارت all پایانی تمرکز میکنند، اما هر مکانیزم include، نشانی، a، mx یا exists قبلی هم qualifier دارد و میتواند ارزیابی را خاتمه دهد. بهجای اینکه فرض کنید ~all یعنی حالت آزمایشی یا -all ثابت میکند همه منابع شناخته‌شده‌اند، بازبینی صریح انجام دهید. نتیجه fail شاهدی برای گیرنده درباره هویت SMTP و IP ارزیابی‌شده است، نه دستوری همگانی برای حذف ایمیل. گیرندگان سیاست محلی خود را اعمال میکنند. neutral و softfail به معنای مجوز pass نیستند. نتیجه موردنظر را برای منابع مجاز، غیرمجاز و موقتاً resolveنشده ثبت کنید و آن را با fixtureهای کنترل‌شده IP و هویت بررسی کنید.
مکانیزمهای نشانی مستقیم‌اند اما به مالکیت نیاز دارند
مکانیزمهای ip4 و ip6 بازه‌های شبکه منطبق را که با سینتکس مخصوص هر پروتکل و طول prefix اختیاری بیان میشوند مجاز میکنند. این مکانیزم‌ها در زمان ارزیابی از lookup اضافی نشانی جلوگیری میکنند، اما با تغییر شبکه‌های خروجی ممکن است قدیمی شوند. از نشانی‌های ارسال عمومی استفاده کنید، هرگز از نشانی‌های خصوصی محیط اجرا، و بازه‌ها را تا جایی که failover عملیاتی اجازه میدهد محدود نگه دارید. هر بازه باید مالک، سیستم مبدأ، محیط، روند تغییر و تاریخ بازبینی داشته باشد. مکانیزم a یک نام A یا AAAA را resolve میکند و اگر domain-spec دیگری داده نشود، بهطور پیش‌فرض دامنه SPF فعلی را به کار می‌برد. مکانیزم mx میزبان‌های MX و نشانی‌های آن‌ها را resolve میکند. این مکانیزم‌ها کار DNS را افزایش می‌دهند و می‌توانند زیرساختی را مجاز کنند که خارج از چرخه انتشار برنامه تغییر میکند. از a یا mx بهعنوان میان‌بر استفاده نکنید، مگر اینکه همه نشانی‌های resolveشده آگاهانه مجاز به ارسال با همان هویت دقیق SMTP باشند. تغییرات را پایش کنید و هر دو مسیر IPv4 و IPv6 را آزمایش کنید.
include سیاست دیگری را ارزیابی میکند، نه یک تکه متن
مکانیزم include سیاست SPF دامنه ارجاع‌شده را ارزیابی میکند و وقتی آن ارزیابی تودرتو pass برگرداند منطبق میشود. این مکانیزم عبارت‌ها را بهطور مکانیکی در رشته فعلی کپی نمی‌کند و سایر نتایج تودرتو اثرات تعریف‌شده‌ای دارند. فقط وقتی از include استفاده کنید که سازمان ارجاع‌شده آن دامنه را صریحاً برای رابطه ارسال شما مستند کرده باشد. دامنه وب‌سایت، دامنه MX یا دامنه From قابلمشاهده یک ارائه‌دهنده بهطور خودکار include مربوط به SPF آن نیست. includeها وابستگی عملیاتی ایجاد میکنند: تغییر رکورد ارائه‌دهنده میتواند مجوزها را تغییر دهد، lookupهای تودرتوی DNS اضافه کند یا خطاهای موقت و دائمی ایجاد کند. فروشنده، سرویس، دامنه دقیق include، منبع قرارداد، مالک و برنامه حذف را ثبت کنید. سیاست حاصل را از IP ارسال واقعی ارائه‌دهنده و دامنه envelope خود آزمایش کنید. هرگز includeهای ارائه‌دهنده را به فهرست‌های کپی‌شده IP تبدیل (flatten) نکنید، مگر اینکه مسئولیت پیگیری هر تغییر نشانی ارائه‌دهنده و حفظ معنای اصلی را هم بپذیرید.
all، redirect و explanation نقش‌های متفاوتی دارند
مکانیزم all همیشه منطبق میشود و معمولاً در انتها قرار می‌گیرد؛ عبارتهای پس از آن نمی‌توانند بر ارزیابی اثر بگذارند. qualifier آن نتیجه را برای منابعی که پیش‌تر منطبق نشده‌اند تعیین میکند. modifier مربوط به redirect به SPF میگوید وقتی هیچ مکانیزمی در رکورد فعلی منطبق نشد، از سیاست دامنه دیگری استفاده کند. redirect با include یکی نیست: include یک مکانیزم در ترتیب است، در حالی که redirect تحت شرایط تعریفشده خود جایگزین تصمیم نهایی سیاست میشود. یک رکورد نباید چند modifier از نوع redirect داشته باشد. modifier مربوط به exp میتواند به توضیحی برای نتیجه fail ارجاع دهد، اما ایمیل را مجاز نمی‌کند و ملاحظات عملیاتی و حریم خصوصی بیشتری ایجاد میکند. توضیحات را کلی نگه دارید و از داده‌های فرستنده یا گیرنده پرهیز کنید. وقتی دامنه‌ها آگاهانه کل یک سیاست را به اشتراک می‌گذارند و مالکیت هماهنگ دارند، redirect را انتخاب کنید. وقتی منابع مجاز یک ارائه‌دهنده را درون یک سیاست محلی گسترده‌تر اضافه می‌کنید، include را انتخاب کنید. مسیرهای منطبق‌نشده را هم آزمایش کنید، نه فقط موفقیت‌های موردانتظار را.
از ptr پرهیز کنید و exists و macroها را پیشرفته بدانید
RFC 7208 میگوید نباید از مکانیزم ptr استفاده کرد، چون کند، غیرقابلاعتماد و پرهزینه است. برای موفق کردن یک IP ناآشنا ptr اضافه نکنید. مکانیزم exists میتواند با استفاده از یک domain-spec آزمون وجود در DNS انجام دهد و macroهای SPF می‌توانند اجزای هویت و اتصال را در فیلدهای پشتیبانی‌شده گسترش دهند. این ابزارها می‌توانند مجوزدهی تفویض‌شده یا به ازای هر مشتری را بیان کنند، اما پیچیدگی، کار DNS، افشای حریم خصوصی و حالت‌های خرابی را افزایش می‌دهند. سینتکس macro قالب‌بندی دلخواه رشته نیست؛ فقط حروف، transformerها، جداکننده‌ها و بافت‌های تعریفشده معتبرند. هرگز نشانی کامل گیرندگان، اسرار یا ورودی نامحدود tenant را در کوئری‌های DNS قرار ندهید. اگر مجموعه ساده‌ای از بازه‌های IP متعلق به خودتان و includeهای مستند ارائه‌دهندگان میتواند سیاست را بیان کند، آن را ترجیح دهید. برای سیاستهای پیشرفته، پیش از production برای چند دامنه، فرستنده، خانواده IP، reverse path تهی، escape کردن macro، NXDOMAIN، timeoutها و پاسخ‌های غیرمنتظره DNS، fixtureهای قطعی بسازید.
محدودیت ده عبارت lookup در DNS را رعایت کنید
RFC 7208 پیاده‌سازی‌های SPF را در یک بررسی به ده عبارتی که باعث کوئری DNS میشوند محدود میکند، از جمله پردازش مربوط به include، a، mx، ptr، exists و redirect. includeهای تودرتو هم شمرده میشوند. این مشخصه همچنین توصیه میکند lookupهای تهی (void)، یعنی وقتی DNS پاسخ خالی یا خطای نام برمی‌گرداند، به دو محدود شوند. عبور از محدودیت‌های پردازش میتواند بهجای pass خطای دائمی ایجاد کند. گراف گسترشیافته ارزیابی را بشمارید، نه فقط عبارت‌هایی را که در رشته TXT سطح بالا دیده میشوند. یک include ارائه‌دهنده میتواند چند وابستگی تودرتو بیاورد و یک مکانیزم mx میتواند برای چند میزبان lookup نشانی ایجاد کند. از یک ارزیاب آگاه از استاندارد با fixtureهای ثبت‌شده DNS استفاده کنید، اما درخت وابستگی را خودتان هم بررسی کنید. ارائه‌دهندگان استفاده‌نشده و مکانیزمهای زائد را حذف کنید. از flatten ناامن که به‌روزرسانی‌های ارائه‌دهنده را بی‌صدا از دست میدهد پرهیز کنید. تغییرات سیاست را پایش کنید و بهجای استقرار دقیقاً در حد نهایی، برای تحولات ارائه‌دهندگان فضای اضافی lookup باقی بگذارید.
برای هر دامنه دقیقاً یک سیاست SPF منتشر کنید
RFC 7208 از رکوردهای TXT در DNS برای SPF استفاده میکند و انتخاب رکوردی را که با v=spf1 شروع میشود الزامی می‌داند. چند رکورد SPF برای یک نام مالک دقیق بهجای ترکیب مجوزها، خطای دائمی ایجاد میکند. سیاست موجود را با مالکیت هماهنگ تغییر دهید؛ فقط چون برنامه دیگری به دسترسی نیاز دارد، رکورد TXT دوم اضافه نکنید. سایر رکوردهای TXT نامرتبط می‌توانند در آن نام وجود داشته باشند، اما فقط یک سیاست SPF انتخابشده باید وجود داشته باشد. رفتار نقل‌قول‌گذاری و تقسیم رشته در کنترل‌پنل DNS را بررسی کنید، سرورهای authoritative را کوئری کنید و سپس resolverهای بازگشتی مستقل را کوئری کنید. مقدار قبلی و TTL را برای بازگشت نگه دارید. انتشار DNS آنی نیست و کش‌های منفی ممکن است باقی بمانند. تیک سبز داشبورد فقط رفتار کوئری و parser مشاهده‌شده خودش را ثابت میکند. دامنه envelope دقیق production را از هدرهای خام دریافتی و لاگ‌های ارائه‌دهنده بررسی کنید، از جمله زیردامنه‌ها و نشانی‌های برگشت که ممکن است سیاستهای جداگانه‌ای منتشر کنند.
سینتکس SPF را به DMARC مرتبط کنید، بدون اینکه آن‌ها را یکی بدانید
SPF معمولاً دامنه MAIL FROM یا هویت HELO را طبق قواعد پروتکل ارزیابی میکند. DMARC از دامنه From قابلمشاهده طبق RFC 5322 استفاده میکند و SPF را فقط زمانی بهعنوان یک مسیر می‌پذیرد که دامنه احرازهویتشده SPF با آن دامنه قابلمشاهده همراستا باشد. بنابراین return-path یک ارائه‌دهنده میتواند در SPF موفق شود اما برای DMARC ناهم‌راستا بماند. برعکس، موفقیت DKIM همراستا میتواند وقتی SPF ناموفق یا ناهم‌راستاست، DMARC را برآورده کند. نتیجه SPF، دامنه ارزیابی‌شده، IP متصل‌شونده، From قابلمشاهده، نتایج DKIM، هم‌راستایی و نتیجه DMARC را جداگانه ثبت کنید. forwarding معمولاً IP متصل‌شونده را تغییر میدهد و میتواند SPF را حتی وقتی فرستنده اصلی مجاز بوده از کار بیندازد. SPF را برای پوشش forwarderهای دلخواه گسترش ندهید. از DKIM و در صورت لزوم از سازوکارهای زنجیره احرازهویتشده و شواهد گیرنده استفاده کنید. موفقیت SPF یکپارچگی پیام، ایمنی محتوا، رضایت گیرنده، پذیرش سرور یا رسیدن به صندوق ورودی را ثابت نمی‌کند.
تغییرات را با یک گردش‌کار قطعی اعتبارسنجی کنید
پیش از ویرایش DNS، رکورد فعلی را خروجی بگیرید و هر مکانیزم یا modifier را همراه با مالک و هدف آن فهرست کنید. رکورد پیشنهادی را طبق گرامر RFC 7208 parse کنید، وابستگی‌های DNS را از snapshotهای کنترل‌شده گسترش دهید، عبارتهای ایجادکننده lookup را بشمارید و fixtureهای IPv4 و IPv6 مجاز و غیرمجاز را آزمایش کنید. رفتار include تودرتو را در حالت‌های pass، fail، neutral، softfail، خطای موقت و خطای دائمی بررسی کنید. پردازش reverse path تهی از طریق HELO، زیردامنه‌ها، return pathهای ارائه‌دهنده و منبعی را که باید به all برسد آزمایش کنید. از طریق کنترل‌های تغییر معمول منتشر کنید، DNS authoritative و بازگشتی را کوئری کنید و سپس از طریق همه جریان‌های واقعی پیام‌های کنترل‌شده ارسال کنید. Authentication-Results خام را از گیرندگان مورد اعتماد نگه دارید و با هویت‌های موردانتظار مقایسه کنید. در صورت از قلم افتادن منابع production، انتخاب چند رکورد، خطاهای محدودیت lookup، temperror گسترده یا مجوزدهی ناخواسته، تغییر را برگردانید. هرگز با ارسال ایمیل ناخواسته آزمایش نکنید.
SPF را با SendHQ راهاندازی کنید
SendHQ بهعنوان بخشی از راهاندازی هویت فرستنده، یک سیاست SPF TXT فراهم میکند. راهاندازی را در صورت سیاستهای SPF متعارض متوقف میکند و بهجای بازنویسی بی‌صدای یک سیاست نامرتبط، یک مقدار SPF ادغام‌شده پیشنهادی گزارش میدهد. دقیقاً یک سیاست SPF قابل‌انتخاب نگه دارید؛ برای جزئیات راهاندازی و تعمیر، مستندات Domains و DNS را ببینید.
پرسش‌های متداول
رکورد SPF باید با چه چیزی شروع شود؟
سیاست SPF که از TXT در DNS انتخاب میشود با v=spf1 شروع میشود و پس از آن مکانیزمهای مرتب و modifierهای اختیاری میآیند که طبق گرامر RFC از هم جدا شدهاند.
علامتهای مثبت، منفی، تیلدا و علامت سؤال در SPF چه معنایی دارند؟
اینها qualifierهای pass، fail، softfail و neutral برای یک مکانیزم منطبق هستند. اگر حذف شوند، qualifier مثبت برای آن مکانیزم فرض میشود.
آیا یک دامنه میتواند دو رکورد SPF منتشر کند؟
خیر. چند رکورد v=spf1 انتخابشده در یک دامنه دقیق، خطای دائمی SPF ایجاد میکنند؛ بهجای آن تغییرات را در یک سیاست واحد هماهنگ کنید.
محدودیت lookup در DNS برای SPF چقدر است؟
RFC 7208 هر بررسی را به ده عبارتی که باعث کوئری DNS میشوند، از جمله پردازش تودرتو، محدود میکند. گراف گسترشیافته وابستگیها را بشمارید، نه فقط عبارتهای سطح بالا را.
آیا include همان کپی کردن رکورد دیگری است؟
خیر. include یک ارزیابی تودرتوی SPF انجام میدهد و با نتیجه pass آن منطبق میشود. سایر نتایج و خطاهای DNS رفتار تعریفشده در پروتکل و ریسک عملیاتی خود را حفظ میکنند.
آیا رکورد SPF باید از ptr استفاده کند؟
برای طراحی سیاست جدید، خیر. RFC 7208 میگوید نباید از ptr استفاده کرد، چون کند، غیرقابلاعتماد و برای name serverها پرهزینه است.
آیا موفقیت SPF یعنی DMARC هم موفق است؟
نه بهطور خودکار. DMARC همچنین الزام میکند دامنه احرازهویتشده SPF با دامنه From قابلمشاهده همراستا باشد، مگر اینکه DKIM همراستا مسیر موفقیت را فراهم کند.
آیا SendHQ SPF را پیکربندی میکند؟
بله. SendHQ بهعنوان بخشی از راهاندازی هویت فرستنده، یک سیاست SPF TXT فراهم میکند و راهاندازی را در صورت سیاستهای SPF متعارض متوقف میکند.
منابع
- RFC 7208: چارچوب سیاست فرستنده (SPF) — RFC Editor
- RFC 7489: احراز هویت، گزارش‌دهی و انطباق پیام مبتنی بر دامنه (DMARC) — RFC Editor
- RFC 5321: پروتکل ساده انتقال ایمیل (SMTP) — RFC Editor