די בפסיק שאינו במקום, או תו מיותר כדי שייווצר כשל באימות הדומיין, שיוביל לחסימה או לפגיעה בעבירוּת. אל תעשו את הטעויות האלה. סיפוי לקוחות
תוכן עניינים
סינדרום התחת הגדול והשמיכה הקטנה
לאימות הדומיין במערכות המדוורות אני מתייחס כאל “סף הכניסה לעבירוּת”. זה הצעד הראשון שמדוורים יכולים לעשות כדי לקחת על עצמם את הבעלות על ה-reputation שלהם. עבירוּת נשענת על כמה עמודי תווך כששלושת העיקריים הם ה-reputation של כתובת ה- IP (הכוונה לכתובות ה-IP של שרתי הדיוור שלרוב המדוורים אין עליהן שליטה), ה-reputation של הדומיין (הדומיין שלנו, לרבות ה-reputation של סיומת ה-TLD של הדומיין, ה-reputation של רשם הדומיינים), התוכן והקישורים שמצורפים לדיוור (אל דומיינים חיצוניים) ועוד כמה וכמה גורמים משפיעים.
אני כותב מערכות מדוורות ולא רק "מערכת דיוור", כי כמעט בכל עסק יש לאימייל כמה וכמה תפקידים. אימיילים עסקיים ישלחו משירות כגון Microsoft 365 או Google Workspace ואימיילים שיווקיים ישלחו ממערכת דיוור. אך פעמים רבות יש לאימייל תפקידים נוספים טרנזקציוניים (כגון אישור הזמנה, איפוס סיסמה, דיוור של מייל הצטרפות לרשימת דיוור) ואימיילים תפעוליים (כגון דוחות וחשבוניות).
אני קורא לזה סינדרום התחת הגדול והשמיכה הקטנה, כי פעמים רבות קיים קונפליקט בין מחלקות תחת אותו דומיין. אני כיעוץ עבירוּת חייב לוודא שכל צורכי האימייל של הארגון יבואו לידי ביטוי ללא הפרעה. בשל שיקולי ניהול reputation השאיפה היא לא לשים את כל ה-reputation תחת הדומיין הראשי. הפרקטיקה הרווחת היא לנהל פעילויות דיוור שונות (email streams) תחת תת דומיינים (sub-domain). מהדומיין הראשי ישלחו האימיילים העסקיים (365, GWS) וינוהלו תת דומיינים נפרדים עבור פעילויות הדיוור שונות (טרנזקציוני, תפעולי, שיווקי).
אנו לא רוצים שפעילות דיוור שיווקית (קמפיינים, ניוזלטרים וכולי) תפריע לפעילות טרנזקציונית ושפעילות תפעולית תפריע לפעילות טרנזקציונית. ההפרדה תכלול הפעלת שרתי דיוור שונים עבור סוגי הפעילויות השונות ולא רק הפרדה לתתי דומיינים. ניתן להשתמש בתת דומיינים תחת דומיין ראשי ללא הגבלה (וזה לא עולה יותר).
ראו הרחבה במאמרים: הדברים הקטנים המשפיעים על domain reputation וגם החשיבות של הפרדת דיוורים
האזנה לפודקאסט
פודקאסט ובלוג העוסקים בנושאי אימייל מרקטינג, שיווק, ודאטה
הגעתם אל הבלוג והפודקאסט המובילים והמעודכנים ביותר בעברית בנושא אימייל מרקטינג ועבירוּת מיילים (email deliverability) הכולל עשרות מאמרים עומק ופודקאסטים בנושא אימייל מרקטינג למתחילים ומתקדמים ומכסה את התחום בצורה מקצועית.
אימייל מרקטינג הוא ערוץ ותיק, אבל אולי דווקא בגלל שהוא ”הסבא” של המדיה הדיגיטלית הוא לא מקבל את תשומת הלב וההתמקצעות הראויה.
אבל זה הולך ונהיה קשה… כדי להצליח באימייל מרקטינג צריך להתמקצע ולא לסמוך רק על כך שהפלטפורמה (מערכת הדיוור) תעשה את הכל.
אפשר למצוא כאן עשרות מאמרים ופודקאסטים מקצועיים ומפורטים בנושא אימייל מרקטינג, עבירוּת אימיילים, סקירת מערכות דיוור, אוטומציה שיווקית, שיווק באמצעות תוכן, אימייל מרקטינג עבור איקומרס, טיפים לשיווק במייל ועוד.
a blog and a podcast (in Hebrew) about email marketing email deliverability, marketing and data.
סיבה חשובה נוספת ליצור הפרדות דיוור קשורה במגבלות ה-lookup (מספר הקריאות אל ה-DNS על מנת לפענח את הרשומה) של רשומת SPF לאימות הדומיין. מגבלת ה-lookups היא עד 10 lookups. ניתן לראות בדוגמא כי הוספת 4 אימותים במקרה הזה יוצרת 7 Lookups.
שכיח לראות טעויות באימות הדומיין שיוצרת overflow על ה-SPF וחריגה ממגבלת ה-lookups מה שעשוי ליצור בעיות בחלק מרשומות האימות דבר שיפתח בעיות עבירוּת ועשוי להוביל לחסימות.
ראו הרחבה במאמר: רשומת SPF וגם חשיבות ה-DNS לפעילות אימייל תקינה
DNS הוא תשתית קריטית בכל עסק ובוודאי לפעילות תקינה של אימייל והגדרות שגויות יכולות ליצור בעיות עבירוּת. מספיק שפסיק או תו לא במקומם.
אימות הדומיין מבוצע על ידי הטמעת רשומות ב-DNS של הדומיין. ה-DNS הוא מנגנון קריטי לפעילות כל מה שקשור בדומיין ובשירותים הקשורים בדומיין, לרבות אימייל. ישנם סוגים שונים של שרתי DNS והם נבדלים ביכולות שלהם, באופן בו מוטמעות הרשומות, בנוחות התפעול ובתפוצתם ויכולות השרידות שלהם (המידע מופץ ומשתכפל בחוות שרתים רבות סביב העולם). רשמי הדומיינים מציעים בעת רישום הדומיין שירות DNS ועסקים רבים מאוד ממשיכים לנהל את ה-DNS אצל רשם הדומיינים. בעיני זו טעות ותמיד עדיף להפריד את ה-DNS מרשם הדומיינים או את ה-DNS מהאתר (קשה או לא ניתן לעשות זאת ב-WIX למשל).
כדי להפריד בין רשם הדומיינים ל-DNS, לאחר רישום אתר (או אם יש לכם כבר דומיין) היכנסו לפאנל הניהול ברשם הדומיינים וחפשו היכן משנים את "שרתי השם" (Name Servers). פיתחו חשבון ב-Cloudflare (שרת ה-DNS המהיר בעולם. יש לו שתי נקודות אירוח בישראל ועוד רבות מאוד סביב לעולם) והעבירו את הדומיין לניהול ב-Cloudflare.
בשלב הזה תקבלו שתי רשומות כדי להטמיע ברשם הדומיינים במקום השרתים הקיימים. צרו גיבוי של ה-Zone (הרשומות הקיימות) ב-DNS הישן לגיבוי. העברת ה-DNS שואבת את הרשומות מהשרת הישן. לא כל הרשומות נדרשות ושכיח שרשמי דומיינים דוחפים רשומות מיותרות ל-DNS שרלוונטיות לשירות שלהן אך לא יהיו פעילות או אף יזיקו לאחר המעבר. לכן כדאי לדעת מה שעושים ולדעת לבקש סיוע מקצועי בעת הצורך.
אנשים חושבים שאימייל זה קל כי כל מזכירה יודעת לשלוח אימייל…
אבל מאחורי הקלעים זה עולם ומלאו שהבסיס שלו הוא טכנולוגי ודורש הבנה והתעמקות בקוצו של יוד.
מדוור ענק, טעות קטנה, חסימה גדולה
לקוח גדול שאני מלווה מספר חודשים מנהל תשתית דיוור פנימית (שרתי MTA עצמאיים) ומדוור כמה מיליוני אימיילים ביום. על דעת עצמו וללא סיוע מתאים הלקוח ביצע מעבר בין שירותי DNS בשיטת copy paste. ה-DNS היה מוגדר מצוין בשירות הקודם והכל עבד כמו שצריך בהקשר של ה- DNS עד המעבר אל שרת Route53 ה-DNS של Amazon. ואז הדברים התחילו להשתבש. הלקוח פנה אלי ותיאר סיטואציה של חסימות של כתובות IP ב-Spamhaus. בדיקת החסימה התגלתה כ-CSS המצביעה על שרתים שלא מוגדרים נכון.
מה קרה?
כל שרת DNS מתנהג אחרת. שרת Route53 של אמזון דורש ברשומות TXT למשל לשרשר רשומות ארוכות. כך קרה שה- DKIM שהוגדר באורך 2048 נשבר ואימות הדומיין שלהם נכשל, מה שהוביל בווליום שהם שולחים לחסימה קריטית של כל השרתים המדוורים. כמו כן לא הוגדר PDR (reverse DNS) על הכתובות לאחר המעבר ל-DNS החדש.
מה אפשר היה לעשות אחרת כדי למנוע את הבעיה שנוצרה?
במעבר DNS או ביצוע שינויים ב-DNS (שפעמים רבות יש גישה אליו ליותר מידי אנשים) כדאי לבדוק את אימות הדומיינים מחדש ולוודא שההגדרות תקינות. זו פעולה שכדאי לעשות תקופתית בדיוק מאותה סיבה. בדיקה יכולה להתבצע על ידי שליחת אימייל לשירות כגון kbxscore.com שמחזיר דוח של מצב האימות.
אימות דומיינים באימייל העסקי
לקוחות רבים שמשתמשים ב-Google Workspace פונים אלי עם בעיה – אימיילים שלהם שולחים מגיעים לספאם אפילו כשהם מתכתבים לכאורה "בתוך הארגון" עם יוזרים אחרים בדומיין העסקי.
מה קרה?
בחלק גדול מהמקרים האלה הסיבה לכך נובעת משימוש באימייל העסקי לצרכי דיוורים שיווקיים באופן כזה שפוגע בדומיין .זה שכיח בקרב מי שעושים cold email. אך פעמים רבות הבעיה נובעת מכך שגם ב-Google Workspace וגם ב- Microsoft 365 הוספת הדומיין אינה מוסיפה רשומות SPF ו-DKIM לאימות הדומיין וזו פעולה שצריך לבצע בנוסף לאחר הוספת הדומיין לשירות האימייל.
מה אפשר היה לעשות אחרת כדי למנוע את הבעיה שנוצרה?
במסך ה-Admin בחלונית העליונה (רלוונטי גם ל-GWS וגם ל-365) חפשו DKIM במסך האימות ושם תראו את הסטטוס של האימות. בדוגמא שבתמונה אפשר לראות שהסטטוס הוא: "לא מתבצע אימות אימייל". כלומר הדומיין אינו מאומת עם רשומת DKIM.
לכן ניצור את הרשומה ב-DNS של הדומיין. זו רשומות TXT המורכבת משני חלקים: החלק הראשון הוא המפריד (S= Selector) של הדומיין במקרה הזה google._domainkey שצריך לרשום או להדביק ב-name ברשומת ה-TXT ב-DNS והחלק השני הוא מפתח ה-DKIM הציבורי שאותו יש להדביק בחלונית השנייה. לשים לב לא להשמיט אף תו ולוודא שאין רווחים (למה Google לא שמו כפתור copy? היה יכול לחסוך טעויות).
באופן דומה ב-Microsoft 365 מחפשים באפליקציית admin בחלונית העליונה DKIM, מגיעים לרשימה של דומיינים המוגדרים במערכת מסמנים את הדומיין ומזיזים את הכפתור. יתקבלו שתי רשומות CNAME שיש להקים ב-DNS של הדומיין.
הטמעת SPF ב-365 וב-GWS נעשית באמצעות רשומת TXT. שימו לב לא לעשות טעות שרבים עושים ולהוסיף כמה רשומות SPF על אותו דומיין. מותר רק רשומה אחת וכאמור מספר ה-lookups יכול להיות עד 10.
*** Microsoft 365 SPF (TXT record)
v=spf1 include:spf.protection.outlook.com -all
*** Google Workspace SPF (TXT record)
v=spf1 include:_spf.google.com ~all
*** Example of inclusing Google Workspace and one other service
v=spf1 include:_spf.google.com include:spf.sendinblue.com ~all
אם יש לכם רשומות SPF נוספות תחת הדומיין צריך לאחד אותן לרשומה אחת, כמודגם בתמונה למעלה.
למה DMARC?
DMARC אינו פרוטוקול לאימות דומיין וניתן לשלוח אימיילים גם ללא DMARC. מערכות דיוור רבות דורשות מהלקוח להציב רשומת DMARC חסרת משמעות ב-DNS שלא תשפר ללקוח את העבירות.
יישום DMARC באמצעות כלי יאפשר לנטר את הדוחות, לזהות תשתיות דיוור שדורשות טיפול ולהתקדם באבולוציה של אימות DMARC על למצב אכיפה בו אפשר לצפות לשיפור בעבירוּת. זו אבולוציה של לפחות 3 חודשים, כחודש בכל שלב.
לדוגמא:
format: TXT record
Host: _dmarc.domain.co.il
Value: v=DMARC1; p=none; adkim=r; aspf=r
כלי הטמעה וניטור DMARC נפוצים
| שם הכלי | הערות |
| dmarcly | |
| dmarcian | |
| kdmarc | |
| dmarcanalyzer | |
| easydmarc | value for money |
| dmarcdigests | value for money |
| dmarcreport |
ראו הרחבה במאמר על רשומת DMARC
רוצה להתייעץ איתי לגבי שיפור האימייל מרקטינג או עבירוּת המיילים שלך? אני מזמין אותך לפגישת ייעוץ ראשונית של 1/2 שעה, ללא עלות.
לקריאה נוספת
אודות הכותב
סלע יֹפֶה
מלווה חברות, עסקים, סטרטאפים ומערכות דיוור בארץ ובעולם בנושא עבירוּת אימיילים (email deliverability) ואסטרטגיית אימייל מרקטינג כדי שאימיילים שעסקים שולחים יגיעו ל-Inbox ולא אל ה-Spam.
יוצר הבלוג והפודקאסט crm.buzz
