הדרישות של ספקיות האימייל הגדולות הפכו את DMARC לסטנדרט חובה עבור מדוורים, אבל רבים מיישמים אותו בצורה שגויה - גם חברות גדולות ומנוסות. טעויות בהגדרה עלולות להשאיר את הדומיין שלכם חשוף להתחזות ולפגוע בעבירוּת האימיילים שלכם. במאמר זה תגלו את הטעויות הנפוצות בהטמעת DMARC ואיך להימנע מהן.
תוכן עניינים
האזנה לפודקאסט
פודקאסט ובלוג מובילים בעברית בנושאי אימייל מרקטינג (email marketing) ועבירוּת אימיילים (deliverability).
הגעתם אל הבלוג והפודקאסט המובילים והמעודכנים ביותר בעברית בתחום אימייל מרקטינג, עבירוּת אימיילים, שיווק ודאטה. כאן תמצאו שפע מאמרים מפורטים ופודקאסטים מקצועיים למתחילים ולמתקדמים, המכסים את התחום בצורה מעמיקה.
חלק מהפרקים כוללים ראיונות עם מומחי אימייל מרקטינג בינלאומיים מובילים, המשולבים בעברית.
אימייל מרקטינג הוא ערוץ ותיק, אך דווקא בגלל שהוא “הסבא” של המדיה הדיגיטלית, הוא לא תמיד זוכה לתשומת לב והמקצועיות הראויה. היום הולך ונהיה קשה יותר להגיע לאינבוקס. כדי להצליח באימייל מרקטינג, יש להתמקצע ולא להסתמך רק על הפלטפורמה (מערכת הדיוור) שתעשה את הכל.
בבלוג ובפודקאסט תמצאו מידע מקיף ועדכני בנושאים כמו אימייל מרקטינג, עבירוּת אימיילים, סקירות מערכות דיוור, אוטומציה שיווקית, שיווק באמצעות תוכן, אימייל מרקטינג לאיקומרס, טיפים לשיווק במייל, דיוור בסטארטאפים ועוד.
יוצר הפודקאסט והבלוג, סלע יפה, הוא מומחה בינלאומי לעבירוּת אימיילים ושיווק באימייל. הוא מסייע למדוורים גלובליים, סטארטאפים, סוכנויות אימייל ומערכות דיוור (ESPs) בנושאי עבירוּת אימיילים, אימות אימייל (SPF, DKIM, DMARC, BIMI) ואסטרטגיית אימייל.
A blog and podcast (in Hebrew) about email marketing, email deliverability, marketing, and data.
DMARC והטעויות
על טעויות נפוצות בהגדרות DMARC, למה זה חשוב וכיצד להימנע מהן.
אחת מהדרישות המנדטוריות של ספקיות האימייל הגדולות שהוצגו ב2024 היתה להגדיר רשומת DMARC.
התחלתי פרויקט מחקר עצמאי שיבדוק את רוב הדומיינים הרשומים על ידי עסקים בישראל. לפי איגוד האינטרנט בישראל ישנם כ-287 אלף אתרים בסיומת IL.
בפרויקט אבחן הביטים שונים הקשורים בדיוור. בין השאר אתמקד ברשומות DMARC בדומיינים הללו.
כשלב ראשון בפרויקט לקחתי את 1000 האתרים הפופולריים בישראל – לא כולם ישראלים – ובדקתי את מצב רשומת DMARC שלהם. הממצאים מפתיעים. בהמשך הפודקאסט אציג אותם…
אבל קודם כל בואו נדבר על הטעויות הנפוצות הקשורות ב-DMARC ואולי עוד קודם לכן – מה זה בכלל DMARC.
—
CRM.BUZZ הוא בלוג ופודקאסט בעברית העוסקים באימייל מרקטינג, עבירוּת אימיילים ושיווק.
יוצר הפודקאסט והבלוג הוא סלע יפה (Sella Yoffe), מומחה בינ”ל לעבירוּת אימיילים ושיווק באימייל, מסייע למדוורים גלובליים, סטרטאפים, סוכנויות אימייל ומערכות דיוור (ESPs) עם מסירות אימייל, אימות אימייל (SPF, DKIM, DMARC, BIMI), ואסטרטגיית אימייל.
הטעויות בהטמעת DMARC ואיך למנוע אותן
אחת מהדרישות המנדטוריות של ספקיות האימייל הגדולות שהוצגו ב2024 היתה להגדיר רשומת DMARC.
התחלתי פרויקט מחקר עצמאי שיבדוק את רוב הדומיינים הרשומים על ידי עסקים בישראל. לפי איגוד האינטרנט בישראל ישנם כ-287 אלף אתרים בסיומת IL (נכון ליולי 2025).
בפרויקט אבחן היביטים שונים הקשורים בדיוור לגבי הדומיינים הללו. אבחן אילו מערכות מדוורות מהדומיין, אילו מערכות מקבלות אימיילים עבור הדומיין, מה הסטטוס של רשומת DMARC בדומיינים הללו והאם זו רשומה תקינה ועוד.
כשלב ראשון בפרויקט לקחתי את 1,000 האתרים הפופולריים בישראל (לא כולם ישראלים) ובדקתי את מצב רשומת DMARC שלהם. הממצאים מפתיעים. בהמשך המאמר אציג אותם…
אבל קודם כל בואו נדבר על הטעויות הנפוצות הקשורות ב-DMARC ואולי עוד קודם לכן: מה זה בכלל DMARC.
פרוטוקול DMARC ראשי תיבות של Domain-based Message Authentication, Reporting & Conformance הוא פרוטוקול אבטחת אימייל שנועד להגן על דומיינים ומותגים ומאפשר לבעלי הדומיין לקבוע מדיניות (Policy) המורות לצד המקבל (ספקיות אימייל) כיצד לטפל בהודעות אימייל שאינן מאומתות ולקבל דוחות לגבי האוטנטיקציה (authentication) וההתאמה (alignment) של SPF ו-DKIM (פרוטוקולים לאימות הדומיין), לדומיין המדוור.
ראו הרחבה במאמרים נפרדים על אימות דומיינים במערכת דיוור.
כמי שמלווה גופים מדוורים בנושא עבירוּת אימיילים דוחות DMARC מספקים לי המון מידע שמסייע לי למפות את פעילות האימייל בארגון (בארגונים רבים יש ערוצי דיוור שונים המדוורים באמצעות מערכות שונות) ולטפל בהתאם.
למרות היותו כלי סייברי, בשנים האחרונות DMARC הפך לעוד שכבת הגנה שרוכבת בעל DKIM ו-SPF ומספקת context (הֶקשר) בין שני הפרוטוקולים פר מקור שולח. הדקויות בהגדרה נכונה של DMARC מאפשרות לגורם המדוור לעשות מסע DMARC שבסופו של דבר, מוסיף למדוור “נקודות עבירוּת”, לעומת זאת הגדרה לא נכונה של DMARC שעשויה לגרום לנזק למדוור.
החובה להגדיר DMARC הוכנס כתנאי סף על ידי ספקיות האימייל הגדולות כמו Gmail, Yahoo ואחרות (כיום גם Microsoft) ומדוורים הנחשבים bulk senders מחויבים כעת לפרסם רשומת DMARC תקינה לדומיין שמהם הם מדוורים, לפחות במדיניות p=none שמשמשת למעקב בלבד.
למרות זאת, ארגונים רבים עדיין מזניחים את DMARC או מיישמים אותו באופן שגוי: לא רק עסקים קטנים, אלא אפילו בנקים, חברות ביטוח משאירים פרצות המאפשרות התחזות שעלולה לסכן את הלקוחות שלהם. מקרים כאלה קרו גם פה בארץ ודיחחתי על כך בפודקאסטים קודמים.
ראו הרחבה במאמרים נפרדים: הדרישות החדשות של ספקיות האינטרנט הגדולות. כעת כל ספקיות האימייל הגדולות אוכפות את הדרישות גם מיקרוסופט מצטרפת למשחק.
במאמר זה אסקור את הטעויות הנפוצות ביותר בהגדרת DMARC ואסביר כיצד ניתן למנוע אותן.
טעות I – לא מפרסמים רשומת DMARC
הטעות הנפוצה ביותר וזו שהכי קל לתקן היא פשוט לא לפרסם רשומת DMARC.
עומדים כיום לרשות מדוורים מכל סוג ובכל תקציב מבחר כלים המאפשרים להגדיר ולנטר DMARC . מכלים חינמיים פשוטים דרך כלים בתשלום ברמות שונות.
ראו הרחבה במאמר על DMARC ושם יש רשימה של כלים מומלצים. אשים את הקישור למאמר גם ב-show notes.
טעות II – מפרסמים רשומת DMARC שגויה או חסרת ערך (שגיאות תחביר, ללא דיווחים)
טעות נפוצה נוספת היא הטמעת רשומת DMARC באופן שגוי, בין אם בגלל שגיאת תחביר (typo) ברשומה ובין אם בגלל הגדרה רשומה חסרת תועלת (useless record). למשל, יש מי שמפרסמים רשומת DMARC ללא כתובת לקבלת דוחות (ללא RUA) שהופך אותה לחסרת תועלת למעשה. במערכות הדיוור בד”כ כשקבלו את הרשומות להגדרת אימות הדומיין שלכם, תתבקשו להגדיר רשומת DMARC חסרת תועלת שכזו.
מערכות הדיוור נוטות להציע לכם לשים רשומה שאינה תקינה, מאחר ורשומת DMARC היא לא באחריותן של מערכות הדיוור, אלא באחריותם של המדוורים. כדי לצאת “ידי חובה”, הן מציעות רשומה שאינה תקינה שאינה כוללת את התג RUA.
לעיתים קרובות אי הוספת הרשומה כלל או הסופת רשומה חסרת תועלת נובע מאי־היכרות עם הפרוטוקול, או מהסתמכות עיוורת על הגדרות ברירת (שאינן תקינות) מחדל שמציעות מערכות הדיוור.
למעשה, חלק ממערכות הדיוור ממליצות למשתמשיהן על רשומת DMARC חלקית, לדוגמה: v=DMARC1; p=none ללא שום פרמטר נוסף. רשומה כזו היא חסרת ערך ואפילו עלולה להזיק. גם רשומה בנוסח v=DMARC1; p=reject לבדה, ללא כתובת לדיווח וללא הגדרות נוספות היא רשומה גרועה ועשויה לפגוע בעבירוּת של הדומיין, משום שהיא לא מספקת למדוור כל משוב או יכולת זיהוי תקלות בזמן אמת. היא אף מורה לצד המקבל לדחות את האימיילים במקרה שאין התאמה או חוסר באימות ברשומות SPF ו-DKIM.
ללא כתובות דיווח, בעלי הדומיין לא יקבלו דוחות DMARC ולא יוכלו להפיק מהם את התובנות החשובות לגבי מקורות אימייל בלתי מוכרים, ולא יבחינו אם אימיילים לגיטימיים נכשלים באימות. הדרך הנכונה לפתור את זה היא להגדיר רשומת DMARC מלאה ותקינה באמצעות כלי לניטור DMARC.
טעות נוספת תחת הקטגוריה הזו היא הטמעת Policy שאינו בשפה נתמכת. אנשים שאינם דוברי אנגלית מחפשים מידע ברשת לגבי הגדרה נכונה של DMARC ונתקלים במידע באנגלית אך משתמשים בתרגום אוטומטי אל שפת המקור שלהם. כך נוצר מצב של הגדרות Policy בשפות שונות שלא נתמכות, על ידי תרגום המילים none, quarantine, reject לשפות זרות שאינן נתמכות. גם סתם שגיאות כתיב בשמות ה-Polices יוצרים הגדרה שגויה.
טעות III – מפרסמים יותר מרשומת DMARC אחת.
שכיח לגלות שמוסיפים רשומת DMARC חדשה מבלי לבדוק האם קיימת כבר רשומה. מותר להגדיר רק רשומת DMARC אחת לכל דומיין. באמצעות טאג SP ניתן להגדיר מדיניות שונה לסאב דומיינים. במקרים מסוימים נרצה להגדיר DMARC נפרד עם הגדרות וטאגים ספציפיים לסאב דומיינים מסוימים המשמשים לדיוור. אבל תמיד תהיה רשומת DMARC אחת לכל דומיין.
טעות IV – השארת מדיניות DMARC במצב P=none לצמיתות
אחת הטעויות הנפוצות בקרב מדוורים שמטמיעים DMARC, אפילו אם ההגדרה נכונה ומיושמת באמצעות כלי ניטור, היא להתחיל במדיניות p=none (מצב ניטור בלבד) אך להישאר את המצב כך לטווח הארוך. פעמים רבות הדבר נובע מההנחה ש”סימנו וי” רק מעצם פרסום הרשומה, בלי הבנה ש- DMARC אינו מנגנון של “הגדר ושכח”. למעשה, DMARC דורש תחזוקה שוטפת: יש לעקוב באופן קבוע אחר הדוחות, לנתח התראות (שמתקבלות באימייל), ולתקן בעיות שהתגלו.
מדיניות p=none לבדה אינה משפרת את העבירוּת של הדומיין אלא משמשת רק לשלב התצפית והלמידה בתחילת התהליך של מסע ה-DMARC. אם נשארים ב-p=none ולא מתקדמים במסע ה-DMARC, לא רק שמפסידים את היתרון שבאכיפה והדומיין נותר ללא הגנה ממשית מפני התחזות (spoofing), אלא שלא ממנפים את האפשרות לזכות ב”נקודות עבירוּת”. ספקיות האימייל מבצעות פחות בדיקות על דומיינים שיש להם רשומת DMARC תקינה במצב אכיפה.
כלומר לאחר מספר שבועות או חודשים של ניטור ותיקון ליקויים כפי שעולים מהדוחות, יש להחמיר בהדרגה את המדיניות: לעבור ל- p=quarantine (בידוד או הסגר בעברית) ולאחר מכן ל-p=reject כלומר חסימה מלאה במקרה של כישלון באימות או בהתאמה לדומיין המדוור בהתאם למדיניות שהוגדרה. רק כך נבטיח שהדומיין מוגן תוך צמצום סיכוני פישינג.
טעות V – הטמעת DMARC רק בתת-דומיין במקום בדומיין הראשי
ישנם ארגונים שמטמיעים DMARC רק על סאב-דומיין מסוים (למשל, הדומיין שדרכו נשלחים דיוורים שיווקיים), אך אינם מגדירים DMARC עבור הדומיין הראשי של הארגון. זוהי טעות שמשאירה את הדומיין הראשי ללא הגנה. מטרתו העיקרית של DMARC היא להגן על הדומיין הראשי של המותג וכל הסאב-דומיינים תחתיו. כאמור קיימת אפשרות טכנית לפרסם רשומת DMARC נפרדת לכל סאב-דומיין, אולם ברוב המקרים המדוורים לא באמת זקוקים לכך כאשר הרשומה ברמת הדומיין הראשי מוגדרת בצורה תקינה. בהעדר רשומת DMARC בדומיין הראשי, תוקפים יכולים לזייף אימיילים שנחזים כאילו נשלחו מהארגון (מהדומיין הראשי). בנוסף, ספקיות אימייל מצפות לראות מדיניות DMARC ברמת הדומיין הארגוני. היעדר רשומת DMARC ברמת הדומיין הראשי עלול להתפרש כהזנחה של אבטחת האימייל מצד המדוור. כדי להגן על הדומיין הראשי והסאב דומיינים קובעים ברשומת DMARC על הדומיין הראשי policy ובאמצעות הטאג SP מגדירים מדיניות זהה או שונה על הסאב דומיינים. זה עובד כלפי מטה אבל לא כלפי מעלה ולכן רשומת DMARC חייבת להיות מוגדרת בראש ובראשונה על הדומיין הראשי.
טעות VI שגיאות בהבנת מנגנון ההתאמה (Alignment)
לפי הדרישות של ספקיות האימייל כדי ש-DMARC יעבור תקין, חייבת להיות התאמה (alignment) בין הדומיין המדוור לכתובת האימייל ב-mail form. נכון לרגע זה אין דרישה להתאמה בין SPF לבין הדומיין המדוור. במערכות דיוור רבות לא קיימת אפשרות לקבל התאמה (alignment) לגבי SPF. הגדרה לא נכונה של הטאגים ברשומת DMARC עשויה במקרים מסוימים לגרום לכישלון של DMARC ובהתאם למצב ה-policy לגרום לאימיילים לעבור ל-quarantine להידחות כלל במקרה של reject.
סוגי ההתאמה (alignment) מוגדרים באמצעות הטאגים aspf ו-askim בהתאמה.
האפשרויות הן התאמה רגועה (Relaxed) – שהיא ברירת המחדל ואינה מכשילה DMARC אם יש אי התאמה ב-SPF או DKIM.
התאמה קפדנית (Strict) דורשת התאמה מדויקת ורצוי להגדיר אותה בשונה מברירת המחדל עבור DKIM, כלומר להכשיל DMARC במקרה של אי התאמת DKIM לדומיין המדוור.
כדאי לשים לב להגדרה זו כשמשתמשים בסאב דומיין לשליחת הדיוורים ללא הגדרה מתאימה כגון אי-התאמה בין Return-Path ל-From address, או בעיות DKIM signature עם דומיין שונה מ-From address.
טעות VII – לא מגנים על דומיינים חונים (Parked Domains)
טעות רווחת היא להתמקד בהטמעת DMARC בדומיין אחד או שניים שמשמשים למשלוח דיוור, בעוד דומיינים אחרים שבבעלות הארגון נותרים ללא כל הגנה. ה-best practice הוא שכל דומיין שבבעלות הארגון גם אם הוא אינו משמש לשליחת אימיילים, צריך להיות מוגן באמצעות DMARC שמוגדר להכשיל כל ניסיון לשלוח אימיילים מהדומיין.
לכן, מומלץ להטמיע DMARC על כל הדומיינים שבבעלות הארגון. בדומיינים שאינם משמשים לדיוור (Parked Domains) כדאי בנוסף לפרסם רשומת SPF שמורה על כשל מוחלט (v=spf1 -all) יחד עם רשומת DMARC במדיניות מחמירה p=quarantine או p=reject על מנת לחסום כל ניסיון שימוש לא מורשה בהם. כך, אפילו דומיינים שלא שולחים דרכם אימיילים עדיין מוגנים מפני ניצול לרעה. בכלים מקצועיים לניטורDMARC מאפשרים להגדיר דומיינים חונים ובד”כ לא משלמים עליהם לכלי הניטור.
ראו הרחבה במאמר נפרד על פרוטוקול DMARC
כלי הטמעה וניטור DMARC נפוצים
| שם הכלי | הערות |
| easydmarc | most accurate for professionals |
| Uriports | value for money |
| DMARC EYE | Affordable |
| DMARC-DKIM | |
| dmarcdigests | |
| dmarcly | |
| dmarcian | |
| dmarcanalyzer | |
| dmarcreport |
טעות VIII – לא מגדירים התראות
בכלים המקצועיים לניטור DMARC אפשר להגדיר התראה במקרה של שינוי ב-policy או במקרה של כישלון באימות DMARC.
מנגנון התראות שכזה יכול לחסוך לארגונים צרות צרורות במקרה שבטעות מישהו נגע ב-DNS ויצר בעיה. בעבר סייעתי ללקוח גדול ששולח מיליוני אימיילים ביום להיחלץ מחסימה ב-Spamhaus של כל תשתיות הדיוור שלו (שרתים MTA שלו). הארגון עבר DNS לזה של אמזון Route53 בלי להיות מודע לכך שהעתקת רשומות DMARC ל-DNS החדש נשברו כי ה-DNS הזה לא תומך במישרין ב-DKIM באורך 2048 וצריך לשרשר אותן ב-DNS. אם היה מגדיר התראות באמצעות כלי לניטור DMARC, הוא היה יכול למנוע את החסימה או לכל הפחות לצמצם את הנזק כי ברגע של כישלון DMARC הייתה מתקבלת אצל הלקוח התראה.
טעות IX – שוכחים את הפרוטוקולים לאימות הדומיין עליהם נשען DMARC
פוטוקול DMARC נשען על אימות דומיין באמצעות ברשמות SPF ו-DKIM, שאותן מגדירים ב-DNS של הדומיין. על מנת ש-DMARC יעבור, צריך להגדיר כראוי את אימות (Authentication) והתאמה (Alignment) אל הדומיין המדוור.
ראו הרחבה במאמרים נפרדים על פרוטוקול SPF ופרוטוקול DKIM לאימות הדומיין במערכות דיוור.
ממצאי הבדיקה שערכתי על 1000 האתרים המובילים בישראל
בימים אלה אני מוביל פרויקט מחקר עצמאי שמתמקד בדומיינים הרשומים על ידי עסקים בישראל.
במסגרת המחקר, אני בוחן היבטים שונים הקשורים לדיוור אלקטרוני עבור הדומיינים הללו.
למשל, אילו מערכות שולחות אימיילים מטעמם, אילו מערכות מקבלות עבורם דואר אלקטרוני, מה מצב רשומת ה-DMARC שלהם, והאם היא תקינה או לקויה.
בשלב הראשון בפרויקט בחנתי את 1,000 האתרים הפופולריים ביותר בישראל (שחלקם אינם ישראליים) ובדקתי את סטטוס רשומת ה- DMARC של כל אחד מהם. הממצאים מפתיעים (לרעה) – וזו רק ההתחלה.
ב-מדגם שבדקתי עולה כי רק 21.9% אוכפים DMARC במצב reject, 14.6% אוכפים DMARC במצב quarantine, ו-34.3% עדיין במצב none. יתרת הדומיינים (29.3%) אינם מפרסמים כלל רשומת DMARC.
תובנות מרכזיות –
פערי דיווח RUA
ללא קבלת דוחות באמצעות הגדרת RUA רשומת ה-DMARC שמפורסמת ב-DNS היא חסרת משמעות ואינה תורמת לדומיין המדוור. ישנם דומיינים שלא מדווחים לכתובת אימייל של שירות ניטור והטמעה של DMARC, ומדווחים לכתובת אימייל פנים ארגונית. אני טוען שברוב המקרים, במקרה של דיווח פנים ארגוני, אף אחד לא קורא את הדוחות. ולכן, למרות שהרשומה נכונה, גם זה חסר משמעות.
52.8% בלבד מהדומיינים מדווחים לרשומת RUA.
כמעט כל הדומיינים שאוכפים ב-reject או ב-quarantine מדווחים, אך יותר מ-40% מהמדיניות “none” אינם מדווחי (רשומת useless).
29.3% מהמדגם לא מפרסם רשומת DMARC בכלל.
יחס אכיפה-דיווח בכל אחת מה-policies:
- Reject 91.78%
- Quarantine 86.3%
- none קצת פחות מ-60% עם RUA
הערות לגבי מגבלות הבדיקה:
לא כל 1,000 האתרים שנבדקו הם ישראלים ; לא כולם מדוורים, וחלקם משתמשים בדומיין אחר לצורך דיוור. בחלק מהמקרים הדיוור נעשה מסאב דומיין שאולי לגביו יש הגדרה ספציפית נפרדת שאותה לא בדקתי.
בהמשך עם התקדמות הפרויקט אפרסם ממצאים עדכניים ונתונים נוספים.
ראיונות בפודקאסט עם מומחי אימייל מרקטינג בינלאומיים
האזנה לפודקאסט
פודקאסט ובלוג מובילים בעברית בנושאי אימייל מרקטינג (email marketing) ועבירוּת אימיילים (deliverability).
הגעתם אל הבלוג והפודקאסט המובילים והמעודכנים ביותר בעברית בתחום אימייל מרקטינג, עבירוּת אימיילים, שיווק ודאטה. כאן תמצאו שפע מאמרים מפורטים ופודקאסטים מקצועיים למתחילים ולמתקדמים, המכסים את התחום בצורה מעמיקה.
חלק מהפרקים כוללים ראיונות עם מומחי אימייל מרקטינג בינלאומיים מובילים, המשולבים בעברית.
אימייל מרקטינג הוא ערוץ ותיק, אך דווקא בגלל שהוא “הסבא” של המדיה הדיגיטלית, הוא לא תמיד זוכה לתשומת לב והמקצועיות הראויה. היום הולך ונהיה קשה יותר להגיע לאינבוקס. כדי להצליח באימייל מרקטינג, יש להתמקצע ולא להסתמך רק על הפלטפורמה (מערכת הדיוור) שתעשה את הכל.
בבלוג ובפודקאסט תמצאו מידע מקיף ועדכני בנושאים כמו אימייל מרקטינג, עבירוּת אימיילים, סקירות מערכות דיוור, אוטומציה שיווקית, שיווק באמצעות תוכן, אימייל מרקטינג לאיקומרס, טיפים לשיווק במייל, דיוור בסטארטאפים ועוד.
יוצר הפודקאסט והבלוג, סלע יפה, הוא מומחה בינלאומי לעבירוּת אימיילים ושיווק באימייל. הוא מסייע למדוורים גלובליים, סטארטאפים, סוכנויות אימייל ומערכות דיוור (ESPs) בנושאי עבירוּת אימיילים, אימות אימייל (SPF, DKIM, DMARC, BIMI) ואסטרטגיית אימייל.
A blog and podcast (in Hebrew) about email marketing, email deliverability, marketing, and data.
חלק שני של הריאיון המרתק עם Jakub Olexa, מנכ”ל מערכת הדיוור Mailkit ושרת הדיוור הטרנזקציוני Omnivery, ומהמומחים הבולטים לתופעת האינטראקציות הלא אנושיות.
מדובר בבוטים “טובים” שפותחים ומקליקים על אימיילים כדי להגן על פרטיות המשתמשים או על מנת לבצע סריקה של הקישורים שבתוך האימייל לצורכי אבטחה.
זה יוצר שיבוש בעולם האימייל מרקטינג – חלק גדול מהפתיחות וגם חלק מסוים מההקלקות שאתם רואים במערכת הדיוור שלכם הם נתונים מנופחים של פתיחות והקלקות שווא, בדיוק בגלל התופעה הזו של אינטראקציות לא אנושיות.
אני מתכוון לערוך את הפרק ולתרגם אותו לעברית ואפרסם את הפרק בליווי תרגום סימולטני לעברית בהמשך כאן ב-crm.buzz
בינתיים אני מפרסם כאן את הפרק באנגלית, בשני חלקים. השבוע יובא החלק ראשון ובשבוע הבא אביא את החלק השני.
השבוע אשתתף ב- Deliverability Summit (וועידת עבירוּת) באמסטרדם ביומיים מרוכזים של מינגלינג ולמידה עם המומחים המובילים בעולם, גם את Jakub אפגוש שם. הוועידה מתמקדת בניהול עבירוּת במערכות דיוור, ניהול שרתי דיוור, ויחסי הגומלין בין מערכות דיוור, הלקוחות של מערכות הדיוור, ספקיות האימייל והגופים הנלחמים בספאם.
אני מתכוון לערוך ראיונות בשטח ואשזור אותם בפרקים הבאים של הפודקאסט.
הכרטיסים לוועידה עצמה אזלו, אבל אפשר לצפות בשידור הסטרימינג מהוועידה אונליין ואף קיבלתי ממארגני הועידה קוד הנחה למי שמעוניין לרכוש כרטיס.
קוד הנחה: SELLA
אני סלע יפה, מומחה אימייל מרקטינג ועבירוּת אימיילים. אני מזמין אותך לפגישת יעוץ ראשונית של 1/2 שעה ללא עלות בנושא עבירוּת אימיילים ואסטרטגיית אימייל מרקטינג. book an email deliverability discovery call.
לקריאה נוספת
Sella Yoffe
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
