- Zen IT Technologies
- מסירת דוא״ל ומוניטין
המיילים שלכם נשלחים. זה לא אומר שהם מגיעים.
מסירת דוא״ל היא אחת מבעיות התשתית הבודדות שהלקוחות שלכם יכולים להרגיש לפני שאתם רואים אותה. מיילים לאיפוס סיסמה מפסיקים להגיע, קמפיינים מואטים בלי התראה, ודומיין יכול להישאר ברשימת חסימה במשך שבועות בלי שאף אחד יבחין. עד שהבעיה פוגעת בהכנסות, כבר יש גם נזק טכני וגם נזק למוניטין.
אנחנו מתכננים ארכיטקטורת שליחה שעומדת בדרישות שספקי תיבות הדואר הגדולים מציבים לשולחים, ומאתרים נזק למוניטין עד לרמת ההודעה הבודדת.
הבעיה
רוב בעיות המסירה הן בעיות ארכיטקטורה.
לחברות אין בעיית מייל אחת. יש להן ארבעה זרמי שליחה: מיילים טרנזקציוניים מהאפליקציה, התראות מוצר, קמפיינים שיווקיים ופניות יזומות מהמכירות. כולם יוצאים מאותו דומיין, חולקים מוניטין אחד, ומפילים זה את זה.
כשיש זינוק בתלונות ספאם על רצף פניות יזומות, אלה מיילי איפוס הסיסמה שמפסיקים להגיע. כשפלטפורמת השיווק מוגדרת לא נכון, זו החשבונית שנוחתת בזבל.
אימות הוא רק השכבה הראשונה. הכשלים שעולים כסף הם מבניים:
-
מוניטין משותף בין זרמי שליחה שלא אמורים להיפגש.
פניות יזומות בסיכון גבוה ומיילים קריטיים לעסק על אותו דומיין.
-
אימות חלקי או מדיניות ללא אכיפה.
רשומות SPF שחורגות מהמגבלה של 10 DNS lookups, חתימת DKIM על חלק מהזרמים בלבד, ו-DMARC שנשאר ב-p=none כבר שנתיים.
-
מוניטין ללא ניטור.
אין נכס ב-Google Postmaster Tools, אין רישום ל-Microsoft SNDS במקרים שבהם כתובות ה-IP בשליטתכם, ואין דרך לדעת שדומיין נחסם, עד שלקוח מספר לכם.
-
רשימות ישנות או קנויות.
מגדילות את החשיפה למלכודות ספאם ומביאות את שיעור התלונות לרמה שבה ספקי תיבות דואר מתחילים להאט או לדחות שליחה.
-
כשלים בתוכן ובתבניות.
מקצרי קישורים, דומייני מעקב עם מוניטין ירוד, תוכן מטעה, תוכן מוסתר ודפוסי עיצוב המזוהים עם דואר לא רצוי.
מה כוללת מסירת דוא״ל
זרמי שליחה
- דואר טרנזקציוני
- התראות מוצר
- דיוור שיווקי
- פניות יזומות
גבולות שליחה ומוניטין
תשתית שליחה
צד הנמענים
- ספקי תיבות דואר קבלה, סינון או דחייה
- שערי אבטחה ארגוניים סינון ארגוני לפני התיבה
החזרות, תלונות, אותות מוניטין וחסימות חזרה אל בקרות השליחה והמוניטין
ארכיטקטורת דומייני שליחה
-
תכנון אימות ואבחון מעמיק
אנחנו מתכננים, מטמיעים ומאמתים SPF, DKIM ו-DMARC בכל מקורות השליחה שלכם, כולל אלה שאף אחד לא תיעד, ו-ARC במקומות שבהם העברת דואר או מתווך בנתיב צריכים לשמר את תוצאות האימות ואת ההקשר שלהן עבור מערכות הקבלה בהמשך הנתיב. אנחנו מנקים ומאחדים רשומות SPF, מצמצמים DNS lookups מיותרים, מכניסים כל זרם שליחה תחת חתימת DKIM, ומעבירים את DMARC מניטור לאכיפה בלי לשבור דואר לגיטימי.
כשמיילים כבר נכשלים, אנחנו עובדים לאחור מתוך כותרות ההודעות ומדוחות ה-DMARC המצטברים, ומזהים בדיוק איזה מקור, איזה selector ואיזה כשל ב-alignment אחראי לבעיה.
-
ארכיטקטורת דומייני שליחה
אנחנו מפרידים בין דואר טרנזקציוני, התראות מוצר, דיוור שיווקי ופניות יזומות על פני תת-דומיינים ייעודיים, עם אימות נפרד לכל זרם. כך נוצרת הפרדה חזקה יותר של המוניטין בין שליחה בסיכון גבוה לבין דואר עסקי קריטי, ומצטמצם הסיכוי שזינוק בתלונות על פניות יזומות יפגע בדואר שהעסק שלכם תלוי בו.
זה כולל תוכניות חימום לתת-דומיינים חדשים, והגדרה של return-path ודומיין ההחזרות, כי SPF מאמת את שולח המעטפה ו-DMARC בוחן אם הדומיין הזה מיושר מול הדומיין שמופיע בשדה From, לפי מצב היישור שהוגדר לדומיין. לצד זה, החלטות על כתובות IP ייעודיות מול משותפות והגדרת פלטפורמות שליחה כמו SendGrid, Amplemarket ודומותיהן.
הדרישות שספקי תיבות הדואר מציבים לשולחים הן חלק מהתכנון ולא תיקון מאוחר: ביטול הרשמה בלחיצה אחת היכן שזה רלוונטי, נתיבי תלונה וביטול הרשמה שבאמת עובדים, ואימות עקבי על פני כל זרם, שנבנים מראש ולא אחרי שזרם כבר מואט. במקומות שבהם יש לעסק חובות משפטיות או חוזיות בנוגע להסכמה ולביטול הרשמה, אנחנו מיישמים אותן טכנית; ההחלטה מה הן אינה שלנו.
-
מוניטין, החזרות ואיכות נמענים
Google Postmaster Tools, ובמקומות שבהם כתובות ה-IP של השליחה בשליטתכם גם Microsoft SNDS, לצד טלמטריה מספקי הדיוור במקום אחד. אנחנו קובעים את קו הבסיס, מגדירים את הספים שבאמת חשובים, ומחליטים מי מקבל התראה כששיעור התלונות מתקרב לרמה שבה ספק מתחיל לפעול בעקבותיה.
החזרות, תלונות וביטולי הרשמה מגנים עליכם רק אם הם משנים את מה שקורה אחר כך. אנחנו מטמיעים חסימה של נמענים להמשך שליחה, כך שהחזרה קשה או תלונה עוצרות שליחה עתידית לאותה כתובת, מחברים feedback loops היכן שהספק מציע אותם, ומתייחסים לאיכות הרשימה כקלט למוניטין ולא כהעדפה שיווקית, כי רשימות ישנות או קנויות הן מהדרכים הסבירות ביותר להגיע למלכודת ספאם.
לדומיינים וכתובות IP שכבר נמצאים ברשימות חסימה אנחנו מטפלים בהסרה: זיהוי מקור החסימה, תיקון הסיבה שהובילה אליה, והגשת בקשות הסרה אחרי שהסיבה תוקנה, כדי שההסרה תחזיק לאורך זמן. בדיקת הודעות ותבניות נעשית מול המערכות שבאמת קובעות את התוצאה, מספקי תיבות הדואר ועד שערי האבטחה שיושבים לפני תיבות רבות בארגונים.
-
בקרות רב-דיירות וברמת השולח
כשפלטפורמה שולחת עבור הלקוחות שלה, הלקוחות עלולים למצוא את עצמם חולקים מוניטין אחד, ובלי בידוד השולח הגרוע ביותר קובע את התקרה לכל השאר. אנחנו מתכננים את ההפרדה שמונעת את זה: שליחה שמופרדת לפי רמת סיכון של לקוח, תקציב מוניטין לכל רמה, וויסות מול דומייני נמענים כדי שקמפיין אגרסיבי אחד לא יבזבז את מעמד הפלטפורמה מול ספק.
מתחת לזה יושבת בקרה ברמת השולח הבודד: סיווג קמפיינים, אימות רשימות, ניתוח תוכן וטלמטריית משוב, כך שצוות הפלטפורמה יכול לראות את התנהגות השולח ולפעול לגביה לפני שספק תיבות הדואר יפעל מול הפלטפורמה כולה.
מסמכים טכניים באנגלית
כש‑DKIM עובר בצד השולח ונכשל בצד הנמען
החתימה מכסה את התוכן לאחר נרמול. שינוי בהמשך עלול לפסול אותה.
עוד בנושא
איך זה עובד
-
ביקורת.
סקירה מתועדת של כל מקורות השליחה, רשומות האימות, דומייני המעקב ואותות המוניטין שיש לכם. אתם מקבלים קו בסיס כתוב, גם אם לא תמשיכו איתנו.
-
ארכיטקטורה.
תכנון שליחה הכולל הפרדת תת-דומיינים, תוכנית אימות ומעבר מדורג שלא פוגע בשליחה הקיימת.
-
הטמעה והעברה.
אנחנו בונים, מחממים ומאמתים.
אפשר לסיים את עבודת ההקמה במסירה מסודרת, כשהצוות שלכם ממשיך להפעיל את הניטור ואת נוהל העבודה. כשנדרש ליווי שוטף, אנחנו נשארים מעורבים כדי לעקוב אחר המוניטין, לחקור שינויים ולהתאים את התוכנית ככל שהתנאים משתנים.
דוגמאות מהשטח
-
מערך שליחה מורכב תוכנן מחדש לבידוד ולעמידות.
פלטפורמת SaaS עסקית
תעבורת הדואר הטרנזקציוני, השיווקי והפניות היזומות הופרדה לפי מטרה ולפי סיכון. האימות נבנה מחדש, גבולות מוניטין הוגדרו וניטור הוטמע, כך שהצוות הפנימי קיבל פלטפורמה שהוא יכול להפעיל באופן עצמאי.
-
פלטפורמת שליחה רב-דיירית נבנתה מחדש סביב רמות סיכון.
פלטפורמת SaaS
תשתית שליחה משותפת תוכננה מחדש סביב רמות סיכון של לקוחות, עם בידוד תעבורה, ויסות מול דומייני נמענים, תקציבי מוניטין ומשוב בזמן אמת, כך שכל רמה נושאת מוניטין משלה במקום מוניטין משותף.
-
בקרות ברמת השולח הבודד נבנו לתוך פלטפורמת שליחה מול לקוחות.
פלטפורמת SaaS
סיווג קמפיינים, אימות רשימות, ניתוח תוכן וטלמטריית משוב שולבו לשכבת בקרה אחת, כך שצוות הפלטפורמה יכול לראות התנהגות של שולח בודד ולפעול לגביה לפני שהיא פוגעת במוניטין ששאר המערך נשען עליו.
לפי בקשה, ניתן לתאם שיחה פרטית עם לקוחות או ממליצים, בכפוף להסכמתם מראש. דוגמאות הלקוחות כאן אנונימיות במכוון.
למי זה מתאים
לחברות שבהן דוא״ל הוא חלק מתשתית ההכנסות ולא רק כלי תקשורת, בדרך כלל באחד משלושה מצבים. חלקן מגיעות כשהבעיה כבר רצה: דואר שהתחיל לנחות בספאם, הודעות טרנזקציוניות שנעלמות בלי החזרה, מוניטין שיורד, או מערך שליחה שהתקבל בירושה ואף אחד לא יודע לתאר אותו במלואו. לחלקן יש כמה זרמים שעומדים על מוניטין אחד, דואר טרנזקציוני והתראות מוצר לצד דיוור שיווקי ופניות יזומות, לא פעם בכלים ובדומיינים שונים, והן מעדיפות להפריד את הסיכון לפני שהוא עולה להן במשהו. ויש פלטפורמות ששולחות עבור הלקוחות שלהן, ששם שולח אחד לא זהיר יכול לבזבז מוניטין שכל השאר נשענים עליו.
ההיקף אינו התנאי. חברה של ארבעים איש שאיפוסי הסיסמה שלה מפסיקים להגיע היא בעיה אמיתית, וחברה גדולה בהרבה עם ארכיטקטורת שליחה נקייה אולי לא צריכה אותנו בכלל.
העבודה עומדת בפני עצמה כפרויקט ממוקד, ואינה מחייבת שננהל את שאר הסביבה שלכם. היא יכולה גם להשתלב בליווי רחב יותר, וכשאנחנו כבר מנהלים את ה-DNS ואת מערכות השליחה הרלוונטיות, המערכות שצריך לשנות כבר נמצאות בתחום האחריות שלנו. המודל הנכון תלוי בשאלה אם הצוות שלכם רוצה לקחת אחריות על הניטור ועל נוהל העבודה, או להשאיר אותנו מעורבים.
שאלות נפוצות
-
למה הדואר שלנו מגיע לספאם כשה-SPF, ה-DKIM וה-DMARC כולם עוברים?
אימות הוא תנאי הכרחי ולא מספיק. שלושתם יכולים לעבור והדואר עדיין ייסונן, כי אימות קובע שדומיין אישר את ההודעה; הוא לא קובע שמערכת הקבלה תבחר להכניס אותה ל-Inbox. ההחלטה איפה ההודעה תונח מתקבלת אחר כך: לפי מוניטין הדומיין וה-IP, לפי היסטוריית תלונות ומעורבות, לפי השאלה אם דומיין השליחה משותף עם זרם בסיכון גבוה יותר, ולפי תוכן ודומייני מעקב שהמסננים שופטים בנפרד מהאימות.
-
אין לנו החזרות. זה אומר שההודעות הגיעו לתיבה?
לא. החזרה סופית אומרת שההודעה לא התקבלה למסירה, והיעדר החזרה לא מוכיח שהיא הגיעה לתיבת הדואר הנכנס. ההודעה עשויה עדיין להמתין בתור אחרי דחייה זמנית, או להתקבל ואז להיות מסווגת לספאם, לנחות בתיקייה שאף אחד לא מסתכל בה, או להיסנן על ידי המערכת המקבלת אחרי שהתקבלה. ברגע שהתשתית המקבלת קיבלה הודעה, הטלמטריה בצד השולח מאשרת בדרך כלל את הקבלה ולא את המקום שאליו אותה מערכת הניחה אותה בסוף. אותות מוניטין מהספקים, feedback loops היכן שהם קיימים ונתוני מעורבות מצמצמים את הפער, ואנחנו נאמר לכם מה מתוכם באמת נראה עבור הזרמים שלכם, אבל לאף שולח אין ראייה מלאה של ההגעה ל-Inbox.
-
מה בעצם נשבר כשעוברים לאכיפת DMARC?
כל מקור שליחה לגיטימי שאינו מיושר כראוי: בדרך כלל פלטפורמת שיווק, מערכת CRM, מערכת חשבוניות או הסדר העברת דואר שאף אחד לא תיעד. בדיוק לכן מגיעים לאכיפה בשלבים, ומשתמשים בדוחות המצטברים כדי לאתר כל מקור לפני שהמדיניות מתהדקת ולא אחרי.
-
האם דיוור שיווקי ודואר טרנזקציוני צריכים לשבת על אותו דומיין?
לא. אפשר לשמור על אותו דומיין שורש לצורך זיהוי, אבל להשתמש בתת-דומיינים נפרדים כדי ליצור הפרדה חזקה יותר של המוניטין. כך זינוק בתלונות על קמפיין פחות צפוי להשפיע על איפוסי סיסמאות ועל קבלות. Cold outreach צריך הפרדה נוספת, ובדרך כלל דומיין נפרד לגמרי.
-
צריך IP ייעודי?
לא אוטומטית, וזה לא השדרוג שלפעמים מוכרים. IP ייעודי מבודד אתכם משולחים אחרים ונותן שליטה, ובתמורה הופך אתכם לאחראים הבלעדיים למוניטין שלכם: צריך לחמם אותו, והוא זקוק להיקף עקבי מספיק כדי לבסס מוניטין משלו ולשמור עליו. בהיקף נמוך או לא סדיר, מאגר משותף שמנוהל היטב יכול לתפקד טוב יותר, כי השליחה שלכם נשענת על מאגר שהתעבורה הקיימת בו כבר ביססה לו מוניטין יציב. ההחלטה נגזרת מההיקף, מהעקביות ומכמה בידוד הזרמים באמת צריכים.
-
אנחנו שולחים עבור הלקוחות שלנו. איך מונעים ששולח אחד יפגע בכל השאר?
בכך שדואגים שלא כולם עומדים על אותו מוניטין. הלקוחות מופרדים לרמות סיכון עם מאגרי שליחה ודומיינים משלהם, כשכל רמה נושאת תקציב מוניטין שהיא יכולה לבזבז בלי לבזבז את זה של כולם, ולצד זה ויסות מול דומייני נמענים כדי שקמפיין אגרסיבי אחד לא יכלה את מעמד הפלטפורמה מול ספק בתוך אחר צהריים. מתחת לזה, טלמטריה ברמת השולח, סיווג קמפיינים ואימות רשימות הופכים את התנהגות השולח הבודד לגלויה מוקדם. זו כל הנקודה: אתם רוצים לפעול מול שולח לפני שספק תיבות הדואר יפעל מול הפלטפורמה.
-
כמה זמן לוקח לשקם מסירה?
תלוי במה שגרם לזה, ובשאלה אם ההתנהגות שגרמה לזה באמת נפסקה. שינויי אימות וארכיטקטורה יכולים להיכנס לתוקף מהר, אחרי שהשינויים ב-DNS ובפלטפורמה מתפשטים. המוניטין עצמו משתנה בקצב של הספקים המקבלים ומול ההיסטוריה שלכם, ולכן דומיין עם רקורד נקי וארוך משתקם אחרת מדומיין ששלח לרשימות ישנות במשך שנה. מה שאנחנו מתחייבים אליו הוא החלק שבשליטתנו: זיהוי הסיבה ותיקונה, תיקון השליחה, הגשת בקשות הסרה אחרי שהסיבה נעלמה, ומעקב אחרי אותות המוניטין כדי שתראו לאן הדברים מתקדמים. אפשר להעריך מתוך האותות ולהראות אם הכיוון משתפר, אבל אף אחד לא יכול להתחייב באמת לתאריך שבו ההגעה ל-Inbox תשתקם.
-
אתם צריכים לנהל את סביבת ה-IT שלנו כדי לעבוד על מסירת דוא״ל?
לא. מסירת דוא״ל עובדת היטב כפרויקט עצמאי: בחינה ואבחון של מערך השליחה, הארכיטקטורה והתיקונים שנדרשים כדי להגיע אליה, ואז מסירה לידיים שלכם עם הניטור ונוהל העבודה. ניטור שוטף אחר כך הוא אופציונלי. גם אין צורך להחליף פלטפורמת שליחה, כי הארכיטקטורה חשובה יותר מהספק והרבה פלטפורמות קיימות יכולות לתמוך בתכנון הנכון; כשאנחנו ממליצים על שינוי, זה בדרך כלל בגלל הפרדת זרמים ולא בגלל הפלטפורמה עצמה. אם אנחנו כבר מנהלים את ה-DNS או את מערכות השליחה הרלוונטיות, התיאום פשוט יותר, אבל זה לא תנאי.
בואו נגלה לאן המיילים שלכם באמת מגיעים.
שיחה של 30 דקות עם ג׳וני לסקירת מערך השליחה שלכם, ולאחריה קו בסיס כתוב אם יש התאמה. נחזור אליכם תוך יום עסקים אחד.