كيفية استضافة نشرتك البريدية ذاتياً باستخدام Listmonk

عند الاستضافة الذاتية، يعمل Listmonk على VPS تدفع تكلفته بالفعل. أما الإرسال فيكلّفك ما يفرضه مُرحِّل SMTP لكل ألف رسالة. وعدد المشتركين لا يُغيّر أياً من الرقمين. هذا هو التحوّل البنيوي الذي يجعل الاستضافة الذاتية جديرة بوقت الإعداد بمجرد أن تتجاوز الباقة المجانية المُدارة.

Listmonk هو مدير نشرات بريدية مفتوح المصدر ومكتوب بلغة Go. تحصل على عدد غير محدود من المشتركين والقوائم والحملات مقابل تكلفة VPS بالإضافة إلى حساب مُرحِّل SMTP. لكن يجب أن يكون أمر واحد واضحاً قبل أن تكتب أي سطر: يتولّى Listmonk كل شيء عدا عملية الإرسال الفعلية. أما وصول بريدك إلى صندوق الوارد أو إلى مجلد الرسائل غير المرغوب فيها فيُحدِّده مُرحِّل SMTP الذي تُعدّه وسجلات DNS التي تضبطها على نطاق الإرسال.

ما الذي يغطّيه هذا الدليل

• نشر Listmonk وPostgreSQL باستخدام Docker Compose خلف وكيل عكسي Nginx (أو Caddy) مع HTTPS
• اختيار مُرحِّل SMTP المناسب لحجم إرسالك وميزانيتك (Amazon SES أو Postmark أو Brevo أو غيرها)
• ضبط سجلات SPF وDKIM وDMARC على نطاق الإرسال
• تجنّب أربعة أنماط أعطال إنتاجية كثيراً ما لا تُظهر أخطاءً واضحة
• الوقت التقديري: ٣٠ دقيقة إذا كان لديك VPS ونطاق جاهزان
• خارج النطاق: أتمتة التنقيط، والبريد المعاملاتي، وإعدادات النُسخ المتعددة (راجع الأسئلة الشائعة)

متى يكون Listmonk هو الأداة الخاطئة

Listmonk هو الجواب الصحيح لحالة محددة. وإذا كانت حالتك مختلفة، فهناك جواب أفضل.

حجم إرسال أقل من ١٠ آلاف رسالة شهرياً تقريباً. قد تكلّفك الباقات المجانية المُدارة لدى Brevo أو Mailchimp أقل إجمالاً من VPS بالإضافة إلى مُرحِّل SMTP عند هذا الحجم. فالاستضافة الذاتية تبدأ تؤتي ثمارها بمجرد أن تتجاوز هذا النطاق. تحقّق من الأرقام مقابل عدد مشتركيك الفعلي ووتيرة إرسالك قبل النشر.

فريق غير تقني. يقدّم Mailchimp وBrevo واجهات استخدام أفضل فعلاً لمن لا يعملون في الطرفية. أما Listmonk فيفترض أن هناك في الفريق من يستطيع الاتصال عبر SSH بخادم، وقراءة سجلات Docker، وتفسير انتشار DNS. وإذا لم يوجد هذا الشخص، فإن الخدمات المُدارة هي الخيار الصحيح.

الحاجة إلى مسارات أتمتة. يُرسل Listmonk الحملات. لكنه لا يدعم تسلسلات التنقيط، ولا الرسائل المُفعَّلة بالسلوك، ولا أدوات بناء المسارات المرئية. إذا كنت بحاجة إلى ذلك، فشغّل Mautic أو اربط Listmonk بـ n8n لطبقة الأتمتة.

قوائم مشتركين حسّاسة وفق GDPR. إذا كان مشتركوك في الاتحاد الأوروبي بشكل أساسي أو كانت قائمتك خاضعة لقواعد إقامة البيانات في GDPR، فشغّل Listmonk في مركز بيانات أوروبي. نحن نوفّر موقعَي فرانكفورت ولندن اللذين يلبّيان متطلبات الإقامة في الاتحاد الأوروبي.

ما الذي تحتاجه قبل أن تبدأ

يحتاج Listmonk إلى جانب PostgreSQL مع حِمل طابور معتدل إلى ٢ GB من RAM كحدّ أدنى. أما ٤ GB فهو الهدف المريح للإنتاج.

العتاد. لقائمة شخصية أقل من ٥٠ ألف رسالة شهرياً، يكفي VPS بمعالجَين افتراضيين، و٤ GB من RAM، و١٢٠ GB من تخزين NVMe. أما القوائم المتنامية التي تتجاوز ٢٠٠ ألف رسالة شهرياً فتحتاج إلى ٤ معالجات افتراضية و٨ GB من RAM. نحن نُشغّل إعداد Compose هذا على VPS بسعة ٤ GB في فرانكفورت. اختر موقعاً قريباً من مشتركيك إن استطعت. زمن انتقال الإرسال لا يهمّ كثيراً، لكن استجابة لوحة الإدارة تهمّ.

النطاق. نطاق يشير إلى VPS الخاص بك عبر سجل A. استخدم نطاقاً فرعياً لواجهة الإدارة، على سبيل المثال mail.example.com. يمكن أن يكون نطاق الإرسال والنطاق الفرعي للإدارة هما نفس النطاق الجذري.

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

البرمجيات على VPS. Ubuntu 22.04 LTS أو 24.04 LTS. وDocker Engine 24.0 أو أحدث مع إضافة Docker Compose. وUFW أو جدار حماية مكافئ مع فتح المنافذ 22 و80 و443. والوصول عبر SSH كمستخدم sudo غير جذري.

نشر Listmonk باستخدام Docker Compose

أنشئ مجلداً للنشر، ثم ضع docker-compose.yml ملفاً يحتوي على خدمتين: postgres لقاعدة البيانات وlistmonk للتطبيق. كلتاهما تُعيد التشغيل عند الفشل. يرتبط Listmonk بـ 127.0.0.1 بحيث يكون الوكيل العكسي هو الشيء الوحيد القادر على الوصول إليه.

ملف Docker Compose

إليك docker-compose.yml. تحقّق من وسوم الصورة الدقيقة وأسماء متغيّرات البيئة مقابل وثائق تثبيت Listmonk الرسمية. فهي تتغيّر مع كل إصدار.

# docker-compose.yml
services:
  postgres:
    image: postgres:16-alpine
    container_name: listmonk-postgres
    restart: unless-stopped
    environment:
      POSTGRES_USER: listmonk
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
      POSTGRES_DB: listmonk
    volumes:
      - listmonk-postgres:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U listmonk"]
      interval: 10s
      timeout: 5s
      retries: 6

  app:
    image: listmonk/listmonk:latest
    container_name: listmonk-app
    restart: unless-stopped
    # Bind to loopback only. The reverse proxy is the public entrypoint.
    ports:
      - "127.0.0.1:9000:9000"
    depends_on:
      postgres:
        condition: service_healthy
    environment:
      LISTMONK_app__address: "0.0.0.0:9000"
      LISTMONK_db__host: postgres
      LISTMONK_db__port: 5432
      LISTMONK_db__user: listmonk
      LISTMONK_db__password: ${POSTGRES_PASSWORD}
      LISTMONK_db__database: listmonk

volumes:
  listmonk-postgres:

أنشئ .env الملف باستخدام POSTGRES_PASSWORD= مضبوطاً على سلسلة عشوائية طويلة. ثم شغّل المكدّس ونفّذ تثبيت قاعدة البيانات لمرة واحدة:

# Pull images and start the database first
docker compose up -d postgres

# Run the install step (creates schema and the first admin user)
docker compose run --rm app ./listmonk --install --idempotent --yes

# Start the application
docker compose up -d

الـ --install يطلب الأمر بريداً إلكترونياً وكلمة مرور للمسؤول. احفظهما. تحقّق من أن كلتا الحاويتين تعملان:

docker compose ps

المخرجات المتوقعة: خدمتان مدرَجتان، كلتاهما بحالة Up. وينبغي أن يُظهر صف postgres الحالة (healthy).

الـ 127.0.0.1:9000 الربط مقصود. فـ Listmonk ليس لديه مُحدِّد لمعدّل محاولات المصادقة المدمج ولا قائمة سماح بعناوين IP. وكشف المنفذ 9000 للإنترنت العام يعني أن أي شخص على وجه الأرض يستطيع الوصول إلى صفحة تسجيل الدخول إلى لوحة الإدارة. والوكيل العكسي هو ما يجعل تسجيل الدخول هذا متاحاً عبر HTTPS فقط.

الوكيل العكسي Nginx وطبقة SSL

ثبّت Nginx وCertbot من مستودعات Ubuntu. أنشئ إعداد موقع عند /etc/nginx/sites-available/listmonk مع ترويسات الوكيل التي يحتاجها Listmonk لإنشاء روابط حملات صحيحة:

# /etc/nginx/sites-available/listmonk
server {
    listen 80;
    server_name mail.example.com;

    location / {
        proxy_pass http://127.0.0.1:9000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        # Listmonk streams campaign progress over WebSocket
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

اربطه رمزياً ضمن sites-enabled، واختبر الإعداد، وأعد تحميل Nginx، ثم أصدر شهادة:

sudo ln -s /etc/nginx/sites-available/listmonk /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx
sudo certbot --nginx -d mail.example.com

يُعيد Certbot كتابة كتلة الخادم لتستمع على المنفذ 443 بالشهادة الجديدة، ويضيف إعادة توجيه من HTTP إلى HTTPS. تحقّق:

curl -I https://mail.example.com

المخرجات المتوقعة: HTTP/2 200 مع ترويسة strict-transport-security صالحة. إذا حصلت على حلقة إعادة توجيه، فتحقّق من ضبط ترويسة X-Forwarded-Proto في إعداد Nginx أعلاه. في تسع حالات من أصل عشر، تكون الحلقة بسبب تلك الترويسة.

إذا كان Listmonk هو الشيء الوحيد على هذا VPS، فاستخدم Caddy بدلاً من ذلك. ملف Caddyfile مكوّن من ثلاثة أسطر ويتولّى تجديد الشهادة دون الحاجة إلى مهمة cron:

mail.example.com {
    reverse_proxy 127.0.0.1:9000
}

إصلاح ترويسة Message-ID

يستخدم Listmonk افتراضياً اسم مضيف النظام في ترويسة Message-ID الصادرة. وإذا كان اسم مضيف VPS الخاص بك هو localhost أو أي شيء ليس FQDN صالحاً، فإن Listmonk يُرسل Message-ID: <[email protected]>. تُشير مرشّحات الرسائل غير المرغوب فيها لدى Gmail وOutlook إلى ذلك فوراً. وهذا موثّق في موضوع منتدى Cloudron رقم 15410.

الإصلاح هو سطر واحد في config.toml. ولتثبيت جديد، أنشئ الملف عبر docker compose run --rm app ./listmonk --new-config. ثم اضبط:

[app]
hostname = "mail.example.com"

أعد تشغيل حاوية التطبيق بعد التعديل:

docker compose restart app

افعل هذا قبل أن تُرسل ولو حملة واحدة. فالقائمة الملوّثة بمعرّفات localhost.localdomain Message-ID يصعب استرجاعها أكثر من قائمة بدأت نظيفة.

اختيار مُرحِّل SMTP الخاص بك

كل عمليات الإرسال تتم عبر مُرحِّل تُعدّه أنت. وسمعة عنوان IP الخاص بالمُرحِّل، وحدود معدّله، ومعالجته للارتدادات، هي ما يُحدِّد ما إذا كان بريدك سيصل إلى صندوق الوارد أو إلى مجلد الرسائل غير المرغوب فيها.

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

المزوّد	بنية التكلفة	خطافات الويب للارتدادات	الأنسب لـ
Amazon SES	لكل رسالة، منخفضة جداً عند الأحجام الكبيرة	نعم، عبر SNS	التكلفة عند الأحجام الكبيرة، وكونك على AWS بالفعل
Postmark	أساس شهري بالإضافة إلى رسوم لكل رسالة	نعم، أصلية	قابلية التسليم أولاً، سمعة معاملاتية
Brevo	باقة مجانية للحجم المنخفض، وباقات مدفوعة لما فوقها	نعم	حجم منخفض مع مسار للترقية
Mailgun	تسعير لكل رسالة	لا توجد نقطة وصول أصلية لخطاف الويب، استخدم واجهة الارتدادات العامة عند الحاجة.	مألوف للمطوّرين

كانت تلك مجرد نظرة سريعة على كل مُرحِّل SMTP. والآن سنتناول كلاً منها بالتفصيل.

Amazon SES (نقطة البداية الموصى بها)

SES هو الخيار الأرخص عند الأحجام الكبيرة والأكثر نقاشاً في مجتمع Listmonk. للإعداد خطوات أكثر من Postmark أو Brevo، لكن فرق التكلفة لكل رسالة كبير بما يكفي عند أي حجم حقيقي ليبرّر الجهد.

أعدّه على ثلاث مراحل. أولاً، أنشئ مستخدم IAM بسياسة AmazonSESFullAccess (أو سياسة مخصّصة أضيق تقتصر على ses:SendRawEmail و ses:GetSendQuota). ثانياً، تحقّق من نطاق الإرسال في وحدة تحكّم SES. سيرشدك SES خلال سجلات DKIM من نوع CNAME التي يجب إضافتها. ثالثاً، أنشئ بيانات اعتماد SMTP من لوحة إعدادات SMTP في SES. هذه ليست مفاتيح الوصول الخاصة بك في AWS، فـ SES يُنشئ اسم مستخدم وكلمة مرور منفصلين خاصين بـ SMTP عند النقر على "Create SMTP credentials".

في لوحة إدارة Listmonk ضمن Settings ← SMTP، أضف خادماً جديداً بالقيم التالية:

• المضيف: email-smtp.<region>.amazonaws.com (استخدم منطقة SES التي تحقّقت من النطاق فيها)
• Port: 587
• Auth protocol: LOGIN
• TLS: STARTTLS
• اسم المستخدم وكلمة المرور: بيانات اعتماد SMTP التي أنشأها SES

يتطلّب SES استخدام STARTTLS على المنفذ 587. إذا تركت TLS مضبوطاً على none أو اخترت المنفذ 465. فإن Listmonk يتصل، ويُعيد SES 530 Must issue a STARTTLS command first. وقد يُظهر اختبار بيانات اعتماد SMTP في لوحة الإدارة نجاحاً رغم ذلك. أرسل رسالة اختبار حقيقية إلى صندوق وارد شخصي تتحكّم به قبل تشغيل أي حملة.

تبدأ حسابات SES الجديدة في الوضع التجريبي (sandbox). وفي هذا الوضع لا يمكنك الإرسال إلا إلى عناوين بريد إلكتروني مُتحقَّق منها، وهو ما لا يفيد قائمة مشتركين. افتح تذكرة دعم من وحدة تحكّم SES لطلب الوصول إلى الإنتاج. وتستغرق الموافقة عادةً يوم عمل واحد.

Postmark (بديل يُقدِّم قابلية التسليم أولاً)

يكلّف Postmark أكثر لكل رسالة من SES، لكن لديه دعم أصلي لخطاف الويب للارتدادات وسمعة في ارتفاع معدّلات الوصول إلى صندوق الوارد مع سياسات مُرسِل صارمة. وهو يستحق ذلك إذا كانت نشراتك البريدية حيوية لعملك أو إذا كنت لا تريد إدارة الموافقة على الانتقال من وضع SES التجريبي إلى الإنتاج.

إعداد Listmonk بالشكل نفسه كما في SES: المضيف، والمنفذ 587، وSTARTTLS، وبيانات الاعتماد من لوحة رموز API الخاصة بخادم Postmark. تحقّق من نطاق الإرسال في إعداد التوقيع لدى Postmark، وأضف سجلات DKIM التي يُنشئها Postmark، وستكون جاهزاً للإرسال.

اختر Postmark عندما تهمّ قابلية التسليم أكثر من التكلفة لكل رسالة. واختر SES عندما يهمّ الحجم أكثر من الإرشاد المُكثَّف.

تحذير بشأن اختبار بيانات اعتماد SMTP. اختبار الاتصال في لوحة إدارة Listmonk يُبلّغ دائماً عن نجاح، حتى مع بيانات اعتماد غير صالحة. وهذا موثّق في بضع مشكلات على GitHub. لا تثق به. بعد ضبط أي مُرحِّل، أرسل حملة إلى مشترك اختبار واحد وتأكّد من الاستلام في صندوق الوارد المستهدف قبل الإرسال إلى قائمتك الكاملة.

تجنّب Mailersend لإرسال الحملات الجماعية. فحدّ ٥ رسائل لكل اتصال لديه يُنتج أخطاء 421 Service not available يسجّلها Listmonk على أنها مُرسَلة رغم فشل التسليم. تبدو الحملة ناجحة في Listmonk بينما تُسقط معظم رسائلها دون أي تحذير.

جعل البريد يصل فعلاً: SPF وDKIM وDMARC

هذه ثلاثة سجلات DNS على نطاق الإرسال تُخبر خوادم البريد المستقبِلة بأن نطاقك خوّل هذا المُرحِّل بالإرسال نيابةً عنك. تخطَّ أياً منها وسيصل جزء معتبر من رسائلك إلى مجلد الرسائل غير المرغوب فيها عند الحجم الكبير، مهما كان مُرحِّلك أو نصّك نظيفاً. أضفها لدى مزوّد DNS الخاص بك قبل إرسال أول حملة.

سجل SPF

يُخوِّل SPF عناوين IP محددة أو خدمات إرسال محددة بإرسال البريد نيابةً عن نطاقك. أضف سجل TXT واحداً عند جذر نطاق الإرسال مع include الخاص بمُرحِّلك. بالنسبة إلى SES يبدو السجل هكذا:

v=spf1 include:amazonses.com ~all

بالنسبة إلى Postmark، استبدل include بـ include:spf.mtasv.net. تحقّق دائماً من وثائق SPF الرسمية لمُرحِّلك لمعرفة قيمة include الدقيقة. فهي تتغيّر حسب المزوّد وأحياناً حسب المنطقة.

لا يمكن أن يكون للنطاق سوى سجل SPF واحد. إذا كان لديك واحد بالفعل لخدمة أخرى (Google Workspace أو Microsoft 365)، فادمج include في السجل الموجود بدلاً من إضافة سجل ثانٍ.

DKIM

يُرفق DKIM توقيعاً تشفيرياً بالرسائل الصادرة تتحقّق منه الخوادم المستقبِلة مقابل مفتاح عام في DNS الخاص بك. يُنشئ مُرحِّلك زوج المفاتيح. وتضيف أنت المفتاح العام كسجل TXT عند نطاق فرعي للمُحدِّد (على سبيل المثال sel1._domainkey.example.com) بالقيمة الدقيقة التي يمنحها لك المُرحِّل.

لا يتولّى Listmonk توقيع DKIM. المُرحِّل هو من يفعل ذلك. ولا يوجد إعداد DKIM خاص بـ Listmonk. اتبع معالج إعداد DKIM الخاص بمُرحِّلك، وأضف السجلات التي يمنحها لك، وانتظر انتشار DNS (عادةً أقل من ٣٠ دقيقة، وأحياناً بضع ساعات).

DMARC

يُخبر DMARC الخوادم المستقبِلة بما يجب فعله بالبريد الذي يفشل في اجتياز فحوص SPF أو DKIM. ابدأ في وضع المراقبة بـ p=none لكي ترى حالات الفشل في التقارير المُجمَّعة دون التأثير على قابلية التسليم بينما تُصلح الإعدادات الخاطئة. أضف سجل TXT عند _dmarc.example.com:

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

بعد أسبوعين أو ثلاثة من التقارير النظيفة، شدّد السياسة إلى p=quarantine or p=reject. لا تتخطَّ مرحلة المراقبة. فخطأ مطبعي في include الخاص بـ SPF مقترناً بـ p=reject في اليوم الأول سيمحو بريدك المشروع نفسه دون أي إشارة إلى أن شيئاً ما قد حدث خطأً.

تُنشئ ترويسة List-Unsubscribe (RFC 8058) تلقائياً بواسطة Listmonk. تأكّد من أنها مُفعّلة ضمن Settings ← General. ويُظهر Gmail وApple Mail هذه الترويسة كخيار إلغاء اشتراك بنقرة واحدة، وهو ما يحمي سمعة المُرسِل.

ما الذي يتعطّل فعلاً في بيئة الإنتاج

أربعة أنماط أعطال لا تظهر حتى تُرسل أول حملة حقيقية لك. اكتشفها قبل أن يكتشفها مشتركوك.

المشكلة ١: معدّل الارتداد لا يطابق رقم مُرحِّلك. يعالج Listmonk الارتدادات بقراءة عنوان بريد ارتدادات مخصَّص عبر POP3 وحذف كل رسالة يقرؤها. ويشمل ذلك ردود الإجازات، وإيصالات التسليم، وإشعارات الغياب عن المكتب، وكلها تُصنَّف على أنها ارتدادات. أما مُرحِّلك فلا يحسب سوى حالات فشل التسليم الحقيقية التي تُعيدها خوادم بريد المستلِمين. إذا أبلغ SES عن ٠٫٦٪ وأبلغ Listmonk عن ٤٪، فهذا هو الفرق. والإصلاح هو ضبط استدعاءات خطاف الويب للارتدادات بدلاً من POP3. بالنسبة إلى SES، استخدم SNS لتوصيل إشعارات الارتداد إلى نقطة وصول خطاف الويب في Listmonk. أما بالنسبة إلى Postmark، فوجّه خطافه الأصلي إلى النقطة نفسها. ارتدادات خطاف الويب دقيقة، أما ارتدادات POP3 فتُضخّم الأرقام.

المشكلة ٢: اختبار بيانات اعتماد SMTP يقول إنه ناجح بينما هو خاطئ. كما ذُكر في قسم المُرحِّل، يُبلّغ اختبار الاتصال دائماً عن نجاح بغضّ النظر عن صحة بيانات الاعتماد. لا تثق به. أرسل دائماً رسالة اختبار حقيقية بعد ضبط أو تغيير أي إعداد لـ SMTP.

المشكلة ٣: تتوقّف الحملة في منتصف الإرسال دون أي خطأ. يُعلّم Listmonk الحملات على أنها Finished حتى عندما يستلم البريد ٦٠٪ فقط من المشتركين. أما عمليات الإرسال المتبقية فقد رفضها المُرحِّل أو خُنقت عند طبقة شبكة VPS، وListmonk لا يُظهر أياً منهما كخطأ على مستوى الحملة (موضوع منتدى Cloudron رقم 13165). إذا أظهرت الحملة عمليات إرسال أقل من عدد المشتركين، فافتح لوحة معلومات مُرحِّلك للنافذة الزمنية للإرسال وقارن العدد المقبول لدى المُرحِّل بعدد Listmonk. الحقيقة موجودة لدى المُرحِّل.

المشكلة ٤: لا أحد ينسخ PostgreSQL احتياطياً. يحتفظ حجم Compose بالبيانات عبر عمليات إعادة التشغيل. لكنه لا يحمي من فشل المضيف، أو حذف حجم docker بالخطأ عبر volume rm، أو الترقيات التالفة. أضف pg_dump يومياً:

0 2 * * * docker exec listmonk-postgres pg_dump -U listmonk listmonk > /backups/listmonk-$(date +\%Y\%m\%d).sql

نفّذ السطر يدوياً مرة واحدة أولاً. تأكّد من أن ملف المخرجات غير فارغ قبل أن تثق بإدخال cron. فنصّ نسخ احتياطي يكتب ملفاً بحجم صفر بايت دون أن يُطلق خطأً أسوأ من غياب النسخ الاحتياطي تماماً، لأنك تتوقّف عن التفكير فيه.

قبل أن تثق بأي من هذا في بيئة الإنتاج، أرسل حملة اختبار إلى مشترك واحد وتأكّد من الاستلام في صندوق الوارد المستهدف. فإذا وصلت تلك الرسالة الواحدة بنظافة، فستصل العشرة آلاف التالية كذلك.

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

لماذا تكون معدّلات ارتداد Listmonk لديّ أعلى مما يُبلّغ عنه Amazon SES؟

تُضخّم معالجة الارتدادات عبر POP3 في Listmonk الأعداد بقراءة ردود الغياب عن المكتب والردود التلقائية للإجازات على أنها ارتدادات. اضبط استدعاءات خطاف الويب عبر SES SNS للحصول على أعداد دقيقة.

هل يدعم Listmonk الرسائل المعاملاتية؟

Listmonk هو أداة للنشرات البريدية وحملات البث. وهو لا يتولّى أصلاً البريد المعاملاتي (إعادة تعيين كلمات المرور، وتأكيدات الطلبات، والرسائل المُفعَّلة الفردية). للبريد المعاملاتي من نطاق الإرسال نفسه، اضبط نقطة الوصول المعاملاتية لمُرحِّلك بشكل منفصل أو استخدم أداة مخصّصة مثل Postal أو واجهة Postmark المعاملاتية إلى جانب Listmonk.

كيف أستورد مشتركي Mailchimp إلى Listmonk؟

صدّر قائمة Mailchimp الخاصة بك كملف CSV من Audience ← Export Audience. في Listmonk، انتقل إلى Subscribers ← Import وارفع ملف CSV. اربط عمودَي البريد الإلكتروني والاسم عندما يُطلب منك ذلك. يقبل Listmonk ملفات CSV القياسية المُصدَّرة من Mailchimp وConvertKit ومعظم منصات النشرات البريدية دون تحويل للتنسيق.

ماذا يحدث عندما يُلغي شخص اشتراكه من حملة Listmonk؟

يضيف Listmonk رابط إلغاء اشتراك إلى كل رسالة حملة افتراضياً. وعندما ينقر عليه المشترك، يُضاف إلى قائمة الحظر ويُزال من جميع الحملات المستقبلية. وتُضمَّن ترويسة List-Unsubscribe (RFC 8058) تلقائياً، بحيث تُظهرها أصلاً برامج البريد التي تدعم إلغاء الاشتراك بنقرة واحدة (Gmail وApple Mail). ويبقى سجل المشترك في قاعدة البيانات لأغراض التدقيق، لكن لن تُرسَل إليه أي حملات أخرى.