إعداد Google Workspace للشركات الصغيرة: النطاق، وGmail، وDNS، والأمان، والتسليم

يبدو إعداد Google Workspace بسيطًا من الخارج: قم بشراء خطة، وإضافة نطاق، وإنشاء مستخدمين، والبدء في استخدام Gmail. في تطبيقات الأعمال الصغيرة الحقيقية، نادرًا ما يكون الخطر هو تدفق الزر. يتمثل الخطر في الملكية غير الواضحة، والوصول غير المعروف إلى DNS، وسجلات MX القديمة، وسجلات SPF المكررة، وفقدان DKIM، والاسترداد الضعيف، وكلمات المرور المشتركة، وعدم التسليم الكتابي.

هذا الدليل مخصّص للمؤسسين ومالكي العيادات والوكالات وشركات الخدمات المحلية والفرق الصغيرة التي تعمل على تقييم Google Workspace للبريد الإلكتروني للأنشطة التجارية الصغيرة على النطاق الخاص بهم، مثل [email protected]. إنه مكتوب من وجهة نظر التنفيذ: اجعل Gmail يعمل، وقم بتوثيق كل قرار مهم، واترك للمالك نظامًا يمكن دعمه لاحقًا.

من الناحية العملية، هذا هو البريد الإلكتروني للنطاق المخصص مع مسار Gmail: تمتلك Google Workspace الهوية التجارية، ويقوم DNS بتوجيه البريد الوارد إلى Gmail، وتساعد سجلات المصادقة الأنظمة المتلقية على الثقة في المجال.

تستخدم لقطات شاشة الواجهة الموجودة في هذا الدليل مجالات وهمية وعناوين وهمية ومفاتيح مقنعة. وقد تم تضمينها لإظهار نمط التنفيذ، وليس لتوفير قيم خاصة بالحساب قابلة لإعادة الاستخدام.

قائمة التحقق من إعداد Google Workspace للأنشطة التجارية الصغيرة

تستخدم إرشادات إعداد Workspace MX الحالية من Google smtp.google.com كقيمة سجل MX وتلاحظ أن التعرف على تغييرات سجل MX قد يستغرق ما يصل إلى 72 ساعة. تعامل مع هذه النافذة على محمل الجد: لا يكتمل الإعداد حتى تمر الاختبارات الواردة والصادرة الحقيقية بعد تغيير DNS. راجع دليل إعداد MX من Google هنا: إعداد سجلات MX لـ Google Workspace.

بالنسبة للشركات الصغيرة، يجب تنظيم القائمة المرجعية حول النتائج:

المرحلة الأولى: تأكيد ملكية النطاق وDNS

تبدأ معظم عمليات إعداد البريد الإلكتروني السيئة بنفس الجملة: "النطاق مع شخص آخر، ولكن لا يزال بإمكاننا المتابعة".

في بعض الأحيان، يتم شراء النطاق بواسطة مستقل قديم. في بعض الأحيان يكون DNS داخل حساب استضافة لم يقم أحد بتسجيل الدخول إليه لسنوات. في بعض الأحيان يكون لدى صاحب العمل حق الوصول إلى GoDaddy، لكن DNS الفعلي موجود في Cloudflare. في بعض الأحيان يكون لدى بائع موقع الويب النطاق، ويكون لدى المالك كلمة مرور Gmail فقط. إذا قمت بتغيير سجلات البريد الإلكتروني دون التأكد أولاً من مضيف DNS النشط ومسار المالك، فيمكنك جعل البريد يعمل مؤقتًا مع جعل العمل يعتمد على الشخص الخطأ.

قبل لمس مسؤول Google أو DNS، أجب عن هذه الأسئلة:

إذا كانت هناك أية إجابة غير واضحة، فتوقف وحل المشكلة أولاً. إنه أسرع من إعادة بناء الوصول إلى البريد الإلكتروني بعد الإغلاق العرضي.

قم بتعيين حالة البريد الإلكتروني الحالية

لا تفترض أن الشركة ليس لديها بريد إلكتروني موجود لمجرد أنه لا أحد يستخدم صندوق بريد احترافي. تحقق من DNS الحالي والإعداد التشغيلي.

ابحث عن:

• سجلات MX الموجودة.
• سجلات SPF TXT الموجودة.
• سجلات DKIM TXT من مزود آخر.
• _dmarc سجل TXT.
• نماذج الاتصال بموقع الويب التي يتم إرسالها من المجال.
• برنامج الفوترة الذي يرسل الفواتير عبر البريد الإلكتروني.
• إدارة علاقات العملاء (CRM) أو مكتب الدعم أو أدوات التسويق.
• معيدي التوجيه مثل info@، sales@، support@، والأسماء المستعارة الشخصية.

وهذا مهم لأن نظام التعرف على هوية المرسل (SPF) يجب أن يكون عادةً سجل سياسة واحد للنطاق، وليس عدة سجلات TXT متنافسة. إذا كان النشاط التجاري يستخدم Google Workspace بالإضافة إلى موفر نماذج مواقع الويب بالإضافة إلى أداة الفوترة، فإن سياسة نظام التعرف على هوية المرسل (SPF) النهائية تحتاج إلى مراعاة المرسلين الشرعيين. تعتمد القيمة الدقيقة على مخزون المرسل الحالي.

المرحلة الثانية: تحديد المستخدمين والأسماء المستعارة والمجموعات وصناديق البريد الوارد المشتركة

غالبًا ما تفرط الفرق الصغيرة في إنشاء صناديق البريد. قد تطلب شركة مكونة من خمسة أشخاص info@، sales@، billing@، support@، careers@، وصناديق البريد الشخصية للجميع. بعض هؤلاء يجب أن يكونوا مستخدمين مدفوعي الأجر. يمكن أن يكون بعضها أسماء مستعارة. يجب أن يكون بعضها عبارة عن مجموعات Google أو صناديق بريد وارد تعاونية. بعضها لا ينبغي أن يكون موجودًا بعد.

استخدم نموذج القرار هذا:

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

المرحلة 3: التحقق من النطاق والتخطيط لسجلات MX في Gmail

يجب إنشاء حساب المشرف الأول بعناية داخل وحدة تحكم مشرف Google Workspace. استخدم بريدًا إلكترونيًا ورقم هاتف مخصصين للاسترداد يتحكم فيهما المالك. إذا ساعد Shinka أو شريك تنفيذ آخر في الإعداد، فيجب أن يكون وصول الشريك مؤقتًا أو موثقًا؛ يجب أن يبقى المشرف المتميز النهائي مع العميل.

أثناء التحقق من نطاق Google Workspace، توفر Google سجل نظام أسماء النطاقات (DNS) أو طريقة أخرى للتحقق. انشر فقط ما تطلبه Google حاليًا داخل وحدة تحكم المشرف، لأن طرق التحقق يمكن أن تتغير. بعد نجاح التحقق، احتفظ بملاحظة:

• نوع سجل التحقق وقيمته.
• مضيف DNS حيث تمت إضافته.
• التاريخ والشخص الذي وافق على التغيير.
• حساب المسؤول المستخدم للإعداد.
• استرداد البريد الإلكتروني ومالك الهاتف.

هذه ليست بيروقراطية. فهو يمنع مشكلة الدعم الشائعة حيث لا أحد يعرف ما إذا كان DNS موجودًا لدى المسجل أو موفر الاستضافة أو Cloudflare أو بائع آخر.

تحدد سجلات MX مكان تسليم البريد الإلكتروني الوارد للنطاق. عند الانتقال إلى Gmail، يجب استبدال سجلات MX لموفر البريد القديم أو إلغاء أولوياتها وفقًا لتعليمات Google Workspace.

بالنسبة للشركات الصغيرة، لا تتعامل مع هذا الأمر باعتباره مهمة نسخ ولصق غير رسمية. التخطيط لنافذة تغيير صغيرة:

1. تصدير أو لقطة شاشة لسجلات DNS الحالية.
2. تحديد سجلات مزود البريد القديم.
3. تأكد من التحقق من نطاق Google Workspace.
4. قم بإنشاء مستخدمين قبل تبديل البريد المباشر.
5. انشر سجل Google Workspace MX.
6. الاختبار من مرسلين خارجيين، وليس من Gmail فقط.
7. مراقبة البريد المتأخر أثناء نافذة التعرف على DNS.

يدرج دليل إعداد MX الحالي من Google smtp.google.com كقيمة Google Workspace MX. إذا كان موفر النطاق الخاص بك لديه عملية إعداد Google Workspace تلقائية، فلا يزال يتعين عليك مراجعة سجلات نظام أسماء النطاقات النهائية يدويًا. يمكن أن تكون التدفقات التلقائية مفيدة، ولكنها لا تفهم دائمًا المزود القديم أو نماذج موقع الويب أو أدوات الإرسال الأخرى.

المرحلة 4: إعداد SPF وDKIM وDMARC

يخبر نظام التعرف على هوية المرسل (SPF) أنظمة البريد المتلقية بالخوادم المسموح لها بإرسال البريد للمجال. تستخدم إرشادات إعداد نظام التعرف على هوية المرسل (SPF) من Google Workspace بشكل شائع ما يلي:

v=spf1 include:_spf.google.com ~all

راجع صفحة مساعدة نظام التعرف على هوية المرسل (SPF) من Google: إعداد نظام التعرف على هوية المرسل (SPF).

الخطأ هو إضافة هذا كسجل SPF ثانٍ عندما يكون موجودًا بالفعل. يجب ألا يحتوي النطاق على عدة سياسات متنافسة لنظام التعرف على هوية المرسل (SPF). إذا كانت الشركة ترسل بالفعل عبر موقع ويب، أو إدارة علاقات العملاء، أو منصة الفواتير، أو خدمة البريد الإلكتروني للمعاملات، أو أداة التسويق، فيجب دمج سياسة نظام التعرف على هوية المرسل (SPF) النهائية بعناية.

أمثلة على المرسلين الشرعيين الذين قد يحتاجون إلى المراجعة:

• نماذج الاتصال بالموقع.
• تذكير بالمواعيد.
• تسلسلات إدارة علاقات العملاء (CRM).
• الفواتير وروابط الدفع.
• إخطارات مكتب الدعم.
• منصات بوابة الرسائل القصيرة/البريد الإلكتروني.
• أدوات النشرة الإخبارية.

إذا قمت بتضمين Google فقط ونسيت مرسل نموذج موقع الويب، فقد يعمل Gmail بينما تبدأ نماذج الاتصال بموقع الويب في فشل المصادقة. إذا قمت بتضمين عدد كبير جدًا من آليات الجهات الخارجية دون مراجعة، فقد تصبح سياسة نظام التعرف على هوية المرسل (SPF) هشة. النهج الصحيح هو جرد المرسل أولاً، وسياسة DNS ثانيًا.

يقوم DKIM بتوقيع البريد الإلكتروني الصادر حتى تتمكن أنظمة الاستلام من التحقق من أن الرسائل مرخصة بواسطة نطاقك ولم يتم تغييرها أثناء النقل. بالنسبة إلى Google Workspace، يتضمن إعداد DKIM عادةً إنشاء سجل DKIM في وحدة تحكم المشرف في Google، ونشر سجل TXT المقدم في نظام أسماء النطاقات، وانتظار رؤية نظام أسماء النطاقات، ثم تشغيل المصادقة.

دليل DKIM من Google موجود هنا: إعداد DKIM.

في أعمال التنفيذ، يفشل DKIM لثلاثة أسباب عملية:

• تتم إضافة سجل TXT إلى مضيف DNS الخاطئ.
• تم لصق المحدد/الاسم بشكل غير صحيح.
• يحاول شخص ما تنشيط DKIM قبل نشر DNS.

قم بتوثيق المحدد وقيمة DNS. لا تقم بلصق الملاحظات الخاصة في الوثائق العامة، ولكن احتفظ بسجل التنفيذ في حزمة التسليم. بعد التنشيط، أرسل بريدًا إلكترونيًا حقيقيًا إلى صندوق بريد خارجي وافحص رؤوس الرسائل بحثًا عن نتيجة تمرير DKIM.

يخبر DMARC أنظمة الاستقبال بما يجب فعله عندما تفشل الرسائل في محاذاة نظام التعرف على هوية المرسل (SPF) أو DKIM. ويمكنه أيضًا إرسال تقارير تساعدك على فهم من يرسل البريد لنطاقك. دليل DMARC من Google موجود هنا: إعداد DMARC.

بالنسبة لمعظم الشركات الصغيرة، الموقف الأول الصحيح ليس "رفض كل شيء اليوم". ابدأ بالمراقبة، وافهم مصادر الإرسال الشرعية، ثم قم بتشديد السياسة عندما تكون لديك الثقة.

قد يبدو سجل البداية العملي كما يلي:

v=DMARC1; p=none; rua=mailto:[email protected]

استخدم صندوق بريد التقارير الخاص بك، وليس example.com. سياسة p=none مخصصة للمراقبة؛ لا يفرض الحجر الصحي أو الرفض. يجب أن تأتي السياسات الأقوى بعد التأكد من مصادقة Google Workspace ونماذج مواقع الويب وإدارة علاقات العملاء (CRM) والفواتير وأدوات التسويق بشكل صحيح.

المرحلة الخامسة: تأمين مساحة العمل واختبارها وتسليمها

عادةً ما يكون البريد الإلكتروني هو الحساب الأكثر أهمية في الشركات الصغيرة لأنه يتحكم في عمليات إعادة تعيين كلمة المرور والفواتير ومحادثات العملاء والوصول إلى المجال والملفات الداخلية. يجب أن يشتمل إعداد Google Workspace على تصريح أمان أساسي، وليس فقط إنشاء صندوق البريد.

الحد الأدنى من خط الأساس العملي:

• خطة التحقق بخطوتين للمستخدمين المالكين والمشرفين.
• يتم التحكم في البريد الإلكتروني والهاتف المخصصين للاسترداد من قبل صاحب العمل.
• مساران على الأقل لاسترداد المسؤول معتمدين من المالك.
• لا توجد كلمة مرور مشتركة للمشرف المتميز في تطبيق WhatsApp للموظفين أو ملاحظات المتصفح.
• افصل المستخدمين الشخصيين عن عناوين الفريق المشتركة.
• مراجعة قواعد الشحن الخارجية.
• قائمة التحقق من مغادرة الموظفين.
• وثائق دور المسؤول.

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

يمكن للوحات الإدارة أن تقول إن الإعداد قد اكتمل بينما لا يزال المستخدمون يواجهون إخفاقات عملية. اختبار النظام من الخارج.

إذا كان البريد الوارد يعمل فقط عند اختباره من حساب Gmail واحد، فإن الاختبار غير مكتمل. استخدم ما لا يقل عن اثنين من مقدمي الخدمات الخارجيين وجهاز محمول واحد.

الفرق بين الإعداد السريع والإعداد الاحترافي هو التسليم. يجب أن تحصل الشركات الصغيرة على دليل تشغيل قصير وسهل القراءة يجيب على أسئلة الدعم المستقبلية.

ينبغي أن تشمل عملية التسليم ما يلي:

• حساب المشرف الأساسي في Google Workspace.
• استرداد البريد الإلكتروني ومالك الهاتف.
• مسجل المجال ومضيف DNS.
• تغيرت سجلات DNS.
• أنشأ المستخدمون.
• الأسماء المستعارة والمجموعات التي تم إنشاؤها.
• حالة SPF وDKIM وDMARC.
• تم الانتهاء من الاختبارات.
• نوافذ الانتظار المعروفة أو ملاحظات النشر المعلقة.
• كيفية إضافة مستخدم جديد.
• كيفية إزالة الموظف.
• بمن يجب الاتصال للحصول على الدعم.

لا يلزم أن تكون هذه الوثيقة طويلة. يجب أن تكون دقيقة. إذا لم يتمكن صاحب العمل من فهم ذلك، فهذا يعني أن التنفيذ لم يكتمل.

الأخطاء الشائعة التي تجعل إعداد Google Workspace أمرًا مؤلمًا

ما يعالج شينكا

تم تصميم خدمة إعداد Google Workspace من Shinka للشركات الصغيرة التي تريد أن يعمل البريد الإلكتروني الخاص بالعمل بشكل صحيح دون التخمين من خلال إعدادات DNS وإعدادات المسؤول.

يمكن أن تغطي الخدمة:

• مراجعة الوصول إلى المجال وDNS.
• إعداد حساب Google Workspace.
• المستخدم والاسم المستعار والتخطيط الجماعي.
• إعداد سجل Gmail MX.
• دعم إعداد SPF وDKIM وDMARC.
• اختبار البريد الوارد والصادر.
• فحوصات الأمان الأساسية للمسؤول.
• إرشادات تسجيل الدخول عبر الهاتف المحمول والمتصفح.
• مراجعة مرسل موقع الويب/نموذج الاتصال عند الاقتضاء.
• تسليم دفتر التشغيل للمالك.

نحن لا ندعي ضمان إمكانية التسليم أو وضع البريد الوارد أو سلوك كل خادم مستلم. تعتمد أنظمة البريد الإلكتروني على سجل المجال، وسلوك المرسل، ونشر DNS، وأدوات الطرف الثالث، وسياسات المستلمين، والصيانة المستمرة. الوعد العملي هو الانضباط في التنفيذ: الوصول الواضح، والسجلات الصحيحة، والاختبار، وتسليم المالك.

الأسئلة الشائعة