# Microsoft 365 > Microsoft 365 عبر Microsoft Graph: النطاقات وDNS وصناديق البريد المرخّصة والحدود. يدير بريد Microsoft 365 لنطاق ما عبر Microsoft Graph: تسجيل النطاق والتحقق منه، ونشر سجلات DNS التي تتطلبها الخدمة، وإنشاء صناديق البريد كمستخدمين مرخّصين. هذه الصفحة صريحة على غير العادة بشأن الحدود، لأن ثلاثة أشياء يتوقعها الناس لا يمكن الوصول إليها عبر Graph أصلًا. يرفضها mailctl بدل قبولها وعدم فعل شيء. ## ما يستطيع Graph فعله وما لا يستطيع **جدول 1. مدعوم** | القدرة | نقطة النهاية | | --- | --- | | إضافة نطاق إلى المستأجر | `POST /domains` | | قراءة سجل الملكية | `GET /domains/{id}/verificationDnsRecords` | | التحقق من الملكية | `POST /domains/{id}/verify` | | التصريح بخدمات النطاق | `PATCH /domains/{id}` | | قراءة سجلات DNS المطلوبة | `GET /domains/{id}/serviceConfigurationRecords` | | سرد مستخدمي النطاق | `GET /domains/{id}/domainNameReferences/microsoft.graph.user` | | إنشاء مستخدم | `POST /users` | | تعيين ترخيص | `POST /users/{id}/assignLicense` | | قراءة مخزون التراخيص | `GET /subscribedSkus` |

جدول 2. غير مدعوم، ولماذا
الأسماء البديلة	يوثّق Graph الحقل `proxyAddresses` على أنه للقراءة فقط، ولا يُحدَّث إلا عبر مركز إدارة Microsoft 365. العنوان الأساسي وحده قابل للكتابة. وجود كتلة `aliases` على نطاق `ms365` خطأ تحقق.
الالتقاط الشامل	يتطلب قاعدة نقل في Exchange، ولا واجهة لها في Graph. وجود كتلة `catchAll` خطأ تحقق.
تفعيل DKIM	لا يمكن استنتاج أهداف CNAME، فالصيغة الحالية تتضمن حرف تقسيم خاصًا بكل مستأجر. وتقول وثائق Microsoft نفسها إن القيم المنشورة للتوضيح فقط، ويجب قراءتها من بوابة Defender أو من Exchange Online PowerShell.

كان بإمكان mailctl استدعاء PowerShell من أجل DKIM. لكنه لا يفعل، لأن ذلك سيجعل `pwsh` ووحدة Exchange متطلبات تشغيل إلزامية لملف تنفيذي له اعتمادية واحدة فقط فيما عدا ذلك. ## الإعداد ### 1\. سجّل تطبيقًا في Microsoft Entra، سجّل تطبيقًا وامنحه صلاحيات **تطبيق** بموافقة المسؤول: - `Domain.ReadWrite.All` - `User.ReadWrite.All` - `Organization.Read.All` ثم صدّر القيم الثلاث: ```properties MS365_TENANT_ID=... MS365_CLIENT_ID=... MS365_CLIENT_SECRET=... ``` ### 2\. اضبط النطاق ```yaml domains: - name: example.com mail: provider: ms365 ms365: license: BUSINESS_BASIC usageLocation: DE dkimCnames: - selector1-example-com._domainkey.contoso.n-v1.dkim.mail.microsoft - selector2-example-com._domainkey.contoso.n-v1.dkim.mail.microsoft mailboxes: - address: a.person@example.com displayName: A Person ```

license

قيمة skuPartNumber مثل BUSINESS_BASIC، لا معرّف skuId بصيغة GUID. رقم الجزء ثابت وظاهر في مركز الإدارة؛ أما GUID فليس كذلك. يُحلَّل مقابل /subscribedSkus.

usageLocation

رمز من حرفين وفق ISO 3166-1 alpha-2. لا يعيّن Graph ترخيصًا دونه، لذا يطلبه mailctl مقدّمًا بدل أن يفشل وقت التطبيق.

dkimCnames

اختياري. الهدفان المنسوخان مرة واحدة من بوابة Defender، لـ selector1 وselector2 بهذا الترتيب. إن أُعطيهما، ينشر mailctl سجلَّي CNAME ويدقّقهما كأي سجل آخر. احذفهما فيبقى DKIM خارج mailctl.

### 3\. طبّق مرتين يُتوقَّع أن يفعل التطبيق الأول أقل مما قد تظن، وهذا مقصود في التصميم وليس خللًا. لا توجد `verificationDnsRecords` و`serviceConfigurationRecords` حتى يُضاف النطاق إلى المستأجر، وقراءة الحالة يجب ألا تغيّر شيئًا أبدًا. فيكون التسلسل: 1. التطبيق الأول: يضيف النطاق إلى المستأجر. لا يُعرف في هذه المرحلة إلا سجلات DKIM، إن كانت مُعَدّة. 2. التطبيق الثاني: صارت سجلات الملكية والخدمة قابلة للقراءة، فيُنشر DNS ويُتحقق من النطاق. 3. التطبيق الثالث: تُنشأ صناديق البريد، بعد التحقق من النطاق. يقول `mailctl plan` ذلك صراحة في كل مرحلة، بدل أن يتركك تخمّن سبب غياب DNS. ## صناديق البريد مستخدمون مرخّصون في Microsoft 365 لا يكون صندوق البريد كائنًا مستقلًا: إنه مستخدم له ترخيص. وإنشاء واحد يستهلك مقعدًا مدفوعًا. لذلك يفحص mailctl المقاعد وقت **التخطيط**، فيقرأ `/subscribedSkus` ويرفض مقدّمًا إن كانت عمليات الإنشاء ستتجاوز المتاح: ```console creating mailboxes needs 3 BUSINESS_BASIC seat(s) but only 2 are free; buy more seats or free some, then rerun ``` اكتشاف ذلك في منتصف التطبيق سيترك بعض الصناديق منشأة وبعضها لا. ### ثلاث حالات لا حالتان يمكن أن يكون الصندوق غائبًا، أو موجودًا دون ترخيص، أو موجودًا ومرخّصًا. توجد الحالة الوسطى لأن إنشاء صندوق يتطلب استدعاءين: إنشاء المستخدم، ثم تعيين الترخيص، وقد يفشل الثاني وحده. يتعامل mailctl معها صراحة:

غائب

أنشئ المستخدم وعيّن الترخيص.

موجود دون ترخيص مطابق

عيّن الترخيص فقط. يُترك المستخدم كما هو.

موجود ومرخّص

لا شيء لفعله.

دون تلك الحالة الوسطى، سيترك فشل الترخيص حسابًا موجودًا يحمل كلمة سر مولّدة ولا صندوق بريد له، بينما تبلّغ كل خطة لاحقة بأنه لا شيء لفعله. ### كلمات سر لمرة واحدة يحصل المستخدم المنشأ على `forceChangePasswordNextSignIn`، فتكون بيانات الاعتماد التي يولّدها mailctl لاستخدام واحد فعلًا: تسلّمها، فيستبدلها المستلم عند أول تسجيل دخول. ## الحذف صعب عمدًا حذف مستخدم في Microsoft 365 يتلف بريد ذلك الشخص، ويمكن استرداده خلال 30 يومًا. لذا يتطلب الحذف `-prune` **و**`-prune-mailboxes`، ثم يطلب منك سؤال التأكيد كتابة اسم النطاق. صناديق البريد غير المُدارة، أي الموجودة في المستأجر والغائبة عن إعدادك، يُبلَّغ عنها في كل `plan` سواء مرّرت تلك الخيارات أم لا، فتعرف بالانحراف دون اللجوء إلى الخيار المُتلِف. يحدد الحذف المستخدمين بمعرّف كائن Graph، لا بعنوان البريد أبدًا. فـ Graph يحلّ `/users/{...}` بالمعرّف أو بـ `userPrincipalName` فقط، والحذف بالعنوان قد يخطئ الهدف، أو يطابق مستخدمًا آخر صادف أن UPN الخاص به يساويه. ## النطاقات الموحّدة يدير mailctl النطاقات المُدارة. إن كان `authenticationType` لنطاق ما هو `Federated`، يبلّغ `plan` بملاحظة: مستخدموه يصادقون في مكان آخر، فإدارة المستخدمين هنا ليست الصورة كاملة.