صفحة هبوط · خدمة ترحيل SMTP من Google

ما الذي ينبغي أن يقيّمه فريق المنتج عند اختيار خدمة ترحيل SMTP من Google؟

اختر ترحيل SMTP في Google Workspace فقط عندما يناسب نموذجه الإداري ونموذج الهوية والحصص عبء العمل. تأكد ممن يملك نطاق Workspace وإعداد Admin console، وهل يستطيع التطبيق استخدام عنوان IP عام ثابت مسموح به أو مصادقة SMTP محمية بـ TLS، وأي مُرسِلي الظرف مسموح بهم، وكيف يُفرض TLS. احسب حدود Google الحالية لكل مستخدم ولكل عميل ولكل معاملة قبل الطرح. اختبر الأخطاء المؤقتة والدائمة، واحتفظ بردود SMTP، وصادق على المُرسِل الظاهر بـ SPF وDKIM وDMARC، وأبقِ القبول والتسليم إلى الخادم المستقبِل والوصول إلى صندوق الوارد نتائج منفصلة.

ابدأ بملاءمة عبء العمل والإدارة

خدمة ترحيل SMTP في Google مسار إداري في Google Workspace للتطبيقات والأجهزة وخوادم البريد التي ترسل عبر smtp-relay.gmail.com. قيّمها بوصفها جزءًا من حدود Workspace والأمان البريدي للمؤسسة، لا بوصفها نقطة SMTP مجهولة عامة. حدد مالك Workspace من المسؤولين الخارقين، والنطاقات في الحساب، وأنظمة المصدر، وعناوين IP العامة للخروج، وعناوين المُرسِل، وفئات الرسائل، وحجم المستلِمين في الذروة ويوميًا، وملف المرفقات، وجهة الاتصال عند الحوادث. قرّر هل عبء العمل معاملاتي أم تشغيلي داخلي أم من تأليف المستخدم أم بريد جماعي للمشتركين أم مولَّد من أجهزة. أبقِ هذه الفئات منفصلة لأن احتياجات التفويض والموافقة والمنع والتدقيق والسمعة تختلف. تأكد من أن البيئات الدنيا لا تستطيع استخدام مسارات الإنتاج أو عناوين العملاء. يستطيع الترحيل نقل رسالة مصرّح بها؛ لكنه لا يقرر هل حدث العمل مشروع، أو هل وافق المستلِم، أو هل ينبغي لحالة التطبيق اللاحقة أن تتقدم.

قارن تفويض IP بمصادقة SMTP

يتيح الإعداد الحالي من Google للمسؤولين حصر استقبال الترحيل في عناوين IP عامة محددة، أو اشتراط مصادقة SMTP عبر TLS، أو الجمع بين خيارات السياسة بحسب الإعداد الموثَّق. قد يناسب تفويض IP الثابت مراكز بيانات خاضعة للتحكم أو بوابات خروج ثابتة، لكنه يصبح هشًا خلف NAT سحابي متغير أو مناطق متعددة أو خدمات تحويل عند الفشل أو شبكات أطراف ثالثة. تحدد مصادقة SMTP حساب Workspace ونطاق الإرسال لكنها تُدخل دورة حياة بيانات الاعتماد وحالة المستخدم وتفاعلات المصادقة متعددة العوامل والسياسات، ومتطلبًا صارمًا لـ TLS. لا تستخدم أبدًا بيانات اعتماد واسعة واحدة عبر المستأجرين أو التطبيقات غير المترابطة. لكل خيار، وثّق من يستطيع إضافة IP أو حساب، وكيف تُراجع التغييرات، وكيف يُكتشف الاختراق، وكيف يُلغى الوصول، وماذا يفعل التحويل عند الفشل. أبقِ نطاقات IP المسموح بها صغيرة قدر الإمكان وتحقق من عنوان الخروج العام من بيئة التشغيل الفعلية بدلًا من نسخ عنوان داخلي.

حدد المُرسِلين المسموح بهم وهوية النطاق

يتحكم إعداد الترحيل في Admin console في المُرسِلين المسموح بهم. توثّق Google خيارات مرتبطة بمستخدمي Apps المسجلين والعناوين في النطاقات المملوكة، وخيارًا أوسع لأي عنوان يزيد التعرض لإساءة الاستخدام. اختر أضيق خيار يستطيع عبء العمل تلبيته. اجرد مُرسِل ظرف SMTP بشكل مستقل عن حقلي From وReply-To الظاهرين. تشير Google إلى أنه عندما يكون المُرسِل خارج نطاقات الحساب، فقد يؤثر SMTP AUTH أو النطاق المقدَّم في HELO أو EHLO في كيفية تحديد مُرسِل الظرف أو إعادة كتابته. لا تعتمد على إعادة الكتابة بديلًا عن نموذج مُرسِل مملوك. اشترط ربطًا معتمدًا بين التطبيق والمستأجر وفئة الرسالة ومُرسِل الظرف ونطاق From الظاهر وReturn-Path. احظر الترويسات التعسفية التي يقدمها المستخدم وحقن الأسطر الجديدة وعناوين From العابرة للمستأجرين قبل الاتصال بـ Google. اختبر توجيه الارتدادات ورسائل خارج المكتب، بما فيها مُرسِل الظرف الفارغ، دون إضعاف الإعداد بأكمله.

اشترط أمان النقل عن قصد

يوجّه دليل الترحيل الحالي من Google الأنظمة المحلية التي تدعم TLS إلى smtp-relay.gmail.com على المنفذ 587 ويوضح أن مصادقة SMTP تتطلب TLS. ويمكن لإعداد Admin أيضًا اشتراط TLS للاتصالات القادمة من الخادم المرسِل. فعّل TLS المطلوب في الإنتاج ما لم يكن هناك قيد قديم موثَّق له استثناء محدود بمدة. تحقق من اسم الخادم وسلسلة الشهادات وسياسة البروتوكول والتشفير المدعومة (cipher) وتفاوض STARTTLS وسلوك الفشل. يجب أن يفشل العميل بشكل مغلق (fail closed) إذا تعذر إنشاء TLS المطلوب؛ فالرجوع الصامت إلى النص العادي يبطل السياسة. احمِ بيانات اعتماد SMTP في مخزن أسرار مُدار وأبقِها خارج أسطر الأوامر وعناوين URL والشيفرة المصدرية والسجلات والتحليلات وتقارير الأعطال والتذاكر. يحمي TLS في النقل القفزة إلى Google، لا دورة حياة الرسالة كاملة ولا صندوق البريد. وقد يحتاج المحتوى الحساس إلى ضوابط على مستوى التطبيق وتقليل البيانات والاحتفاظ بها وقرارات تشفير منفصلة من طرف إلى طرف.

احسب الحصص الحالية قبل اختيار الترحيل

تنص وثائق إعداد ترحيل SMTP الحالية من Google على أن كل مستخدم يستطيع إرسال ما يصل إلى 10,000 رسالة وإلى ما لا يزيد على 10,000 مستلِم فريد خلال 24 ساعة، مع احتمال أن تكون حدود الفترة التجريبية أقل. كما توثّق حدًا قدره 100 مستلِم لكل معاملة SMTP وضوابط إضافية للعميل والذروة واليومية. تعامل مع هذه الأرقام على أنها سقوف موثَّقة حاليًا، لا هدفًا للسعة ولا عقدًا دائمًا. أعد فحص الصفحة الرسمية للحساب وعبء العمل قبل الإطلاق. احسب المستلِمين لا الرسائل فقط عبر To وCc وBcc وإعادة المحاولات والتوزيع (fan-out). ضع ضوابط على مستوى التطبيق للمعدّل والتزامن وعمر الطابور وعدالة المستأجرين أدنى من حدود Google. نبّه عند التسارع وعند انخفاض الهامش المتبقي. لا تستجب لحد ما بتقسيم الحركة على حسابات غير مصرّح بها أو تدوير مُرسِلي الظرف أو فتح اتصالات غير خاضعة للتحكم. قد يحتاج عبء العمل الذي يقترب باستمرار من حد Workspace مشترك إلى تقييم وسيلة نقل مخصصة الغرض.

ابنِ سير عمل إرسال دائمًا

ضع عميل SMTP خلف عامل خادم مصرّح به أو طابور. خزّن مهمة صادرة واحدة بمفتاح حدث عمل ثابت والمستأجر وفئة الرسالة وإصدار القالب والمُرسِل والمستلِمين المعتمدين وأساس الموافقة أو الضرورة وقرار المنع وسجل المحاولات. استحوذ على تلك المهمة مرة واحدة، وولّد المحتوى وتحقق منه، ثم اتصل بنقطة Google المضبوطة. حدد عدد المستلِمين لكل معاملة وحجم الرسالة وفق الحدود الحالية وسياسة المنتج. سجّل رد SMTP الكامل ورمز الحالة المحسّن والمضيف البعيد والطابع الزمني ومعرّف المحاولة دون تسجيل بيانات الاعتماد أو محتوى غير ضروري. إذا قبل الترحيل معاملة DATA، فعلّم مرحلة قبول المزوّد أو الترحيل فقط. وإذا انتهت مهلة العميل بعد إرسال البيانات وقبل رؤية الرد النهائي، فأبقِ المحاولة في حالة غير معروفة وطابِقها قبل إعادة الإرسال. لا يوفّر SMTP مفتاح عدم تكرار (idempotency key) للتطبيق، لذلك يعود التحكم في التكرار إلى طابور المنتج ونموذج الأحداث.

صنّف أخطاء الترحيل بدلًا من إعادة محاولة كل شيء

توثّق صفحة أخطاء ترحيل SMTP من Google حالات متميزة تشمل رفض الترحيل (mail relay denied)، وبيانات اعتماد ترحيل أو تعريف نطاق غير صالحة، وتجاوز الحد اليومي، وتأجيل مؤقت لحد الذروة، وكثرة المستلِمين في معاملة واحدة. سجّل الرد بدقة واربطه بفئة داخلية ضيقة. أصلح أخطاء الإعداد ونطاق المُرسِل وبيانات الاعتماد وIP والمستلِمين لكل معاملة قبل إعادة المحاولة. أوقف العمل أو أعد جدولته بعد استنفاد الحد اليومي. أعد محاولة أخطاء الذروة أو النقل المؤقتة المؤهلة بتراجع أُسّي مع jitter وحدود لعدد المحاولات وعمر الطابور. لا تعد محاولة استجابة دائمة إلى ما لا نهاية. وإذا سمّى الخطأ عنوان IP غير مسجّل، فتأكد من عنوان الخروج العام الحقيقي لبيئة التشغيل وإعداد Workspace الصحيح بدلًا من توسيع قائمة السماح. احتفظ بأعداد مجمّعة تراعي الخصوصية بحسب نظام المصدر وإصدار الإعداد ونطاق المُرسِل وفئة الحالة والوقت. نبّه عند ردود جديدة وارتفاعات المصادقة لأنها قد تدل على انحراف السياسة أو إلغاء بيانات الاعتماد أو تغيّر NAT أو إساءة استخدام.

صادق على المُرسِل بما يتجاوز الوصول إلى الترحيل

إذن استخدام ترحيل Google ليس هو نفسه مصادقة المُرسِل الموجَّهة للمستلِم. انشر سياسة SPF تفوّض مسار الإرسال الفعلي لهوية الظرف، واضبط توقيع DKIM بنطاق تتحكم فيه المؤسسة ومحاذٍ لـ DMARC، وانشر سياسة DMARC تمت مراجعتها لنطاق From الظاهر. تحقق من الرسالة الخام المستلَمة من صناديق بريد خارجية خاضعة للتحكم. سجّل نتيجة SPF ونطاقها ونتيجة DKIM ونطاق d= والمحدِّد ونطاق From الظاهر والمحاذاة ونتيجة DMARC. قد يبقى توقيع صالح تقنيًا من المزوّد أو Workspace غير محاذٍ لنطاق From مخصص. وقد تغيّر إعادة التوجيه أيضًا أدلة SPF. لا تضف سجل SPF ثانيًا ولا تضعف DMARC على مستوى المؤسسة لمجرد نجاح اختبار واحد. نسّق بين مسؤولي DNS والبريد، واحتفظ بالسجلات السابقة، واختبر الإجابات الموثوقة والتكرارية، وأطلق تغيير هوية واحدًا في كل مرة.

اشترط قابلية المراقبة ومسار خروج مختبَرًا

استخدم بحث سجل البريد في Google Admin وسجلات جهة الترحيل حيثما توفرت، لكن أبقِ سجل الإرسال الصادر المملوك للمنتج نظام القرار. راقب عمر الطابور والقبول والاستجابات المؤقتة والدائمة واستخدام الحدود وإشارات الارتداد والشكاوى والمصادقة وزمن الاستجابة بحسب فئة الرسالة ونطاق المُرسِل. قيّد الوصول وتجنّب العناوين الكاملة أو المحتوى في المقاييس الروتينية. اختبر تغييرات IP المصدر وتدوير بيانات الاعتماد وفشل TLS وتعطيل إعداد Admin وتعليق المستخدم واستنفاد الحدود وتوزيع المستلِمين وتغييرات DNS وانقطاع المزوّد. حدد تراجعًا يستطيع إيقاف الفئة المتأثرة دون إسقاط المهام الدائمة. وعند الترحيل، اعزل حقول SMTP الخاصة بالمزوّد في محوّل (adapter) واحد واحتفظ بمفاتيح أحداث العمل وحالة المنع وتفويض المُرسِل وسجل المحاولات. يجب ألا يصبح ترحيل ثانٍ تجاوزًا تلقائيًا لرفض سياسة دائم أو رفض مستلِم. يتطلب التوافق اختبارات على مستوى الحقول والأخطاء، لا مجرد تغيير اسم المضيف.

كيف ينسجم SendHQ

SendHQ هو واجهة API للبريد الإلكتروني على مستوى مساحة العمل لاتصال المنتج المتوقع، مع إرسال نطاقات موثقة وبريد وارد وقوالب مستضافة وأحداث تسليم وقوائم منع ولوحة تحكم على الويب. قارنه بترحيل Google Workspace SMTP من خلال وثائقه الحالية واختبارات مضبوطة لحدود الحساب والمستأجر وبيانات الاعتماد وتدويرها وفرض المرسِل المسموح وهويات الظرف والهويات الظاهرة وفشل TLS وحدود المستلِمين والردود المؤقتة والدائمة والنتائج الملتبسة وقوائم المنع واسترجاع الأحداث والترحيل.

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

ما اسم المضيف الذي يستخدمه Google Workspace لترحيل SMTP؟

يستخدم دليل الإعداد الحالي من Google الخادم smtp-relay.gmail.com. اختر المنفذ وسلوك TLS من التعليمات الرسمية وسياسة الأمان المفروضة في المؤسسة.

هل يمكن تقييد ترحيل SMTP في Google بحسب IP المصدر؟

نعم. يمكن لإعداد Admin أن يقبل عناوين IP عامة محددة فقط. أبقِ النطاقات ضيقة وتحقق من عنوان الخروج (egress) الفعلي لبيئة التشغيل وسلوك التحويل عند الفشل.

هل تعمل مصادقة SMTP بدون TLS على هذا الترحيل؟

يذكر الدليل الحالي من Google أن مصادقة SMTP تتطلب TLS. ينبغي لعملاء الإنتاج أن يفشلوا بشكل مغلق (fail closed) إذا لم ينجح التفاوض المطلوب على TLS أو التحقق من الشهادة.

كم مستلِمًا يمكن أن تحتوي معاملة ترحيل SMTP واحدة؟

توثّق Google حاليًا حدًا قدره 100 مستلِم لكل معاملة على smtp-relay.gmail.com. أعد فحص الصفحة الرسمية الحية لأن حدود المزوّد وظروف الحساب قد تتغير.

هل ينبغي إعادة محاولة خطأ حد الذروة في الترحيل؟

تصف Google استنفاد حد الذروة بأنه مؤقت. احتفظ بالمهمة الدائمة نفسها واستخدم تراجعًا محدودًا مع jitter وحدودًا لعدد المحاولات وعمر الطابور بدلًا من التوزيع الفوري (fan-out).

هل يعني قبول الترحيل أن المستلِم استلم الرسالة؟

لا. قبول الترحيل مرحلة نقل واحدة. أما قبول الخادم المستقبِل والارتداد اللاحق وترشيح صندوق البريد والوصول إلى صندوق الوارد وتفاعل الأشخاص فتبقى ملاحظات منفصلة.

هل يمكن أن يحل الوصول إلى ترحيل Google محل SPF وDKIM وDMARC؟

لا. تتحكم ضوابط تفويض الترحيل في استخدام خدمة Google. أما المصادقة الموجّهة للمستلِم ومحاذاة DMARC فتتطلبان هويات إرسال صحيحة وسجلات DNS وتوقيعات والتحقق من الرسالة المستلَمة.

هل تثبت هذه الصفحة أن SendHQ متوافق مع ترحيل SMTP من Google؟

لا. قارن القدرات الموثقة لـ SendHQ بمتطلبات ترحيل Google Workspace SMTP واستخدم اختبارات مضبوطة للمصادقة وTLS والحصص والأخطاء واسترجاع أحداث التسليم.

المصادر

تابع التعلّم

كيفية تقييم خدمة ترحيل SMTPقيّم خدمات ترحيل SMTP بحسب أمان الإرسال والمصادقة والطوابير وسلوك إعادة المحاولة والحدود وأحداث التسليم والمنع والعزل وملاءمة الترحيل.بروتوكول بريد SMTP: كيف ينتقل بريد التطبيقاتتعرّف كيف يشكّل إرسال SMTP والترحيل والظروف (envelopes) ورموز الاستجابة وTLS وإعادة المحاولة ومحتوى الرسالة سير عمل بريد التطبيق.منافذ SMTP 25 و465 و587: دليل عملياختر منفذ SMTP المناسب بحسب الدور ووضع TLS، ثم شخّص إخفاقات الاتصال والمصافحة والمصادقة وقبول الرسائل.كيفية تقييم خدمة قابلية تسليم البريد الإلكترونيقيّم خدمات قابلية تسليم البريد الإلكتروني بحسب النطاق والأدلة والمصادقة وحلقات الملاحظات وقوائم المنع والخصوصية وقابلية النقل والملاءمة التشغيلية.دليل تنفيذ Gmail API لفرق المنتجنفّذ الوصول إلى Gmail API بـ OAuth بأقل الصلاحيات، ومزامنة دائمة لصندوق البريد، وإرسال آمن، وإعادة محاولات محدودة، ونموذج واضح لحساب الخدمة.