מלכודת חבילת האחסון והדואר בדומיין והפתרון

דומיין דוא"ל שמצורף לחבילת אחסון אתרים משותף הוא מלכודת נפוצה של עבירות דואר בקרב מפעילים קטנים. החבילה נוחה בזמן ההרשמה, אך המבנה שלה עלול לפגוע בהגעה לתיבת הדואר הנכנס. כעבור שישה חודשים, תשובות של לקוחות עשויות להתחיל להגיע לספאם בלי שהמפעיל יבין מדוע, מפני שהמוניטין של כתובת ה-IP המשותפת אינו גלוי מתוך המערכת.

רוב התקנות "דומיין דוא"ל באחסון אתרים" נוצרו מפני שתהליך התשלום אצל הרשם קידם את החבילה בזמן ההרשמה. המלכודת מתגלה כשדייר אחד בכתובת ה-IP המשותפת גורם להוספתה לרשימת חסימה, וכל הדיירים באותה כתובת מאבדים הגעה לתיבה למשך ימים או שבועות. פתרון אפשרי דורש כ-30 דקות של עבודה: להעביר את הדואר למארח ייעודי ולהשאיר את האתר במקומו.

המדריך מתאר את מצבי הכשל ועובר על הפתרון. למסגרת התאמת הגודל לצוות קטן, ראו אחסון דוא"ל לעסקים קטנים.

מהו בפועל דומיין דוא"ל באחסון אתרים

זוהי תכונת אחסון הדוא"ל שמצורפת לתוכניות אחסון אתרים משותף. ספקים בסגנון cPanel, כגון Bluehost, HostGator, Hostinger, אחסון GoDaddy וספקים דומים, מוכרים דומיין, אתר ודוא"ל בחבילה אחת. שרת הדואר פועל על אותה כתובת IP שבה נמצאים האתר שלכם ואתרים של מאות דיירים אחרים.

לחבילה יש חולשות מבניות בכמה ממדים חשובים להגעה לתיבת הדואר הנכנס: מוניטין משותף של כתובת IP, אימות חלש כברירת מחדל, היעדר נראות DMARC ו-DNS בחבילה שקושר כל שכבה לאותו ספק. הנוחות בזמן ההרשמה עלולה להסתיר עלות בעבירות הדואר שמתגלה חודשים לאחר מכן.

ארבעת מצבי הכשל של החבילה

ארבעה מצבי כשל עלולים להשפיע על דומיין דוא"ל שמצורף לאחסון אתרים משותף. אלה בעיות מבניות ולא רק בחירות הגדרה שקל לתקן. כל אחת מהן עלולה לפגוע בעבירות או להוסיף קושי להעברה, עלויות שמפעילים כמעט אינם כוללים בחיסכון לכאורה של החבילה בעת ההרשמה.

1. פגיעה במוניטין של כתובת IP משותפת. דייר בעייתי גורם להוספת הכתובת לרשימת חסימה, וכל הדיירים מאבדים הגעה לתיבת הדואר הנכנס.
2. אימות חלש כברירת מחדל. SPF הוא רשומה משותפת אחת; DKIM עשוי להיות חסר; DMARC כמעט שאינו שולח דוחות ליעד שימושי.
3. היעדר נראות של DMARC. אי אפשר לראות מי מתחזה לדומיין שלכם אם החבילה אינה מנתבת את הדוחות לתיבה שבשליטתכם.
4. תלות שמקשה על העברה. DNS, הרשם ומארח תיבת הדואר נמצאים כולם אצל אותו ספק, ולכן עזיבה פירושה החלפת שלושתם.

כל כשל מחמיר את האחרים. אימות חלש מחמיר את בעיית כתובת ה-IP המשותפת. בלי נראות DMARC מגלים בעיות באיחור. התלות בספק מונעת עזיבה מהירה. ארבעת הכשלים יחד מסבירים מדוע הביצועים של התקנות חבילה כאלה נוטים להיחלש כשהן מתרחבות.

כשל 1: פגיעה במוניטין של כתובת IP משותפת

פגיעה במוניטין של כתובת IP משותפת היא הכשל המבני הראשון. הדואר היוצא שלכם נשלח מכתובת IP שמשותפת עם 100-500 דיירים אחרים. כשדייר אחד שולח ספאם, הכתובת עשויה להיכלל ברשימות חסימה מרכזיות, והגעת ההודעות שלכם לתיבת הדואר הנכנס יורדת עד להסרת הרישום, תהליך שאורך לעיתים קרובות ימים או שבועות.

הנזק אינו מתחלק באופן שווה. הדייר שגרם להוספה לרשימה כמעט שאינו משלם את עלות הניקוי. הדיירים האחרים באותה כתובת IP משלמים בתשובות שאבדו ובתלונות לקוחות. ספקי אחסון אתרים רבים אינם מודיעים באופן יזום לדיירים שנפגעו מאירוע ברשימת חסימה; בדרך כלל מגלים אותו כשמבחינים בפחות תשובות מהרגיל ומתחילים לבדוק. בשלב זה, הנזק עלול כבר להצטבר לאורך ימים או שבועות של דואר חיוני לעסק.

כשל 2: אימות חלש כברירת מחדל

אימות חלש כברירת מחדל הוא הכשל השני. SPF מתפרסם כרשומה משותפת אחת שמכסה את השולחים של כל הפלטפורמה המשותפת, ואי אפשר לצמצם אותו לשולחים בפועל של הדומיין שלכם. DKIM לעיתים קרובות חסר לחלוטין; אם הוא קיים, ייתכן שהמפתח מסתובב לעיתים רחוקות. גם DMARC כמעט שאינו מתפרסם.

גם כאשר לכתובת ה-IP המשותפת יש מוניטין נקי, הדואר היוצא שלכם עלול להיות מאומת באופן חלש. נמענים מודרניים, כגון אכיפת כללי השולחים בכמויות גדולות של Gmail ובדיקות ההתאמה המחמירות יותר של Microsoft, מענישים דואר לא מאומת בהיקף נרחב. העונש חל על הדומיין בלי קשר למוניטין ה-IP, ולכן ביצועי חבילות דוא"ל באחסון אתרים עלולים להיות נמוכים מהצפוי גם בכתובת משותפת נקייה.

כשל 3: היעדר נראות של DMARC

דוחות DMARC מאפשרים לגלות מי שולח דואר וטוען שהוא מגיע מהדומיין שלכם: השולחים החוקיים שלכם, שזקוקים לאימות, וגם מתחזים שמנסים להתחזות למותג. בלי שהדוחות יזרמו לתיבת דואר שבשליטתכם, שני הסוגים נותרים בלתי נראים.

פלטפורמות רבות של אחסון אתרים בחבילה אינן חושפות את ניתוב דוחות DMARC. אי אפשר לראות מי מתחזה לדומיין שלכם מפני שזרם הדוחות מגיע לספק ולא אליכם. חוסר הנראות עלול לאפשר לבעיות להצטבר במשך חודשים לפני שהן מתגלות. מארחי תיבות דואר ייעודיים יכולים לנתב דוחות לתיבה מוגדרת לכל דומיין, וכך לספק נראות כברירת מחדל. ראו דוא"ל עם דומיין מותאם אישית למסגרת האימות הרחבה יותר.

כשל 4: תלות שמקשה על העברה

החבילה מציבה את DNS, הרשם ומארח תיבת הדואר אצל אותו ספק. החלפת אחד מהם דורשת בדרך כלל החלפה של האחרים, וכך שינוי שהיה אמור להיות עדכון של רשומת MX הופך לפרויקט העברה של כמה שבועות. חלק מהספקים גובים גם $50-200 לכל תיבת דואר עבור סיוע בהעברה אל מחוץ לפלטפורמה.

התלות הזאת מסבירה מדוע מפעילים נשארים עם התקנות חבילה זמן רב מדי. עלות ההעברה, בזמן, בכסף ובהפרעה ללקוחות, עולה על העלות השולית של הישארות לרבעון נוסף. העלות המצטברת של בעיות העבירות עשויה בסופו של דבר להוביל להעברה בכל מקרה, אך מאוחר יותר מכפי שהיה קורה אילו הקושי היה נמוך יותר. כל חבילת דומיין דוא"ל ששולטת בשלוש השכבות עלולה ליצור את המלכודת הזאת.

מדריך לפתרון ב-30 דקות

אחת הדרכים לטפל במצבי הכשל היא להעביר את הדואר למארח תיבות דואר ייעודי ולהשאיר את האתר במקומו. רשומות A ו-CNAME של האתר אינן משתנות. רק רשומות MX מתעדכנות כך שיפנו למארח תיבת הדואר החדש. העלות המצוינת לתיבה החדשה היא $0-51/year.

שלב אחר שלב: הירשמו ל-TrekMail, עם Nano בחינם או Starter במחיר $4/month. הוסיפו את הדומיין בלוח הבקרה. מצאו את אזור רשומות DNS ב-cPanel של אחסון האתר, בדרך כלל תחת "Zone Editor" או "DNS Manager." החליפו את רשומות MX, ההגדרות שמורות לאינטרנט היכן למסור דוא"ל עבור הדומיין, בערכים של TrekMail. פרסמו את רשומות SPF, DKIM ו-DMARC שהאשף של TrekMail יוצר. שלחו הודעת בדיקה מהתיבה החדשה אל Gmail, Outlook ו-Yahoo. אשרו שבכותרות מופיע PASS אצל שלושתם. בכך התהליך מסתיים. מפעילים רבים יכולים להשלים זאת בתוך פחות מ-30 דקות.

כיצד TrekMail משתלב בפתרון

TrekMail מטפל בשכבת תיבת הדואר בלי לשלוט ב-DNS, באחסון האתר או ברישום הדומיין. הפלטפורמה יוצרת רשומות DNS לפרסום אצל מארח ה-DNS הקיים; האתר ממשיך לפעול אצל מארח האינטרנט הנוכחי; והדומיין נשאר אצל הרשם הקיים. רק שכבת הדואר עוברת.

לפי ההגדרה המתוארת, סבב DKIM לכל לקוח, ניהול SPF אוטומטי וניתוב דוחות DMARC מתבצעים כברירת מחדל. ההגנות המבניות מול ארבעת מצבי הכשל משולבות בפלטפורמה ומצמצמות את הצורך בהגדרה מצד המפעיל. ראו תמחור דוא"ל עסקי להשוואת העלות מול החבילה.

השלבים הבאים

הפתרון לדומיין דוא"ל שמצורף לאחסון משותף הוא ישיר: השאירו את האתר במקומו והעבירו את הדואר למארח תיבות ייעודי. עדכנו רק את רשומות MX ואת רשומות האימות. ההפרדה הזאת מטפלת בארבעת מצבי הכשל מבחינה מבנית בלי לגעת ב-DNS של האתר או ברשם.

נסו את TrekMail Nano בהתאם לתנאים העדכניים ב-trekmail.net/pricing. ההצעה המתוארת אינה דורשת כרטיס ואינה מציינת תפוגה לניסיון. מסלול Nano מכסה 10 domains × 10 mailboxes; Starter במחיר $4/month מרחיב את הקיבולת ל-50 × 100 כשנפח השליחה גדל.

לעיתים רחוקות חוזרים לבחון את הבעיות האלה, מפני שהמפעילים אינם רואים את העלות. היא משולמת בתשובות שאבדו ובשיחות מכירה איטיות יותר, ולא בחשבונות כספיים. מעבר למארח ייעודי עשוי לחשוף שהעלות היתה ממשית לאורך כל הדרך; מפעילים מסוימים מדווחים על שיעורי תשובה גבוהים יותר ועל מחזורי מכירה מהירים יותר בתוך שבועות מההעברה, אך התוצאה תלויה גם בגורמים נוספים.

האבחון פשוט: בדקו אם דוחות DMARC מצטברים, סיכומים יומיים שמראים מי שולח דוא"ל וטוען שהוא מהדומיין שלכם, מגיעים לתיבת דואר שבשליטתכם. אם לא, מצב הכשל 3 קיים ומומלץ לבדוק גם את שלושת האחרים. מעבר למארח ייעודי עשוי לטפל בכל הארבעה בבת אחת. רשמים שמוכרים חבילות כמעט שאינם מציינים את בעיית העבירות, מפני שהחבילה רווחית עבורם. המפעילים צריכים לחשוף את הבעיה בעצמם, בדרך כלל באמצעות דוחות DMARC או לאחר שמבחינים בירידה בשיעור התשובות.

למפעילים עם כמה אתרים באותו חשבון אחסון משותף, הבדיקה דחופה יותר. הדואר היוצא של כל אתר חולק את אותה כתובת IP ואת אותה חולשת אימות. מארח ייעודי עם סבב DKIM לכל לקוח מפריד את המוניטין של כל מותג, ועשוי למנוע מאירוע במותג אחד להתפשט לכל האחרים באותו חשבון מפעיל.

הערה אחרונה: הרשם שמכר את החבילה מלכתחילה כמעט שאינו מציין את בעיית העבירות מיוזמתו. החבילה רווחית והמעבר החוצה כרוך בחיכוך. מפעילים צריכים לגלות את הבעיה בעצמם באמצעות דוחות DMARC או לאחר שמבחינים בירידה בשיעור התשובות. הפתרון מתחיל בדרך כלל ביוזמת המפעיל ולא בהמלצת הספק. הגדירו תזכורת בלוח השנה לבדוק דוחות DMARC מדי רבעון, אם טרם עשיתם זאת.