mailctlDocumentation PDF GitHub

قابلية التسليم

SPF وDKIM وDMARC وMTA-STS وTLS-RPT وBIMI مع mailctl، وترتيب تفعيلها.

.md

خمسة أنواع من السجلات تقرر هل يُقبل بريدك وهل يستطيع أحد تزويره. ينشرها mailctl كلها من كتلة واحدة، ويفرض القواعد التي يسهل الخطأ فيها يدويًا.

SPF: سجل واحد بالضبط

يسمح RFC 7208 بسجل SPF واحد بالضبط من نوع TXT لكل اسم. سجلان ليسا "تغطية أوسع"، بل خطأ دائم يعامله بعض المستقبِلين كفشل قاطع.

لهذا لا ينشر أي مزوّد سجل SPF الخاص به مباشرة. يقدّم كل منهم متطلبه، ويدمجها mailctl:

deliverability:
  spfIncludes:
    - include:servers.mailgun.org

مع Purelymail للوارد وذلك التضمين الإضافي، يكون السجل المنشور سجل TXT واحدًا:

v=spf1 include:_spf.purelymail.com include:servers.mailgun.org ~all

قاعدتان يفرضهما الدمج:

  • الأشد يفوز. إن طلب أي مُدخل -all، فالنتيجة -all. تخفيف السياسة بصمت هو الخطأ الأسوأ.

  • المدخلات آليات مفردة. بلا مسافات، وبلا محدِّد all، وبلا redirect=. يُرفض مدخل spfIncludes الذي قد يتجاوز محدِّد السجل، لأن الغاية من الدمج كلها أن يتحكم mailctl في النتيجة.

ويرفض mailctl أيضًا الآلية المشوّهة مباشرة: include: بلا قيمة، أو include بلا نقطتين. كلاهما ينتج سجلًا يبدو مضبوطًا ولا يفشل إلا على خوادم الآخرين المستقبِلة، وهذا أسوأ أنواع العطب.

DMARC

deliverability:
  dmarc:
    policy: quarantine        # none | quarantine | reject
    subdomainPolicy: reject
    pct: 100
    rua: mailto:dmarc@example.com

ابدأ بـ none مع عنوان rua، واقرأ التقارير أسبوعًا أو اثنين، ثم انتقل فقط بعدها إلى quarantine ثم reject. الانتقال مباشرة إلى reject على نطاق لم تحصر مرسليه بعد يتخلّص بصمت من بريد مشروع.

ضبط dmarc يجعل mailctl مالك الاسم _dmarc. والمزوّدون الذين كانوا سينشرون CNAME خاصًا بهم لـ _dmarc يتنحّون، فلا يتنافس الاثنان أبدًا.

MTA-STS

يخبر MTA-STS خوادم الإرسال بأن تشترط TLS لنطاقك. ويحتاج إلى سجل TXT *و*ملف سياسة يُقدَّم عبر HTTPS على عنوان معروف.

deliverability:
  mtaSts:
    mode: testing             # none | testing | enforce
    maxAge: 604800
    deploy: true

يجعل deploy: true mailctl يولّد ويرفع Cloudflare Worker يقدّم السياسة، ويربطه بـ mta-sts.<domain>. لا حاجة إلى أدوات Node ولا إلى تثبيت Wrangler، فالـ Worker يُولَّد ويُرفع مباشرة.

ابدأ بـ testing وراقب تقارير TLS-RPT أسبوعًا. في وضع enforce يصير MX المضبوط خطأً بريدًا لا يُسلَّم دون أي تحذير، إذ يرفض المرسلون التسليم بدل التراجع.

يُشتق معرّف السياسة من محتواها، فتحتفظ السياسة غير المتغيرة بمعرّفها وتحصل المعدّلة على معرّف جديد تلقائيًا. ويسحب mode: none السياسة بدل أن يكون بلا أثر.

TLS-RPT

deliverability:
  tlsRpt: mailto:tls-reports@example.com

يطلب من المستقبِلين الإبلاغ عن إخفاقات تسليم TLS. يستحق التفعيل قبل MTA-STS، لتكون التقارير جاهزة والسياسة في وضع testing. يجب أن يبدأ كل عنوان مفصول بفاصلة بـ mailto: أو https:.

BIMI

deliverability:
  bimi:
    logo: https://example.com/logo.svg

ينشر سجل BIMI الذي يشير إلى شعارك. لاحظ أن معظم المستقبِلين يشترطون أيضًا شهادة علامة موثّقة (VMC) وسياسة DMARC بقيمة quarantine أو reject قبل عرضه، فلا يُرجَّح أن يُظهر BIMI وحده شيئًا.

ترتيب معقول

  1. شغّل البريد: MX وSPF وDKIM. تأكّد بـ mailctl audit.

  2. أضف DMARC بـ policy: none مع عنوان rua.

  3. أضف tlsRpt.

  4. اقرأ التقارير. أصلح ما تكشفه.

  5. انقل DMARC إلى quarantine، ثم reject.

  6. أضف MTA-STS بـ mode: testing.

  7. بعد أسبوع هادئ، انقل MTA-STS إلى enforce.

كل خطوة قابلة للتراجع حتى الخطوتين الأخيرتين، ولهذا بالضبط تأتيان في النهاية.

عدّل هذه الصفحة آخر تحديث

اختصارات لوحة المفاتيح

Ctrl/⌘ K أو /
ابحث في التوثيق
↑ ↓ Enter
تنقّل بين نتائج البحث
→ ←
الصفحة السابقة أو التالية
g h
الصفحة الرئيسية
t
بدّل المظهر
?
هذه القائمة
Esc
أغلق القائمة أو نتائج البحث