עדכון חשוב: במאי 2026 פרסם ארגון ה-IETF תקן DMARC חדש (DMARCbis) המחליף את התקן המקורי מ-2015. המאמר הזה עודכן במלואו כך שהוא תואם לתקן החדש. שימו לב במיוחד לתגיות שהוצאו משימוש (pct, rf, ri) ולתגיות החדשות (np, t, psd). בסוף המאמר ישנן שאלות ותשובות.
תוכן עניינים
האזנה לפודקאסט
פודקאסט ובלוג מובילים בעברית בנושאי אימייל מרקטינג (email marketing) ועבירוּת אימיילים (deliverability).
הגעתם אל הבלוג והפודקאסט המובילים והמעודכנים ביותר בעברית בתחום אימייל מרקטינג, עבירוּת אימיילים, שיווק ודאטה.
כאן תמצאו שפע מאמרים מפורטים ופודקאסטים מקצועיים למתחילים ולמתקדמים, המכסים את התחום בצורה מעמיקה. חלק מהפרקים כוללים ראיונות עם מומחי אימייל מרקטינג בינלאומיים מובילים, המשולבים בעברית. אימייל מרקטינג הוא ערוץ ותיק,
אך דווקא בגלל שהוא “הסבא” של המדיה הדיגיטלית, הוא לא תמיד זוכה לתשומת לב והמקצועיות הראויה. היום הולך ונהיה קשה יותר להגיע לאינבוקס. כדי להצליח באימייל מרקטינג, יש להתמקצע ולא להסתמך רק על הפלטפורמה (מערכת הדיוור) שתעשה את הכל. בבלוג ובפודקאסט תמצאו מידע מקיף ועדכני בנושאים כמו אימייל מרקטינג, עבירוּת אימיילים, סקירות מערכות דיוור, אוטומציה שיווקית, שיווק באמצעות תוכן, אימייל מרקטינג לאיקומרס, טיפים לשיווק במייל, דיוור בסטארטאפים ועוד. יוצר הפודקאסט והבלוג, סלע יפה, הוא מומחה בינלאומי לעבירוּת אימיילים ושיווק באימייל. הוא מסייע למדוורים גלובליים, סטארטאפים, סוכנויות אימייל ומערכות דיוור (ESPs) בנושאי עבירוּת אימיילים, אימות אימייל (SPF, DKIM, DMARC, BIMI) ואסטרטגיית אימייל. A blog and podcast (in Hebrew) about email marketing, email deliverability, marketing, and data.
כדי להפוך את האימייל לבטוח יותר פותחו במשך השנים פרוטוקולי אימות דומיין שולח (SPF, DKIM). קשה לנטר אותם כשלעצמם וזה הפער ש-DMARC משלים. הוא מאפשר לנטר את האימות (authentication) של SPF ו-DKIM לגבי כל מקור שולח והתאמתם (alignment) לדומיין השולח * אם פועלים נכון אפשר לזכות בכמה “נקודות עבירוּת” *
במאי 2026 DMARC עודכן לתקן חדש. האם אתם מוכנים?
בעולם שבו כולנו חשופים לעשרת אלפים מסרים שיווקיים ויותר בכל יום, הקושי להבדיל בין פייק לאמת רק הולך וגובר.
כאן בולט יתרונו של האימייל בהשוואה ל”ערוצי התקשורת” הישירים האחרים, בכך שהוא כולל בתוכו מנגנונים מובנים לאימות זהות הדומיין השולח הנבדקים ברמת המפעילים (ספקיות אימייל, מסננות ספאם, מסננות phishing ומנגנוני אבטחת מידע נוספים).
מנגנונים אלה אינם קיימים באופן מובנה ברמת המפעילים בטלפון (קווי או סלולרי), ב-SMS, או בערוצי מסרים מידיים אחרים, מה שהופך את הערוצים הללו לפגיעים יותר וקלים יותר לזיוף.
כדי להפוך את האימייל לבטוח עוד יותר פותחו במשך השנים שורה של פרוטוקולים לאימות הדומיין השולח הנבדקים ע”י השרתים המקבלים (SPF, DKIM) וגם אמצעים הניתנים לזיהוי ויזואלי ע”י נמענים המקבלים את הודעות האימייל (BIMI). כל אלה מקנים לאימייל יתרונות והוא נחשב לערוץ האמין (trusted) ביותר בעיני לקוחות.
יחד עם זאת, הגדרות נכונות של אימות הדומיין הן סף כניסה לעבירוּת. אימות הדומיין אינו מבטיח הגעה ל-INBOX.
ראו הרחבה על הפרוטוקולים SPF, DKIM, BIMI
מה זה DMARC ?
פרוטוקול DMARC נועד להגן על דומיינים (domains) ומותגים (brands) מפני התחזות (spoofing) ולנטר הגדרות SPF ו-DKIM.
DMARC אינו פרוטוקול לאימות דומיין. פרוטוקולי אימות הדומיין SPF ו-DKIM מאמתים בשיטות שונות את זהות השולח.
פרוטוקול SPF – מגדיר כתובות IP ורשתות מורשות לשלוח בשם הדומיין.
פרוטוקול DKIM מצפין מקטעים מההודעה כדי לוודא שלא עברה שינוי בתווך שבין המוען (השולח) לנמען (המקבל).
קשה לנטר את אותם פרוטוקולים כשלעצמם וזהו הפער ש-DMARC משלים ומגשר.
משמעות ראשי התיבות DMARC: Domain-based Message Authentication, Reporting & Conformance.
מְדִינִיוּת (DMARC policy) מאפשרת להגדיר לספקיות אימייל ומסננות ספאם כיצד לטפל בהודעות אימייל שאינן מאומתות או תואמות לדומיין השולח כמוגדר על ידי SPF ו-DKIM.
בנוסף, DMARC מספק דוחות אגרגטיביים (Aggregate reports) ודוחות כישלון (Failure report – נקראו בעבר forensic reports) שנשלחים על ידי שרתי אימייל מקבלים (receiving side כגון Gmail ואחרים) ומספקים לצד השולח נתונים כיצד הצד המקבל רואה את תעבורת האימייל שלו. הדיווח כולל סטטוס אימות דומיין (valid SPF / DKIM) והתאמה (aligned SPF / DKIM) של הגדרות אימות דומיינים ונתונים נוספים.
חשוב לדעת בהקשר של התקן החדש: בבדיקת SPF לצורכי DMARC, התקן החדש קובע שנבדקת אך ורק זהות ה-MAIL FROM (המוכרת גם כ-return-path או envelope sender), ללא Fallback לזהות ה-HELO. לרוב המדוורים זה שקוף, אבל אם יש לכם תשתית שנשענה על HELO – כדאי לבדוק.
התקן החדש: שלושה מסמכי RFC במקום אחד
התקן המקורי, RFC 7489, פורסם ב-2015 כמסמך אחד גדול במעמד Informational בלבד. כעת מסמך זה אינו בתוקף.
התקן החדש שפורסם במאי 2026 מפצל אותו לשלושה מסמכים נפרדים במעמד Proposed Standard – מסלול התקינה הרשמי של ה-IETF:
RFC 9989 – הפרוטוקול עצמו. איך מגלים מדיניות, איך בודקים Alignment של SPF ו-DKIM, איך שרת מקבל אמור להתנהג. המסמך הזה גם מתכלל לתוכו את RFC 9091 (תגית ה-psd) שהתייתר.
RFC 9990 – דוחות מצטברים (Aggregate Reports). מבנה ה-XML, איך מגלים לאן לשלוח ואיך מוסרים את הדוחות.
RFC 9991 – דוחות כשל (Failure Reports). דוחות ברמת ההודעה הבודדת, עם דגש מוגבר על פרטיות.
הקפיצה של תקן DMARC מ-Informational ל-Standards Track היא לא רק סמנטיקה. היא אומרת שספקיות אימייל בעולם יפרשו ויישמו את הפרוטוקול בצורה עקבית יותר, ושרגולטורים ותקנים כמו PCI DSS ו-NIS2 יכולים עכשיו להצביע על תקן אינטרנט רשמי.
ומה מצב רשומת ה-DMARC שלכם? אמנם התקן עודכן לתקן DMARC 2.0, אבל אין דבר כזה DMARC2 ברמת הרשומה. הרשומה ממשיכה להתחיל ב-v=DMARC1 והתאימות לאחור מלאה. מה שכן השתנה מפורט בהמשך.
חדש – DNS Tree Walk במקום Public Suffix List
שינוי טכני משמעותי בתקן החדש, הוא שעד היום, כששרת מקבל היה צריך להחליט מה הדומיין הארגוני (Organizational Domain) של הודעה, הוא נעזר ב-Public Suffix List – רשימה חיצונית שמתוחזקת ידנית, שמתעדכנת באיחור ושלא נבנתה בכלל לצורכי אימות אימייל (הוקמה על ידי ארגון Mozila).
התקן החדש מחליף את הרשימה באלגוריתם שנקרא DNS Tree Walk: השרת המקבל שואל את ה-DNS ישירות. הוא מחפש רשומת DMARC בדומיין שממנו נשלח האימייל, ואם לא מצא – מטפס למעלה תווית אחר תווית (לדוגמא: invoices.example.com, אחר כך example.com, אחר כך com), עד מקסימום שמונה רמות. הרשומה הראשונה שנמצאה היא הקובעת. ה-DNS הוא מקור האמת, אז בתקן DMARC החדש שואלים אותו ישירות בצורה חכמה שמתחשבת בשימוש הנפוץ של אימייל בסאב דומיינים.
החובה להגדיר DMARC:
בניגוד לדעה הרווחת יש יתרון גדול בביצוע הגדרת DMARC Policy נכונה (ראו בהמשך לגבי טעויות בהגדרה), גם אם אתם משוכנעים שהגדרתם SPF ו-DKIM באופן מדויק ונכון.
החל מ-2024, לפי הדרישות של ספקיות האימייל הגדולות ממדוורים, הגדרה של רשומת DMARC תקינה הפכה למנדטורית עבור מדוורים גדולים (bulk senders). מדוור גדול נחשב כל מי ששולח 5,000 אימיילים ויותר ביום אל Gmail, מה שהופך גם בעלי רשימות דיוור קטנות יחסית למדוורים גדולים לפי הגדרה זו. כך למשל אם יש לכם רשימה של 1,800 נמענים ויש לכם שבוע מכירות מיוחד במסגרתו שלחתם דיוור 3 פעמים באותו היום לכל הרשימה – מבחינת Gmail והספקיות הגדולות האחרות, עברתם את הסף ומעתה אתם נחשבים bulk sender. גם אם עברתם את סף ה-5,000 אימיילים ביום פעם אחת בלבד.
ההמלצה שלי לכל מדוור, גם מדוורים קטנים ומתחילים, לראות עצמם מחויבים לכך. גם מדוורים קטנים יותר מנוטרים על ידי ספקיות האימייל.
מאוד שכיח שאנשי ומנהלי IT אינם מטמיעים DMARC כי “אצלם הכל בסדר”. אך הם לא תמיד מודעים למערכות SaaS שהשיווק מפעיל, שרתי SMTP שצדדי ג’ מפעילים עבורכם, או שרתי דיוור שאנשי פיתוח הגדירו בסביבות פיתוח ובדיקות שונות.
הערך המרכזי של דוחות DMARC הוא ביכולתם לספק תמונה מלאה לגבי תעבורת האימייל שלכם, תוך חשיפת כלל התשתיות השולחות (discoverability) – בין אם הן פנימיות או חיצוניות. קבלת הדוחות מאפשרת לנטר את תקינות אימות הדומיין (Authentication ו-Alignment) בכל אחת מהתשתיות המדוורות, באופן שוטף ולהציף תקלות בזמן אמת. זה קריטי כי גם שינויים קלים בהגדרות ה-DNS או במערכות הדיוור עלולים להתרחש בכל עת. מספיק שפסיק נמחק בטעות, או רשומה שלא עודכנה כראוי ב-DNS כדי לשבור את אימות הדומיין.
ללא מנגנון הדיווח של DMARC, בעיות כגון אלה עלולות להישאר סמויות מן העין ולפגוע משמעותית בעבירוּת (deliverability) שלכם, מה שיוביל לנזק שייקח זמן לזהות ולתקן. במקרים רבים, כאשר הבעיה מתגלית, אתם שקועים עמוק בבוץ, והתיקון יהיה הרבה יותר קשה.
התקן החדש של DMARC זוכה למעמד של Standards Track, דבר שמחזק את מעמדו וחשיבותו של DMARC. מבקרים ורגולטורים יכולים עכשיו להפנות לתקן רשמי, והלחץ על ארגונים ליישר קו צפוי להתגבר.
אמנם חלה עלייה בכמות הדומיינים שהטמיעו רשומת DMARC תקינה, הרבה מזה הודות לדרישות החדשות של ספקיות האימייל הגדולות שנכנסו לתוקף ב-2024, אך ניכרת ירידה בכמות הדומיינים שעברו למצב אכיפה.
איך מגדירים DMARC
רשומת TXT המוגדרת ב-DNS של הדומיין תחת סאב דומיין: “_dmarc”
רשומת DMARC לדוגמא בפורמט התקן החדש:
ברשומה זו, הדומיין הראשי מקבל דוחות בלבד, סאב דומיינים קיימים במצב quarantine וסאב דומיינים לא קיימים במצב reject. הרשומה מוגדרת לקבל דוחות אגרגטיביים בלבד (לא דוחות כשל).
v=DMARC1; p=none; sp=quarantine; np=reject ; rua=mailto:rua-email@domain.com
ניתן להוסיף לרשומה תגיות (Tags) שונות:
| Tag | ערך | הסבר |
|---|---|---|
| v | DMARC1 | גרסת DMARC. ערך קבוע DMARC1. נשאר ללא שינוי גם בתקן החדש |
| p | none / quarantine / reject | המדיניות המורה לשרת המקבל מה לעשות בכישלון אימות והתאמה (alignment) של SPF/DKIM: none = השרת המקבל מחליט מה לעשות. quarantine = להעביר להסגר או ספאם. reject = לדחות את האימייל |
| sp | none / quarantine / reject | מדיניות עבור sub-domains קיימים. אם לא הוגדרה, חלה מדיניות ה-p (זהה לדומיין הראשי) |
| np | none / quarantine / reject | חדש בתקן: מדיניות עבור sub-domains שאינם קיימים (מחזירים NXDOMAIN). אם לא הוגדרה, תחול מדיניות sp ואם אין אז p |
| t | y / n | חדש בתקן: מצב בדיקה. t=y מאותת שהמדיניות בבדיקה, והציפייה היא שהצד המקבל יחיל רמה אחת מתחת למוצהר (reject יטופל כ-quarantine, ו-quarantine כ-none). אין השפעה על מדיניות none, ואין השפעה על שליחת הדוחות. ברירת המחדל t=n - אכיפה מלאה. |
| psd | y / n / u | חדש בתקן: מיועד למפעילי Public Suffix Domains בלבד. עוזר ל-Tree Walk לזהות את הגבול הארגוני. רוב המדוורים לא צריכים לגעת בתגית הזו |
| rua | mailto:address | כתובת האימייל אליה יישלחו דוחות אגרגטיביים. שימו לב: אפשרות ציון מגבלת גודל לדוח בוטלה בתקן החדש |
| ruf | mailto:address | כתובת האימייל אליה יישלחו דוחות כשל. מומלץ לא להגדיר קבלה של דוחות כשל |
| fo | 0 / 1 / d / s | רלוונטי לדוחות כשל: 0 = דוח בכישלון של SPF וגם DKIM. 1 = דוח בכישלון של SPF או DKIM. d = כישלון DKIM בלבד. s = כישלון SPF בלבד |
| adkim | r / s | מצב בדיקת ההתאמה (alignment) של DKIM מול דומיין ה-From. ברירת מחדל r (relaxed), אפשרי s (strict) |
| aspf | r / s | מצב בדיקת ההתאמה (alignment) של SPF מול דומיין ה-From. ברירת מחדל r (relaxed), אפשרי s (strict) |
מנגנון DMARC בודק alignment בין ה- mfrom (נקרא גם return-path addressאוenvelope-sender address או (bounce address, ה- from address (הכתובת המוצגת לנמענים), אליה נמעני יעשו reply ובודק את ה-alignment עם SPF ו-DKIM.
שימו לב: בניגוד לדוגמאות ישנות שמסתובבות ברשת (כולל בגרסה הקודמת של המאמר הזה), הטאגים pct, rf או ri – אינם בתוקף בתקן החדש. שרת שתומך בתקן החדש מתעלם מהן. ראו רשימה של תגיות שאינן בתוקף לפי התקן החדש.
אם התגיות האלה עדיין קיימות ברשומת ה-DMARC שלכם – האימייל לא יישבר, שרתים פשוט יתעלמו מהן. רצוי לנקות ולהגדיר רשומה עדכנית בהקדם.
DMARC deprecate tags
| Tag | מה היא עשתה | למה הוצאה ומה עושים במקום |
|---|---|---|
| pct | אכיפה הדרגתית באחוזים | בפועל כמעט אף פעם לא יושמה במדויק על ידי ספקיות האימייל. שרת תואם לתקן החדש יתייחס לכל ערך כאילו נכתב 100. במקומה נשתמש בתגית t (הכל או כלום) והרצה הדרגתית מנוהל תפעולית |
| rf | פורמט דוחות כשל | היה קיים רק פורמט אחד נתמך (afrf), התגית הייתה מיותרת. ניתן פשוט להסיר |
| ri | מרווח זמן בין דוחות מצטברים | בפועל כולם קיבלו דוח יומי בלי קשר לערך. דוחות ממשיכים להגיע יומית או בתדירות גבוהה יותר. אפשר פשוט להסיר |
את כתובת האימייל עבור ה-aggregate reports שבדוגמא יש להחליף בכתובת שתקבלו מכלי ניטור ה-DMARC שלכם.
רשימה של כמה כלי ניטור ואפשרות להצטרף לרשימת המתנה להצטרפות לבטא סגורה של סוויטת כלים לניהול וניטור DMARC שאשיק בקרוב בהמשך המאמר.
יש חשיבות רבה ל-Syntax של הרשומה. התגית v=DMARC1 חייבת להופיע ראשונה, כשהערך DMARC1 באותיות גדולות. תגית ה-p מופיעה אחריה, מופרדת בנקודה-פסיק.
משמעות רשומת ה-DMARC בדוגמא הנ”ל:
- מדיניות עבור הדומיין הראשי (P) = none
- מדיניות עבור סאב דומיינים קיימים (sp) = quarantine
- מדיניות עבור סאב דומיינים שאינם קיימים (np) = reject
הרשומה מוגדרת לקבל דוחות אגרגטיביים בלבד.
אבולוציה נכונה ואחראית של המדיניות הראשונית תמיד תהיה none על מנת להתחיל לקבל דוחות. בהמשך, אחרי מספר חודשי פעילות ותיקון הליקויים שיציפו הדוחות, אפשר יהיה לעבור ל-p=quarantine ובהמשך ל-reject.
טיפ: בתקן החדש אפשר ליישם כבר בשלב ההתחלתי, כאשר המדיניות (Policy) היא none (קבלת דוחות בלבד ללא אכיפה), את ההוראה מה על הצד המקבל לעשות לגבי סאב דומיינים שאינם קיימים (לא בשימוש) ובכך לשפר את ההגנה מפני spoofing.
הוסיפו np=reject. סאב-דומיין שלא קיים ב-DNS שלכם גם לא אמור לשלוח אימיילים. אז אין שום סיבה לא לחסום אותו כבר עכשיו, גם אם הדומיין הראשי עדיין בניטור בלבד.
מסע DMARC: איך עוברים לאכיפה לפי התקן החדש?
גם לאחר מעבר ל-p=reject (הגנה על הדומיין) לא תמה העבודה. צריך להמשיך לנטר דוחות בקביעות ולהפעיל התראות, אם המערכת לניהול וניטור DMARC שאתם משתמשים בה מאפשרת זאת. כך תוכלו להיות מעודכנים באמצעות אימייל, Webhook אל מערכת אוטומציה, SMS או כל ערוץ התראה אחר, כאשר משהו משתבש ב-DNS או שמשהו באימות הדומיין שלכם השתבש באחת מהמערכות המדוורות.
בתקן הישן, תגית ה-pct הבטיחה (על הנייר) מעבר הדרגתי: אכיפה רק ל- 25% מהתעבורה, אחר כך 50% וכן הלאה. בפועל היא עבדה בצורה לא עקבית. ספקיות אימייל שונות התייחסו לתגית הזאת בצורה שונה ובפועל, הם שלחו דוחות בקצב שהם רוצים, ועל אחוז התעבורה שהם בחרו מהשיקולים שלהם. התקן החדש ביטל את תגית PCT ויצר מנגנון חלופי באמצעות התגית t הבינארית: או שהסטטוס הוא טסט (t=y, שום דבר לא נאכף) או שאוכפים הכל. אין אמצע (כמו במנגנון האחוזים).
המשמעות המעשית של מסע ה-DMARC בדרך אל היעד – אכיפה:
- בוחרים כלי לניהול וניטור DMARC.
- מגדירים ב-DNS של הדומיין את רשומת ה-DMARC בהתאם להנחיות שקיבלתם.
- מתחילים במדיניות p=none עם ניטור מלא באמצעות כלי ייעודי לניטור DMARC.
- מקבלים דוחות שחושפים את כל התשתיות המדוורות.
- מתקנים מקור שליחה אחר מקור שליחה, עד שהדוחות מראים שכל התעבורה הלגיטימית מאומתת ומותאמת לדומיים (Authenticated and aligned).
- אם יש לכם כמה דומיינים מדוורים – מעלים לאכיפה קודם את הדומיינים בעלי הסיכון הנמוך (Quick win).
- גם כשהכל נראה תקין כדי לרוץ במצב none לאורך חודש לפחות (די שכיח לגלות שפעם בחודש מתעורר שרת טסטים שאף אחד לא זוכר שהוא קיים ושולח אימייל משרת לא מאומת. לכן, כדאי לרוץ תקופה מסוימת בכל מצב לפני מעבר לשלב הבא.
- עוברים ל-quarantine, ממשיכים לנטר לפחות חודש, ורק אז עוברים ל-reject.
- ממשיכים לנטר ולעקוב אחרי התראות.
זה בדיוק התהליך שתמיד המלצתי עליו. התקן החדש הפך זאת לדרך היחידה המומלצת.
p=reject ו-discussion list
התקן החדש ממליץ במפורש שלא להשתמש ב-p=reject בדומיינים המשמשים רשימות דיון (discussion lists), כגון Mailman, Google Groups, IETF lists, LISTSERV ובתרחישי Forwarding אל כתובת role-based email aliases, and mailing lists, בגלל שפעולת ההעברה (forwared) באמצעות שרצתי ביניים, שוברת את החתימות – בעיקר של SPF. לשימושים כגון אלה, התקן מציע להשתמש תמיד ב-DKIM בנוסף ל- SPF (פרקטיקה מומלצת לכל מדוור).
דוחות אגרגטיביים DMARC aggregate reports
דוחות DMARC נשלחים משרתי אימייל המקבלים אימיילים (receiving side), כגון מספקיות האימייל הגדולות (Gmail, Yahoo, Microsoft ואחרות) ושרתי אימייל ארגוניים.
דוחות DMARC הם בפורמט XML שאינו נוח לקריאה והבנה ללא כלי מתאים. על מנת לקבל את הדוחות ולהפיק מהם תובנות והמלצות, צריך להשתמש בכלי לניטור DMARC. זו גם הסיבה שאין טעם לקבל את הדוחות לכתובת האימייל שלכם. גם אם תקבלו את הדוחות לכתובת האימייל שלכם ורשומת ה-DMARC שלכם תיראה תקינה, זה לא מספיק. זה כמו להסיק מסקנה מפריים בודד מתוך סרטון שלם.
הדוחות כוללים פרטים כגון: מי שלח (from, mfrom), כתובת ה-IP ממנה נשלח האימייל, מצב האותנטיקציה (authentication ו- alignment של SPF ו-DKIM), המדיניות שפורסמה והמדיניות שיושמה בפועל על ידי הצד המקבל.
שימו לב שאלו לא תמיד זהות. בתקן הישן, downgrade של המדיניות היה בגדר שיקול דעת מקומי של השרת המקבל: בשטח היה שכיח ששרתים “מבינים” שהודעה הייתה מאומתת כהלכה אך האימות נשבר בדרך (למשל כתוצאה מ-forward), מקלים במדיניות, ומדווחים על כך בדוח כסיבת override. התקן החדש לוקח את הפרקטיקה הזאת צעד קדימה ומעגן אותה רשמית: הוא מנחה שרתים מקבלים שלא לדחות הודעה רק בגלל שהדומיין פרסם p=reject, אלא להתייחס אליה כאל quarantine כברירת מחדל. כלומר, הפרקטיקה הפכה להתנהגות המומלצת. בדוח, הסטייה ממשיכה להיות מתועדת באלמנט reason ייעודי, כך שתמיד תוכלו לראות מתי ולמה המדיניות שלכם לא יושמה כלשונה.
מה השתנה בדוחות בתקן החדש (RFC 9990):
- לסכימת ה-XML נוספו שדות אופציונליים חדשים, בהם discovery_method (שמראה אם השרת המקבל השתמש ב-PSL הישן או ב-Tree Walk החדש), אינדיקציה למצב בדיקה (testing), שדה np, ושדה generator שמזהה את התוכנה שיצרה את הדוח.
- דרישות שהיו בגדר “רצוי” (SHOULD) הפכו ל”חובה” (MUST): סוגי המדיה של הקובץ המצורף (application/gzip או text/xml), פורמט שם הקובץ ונושא האימייל.
- אימות יעדי דיווח חיצוניים (כשה-rua מפנה לדומיין אחר) הפך לחובה עבור המדווחים. אם אתם משתמשים בפלטפורמת ניטור DMARC – ודאו שרשומת ההרשאה החיצונית שלכם במקום (ראו בהמשך).
- אפשרות ציון מגבלת גודל בתגית rua בוטלה.
כלי ניטור קיימים ממשיכים לעבוד. כלים מעודכנים לתקן החדש יידעו לחלץ מהשדות החדשים מידע עשיר יותר.
הדוחות האגרגטיביים מאפשרים לגלות תשתיות (שרתי דיוור) שלכם ושל צדדי ג’ המורשים על ידכם לשלוח בשם הדומיין שלכם. זה מאפשר לתקן הגדרות אימות דומיין לא תקינות בשרתים אלה.
דוחות DMARC יציפו מעתה מערכות מדוורות שיתכן שהן מתחזות לדומיינים שלכם. שהרי זו המטרה הראשונית של DMARC: להגן על הדומיין שלכם מפני abuse והתחזות.
האזנה לפודקאסט
פודקאסט ובלוג מובילים בעברית בנושאי אימייל מרקטינג (email marketing) ועבירוּת אימיילים (deliverability).
הגעתם אל הבלוג והפודקאסט המובילים והמעודכנים ביותר בעברית בתחום אימייל מרקטינג, עבירוּת אימיילים, שיווק ודאטה.
כאן תמצאו שפע מאמרים מפורטים ופודקאסטים מקצועיים למתחילים ולמתקדמים, המכסים את התחום בצורה מעמיקה. חלק מהפרקים כוללים ראיונות עם מומחי אימייל מרקטינג בינלאומיים מובילים, המשולבים בעברית. אימייל מרקטינג הוא ערוץ ותיק,
אך דווקא בגלל שהוא “הסבא” של המדיה הדיגיטלית, הוא לא תמיד זוכה לתשומת לב והמקצועיות הראויה. היום הולך ונהיה קשה יותר להגיע לאינבוקס. כדי להצליח באימייל מרקטינג, יש להתמקצע ולא להסתמך רק על הפלטפורמה (מערכת הדיוור) שתעשה את הכל. בבלוג ובפודקאסט תמצאו מידע מקיף ועדכני בנושאים כמו אימייל מרקטינג, עבירוּת אימיילים, סקירות מערכות דיוור, אוטומציה שיווקית, שיווק באמצעות תוכן, אימייל מרקטינג לאיקומרס, טיפים לשיווק במייל, דיוור בסטארטאפים ועוד. יוצר הפודקאסט והבלוג, סלע יפה, הוא מומחה בינלאומי לעבירוּת אימיילים ושיווק באימייל. הוא מסייע למדוורים גלובליים, סטארטאפים, סוכנויות אימייל ומערכות דיוור (ESPs) בנושאי עבירוּת אימיילים, אימות אימייל (SPF, DKIM, DMARC, BIMI) ואסטרטגיית אימייל. A blog and podcast (in Hebrew) about email marketing, email deliverability, marketing, and data.
לדף הפודקאסט בבלוג לאתר Mailkit לאתר Omnivery
See omnystudio.com/listener for privacy information.
דוחות כשל – DMARC failure reports
מה שנקרא בעבר “דוחות פורנזיים” נקרא בתקן החדש בשם הרשמי Failure Reports, והם קיבלו מסמך RFC נפרד משלהם (RFC 9991) עם דגש מוגבר על סיכוני פרטיות ומידע אישי (PII).
ההמלצה שלי לא השתנתה: לא להגדיר קבלת דוחות כשל. הם מכילים מידע אישי כגון כתובות אימייל, הדוחות האגרגטיביים מספקים, ורוב השרתים ממילא אינם שולחים דוחות כשל, בדיוק מסיבות של GDPR וחוקי פרטיות מקבילים. התקן החדש רק חיזק את ההסתייגויות האלה.
אם אתם בכל זאת רוצים לקבל דוחות כשל, הגדירו את הרשומה בהתאם עם התגית RUF.
שגיאות נפוצות בהטמעת DMARC
לא משתמשים בכלי לניטור DMARC
רשומת ה-DMARC שלכם עשויה להיראות תקינה לחלוטין, אך בפועל אם אינכם משתמשים בכלי ניטור DMARC (ראו בהמשך טיפים לבחירת הכלי המתאים עבורכם), אינכם יודעים מה באמת קורה ב”רשת האימייל” שלכם.
דוחות DMARC נשלחים בפורמט XML, כמעט בלתי אפשרי לקרוא אותם בעין אנושית ללא כלי ניטור או פענוח (parsing) ייעודי.
לבחון דוחות DMARC ללא כלי מתאים זה כמו לצפות בפריים בודד מתוך סרט שלם, ללא היכולת לרדת לעומקם של דברים (drill down) ולהבין באמת מה מתרחש ברשת האימייל שלכם.
מתחילים ב-p=none ונשארים כך…
טעות נפוצה למי שכבר הטמיע DMARC היא חוסר הבנה של המנגנון. DMARC אינו שגר ושכח אלא מנגנון שצריך לעבוד איתו בשוטף, לקבל דוחות והתראות, לבחון אותם על בסיס קבוע ולתקן ליקויים שנתגלו.
השאיפה היא לעבור מ-p=none (שלא נותן כל ערך בהגנה על הדומיין) ל-p=quarantine ולבסוף ל-p=reject. “מסע ה-DMARC” לוקח בד”כ מספר חודשים של עבודה. גם כאשר מגיעים למצב האכיפה הגבוה – reject צריך להמשיך ולנטר ולבחון התראות.
השלב הנייטרלי p=none הוא צעד חשוב שמאפשר קבלת דוחות DMARC מבלי לפגוע בפעילות הדיוור. אם תתחילו ב-quarantine או reject אתם למעשה אומרים לצד המקבל לחסום או לדחות אימיילים ממקור שאינו מאומת. שלב ה-none מאפשר למדוורים להבין את תמונת המצב ולערוך שיפורים בהתאם, מבלי להורות לצד המקבל מה עליו לעשות במקרה של אי התאמה לדומיין המדוור או של כשל באימות הדומיין.
בתקן החדש אפשר לחסום כבר בשלב הראשוני סאב-דומיינים לא קיימים עם np=reject.
מטמיעים DMARC שגוי או חסר ערך
שכיח לגלות שגיאות כתיב (typo) בהגדרת DMARC, או אף להטמיע DMARC שגוי או חסר תועלת לחלוטין, למשל רשומת DMARC ללא קבלת דוחות.
לניטור והטמעה של DMARC Policy אני ממליץ להשתמש בכלי חיצוני (ראו בהמשך רשימה של כלים) ולא להשתמש בהגדרות שמסופקות על ידי מערכות הדיוור השונות.
במקרים רבים ההגדרה שמערכת הדיוור שלכם מציעה לכם היא חסרת תועלת. מערכת הדיוור אינה אחראית על DMARC. המדוורים ובעלי הדומיין אחראים לגביו.
ראו הרחבה במאמר נפרד על 9 שגיאות בהטמעת DMARC
v=DMARC1; p=none;
משאירים תגיות שהוצאו משימוש
טעות חדשה שנולדה עם התקן החדש: רשומות עם pct, rf או ri. הן לא ישברו כלום, אבל הן מעידות על רשומה שלא תוחזקה, ובמקרה של pct – עלולות ליצור פער בין מה שאתם חושבים שקורה (אכיפה חלקית) לבין מה שקורה בפועל (אכיפה מלאה אצל שרתים שתואמים את התקן החדש). נקו את הרשומה והתאימו אותה לתקן החדש.
מטמיעים DMARC על sub-domain בלבד ולא על הדומיין הראשי
טעות נוספת ששכיח לגלות היא ש-DMARC הוטמע רק על sub-domain ולא על הדומיין הראשי. מטרת DMARC לרוב תהיה להגן על הדומיין הראשי וכל תת-הדומיינים שתחתיו. אפשר להטמיע DMARC נפרד ל-sub-domains אך לרוב המדוורים אין צורך בזה. עם המעבר ל-DNS Tree Walk חשוב שבעתיים להבין איזו רשומה תימצא ראשונה עבור כל מקור שליחה.
לא מטמיעים DMARC בכל הדומיינים של העסק
לאחרונה בוצעה מתקפת פישינג משמעותית שאפשרה לתוקף מתוחכם לשלוח אימיילים מהדומיין של משרד המשפטים. המתקפה הזו הצליחה בין השאר בגלל שהדומיין לא היה במצב אכיפה, מה שיכול היה למנוע את המתקפה.
רצוי להגדיר DMARC על כל הדומיינים שלכם, גם על דומיינים שאינם מדוורים (parked domains). על דומיינים שאינם מדוורים רצוי מאוד להגדיר רשומת SPF שתכשיל SPF ותנוטר ב-DMARC.
דוגמא לרשומת SPF לדומיינים שאינם מדוורים:
parked-domain.co.il TXT v=spf1 -all
לא נותנים הרשאות חיצוניות
פרוטוקול DMARC מתוכנן לשלוח דוחות לדומיין המנוטר. כאשר משתמשים בכלי ניטור חיצוני חובה לתת הרשאה לשליחת דוחות לדומיין חיצוני. בתקן החדש האימות הזה הפך ממומלץ לחובה עבור המדווחים, כך שבלי רשומת ההרשאה בדומיין החיצוני שמקבל את הדוחות עבור הדומיין שלכם – דוחות פשוט לא יגיעו.
זו רשומת ה-TXT שמגדירים ב-DNS של כלי הניטור (כלי הניטור עושים את זה עבורכם):
domain.co.il._report._dmarc.external-dmarc-tool-domain.com
לא ממשיכים בניטור DMARC
ניטור DMARC באמצעות כלי ייעודי מאפשר לעסקים לקבל דוחות באופן קבוע לאורך זמן.
בכלי ניטור רבים, חלק מהתמחור הוא משך זמן הריטנשן, כלומר לאורך כמה זמן הם שומרים את ההיסטוריה של הדוחות. הטעות היא שלאחר ההטמעה לא מתקיים תהליך ניטור ושיפור מתמיד. העבודה לא נגמרת בהטמעה. הדוחות השוטפים מאפשרים לנטר כל שינוי בתשתיות המדוורות שלכם ותשתיות המנסות להתחזות לדומיינים שלכם.
איך בוחרים כלי ניטור DMARC שמתאים לכם
שוק כלי ה-DMARC נראה במבט ראשון לא הגיוני: יש כלים חינמיים, יש כלים ב-4 דולר לדומיין לחודש ללא הגבלת אימיילים ושנה היסטוריה לאחור, ויש כלים שהעלות שלהם מתחילה בכמה מאות דולרים לחודש פר דומיין. כולם מקבלים את אותם דוחות XML בדיוק. אז למה בעצם יש כאלה פערים?
ההבדל הוא לא בנתונים, אלא במה שהכלי עושה איתם, פשוטות הבנת הנתונים, כמה עבודה נשארת לכם, רמת ההגנה שהכלי מספק ברמת ההתראות, אינטגרציות עם מערכות אחרות.
הכלים החינמיים מתאימים לבדיקה ראשונית ולדומיין בודד עם תעבורה נמוכה. המגבלות מגיעות מהר: היסטוריה קצרה, בלי התראות או עם התראות בסיסיות, בלי צירוף חברי צוות (חשוב בסביבה ארגונית), ולעיתים בלי עיבוד של כל סוגי הדוחות. אם אתם רק רוצים לדעת “מי שולח בשם הדומיין שלי” – זו נקודת התחלה טובה הרבה יותר מאשר לא לפרסם רשומת DMARC כלל או לפרסם רשומה חסרת תועלת.
הכלים הזולים (סדר גודל של דולרים בודדים לדומיין לחודש) מכסים היום את מה שרוב העסקים צריכים בפועל: עיבוד מלא של דוחות מצטברים, זיהוי מקורות שליחה, התראות על שינויים, והיסטוריה מספקת. עסק עם דומיין אחד או שניים, תשתית שליחה מוכרת (מערכת דיוור, CRM, Google Workspace או Microsoft 365) ומשתמש אחד שמסתכל על הדוחות – כנראה לא יקבל ערך נוסף אמיתי מכלי יקר.
הכלים היקרים לא מוכרים דוחות, הם מוכרים ניהול של פרויקט: ליווי אנושי במסע ל-p=reject, ניהול עשרות ומאות דומיינים תחת ארגון אחד, הרשאות לצוותים, אינטגרציות ל-SIEM, ניהול SPF ו-DKIM בכלי עצמו (hosted SPF, hosted DKIM, hosted DMARC), תמיכה ב-SLA ודוחות למנהלים ולמבקרים. ארגון עם עשרות דומיינים, צוותי IT ורגולציה – משלם על הורדת עומס תפעולי, לא על ניתוח דוחות.
אז איך מחליטים? ארבע שאלות:
- כמה דומיינים ומקורות שליחה יש לכם? דומיין אחד עם שלושה מקורות – כלי זול מספיק. עשרות דומיינים עם צדדי ג’ מתחלפים (סוכנויות, מקורות שליחה) – תוכלו ליהנות ממה שמציע כלי מתוחכם יותר.
- מי הולך לקרוא את הדוחות? אם התשובה היא “אף אחד”, הכלי הכי יקר בעולם לא יעזור. אם יש צוות, בדקו הרשאות, התראות ואינטגרציות. יש לי לקוח שמשלם כ- 3,000 דולר בשנה על כלי ניטור DMARC ואף אחד אצלם הצוות לא נגע בכלי כבר חצי שנה…
- איפה אתם במסע? בשלב p=none וגילוי המקורות – כלי פשוט וזול נותן את רוב הערך. במעבר לאכיפה על סביבה מורכבת – ליווי ופיצ’רים מתקדמים מצדיקים את עצמם. תזכרו ש-DMARC זה מסע. אל תתקעו ב-none ומצד שני גם במצב reject העבודה לא תמה וצריך להמשיך לנטר.
- מה קורה כשמשהו נשבר? בדקו לפני שאתם משלמים: תוך כמה זמן תקבלו התראה על מקור חדש שנכשל? זו בסופו של דבר הסיבה שבגללה אתם מנטרים.
ועדכון אחד רלוונטי לתקן החדש: לפני שאתם סוגרים עם כלי, כדאי לוודא שהוא כבר תומך בסכימת הדוחות המעודכנת לתקן DMARC החדש (RFC 9990) ובתגיות החדשות, ושרשומת ההרשאה החיצונית שלו מוגדרת כנדרש – בתקן החדש בלעדיה דוחות פשוט לא יגיעו.
התקן רק פורסם. כמו במערכות דיוור וכלי Saas אחרים, יש כלים שרמת העדכון שלהם נמוכה ואיטית (או ממש לא קיימת). המחיר של כלי הוא שיקול בבחירה, אבל כלי שלא התעדכן לתקן DMARC החדש הוא מועמד שיש לפסול.
כלי הטמעה וניטור DMARC נפוצים
| שם הכלי | הערות |
| easydmarc | most accurate for professionals |
| DMARC EYE | Affordable |
| DMARKOFF | value for money |
| Uriports | value for money |
| DMARC-DKIM | |
| dmarcdigests | |
| dmarcly | |
| dmarcian | |
| dmarcanalyzer | |
| dmarcreport |
אני סלע יפה, מומחה אימייל מרקטינג ועבירוּת אימיילים. אני מזמין אותך לפגישת יעוץ ראשונית של 1/2 שעה ללא עלות בנושא עבירוּת אימיילים ואסטרטגיית אימייל מרקטינג. book an email deliverability discovery call.
שאלות ותשובות - תקן DMARC חדש
שאלות ותשובות לגבי תקן DMARC החדש
מה זה DMARC?
תקן DMARC הוא פרוטוקול שנועד להגנה על דומיינים ומותגים מפני התחזות (spoofing) ולניטור הפרוטוקולים לאימות הדומיין.
הוא לא מאמת את הדומיין בעצמו (את זה עושים SPF ו-DKIM) אלא “רוכב” מעליהם ומאפשר לבעל הדומיין לפרסם מדיניות האומרת לשרתים המקבלים מה לעשות עם הודעות שנכשלות באימות (להעביר, להעביר להסגר או לדחות), ולאילו כתובות אימייל לשלוח דוחות DMARC על כל מי ששולח אימייל בשם הדומיין.
מה השתנה בדוחות ה-DMARC בתקן החדש?
- מסמך RFC 9990 הוסיף לסכימת ה-XML שדות חדשים (בהם discovery_method, אינדיקציית מצב בדיקה ושדה generator).
- הפך דרישות פורמט מ”רצוי” ל”חובה”.
- ביטל את מגבלת הגודל בתגית rua.
- הפך את אימות יעדי הדיווח החיצוניים לחובה – כך שבלי רשומת ההרשאה החיצונית, דוחות לכלי ניטור חיצוני פשוט לא יישלחו.
מה בעלי דומיין צריכים לעשות עכשיו בעקבות תקן DMARC החדש?
ארבעה פעולות רצויות:
- להסיר את התגיות pct, rf ו-ri מהרשומה אם הן קיימות.
- לשקול הוספת np=reject לחסימת סאב-דומיינים לא קיימים.
- לוודא שכלי ניטור ה-DMARC שלכם תומך בסכימת הדוחות החדשה ושרשומת ההרשאה החיצונית במקומה.
- אם המדיניות שלכם היא reject על דומיין עם משתמשים ששולחים לרשימות דיוור (discussion lists) – לבחון מחדש את ההחלטה מול הדוחות המצטברים.
מה קורה כשהשרת המקבל לא אוכף את מדיניות DMARC שפרסמתי?
למעשה זו התנהגות לגיטימית ומתועדת. התקן החדש קובע במפורש ששרת מקבל רשאי לקבל הודעה שנכשלה ב-DMARC גם תחת מדיניות reject, ואף ממליץ לא לדחות רק על בסיס המדיניות. הסטייה מהמדיניות המיושמת לעומת המפורסמת מתועדת בדוח המצטבר באלמנט reason, כך שבדוחות תוכלו לראות בדיוק מתי ולמה המדיניות שלכם לא יושמה כלשונה.
האם תקן DMARC החדש מסתמך על ARC כפתרון לבעיית ה-Forwarding?
לא. ARC (RFC 8617) נשאר מסמך נפרד במעמד Experimental, והוא אינו חלק מהמנגנון הנורמטיבי של תקן ה-DMARC החדש. התקן מתמודד עם הבעיה אחרת: הוא מנחה שרתים מקבלים שלא לדחות הודעה רק בגלל מדיניות reject שפורסמה, אלא להפעיל שיקול דעת נוסף. שרת מקבל רשאי להשתמש ב-ARC כאחד הכלים לשיקול הדעת הזה, אבל זו החלטה מקומית שלו, מחוץ למוגדר בתקן.
למה Forwarding שובר את אימות הדומיין ומכשיל DMARC?
פעולת Forwarding (העברה) שוברת את אימות הדומיין ומכשילה DMARC, כי ה-SPF נבדק מול כתובת ה-IP של השרת האחרון ששלח, וזו של שרת הביניים (שביצע את ההעברה) אינה מופיעה ברשומת ה-SPF של דומיין המקור.
התקן החדש אף מחדד שהבדיקה נעשית אך ורק מול זהות ה-MAIL FROM, ללא Fallback ל-HELO. ה-DKIM שורד Forwarding לרוב כל עוד לא נעשה שינוי לגוף ההודעה, אך נשבר כשהמתווך משנה את ההודעה (למשל אם מתווסף footer או disclaimer).
מה מחליף את תגית pct בתקן החדש?
בתקן DMARC החדש הוגדר מצב בדיקה חדש באמצעות התגית t.
התגית t מחליפה את תגית PCT (אחוזים) שאינה תקפה עוד. t=y מאותת שהמדיניות כעת במצב בדיקה, והציפייה היא שהצד המקבל יחיל רמה אחת מתחת למוצהר (reject יטופל כ-quarantine, ו-quarantine כ-none). אין השפעה על מדיניות none, ואין השפעה על שליחת הדוחות.
ברירת המחדל t=n – אכיפה מלאה.
מה עושה תגית np החדשה?
תגית np מגדירה מדיניות נפרדת לסאב-דומיינים שאינם קיימים (מחזירים NXDOMAIN). זו ההגנה הראשונית שכדאי להפעיל בתקן החדש: סאב-דומיין שלא קיים ב-DNS לא שולח אימייל לגיטימי, ולכן אפשר להגדיר np=reject כבר היום, גם אם הדומיין הראשי עדיין ב-p=none, בלי שום סיכון שאימייל אמיתי שלכם יפגע.
אילו תגיות DMARC הוצאו משימוש בתקן החדש?
שלוש תגיות: pct (אכיפה הדרגתית באחוזים, שבפועל לא יושמה בעקביות), rf (פורמט דוחות כשל, שהיה מיותר כי קיים רק פורמט אחד) ו-ri (מרווח בין דוחות, שממילא זכה להתעלמות). אם הן קיימות ברשומה שלכם, שרתים מתעלמים מהן – אבל כדאי להסיר אותן.
מה זה DNS Tree Walk?
DNS Tree Walk הוא האלגוריתם באמצעותו שרת מקבל מאתר את רשומת ה-DMARC ואת הדומיין הארגוני בתקן החדש.
במקום להסתמך על ה-Public Suffix List חיצונית, השרת שואל את ה-DNS ישירות: הוא מחפש רשומה בדומיין השולח, ואם לא מצא – מטפס במעלה ההיררכיה תווית אחר תווית, עד שמונה רמות. הרשומה הראשונה שנמצאת קובעת.
האם קיים תקן שנקרא DMARC 2 או DMARC 2.0?
לא. אין דבר כזה DMARC2. במאי 2026 פורסם תקן DMARC מעודכן (שכונה בקהילה DMARCbis או DMARC2.0), אבל מזהה הגרסה ברשומה לא השתנה: רשומת DMARC ממשיכה להתחיל ב-v=DMARC1, ורשומות קיימות ממשיכות לעבוד ללא שינוי.
האם בעקבות פרסום תקן DMARC חדש, רשומת ה-DMARC הקיימת שלי תפסיק לעבוד?
לא. התאימות לאחור מלאה. שרתים מקבלים ממשיכים לקרוא רשומות קיימות, ותגיות שהוצאו משימוש פשוט זוכות להתעלמות.
אין צורך בשינוי דחוף, אבל מומלץ לנקות תגיות ישנות בעדכון ה-DNS הבא.
הסיבה למהר ולעדכן את הרשומה היא התגית החדשה np – שמאפשר להגן מיד על סאב דומיינים לא קיימים (שאינם בשימוש).
מה ההבדל המהותי בין תקן DMARC הישן לתקן DMARC החדש?
עיקרי השינויים בתקן DMARC החדש:
- התקן החדש קיבל מעמד Proposed Standard במסלול התקינה הרשמי של ה-IETF.
- החלפת ה-Public Suffix List באלגוריתם DNS Tree Walk.
- הוצאת שלוש תגיות משימוש (pct, rf, ri).
- הוספת שלוש תגיות חדשות (np, t, psd).
- הנחיות מפורשות לשרתים מקבלים לגבי אופן אכיפת מדיניות reject.
מהם מסמכי ה-RFC של תקן ה-DMARC החדש?
התקן החדש מורכב משלושה מסמכים שפורסמו במאי 2026:
RFC 9989 – הפרוטוקול עצמו.
RFC 9990 – דוחות מצטברים
RFC 9991 – דוחות כשל.
שלושתם יחד מתחליפים את RFC 7489 מ-2015 ואת RFC 9091.
לקריאה נוספת
אני סלע יפה, מומחה אימייל מרקטינג ועבירוּת אימיילים. אני מזמין אותך לפגישת יעוץ ראשונית של 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
