الأسماء المستعارة للنطاق عبر API وMCP

يتيح الاسم المستعار للنطاق أن يتبع نطاق واحد عناوين الاستقبال في نطاق آخر. إذا كان hello@company.example قادرا على استقبال البريد، فيمكن تسليم البريد المرسل إلى hello@brand.example إلى المكان نفسه دون إنشاء صندوق بريد أو اسم مستعار ثان وإدارته.

هذه الميزة مخصصة للاستقبال فقط. فهي لا تنشئ عنوان From، ولا تغير SMTP، ولا تتيح لأي شخص الإرسال باسم النطاق المتصل.

متى تكون مفيدة

تفيد الأسماء المستعارة للنطاق عندما تملك الشركة عدة نطاقات لعلاماتها التجارية، أو نطاقا قديما ما زال يستقبل بريد العملاء، أو نطاقات منفصلة للبلدان ينبغي أن تتشارك أسماء صناديق الوارد نفسها.

على سبيل المثال:

hello@brand.example   → hello@company.example
billing@brand.example → billing@company.example

يبقى الجزء السابق للرمز @ مطابقا تماما. وإذا لم يكن العنوان المطابق موجودا في النطاق الأساسي، فلن ينشئه TrekMail تلقائيا.

الخطط والحدود

يمكن لنطاق متصل واحد أن يتبع نطاقا أساسيا واحدا في كل مرة. ويمكن لنطاق أساسي واحد خدمة عدة نطاقات متصلة حتى الحد العادي للنطاقات في الحساب. ولا يمكن أن يكون النطاق متصلا وأساسيا في الوقت نفسه، ما يبقي التوجيه بسيطا ويمنع الحلقات.

يجب أن ينتمي النطاقان إلى الحساب نفسه، وأن يستخدما TrekMail للبريد الوارد، وأن يكونا نشطين ولديهما سجلات MX عاملة. إذا تغيرت حالة الخطة أو الحساب أو DNS لاحقا، يحتفظ TrekMail بالاتصال المحفوظ لكنه يوقف التسليم مؤقتا حتى استعادة المتطلبات.

ما يحتفظ بالأولوية

لا يعمل الاسم المستعار للنطاق إلا بعد أن يتحقق TrekMail من العناوين الدقيقة المهيأة مسبقا في النطاق المتصل. تحتفظ صناديق البريد والأسماء المستعارة وعناوين إعادة التوجيه وإعادة توجيه صندوق البريد وإعدادات catch-all الحالية بأولويتها الموثقة.

وهذا يعني أن قاعدة sales@brand.example المقصودة لا تستبدل بصمت بالعنوان sales@company.example.

REST API

تستخدم نقاط النهاية الثلاث معرّف النطاق المتصل:

تحتفظ نقطة النهاية بمسار /matching-addresses الأصلي حتى لا تتعطل عمليات التكامل الحالية. وتستخدم لوحة التحكم والوثائق المصطلح الأكثر وضوحا في المجال، وهو الاسم المستعار للنطاق.

يتطلب PUT وDELETE ترويسة Idempotency-Key. ومن الآمن تكرار الطلب الناجح نفسه باستخدام المفتاح نفسه.

ربط نطاق

PUT /api/v1/domains/42/matching-addresses
Authorization: Bearer tm_live_...
Idempotency-Key: matching-brand-company-v1
Content-Type: application/json

{
  "primary_domain_id": 7
}

قراءة النتيجة

{
  "configured": true,
  "enabled": true,
  "delivering": true,
  "status": "delivering",
  "paused_reason": null,
  "alias_domain": {
    "id": 42,
    "domain": "brand.example"
  },
  "primary_domain": {
    "id": 7,
    "domain": "company.example"
  },
  "primary_domain_restricted": false
}

يوضح configured ما إذا كان الاتصال محفوظا. ويوضح delivering ما إذا كان يعمل الآن. تحقق من الاثنين بدلا من اعتبار الصف المحفوظ دليلا على تدفق البريد.

عندما يستطيع الرمز الوصول إلى النطاق المتصل ولا يستطيع الوصول إلى النطاق الأساسي، تضبط الاستجابة primary_domain_restricted على true وتخفي هوية النطاق الأساسي. ولا تكشف أبدا نطاقا خارج قائمة السماح الخاصة بالرمز.

حالات التسليم

أدوات MCP

يتوفر سير العمل نفسه من خلال ثلاث أدوات للنطاق:

• get_domain_alias: قراءة الاتصال المحفوظ وحالة التسليم المباشرة؛
• set_domain_alias: ربط النطاق الأساسي أو تغييره؛
• remove_domain_alias: فصل الاتصال بعد confirm_remove: true.

يطبق MCP المستضاف الأذونات المعتمدة أثناء OAuth. ويمكن لمسؤول MCP المستضاف محليا طلب موافقة صريحة على إجراءات الكتابة. ويفرض كلا المسارين خطة الحساب ونطاقات الرمز وقائمة السماح للنطاق والتحقق على جانب الخادم.

تستخدم أسماء الأدوات والعناوين الموجهة للعملاء مصطلح الاسم المستعار للنطاق. وتحتفظ نقطة REST بمسارها الأصلي للتوافق.

الإزالة الآمنة وخفض الخطة

لا تؤدي إزالة الاتصال إلى حذف أي من النطاقين أو أي صندوق بريد. وتبقى صناديق البريد الدقيقة والأسماء المستعارة وعناوين إعادة التوجيه وقواعد catch-all بلا تغيير. قد تبدأ العناوين غير المطابقة التي اعتمدت على المطابقة وحدها في الارتداد، لذا راجع النطاق قبل تأكيد الإزالة.

تؤدي إزالة نطاق متصل إلى إزالة اتصاله تلقائيا. ولن يحذف TrekMail نطاقا أساسيا ما دامت نطاقات متصلة تعتمد عليه؛ افصل تلك النطاقات أولا.

بعد خفض الخطة إلى Nano، يبقى الاتصال محفوظا لكنه يتوقف عن التسليم. وتؤدي العودة إلى Starter أو خطة أعلى إلى استعادته دون إعادة إدخال النطاق الأساسي.

سجل التدقيق

يظهر كل تغيير عبر API أو MCP ضمن وكلاء الذكاء الاصطناعي وAPI ← سجل التدقيق. تسجل أحداث الربط والتغيير معرّفي النطاقين والنطاق الأساسي السابق عند انطباق ذلك والرمز المنفذ ومعرّف الطلب والوقت. وتسجل الإزالة الاتصال الذي أزيل. ولا تكتب محتويات البريد الإلكتروني أو بيانات الاعتماد في هذه الأحداث.

قائمة التحقق لاستكشاف الأخطاء

1. تأكد من أن النطاقين يظهران بالحالة نشط ويستخدمان TrekMail للبريد الوارد.
2. تحقق من سلامة سجلات MX للنطاقين.
3. تأكد من أن الحساب يستخدم Starter أو Pro أو Agency.
4. افحص configured وdelivering وstatus وpaused_reason معا.
5. تحقق مما إذا كان صندوق بريد دقيق أو اسم مستعار أو عنوان إعادة توجيه أو قاعدة catch-all يملك العنوان بالفعل.
6. راجع سجل التدقيق بحثا عن آخر عملية ربط أو تغيير أو إزالة.