הקשר בין תהליכים ארגוניים לאימייל מרקטינג

הקשר בין תהליכים ארגוניים לאימייל מרקטינג

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

תוכן עניינים

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

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

עבור משתמשי אימייל, התפעול החלק של תקשורת האימייל כולל רק לחיצה על כפתור השליחה. 

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

המרכיבים הללו מסייעים לכך שאימיילים יגיעו לתיבות הדואר הנכנס של הנמענים (Email deliverability).

הבסיס לעבירוּת אימיילים טמון בהגדרה הטכנית של תשתית האימייל. על בסיס זה ישנם מספר אבני בניין, כולל “אימות דומיין”. עם ההנחיות החדשות למדוורים שנכנסו לתוקף ב- 2024, אימות הדומיין הפך להיות חובה, והוא מאפשר לצד המקבל (שרתי אימייל בצד של ספקיות האימייל) לאמת שלשולח יש הרשאה לשלוח אימיילים בשם הדומיין. 

אימות הדומיין מסתמך על שני פרוטוקולים SPF ו-DKIM ורשומות מתאימות ב-DNS של הדומיין. על גבי שני הפרוטוקולים הללו נבנה פרוטוקול DMARC שנועד להגן על דומיינים ומותגים מפני זיוף (spoofing) וניסיונות פישינג. 

פרוטוקול נוסף שתלוי בשלושת הפרוטוקולים הקודמים הוא BIMI – זהו הלוגו של המותג שמשמש כחותם שעווה מודרנית, בדרך כלל בשילוב עם תעודת VMC הדורשת סימן מסחרי רשום על הלוגו ומספקת לנמענים הוכחה חזותית לאותנטיות של הלוגו והדומיין השולח, או תעודה חדשה יותר שנקראת CMC שלא דורשת רישום סימן מסחרי, ומספקת לנמענים הוכחה חזותית לאותנטיות של הלוגו. ב-Gmail לא יופיע V כחול במקרה של תעודת CMC. 

ראו הרחבה במאמרים נפרדים על הפרוטוקולים לאימות הדומיין

הארגון (שלא) לומד

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

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

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

אתגר ה-DNS – הפרד ומשול

ה-DNS הוא רכיב קריטי של כל עסק. עבור עסקים רבים, רשם הדומיינים מנהל את ה-DNS של הדומיין שלהם, כלומר הניהול נשאר אצל הרשם – GoDaddy או Namecheap או רשם ישראלי כלשהו.

Cloudflare DNS comments

מומלץ שה-DNS ינוהל בנפרד למטרות אבטחה וגיבוי. כדי לעשות זאת, בעל הדומיין יכול להגדיר את רשומות ה-Name Server (רשומות NS) ברשם הדומיינים ולכוון את ניהול ה-DNS לשירות חיצוני.

אמנם הוא חווה שתי נפילות חלקיות לאחרונה, אך למרות הכל Cloudflare מציעה שרת DNS מאובטח ומופץ היטב (Propagated) עם למעלה מ-12,500 רשתות (Nodes) ברחבי העולם, והוא מהיר וחינמי. יש לו גם תכונה מעניינת שיכולה לעזור לאנשי ה-IT לארגן את הבלאגן ב-DNS: ניתן להוסיף שורת הערה לכל רשומה שמסבירה את מטרת אותה שורה ב-DNS ומי בארגון ביקש את הגדרתה ואפשר גם ליצור תג לכל רשומה לפי מערכות או מחלקות. 

אתגר ה-SPF

גם אנשי IT מנוסים בארגונים עושים לפעמים טעויות, כמו הוספת מספר רשומות SPF לאותו דומיין (אפשר רק אחת) או שימוש ברשומות SPF מיושנות ב-DNS (רשומת SPF שקיימת עדיין ב-DNS מסוימים אינה בתוקף. רשומת SPF תקינה היא מסוג TXT או CNAME בהתאם להגדרות פר מערכת מדוורת) . דאגה נוספת היא ש-SPF authentication עלול להיפגע עבור פלטפורמות אימייל מסוימות אם מחלקת ה-IT לא מפקחת על רשומות ה-DNS ועל הרלוונטיות שלהן. זאת משום שרשומת ה-SPF עלולה לחרוג מהמגבלה המותרת של עד עשרה חיפושי DNS מה שגורם לחלק מפלטפורמות האימייל להיכשל באימות SPF. יש פתרונות לבעיה הזו של DNS lookups, שעשויה לגרום לבעיות עבירוּת. במקביל, הרשאה לפלטפורמות לא רלוונטיות לשלוח הודעות בשם הדומיין טומנת בחובה סיכון אבטחתי ומטילה אחריות על הארגון.

האזנה לפודקאסט

אתגר ה-DKIM

דוגמה נוספת קשורה לרשומת ה-DKIM (פרוטוקול נוסף לאימות דומיין). ארגונים מסוימים יישמו DKIM לפני מספר שנים בגודל רשומה של 1024K (או אפילו 512K). לעומת זאת, כיום, בגלל שיקולי אבטחה, מומלץ ליישם רשומה בגודל 2048K.

שיקול אבטחתי נוסף –  מומלץ גם שרשומת ה-DKIM תוחלף (rotation) מעת לעת. לא תמיד ברור מי מטפל בהחלפת DKIM. האם ה-rotation מתבצע על ידי מערכת הדיוור או על ידי הארגון עצמו?

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

אתגר ה-DMARC

לפני כניסתן לתוקף ב- 2024 של “הדרישות החדשות למדוורים” שהציבו ספקיות האימייל הגדולות, אפשר היה לשלוח אימיילים מאומתים היטב ללא רשומת DMARC. אחד הדברים החדשים הבודדים ב”הנחיות החדשות” הוא ש-DMARC הפך להיות חובה. 

אם מסתכלים על רשומת ה-DMARC הטיפוסית המומלצת, כמעט כל מערכת דיוור ממליצה על הרשומה הזו: V=DMARC1; p=none. זו רשומה חסרת תועלת כי היא אינה כוללת את כתובת האימייל לקבלת דוחות DMARC (אין תג RUA). גם אם יש כתובת אימייל ברשומת ה-DMARC, לעיתים קרובות זו כתובת אימייל בתוך הארגון שאף אחד לא בודק, וגם אם מישהו כן בודק מידי פעם, אלו דוחות בפורמט XML וקשים לקריאה והבנה ללא כלי לניטור DMARC. זה כמו לראות פריים מתוך סרט.

המטרה של DMARC היא להגן על המותג ועל הדומיין. לצורך זה ארגונים צריכים לעבור את “מסע ה-DMARC” מ-p=none דרך p=quarantine ל-(רצוי) p=reject.

shared IP pool

דוחות DMARC משמשים כמנגנון גילוי שמאפשר לחשוף את כל הפלטפורמות ששולחות אימיילים בשם הדומיין. זה מגלה תשתיות שאף אחד בתוך הארגון לא זוכר שקיימות אבל עדיין שולחות אימיילים בשם הדומיין של הארגון, כמו שרתי פיתוח ישנים או מערכות ותיקות. חלקם  כבר לא רלוונטיים וניתן להפסיק אותם (להסיר רשומות מה-DNS), וחלקם דורשים תיקון של מנגנוני האימות וההתאמה (Authentication and alignment). 

אני רואה לפעמים רשומות DMARC במצב reject ללא כתובת דיווח (ללא RUA), וברור שמכיוון שאין דיווח, אף אחד לא עבר את מסע ה-DMARC. זה מצב קלאסי של לירות לעצמך ברגל. 

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

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

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

ראיונות בפודקאסט עם מומחי אימייל מרקטינג בינלאומיים

האזנה לפודקאסט
אני סלע יפה, מומחה אימייל מרקטינג ועבירוּת אימיילים. אני מזמין אותך לפגישת יעוץ ראשונית של 1/2 שעה ללא עלות בנושא עבירוּת אימיילים ואסטרטגיית אימייל מרקטינג. book an email deliverability discovery call.

לקריאה נוספת

 
Sella Yoffe
CEO , 

Email Deliverability & Email Marketing Expert 

Helping global email senders, startups, digital agencies, and ESPs with email deliverability, email authentication (SPF, DKIM, DMARC, BIMI), and email & content strategy

Podcast creator & Blogger @ CRM.BUZZ & EmailGeeks.Show

רוצה להתמקצע

באימייל מרקטינג?

אני סלע יפה. יועץ עבירוּת אימיילים ויוצר הבלוג והפודקאסט המובילים בנושא אימייל מרקטינג.

אני מזמין אותך להצטרף ולקבל גישה לקורס דיגיטלי בלעדי למנויי הניוזלטר

בנושא שיפור עבירוּת אימיילים

Close the CTA
הרשמה לניוזלטר
Scroll to Top

באתר זה נעשה שימוש בקבצי cookies. המשך גלישתך באתר מהווה הסכמה לתנאי השימוש ומדיניות הפרטיות באתר.

קבלת הכל