כל אתר שולח מיילים. אישורי הזמנה, איפוסי סיסמה, פניות מטופס יצירת קשר ותזכורות להזמנות הם כולם מיילים תפעוליים מהאתר. זו קטגוריה שאיש כמעט אינו מתכנן מראש, אף שכולם תלויים בה. בדרך כלל מי שבנה את האתר מגדיר אותה פעם אחת ואינו בודק אותה שוב.
ואז לקוחות מפסיקים לקבל אישורי הזמנה, ומתברר שבמשך שמונה חודשים הם הגיעו לתיקיית הספאם. בעמוד הזה נסביר למה זה קורה בלי קשר לפלטפורמה שבה האתר פועל, ואיזה מבנה ימנע זאת.
למה מיילים תפעוליים מהאתר נכשלים בלי שתדעו
ברוב הפלטפורמות, הגדרת ברירת המחדל שולחת מייל ישירות משרת האינטרנט באמצעות פונקציית הדואר של שפת התכנות. בבדיקות זה עובד, כי אתם בודקים מול תיבת הדואר שלכם וספק הדואר שלכם נותן בכם אמון.
בסביבת הייצור השליחה נכשלת מסיבה שאינה קשורה לקוד. לשרת האינטרנט אין מוניטין שליחה, כתובת ה-IP שלו משותפת לכל שירות אחר שחברת האחסון מפעילה, וההודעה מציגה את עצמה כאילו נשלחה מהדומיין שלכם אף שהיא מגיעה ממקום שהדומיין מעולם לא אישר. ספקי הדואר המקבלים מזהים בדיוק את הדפוס הזה כהתחזות, משום שברוב המקרים זו אכן התחזות. בדיוק מסיבה זו ההנחיות של Google לשולחי אימייל מחייבות אימות.
מבחינתכם הכשל שקט. האתר מדווח שהמייל נשלח, ביומנים לא מופיעה שגיאה, ואין שום סימן לכך שבצד המקבל ההודעה תויקה כדואר זבל. מיילים תפעוליים מהאתר גרועים במיוחד בדיווח על כך שאינם עובדים, ולכן בדרך כלל מגלים את הבעיה רק בעקבות תלונה של לקוח כעבור חודשים.
אותה בעיה בכל פלטפורמה
זו אינה בעיה ייחודית ל-WordPress, אף שלרוב מאשימים אותה משום שהיא הפלטפורמה הנפוצה ביותר. המנגנון זהה בכל מקום.
WordPress משתמשת כברירת מחדל בפונקציית הדואר של PHP, כלומר בשליחה ישירה מהשרת עם כל הבעיות שתוארו למעלה. תוסף SMTP מחליף את המנגנון הזה, וזה הפתרון המקובל.
Shopify, Wix ו-Squarespace שולחות את המיילים התפעוליים באמצעות התשתית שלהן, שבדרך כלל מתוחזקת היטב. עם זאת, ללא הגדרה מתאימה הן לא תמיד מאפשרות לשלוח מהדומיין שלכם עם אימות תקין. לכן לא בהכרח ניתן לוודא שהודעות שמוצגות כאילו נשלחו מכם אכן הגיעו מכם.
Webflow, Ghost ויישומים מותאמים אישית נבדלים בפרטים, אך הדפוס נשאר זהה: מנגנון השליחה שמוגדר כברירת מחדל כמעט אף פעם אינו מאומת מול הדומיין שלכם.
הפתרון העקבי בכל הפלטפורמות הוא להעביר את המיילים התפעוליים של האתר דרך חיבור SMTP מאומת בדומיין שרשומות ה-DNS שלו קובעות כי החיבור מורשה לשלוח.
פתרון שמורכב משלושה חלקים
נדרשים שלושה רכיבים, ושלושתם חיוניים. שניים מתוך שלושה עדיין עלולים להשאיר את ההודעות בתיקיית הספאם.
חשבון SMTP שדרכו מתבצעת השליחה. במקום ששרת האינטרנט ישלח ישירות, האתר מזדהה מול שרת דואר ומעביר אליו את ההודעה. כל פלטפורמה תומכת בכך, באופן מובנה או באמצעות תוסף.
הגדרות DNS שמעניקות הרשאה. נדרשת רשומת SPF שמציינת את שרת השליחה, וכן חתימת DKIM שמצרפת להודעה חתימה שניתן לאמת. בלעדיהן גם שליחה מאומתת תיראה לנמען כשליחה ללא הרשאה. המדריכים שלנו בנושא SPF ובנושא DKIM מסבירים כיצד להגדיר את הרשומות עצמן.
כתובת שולח שקיימת בפועל. שליחת מייל מ-noreply@yourdomain.com כשאין תיבת דואר כזו היא אות שלילי קטן אך ממשי, והיא גם גורמת לתשובות להיעלם. יצירת התיבה אינה עולה כאן דבר, מכיוון שהחיוב אינו נעשה לפי משתמש.
הפרדה מהמיילים האישיים והעסקיים שלכם
כשהיקף השליחה עובר רף מסוים, כדאי להעביר את המיילים התפעוליים של האתר במסלול נפרד.
מיילים אוטומטיים ומיילים שנכתבים בידי אדם מתנהגים אחרת וגם נבחנים אחרת. גל של חמש מאות הודעות לאיפוס סיסמה בעקבות אירוע אבטחה אינו דומה כלל לאדם שכותב מיילים. אם שני הסוגים יוצאים באותו מסלול, המוניטין של התעבורה האוטומטית הופך גם למוניטין של התכתובת הרגילה שלכם.
פרופיל SMTP נפרד לכל דומיין מאפשר לבצע את ההפרדה בקלות: הפנו את הדומיין שממנו היישום שולח למסלול אחד, ואת הדומיין שממנו אנשי הצוות כותבים למסלול אחר. כך בעיה בצד אחד נשארת באותו צד. הוראות ההגדרה נמצאות במדריך SMTP מותאם לכל דומיין.
יש עסקים שמתקדמים צעד נוסף ומשתמשים בתת-דומיין נפרד לחלוטין למיילים אוטומטיים. כך המוניטין מבודד לגמרי, במחיר של כתובת שולח מעט פחות נקייה. הכדאיות תלויה בהיקף השליחה.
מתי ספק ייעודי למיילים תפעוליים הוא הפתרון הנכון
חשוב להבהיר בכנות את הגבול: כשמדובר בהיקף שליחה גדול באמת, יש סיבות טובות לקיומם של שירותים ייעודיים למיילים תפעוליים.
אם אתם שולחים עשרות אלפי הודעות ביום, תזדקקו לאירועי מסירה לכל הודעה, לקריאות webhook בעת החזרה, לניהול תבניות ולניתוח נתונים מפורט. זו כל מטרתם של המוצרים האלה, ואף שירות אחסון דואר אינו מספק את היכולות הללו באותה רמה.
המגבלות היומיות שלנו מתאימות לתכתובת ולא לקמפיינים. בחבילת Starter ניתן לשלוח 1,000 הודעות מכל תיבת דואר ביום, ובחבילת Agency עד 2,500. מיילים תפעוליים מאתר של חנות קטנה או מערכת הזמנות נכנסים בקלות לטווח הזה. פלטפורמה בנפח גבוה אינה מתאימה לכך, והמבנה הנכון עבורה הוא ספק מיילים תפעוליים שמחובר דרך פרופיל SMTP מותאם. כך אחסון הדואר והשליחה בכמויות גדולות נשארים נפרדים, בלי צורך בשני ספקים שונים לאחסון דואר.
איך לוודא שהכול באמת עובד
ההרגל החשוב ביותר הוא לבדוק במקום להניח, משום שתקלות בקטגוריה הזו אינן משמיעות קול.
הפעילו הודעה אמיתית, למשל בצעו הזמנת בדיקה או בקשו איפוס סיסמה, ושלחו אותה לכתובות אצל שני ספקי דואר גדולים ושונים. פתחו את כותרות ההודעה וודאו שבדיקות SPF ו-DKIM עברו וש-DMARC מציג התאמה תקינה. אם שלוש הבדיקות עברו, ההגדרה אכן הושלמה.
חזרו על הבדיקה מדי רבעון, וגם מיד לאחר שמישהו משנה את הגדרות ה-DNS או את שירות האחסון. מיילים תפעוליים מהאתר נשברים לרוב לא בשלב ההגדרה, אלא כשמשהו סמוך משתנה. איש כמעט אינו חושב לבדוק שוב את אישורי ההזמנה לאחר מעבר לשרתי שמות חדשים.
אם ההודעות מגיעות אך נוחתות בספאם, נתוני המסירה של הדומיין ודוחות DMARC יצביעו בדרך כלל על הסיבה מהר יותר מניחושים לגבי שינויים בתוכן.
