אתם מפעילים שרת דואר עבור 30 דומיינים של לקוחות. כל אחד זקוק לרשומת MX, למפתח DKIM, לרשומת SPF, למדיניות DMARC ולכללי הסגר משלו, לצד מעקב אחר מוניטין השליחה. השאלה אינה אם שרת אחד מסוגל לעשות זאת: Postfix ו-Dovecot תומכים בכך כבר שני עשורים. השאלה היא אם התצורה תחזיק מעמד כשקמפיין יוצא של לקוח יפגע במוניטין כתובת ה-IP המשותפת.
שרת דואר לריבוי דומיינים הוא ארכיטקטורה מתאימה למפעילים רבים. לאחרים, שמניחים שהוא יחסוך כסף לעומת שירות מנוהל מרובה דיירים בלי לחשב את עבודת התפעול, הוא עלול להתאים פחות. המדריך סוקר את הארכיטקטורה, תצורות המסייעות להפריד בין לקוחות, שלושה סוגי כשל בהפרדה שעשויים להופיע עם הצמיחה ואת השיקולים הכלכליים מול מסלול מנוהל כמו TrekMail Agency.
מהו בעצם שרת דואר לריבוי דומיינים
שרת דואר לריבוי דומיינים הוא מערך תעבורת דואר אחד שמקבל ושולח הודעות עבור כמה דומיינים על אותה תשתית. מופע Postfix אחד מקבל דואר עבור client1.com, client2.com ו-client3.com; מופע Dovecot אחד מאחסן את תיבות שלושת הדומיינים בהתאם לכללי ההפרדה שהוגדרו; ותור יוצא אחד שולח הודעות עם חתימת DKIM ייעודית לכל דומיין.
זה אינו זהה למונח השיווקי ״אירוח דואר לריבוי דומיינים״, שמשמעותו בדרך כלל מסלול שבו מוסיפים כמה דומיינים תחת חשבון חיוב אחד. השרת הוא המימוש התפעולי שמאחורי ההצעה: תצורת Postfix ו-Dovecot שמאפשרת אותה. אפשר להפעיל אותו על VPS משלכם או להשתמש בספק כמו TrekMail Agency, שמנהל את התשתית מרובת הדיירים.
שלוש ארכיטקטורות להפעלת דומיינים רבים
מפעילי דואר עם 10 דומיינים או יותר נוטים לבחור בין שלוש ארכיטקטורות. כל אחת מאזנת אחרת בין עלות, שליטה ומורכבות תפעולית. ההחלטה תלויה בזמן וביכולת של הצוות הטכני לא פחות מאשר בחישוב הכספי. בחירה מתאימה מראש עשויה לחסוך תכנון מחדש יקר אחרי שנתיים, כשהפתרון הראשוני כבר אינו עומד בצרכים.
דפוס 1: שרת דואר לכל דומיין
הארכיטקטורה הפשוטה ביותר היא מופע Postfix/Dovecot לכל דומיין לקוח. אין לקוחות שחולקים את אותו מערך וצריך להפריד ביניהם בתוכו, אך מערכת ההפעלה, הרשת והרשאות הניהול עדיין דורשות הגנה. לכל דומיין VPS, כתובת IP ופרופיל מוניטין משלו. זה עשוי להתאים ל-3-5 דומיינים, שכל אחד מייצג עסק עצמאי משמעותי. ב-20+ דומיינים התפעול עלול להכביד: עדכונים, ניטור וחידוש אישורים גדלים עם מספר השרתים.
דפוס 2: שרת אחד לריבוי דומיינים ודיירים
התצורה המקובלת לסוכנויות היא מערך Postfix + Dovecot אחד לכל דומייני הלקוחות, עם virtual_mailbox_domains, מפתחות DKIM לכל דומיין ותצורה מרובת דיירים ב-Dovecot. מנהלים תשתית של שרת אחד ומשרתים N דומיינים. כהערכה להמחשה, היתרון הכלכלי עשוי להתחיל בסביבות 10 דומיינים, ומורכבות התפעול עשויה לגדול בסביבות 200 דומיינים, בהתאם לעומס. חלק מהמפעילים עוברים אז לשירות מנוהל או מחלקים דומיינים בין שרתים לפי פרופיל מוניטין.
דפוס 3: שירות מנוהל מרובה דיירים, לקנות או לבנות
סוכנויות רבות מגלות שהפעלת דואר פנימית מצריכה עבודה הנדסית ניכרת, לעיתים בהיקף של משרה מלאה, שעלותה יכולה לעלות על מנוי מתאים. בתרחיש המקור TrekMail Agency עולה $29 לחודש, או $23.25/mo כשווי חודשי בחיוב שנתי, וכוללת 1,000 דומיינים וכלים להחלפת מפתחות DKIM ולניהול SPF/DMARC. המקור מזכיר גם תורים יוצאים לכל חשבון: אין בכך בהכרח הפרדה לכל דומיין או בידוד של מוניטין IP. בדקו תכונות ותנאים עדכניים. ייתכן שלא תצטרכו לכתוב תצורת Postfix, אך ניהול לקוחות נשאר. כדי למצוא את נקודת האיזון השוו את ערך שעות העבודה השנתיות לעלות המנוי השנתית; גם שעת עבודה מקצועית אחת יכולה להשפיע על החישוב.
Postfix + Dovecot: התשתית המקובלת
בהפעלה עצמית, מערך מקובל ב-2026 הוא Postfix לתעבורת SMTP ו-Dovecot לגישת IMAP, לאחסון ולמסירה באמצעות LMTP. הדוגמאות להלן מניחות Debian או Ubuntu LTS. אפשר להתאים את העקרונות להפצות אחרות, אך הקטעים אינם תצורה מלאה ויש לבדוק אותם מול הגרסאות המותקנות.
virtual_mailbox_domains וקובצי המיפוי
Postfix תומך בדומיינים וירטואליים באמצעות ההנחיה virtual_mailbox_domains. במקום לכתוב את הדומיינים ישירות ב-main.cf, שומרים אותם במפת hash, או במקור נתונים מסוג SQL או LDAP בהיקף גדול יותר:
# /etc/postfix/main.cf
virtual_mailbox_domains = hash:/etc/postfix/vhosts
virtual_mailbox_maps = hash:/etc/postfix/vmailbox
virtual_alias_maps = hash:/etc/postfix/valias
virtual_transport = lmtp:unix:private/dovecot-lmtpהקובץ /etc/postfix/vhosts מפרט את הדומיינים שעבורם השרת מקבל דואר, אחד בכל שורה בפורמט של מפת hash: שם דומיין כמפתח ולצידו ערך מתאים, ולא שמות דומיינים בלבד. בתצורת LMTP הזאת /etc/postfix/vmailbox משמש לבדיקת קיום הנמען; הערך במפה אינו קובע את נתיב האחסון בפועל, משום ש-Dovecot מבצע את המסירה. /etc/postfix/valias מטפל בכינויים, למשל info@client1.com → real-person@client1.com.
מבנה ספריות מרובה דיירים ב-Dovecot
Dovecot יכול לשמור תיבות תחת ספריות נפרדות לכל דומיין. מבנה מקובל הוא /var/vmail/<domain>/<user>/. דוגמת תצורה:
# /etc/dovecot/conf.d/10-mail.conf
mail_location = maildir:/var/vmail/%d/%n
mail_uid = vmail
mail_gid = vmail%d מייצג את חלק הדומיין ו-%n את החלק המקומי בכתובת. הדואר של כל משתמש נשמר תחת הדומיין שלו, מה שמקל על גיבוי ופעולות ניהול לכל לקוח. אפשר להעתיק נתונים של לקוח אחד באמצעות rsync בלי לבחור את נתוני האחרים. ספריות נפרדות לבדן אינן גבול אבטחה: גם אימות, הרשאות וגישה לקבצים צריכים לאכוף את ההפרדה.
LMTP להעברת הדואר מ-Postfix ל-Dovecot
מערכים מודרניים משתמשים לעיתים קרובות ב-LMTP, כלומר Local Mail Transfer Protocol, להעברה מ-Postfix ל-Dovecot. הדבר יכול להפחית את עלות יצירת התהליכים לעומת הפעלת dovecot-deliver נפרד לכל הודעה, ומאפשר לאכוף מכסות לכל נמען כאשר הן מוגדרות. הגדירו ל-Dovecot האזנה לשקע Unix של-Postfix יש הרשאות מתאימות לגשת אליו.
ניהול SPF, DKIM ו-DMARC לכל דומיין בהיקף גדול
האתגר המרכזי אינו תמיד התעבורה; ל-Postfix יש מנגנונים ותיקים לכך. הקושי הוא לשמור על SPF, DKIM ו-DMARC תקינים אצל כל הלקוחות ולנהל את מחזור חיי מפתחות DKIM כך שיצומצם הנזק במקרה של חשיפתם. זו יכולה להיות משימה עתירת זמן בהפעלה עצמית, ושיקול חשוב בבחינת שירות כמו TrekMail Agency.
SPF לכל דומיין
כל דומיין המשמש בזהות SMTP שעליה מתבצעת בדיקת SPF זקוק למדיניות מתאימה למקורות השליחה שלו. הרשומות נמצאות ב-DNS של הדומיינים, לא בשרת שלכם. כשמוסיפים כתובת IP יוצאת, מעדכנים את המדיניות של הדומיינים המושפעים אם הם מאשרים אותה ישירות. עם include מנוהל כראוי ייתכן שמספיק לשנות את המדיניות שאליה הוא מפנה; לא תמיד צריך לשנות את רשומות כל הלקוחות. לעיתים השינוי נעשה אצל ספק ה-DNS של הלקוח, שאין לכם גישה אליו. ההסבר המלא נמצא ב-מדריך להגדרת SPF.
DKIM לכל דומיין והחלפת מפתחות רבעונית
ניהול DKIM בהפעלה עצמית ובהיקף גדול עשוי להיות יקר מבחינת עבודה. לכל דומיין זוג מפתחות משלו: הפרטי חותם על הדואר היוצא והציבורי מתפרסם ב-DNS תחת selector של הדומיין. החלפה בכל רבעון היא מדיניות אפשרית, לא חובה אחידה לכולם. אם בוחרים בה, צריך לפרסם selector חדש לכל דומיין בכל רבעון, לוודא שהוא זמין ולשמור את המפתח הציבורי הישן למשך הזמן הדרוש לפני הסרתו. ב-100 דומיינים הדוגמה כוללת 400 עדכוני DNS בשנה אם העבודה ידנית. המדריך להגדרת DKIM מתאר את התהליך.
דיווח DMARC בהיקף גדול
DMARC לכל דומיין מחייב לשייך דוחות מצטברים ללקוח הנכון. הם מגיעים לעיתים מדי יום בקובצי XML ממערכות מקבלות שתומכות בדיווח ומיישמות אותו; לא כל נמען מדווח, ואין הבטחה למשלוח יומי קבוע. פענוח הדוחות והפקת סימנים שימושיים, כגון התחזות לדומיין או שולח שהוגדר לא נכון, יכולים להפוך לפרויקט הנדסי בפני עצמו. המדריך להגדרת DMARC עוסק בעיבוד הדוחות.
שלושה כשלים אפשריים בהפרדה
איכות שרת מרובה דומיינים תלויה גם בהפרדה בין הלקוחות. שלושה סוגי בעיות עלולים לערער אותה עם הגדילה, ולעיתים מתגלים רק בעקבות אירוע ממשי. תכננו עבורם מראש: איתור התקלה בזמן משבר מסירה פעיל קשה הרבה יותר.
כשל 1: פגיעה במוניטין ה-IP היוצא המשותף
לקוחות ששולחים מאותה כתובת IP חולקים חלק מסיכון המוניטין. אם לקוח מפעיל קמפיין פנייה קרה עם רשימות לא מטויבות, הכתובת עלולה להיות מסומנת ולקוחות אחרים עלולים להיתקל בהגבלות אצל Gmail או נמענים אחרים. אפשר להקצות כתובות נפרדות ללקוחות עם צורך מוצדק, לצד חימום וניהול מוניטין, או לטפל בשימוש לרעה כאירוע של המאגר המשותף. החלפת כתובות כדי לעקוף חסימות או מנגנוני אנטי-ספאם אינה פותרת את הסיבה. לקוח בעייתי אחד יכול להשפיע על כל המשתמשים באותו מאגר.
כשל 2: עומס בתור המשותף
כשתור Postfix גדל, למשל בעקבות רצף שגיאות זמניות מסוג 4xx אצל נמען, גם השליחה של לקוחות אחרים עלולה להאט אם המשאבים משותפים. Postfix מאפשר להגביל לפי יעד, אך יש גם משאבים כלליים שצריך לתכנן. ב-50 דומיינים, ניוזלטר של 500K הודעות מלקוח אחד עשוי לעכב דואר תפעולי של אחרים במשך שעות, בהתאם לעומס ולתצורה.
כשל 3: אימות מול נתונים של לקוח אחר
אם בסיס נתוני האימות של Dovecot אינו מבחין היטב בין דומיינים, משתמש של לקוח A עלול להיות מושווה לרשומות של לקוח B כאשר החלק המקומי של השם זהה. אימות שמות, שאילתות למקור הנתונים והרשאות חייבים כולם להתחשב בדומיין. הגדרת auth_username_format ל-%u, הכתובת המלאה, במקום %n, החלק המקומי בלבד, יכולה להיות חלק מהפתרון בגרסה המתאימה. השורה הזאת לבדה אינה מספיקה בלי מקור נתונים ומדיניות גישה תקינים. להחמצת הפרט הזה עשויות להיות השלכות חמורות על המשתמשים. הסקירה המלאה נמצאת ב-סיכוני אירוח דואר לריבוי דומיינים.
הפעלה עצמית לעומת שירות מנוהל
ההחלטה אם לקנות או לבנות תלויה בעלות האמיתית של הזמן שלכם. הפעלה עצמית נראית זולה כשסופרים רק VPS ורוחב פס. התמונה משתנה כשמוסיפים שעות לכוונון Postfix, לבקשות הסרה מרשימות חסימה, להחלפת מפתחות DKIM ולאירוע מסירה אפשרי ב-3 לפנות בוקר. שלוש נקודות המעבר הבאות מסייעות בהשוואה; הסכומים הם דוגמאות, לא הצעות מחיר עדכניות.
| מספר דומיינים | שרת דואר בהפעלה עצמית | שירות מנוהל, TrekMail Agency | המלצה מעשית |
|---|---|---|---|
| 1-5 דומיינים | ~$10/mo ל-VPS + זמן העבודה שלכם | $29/mo קבוע, $23.25 לחודש בחיוב שנתי, או Starter ב-$4/mo עבור 50 דומיינים לפי המקור | שקלו שירות מנוהל: הזמן יכול להיות שווה יותר מהפרש המחיר |
| 5-50 דומיינים | ~$30/mo ל-VPS + 10-20 שעות/mo עבודה הנדסית | $29/mo Agency ו-0 שעות/mo לניהול שרת הספק; ניהול הלקוחות עדיין נדרש | שירות מנוהל עשוי להיות זול יותר מעלות שעות העבודה לבדן |
| 50-500 דומיינים | $100-300/mo לתשתית + 1 איש מקצוע בתחום הדואר במשרה חלקית | $29/mo Agency, עדיין 0 שעות/mo לניהול השרת הבסיסי אצל הספק | מנוהל, אלא אם נדרשת שליטה מסוימת שהספקים הזמינים אינם מציעים |
| 500-5,000 דומיינים | $500-2,000/mo + 1-2 FTE של אנשי מקצוע בתחום הדואר, בשווי משרות מלאות | $29/mo Agency + Drive Add-on לאחסון; בדקו קיבולת דומיינים ומכסות דואר, בלי להניח שהמסלול מכסה את כל הטווח | דורש בחינה; לעיתים היברידי: מנוהל לדואר תפעולי ועצמי לדרישות לקוח מיוחדות |
בתרחישי העלות המוצגים שירות מנוהל יכול להשתלם בהיקפים רבים מתחת ל-5,000 דומיינים, אך העומס, הידע והדרישות משפיעים על התוצאה. חריג אפשרי הוא דרישת ציות שאף ספק זמין אינו מקיים, למשל אחסון פיזי בתחום שיפוט שבו הספק אינו פועל. גם אז, לעיתים מתאים לנהל רק את הלקוח החריג ולהשתמש בשירות מנוהל לאחרים, במקום להפעיל את כל המערך.
מה מקבלים בפועל משירות מנוהל מרובה דיירים
שירות מנוהל יכול לספק ארבע קבוצות כלים שלא תצטרכו לבנות לבד: החלפת מפתחות DKIM לכל דומיין עם תיעוד שניתן לבדוק; אשפי SPF/DMARC ושילוב עם ספקי DNS, כשהם נתמכים ומורשים; חימום מאגר ה-IP היוצא ומעקב מוניטין; ועיבוד דוחות DMARC מצטברים למידע מעשי במקום XML גולמי. כל רכיב יכול לדרוש חודשי פיתוח פנימי. המקור מציג אותם כתכונות בלוח הבקרה של TrekMail Agency. בדקו מה זמין בפועל ומה נשאר באחריותכם: אשף אינו מבטיח שרשומות DNS נכונות יתפרסמו אוטומטית בלי פעולה או הרשאה נוספת.
השוואת שירותי דואר מנוהלים לריבוי דומיינים
אם בחרתם לקנות, אפשר להשוות בין היתר את TrekMail, Migadu ו-Workspace לארגונים גדולים יותר. לכל אחד מודל אחר. הדוגמה מניחה 50 דומיינים של לקוחות עם ~10 תיבות בכל אחד, כלומר 500 תיבות בסך הכול, כפרופיל אפשרי של סוכנות בינונית. מחירים ותכונות הם הנחות מהמקור, לא הצעה עדכנית שנבדקה. הוספת דומיינים לארגון Workspace אחד אינה יוצרת אוטומטית לקוחות עצמאיים מופרדים; בדקו שליטה בדומיינים, הרשאות ניהול והפרדת נתונים ארגונית.
| ספק | מודל תמחור | החלפת מפתחות DKIM לכל דומיין | הפרדת תורים יוצאים | עלות ל-50 דומיינים × 10 תיבות |
|---|---|---|---|---|
| TrekMail Agency | $29/mo קבוע, $23.25 לחודש בחיוב שנתי | אוטומטי לכל לקוח לפי המקור; יש לבדוק | תור לכל חשבון ומאגר IP משותף; לא הפרדה אוטומטית לכל דומיין | $348/שנה בדוגמת התעריף החודשי |
| Migadu Max | $90/שנה לכל דומיין בהנחת המקור; בדקו את מודל החיוב בפועל | החלפה ידנית לכל דומיין בהנחת המקור | משותף לפי רמת המסלול בהנחת המקור | $4,500/שנה בדוגמת החישוב, 50 × $90 |
| Google Workspace | $14/משתמש/mo בהנחת המקור | לכל דומיין; התמחור למשתמש משפיע על ההשוואה | מאגר שליחה משותף של Google לפי המקור | $84,000/שנה בדוגמת החישוב, 500 × $14 × 12 |
בהנחות האלה TrekMail Agency תהיה זולה בערך פי 13 ממודל הדומיין המיוחס ל-Migadu ופי 240 ממודל המשתמש המיוחס ל-Workspace. אלה יחסים חשבוניים להמחשה, לא הוכחה כללית לחיסכון. בדקו במיוחד את מודל החיוב האמיתי של Migadu ואת תנאי כל המסלולים. ההבדל בין כתובות IP משותפות לכתובות ייעודיות לכל דומיין תלוי בהצעה בפועל ובפרופיל השליחה. כתובת ייעודית יכולה לעזור להפריד מוניטין, אך דורשת חימום וניהול ואינה מבטיחה הגעה לתיבת הדואר הנכנס.
מתי הפעלה עצמית באמת מתאימה יותר
הדוגמאות הקודמות נוטות לטובת שירות מנוהל. עם זאת, יש שלושה תרחישים שבהם הפעלה עצמית יכולה להתאים למרות העלות התפעולית. חשוב לדעת מתי לחרוג מהבחירה הרגילה, לא רק להכיר אותה.
תרחיש ראשון: דרישות רגולטוריות שאף ספק שנבדק אינו מקיים. אם נתוני לקוח חייבים להימצא פיזית בתחום שיפוט שבו TrekMail, Migadu וחבילות הענן שנשקלו אינם פועלים, ייתכן שנדרשת הפעלה עצמית. מחיר התפעול נשאר ממשי. סוכנויות רבות בוחרות כאן בגישה היברידית: אירוח עצמי ללקוח הזה ושירות מנוהל לאחרים. אין בהכרח צורך להפעיל את המערך כולו עבור חריג אחד.
תרחיש שני: כתובות IP ייעודיות לכל לקוח עם דרישות שליחה שאינן מכוסות בהצעות הזמינות. חלק ממפעילי הניוזלטרים בנפח גבוה או משירותי הדואר התפעולי עשויים להזדקק להפרדת מוניטין. מסלולים מנוהלים רבים משתמשים במאגרים משותפים, אך צריך לבדוק חלופות בפועל. אם פרופיל הלקוח מצדיק כתובות ייעודיות וחימום מסודר, VPS עם כתובות המחולקות לפי פרופיל מוניטין יכול להתאים. זו אינה דרישה אוטומטית: לקוחות רבים שמבקשים IP ייעודי אינם שולחים בנפח או בדפוס שהופך אותו לכדאי.
תרחיש שלישי: יכולת הנדסית פנימית שכבר קיימת לצרכים אחרים. אם יש בצוות איש מקצוע בתחום הדואר מסיבות נפרדות, העלות השולית של הוספת ניהול ריבוי דומיינים עשויה להיות נמוכה. השעות אינן חינם: בדקו זמינות, כוננויות ואת העבודה שתידחה לטובתן. כוח אדם קיים משנה את החישוב, אך אינו מבטל את עומס התפעול.
הקשחת אבטחה לשרת דואר מרובה דומיינים
שרת מרובה דומיינים הוא יעד בעל ערך לתוקפים, משום שפריצה אליו עשויה לתת שליטה בתעבורת הדואר של כל הלקוחות המאוחסנים. הרשימה הבאה מתמקדת בבקרות שמסייעות להפחית סיכון בפועל, ולא באמצעים מרשימים למראית עין ללא השפעה רבה. היא אינה מבטיחה אבטחה מלאה.
הציעו SMTP submission מאומת בפורט 587 עם STARTTLS או בפורט 465 עם TLS ישיר (implicit TLS). דרשו חיבור TLS תקין לפני אימות ואל תעבירו פרטי התחברות בטקסט גלוי. פורט 25 נשאר פתוח לדואר נכנס משרתים אחרים. עליו למנוע ממסר לא מורשה ושימוש בלתי מורשה כנתיב submission, לא לדחות כל דואר מקומי לנמען מקומי, שעשוי להיות מסירה לגיטימית. השארת פורט 25 כדרך עוקפת לשליחה לא מורשית מרחיבה את הסיכון.
מגבלות שליחה לכל לקוח יכולות לצמצם את הנזק למוניטין IP שתיבה שנפרצה גורמת בתוך 20 דקות, אך אינן מונעות אותו בוודאות. התאימו מגבלות לכל תיבה בשעה ולכל חשבון ביום לדפוסי השליחה בפועל. ללא מגבלות, סיסמה שנגנבה עשויה לאפשר 100K הודעות ספאם לפני שהניטור מגיב בתרחיש המתואר. המקור מציין מגבלות TrekMail כגון 1,000 הודעות לתיבה ביום ו-6,000 לחשבון ביום ב-Starter, וכן 50 הודעות בשעה דרך SMTP submission ב-Nano. בדקו ערכים עדכניים. אלה אותם סוגי בקרות שצריך לבנות במערך Postfix עצמאי, לא הגנה מלאה מפני שימוש לרעה.
גישת ניהול דורשת סיסמאות חזקות ו-2FA. גם 2FA לתיבות הדואר חשובה: פריצה לתיבה יכולה לחשוף נתונים ולאפשר שחזור גישה לחשבונות אחרים. ה-2FA של מנהל מגן על גישה בעלת טווח השפעה רחב יותר, שעלולה לפגוע בהפרדה של כל הלקוחות. השתמשו באימות נוסף היכן שנתמך ובסיסמאות יישום ל-IMAP לפי הצורך, והגנו על שתי הרמות בהתאם לסיכון.
רשימת תפעול לשרת דואר מרובה דומיינים
אם בחרתם בהפעלה עצמית, משימות יומיות ושבועיות חשובות לפחות כמו ההגדרה הראשונית. מערך Postfix + Dovecot שהוגדר היטב יכול לפעול במשך שנים עם עדכונים ותחזוקה. המשמעת התפעולית השוטפת היא ששומרת על אמינותו. הנה רשימה מעשית להתאמה לסביבה שלכם.
מדי יום: עקבו אחר עומק התור וקצב השליחה לכל לקוח. עלייה פתאומית לפי 10 מהקצב הרגיל יכולה להיות קמפיין או פריצה; שתיהן דורשות בדיקה. בדקו כתובות IP יוצאות ברשימות חסימה באמצעות MX Toolbox או כלי דומה. ודאו שמשימות cron ליליות, כגון החלפת קובצי לוג, קליטת דוחות DMARC והחלפת גיבויים, הסתיימו כראוי.
מדי שבוע: בדקו את דוחות DMARC המצטברים הזמינים לכל דומיין לקוח. שירותי ניוזלטר, ספקי תשלומים וכלי מכירות חדשים יכולים להוסיף מקורות שליחה שיש לאשר באופן מתאים ב-SPF וב-DKIM לפי הזהות המשמשת אותם. עקבו אחר גידול האחסון לכל לקוח: תיבות מעל 30 GB בתרחיש המסלול הטיפוסי עשויות לדרוש מדיניות ארכוב או שיחה על שדרוג. בדקו את מוני חיבורי IMAP של Dovecot לכל לקוח. התקרבות למגבלה המוגדרת עלולה לגרום לסנכרון מקוטע ולפניות תמיכה.
מדי רבעון: החליפו מפתחות DKIM לכל דומיין אם זו המדיניות שבחרתם. התהליך לדוגמה מפרסם selector חדש ב-DNS של הלקוח, ממתין 48 שעות, משנה את חתימת Postfix ומשאיר את ה-selector הישן עוד 48 שעות לפני הסרתו. אלה חלונות לדוגמה, לא הבטחה להפצת DNS. בדקו TTL, זמינות הרשומה החדשה והודעות שעדיין בתעבורה, והאריכו את החפיפה לפי הצורך. ב-100 דומיינים המקור מעריך 8-12 שעות עבודה לרבעון וכ-40 שעות בשנה לניהול DKIM בלבד. מסלול כמו TrekMail Agency עשוי לבצע חלק מהפעולות אוטומטית, בהתאם לתכונות הזמינות. החלפת מפתחות מפחיתה את סיכון חשיפתם, אך אינה מתקנת לבדה מוניטין שליחה.
מדי שנה: בחנו את ניהול אישורי SSL/TLS לשירותי SMTP ו-IMAP, בדקו גיבויים באופן מלא באמצעות שחזור דואר של לקוח אחד למופע Dovecot נקי ובצעו ביקורת על מקורות נתוני האימות. המקור משתמש באישורי Let's Encrypt לתקופה של 90 יום כדוגמה; בדקו תוקף עדכני וחידוש אוטומטי ונטרו אותם לאורך השנה, לא רק בבדיקה השנתית. הכינוי הוותיק SSL/TLS מתייחס כאן לניהול אישורים עבור TLS מודרני, לא להפעלת SSL מיושן. גם חידוש אוטומטי עלול לדרוש התערבות. ב-Dovecot עשויות להצטבר רשומות ישנות, למשל משתמשי לקוחות שהדומיינים שלהם הוסרו מ-Postfix אך הם עדיין מורשים להתחבר.
הצעדים הבאים
הפעלה עצמית של שרת לריבוי דומיינים אפשרית טכנית, אך יכולה להיות תובענית תפעולית. Postfix ו-Dovecot הם רכיבים מבוססים; החלפת DKIM לכל דומיין וניתוח DMARC עשויים לצרוך שבועות עבודה בשנה. שירות מנוהל יכול להשתלם לסוכנויות רבות, כל עוד החישוב כולל דרישות, עומס ומשימות שנשארות אצל הלקוח.
במקור TrekMail Agency עולה $29 לחודש, או $23.25 כשווי חודשי בתשלום שנתי, עבור 1,000 דומיינים × 1,000 תיבות לכל דומיין, 200 GB אחסון משותף לדואר ול-TrekMail Drive, כלים להחלפת DKIM לכל דומיין, עורך Sieve למסננים מותאמים, תמיכה ייעודית, 100 כינויים לתיבה וייבוא מרוכז של 50 דומיינים של לקוחות בקובץ CSV אחד. בדקו זמינות, מכסות ותנאים עדכניים: המספרים אינם מבטיחים שכל שילוב יתאים לאחסון הכלול. תקופת הניסיון החינמית של 14 יום דורשת כרטיס אשראי לפי התיאור. מסלול Nano החינמי מתואר ללא כרטיס וללא תקופת ניסיון, וכולל 10 דומיינים × 10 תיבות כדי לבדוק את לוח הבקרה לפני בחירת Agency. לסקירת הסיכונים לכל דומיין ראו גם את המדריך לאירוח דואר לריבוי דומיינים. השוואת המסלולים המלאה והמחירים העדכניים נמצאים ב-trekmail.net/pricing.
