כדי להפוך את האימייל לבטוח יותר פותחו במשך השנים פרוטוקולי אימות דומיין שולח (SPF, DKIM). קשה לנטר אותם כשלעצמם וזה הפער ש-DMARC משלים. הוא מאפשר לנטר את האימות (authentication) של SPF ו-DKIM לגבי כל מקור שולח והתאמתם (alignment) לדומיין השולח * אם פועלים נכון אפשר לזכות בכמה "נקודות עבירוּת" * במאי 2026 DMARC עודכן לתקן חדש. האם אתם מוכנים?
עדכון חשוב: במאי 2026 פרסם ארגון ה-IETF תקן DMARC חדש (DMARCbis) המחליף את התקן המקורי מ-2015. המאמר הזה עודכן במלואו כך שהוא תואם לתקן החדש. שימו לב במיוחד לתגיות שהוצאו משימוש (pct, rf, ri) ולתגיות החדשות (np, t, psd). בסוף המאמר ישנן שאלות ותשובות.
תוכן עניינים
בעולם שבו כולנו חשופים לעשרת אלפים מסרים שיווקיים ויותר בכל יום, הקושי להבדיל בין פייק לאמת רק הולך וגובר.
כאן בולט יתרונו של האימייל בהשוואה ל”ערוצי התקשורת” הישירים האחרים, בכך שהוא כולל בתוכו מנגנונים מובנים לאימות זהות הדומיין השולח הנבדקים ברמת המפעילים (ספקיות אימייל, מסננות ספאם, מסננות 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) שנשלחים על ידי שרתי אימייל מקבלים (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) שונות:
מנגנון DMARC בודק alignment בין ה- mfrom (נקרא גם return-path addressאוenvelope-sender address או (bounce address, ה- from address (הכתובת המוצגת לנמענים), אליה נמעני יעשו reply ובודק את ה-alignment עם SPF ו-DKIM.
שימו לב: בניגוד לדוגמאות ישנות שמסתובבות ברשת (כולל בגרסה הקודמת של המאמר הזה), הטאגים pct, rf או ri – אינם בתוקף בתקן החדש. שרת שתומך בתקן החדש מתעלם מהן. ראו רשימה של תגיות שאינן בתוקף לפי התקן החדש.
אם התגיות האלה עדיין קיימות ברשומת ה-DMARC שלכם – האימייל לא יישבר, שרתים פשוט יתעלמו מהן. רצוי לנקות ולהגדיר רשומה עדכנית בהקדם.
את כתובת האימייל עבור ה-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 נראה במבט ראשון לא הגיוני: יש כלים חינמיים, יש כלים ב-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
מתחילים ב-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 תקינה באמצעות כלי ניטור 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 שתכשיל הכל ומדיניות DMARC במצב אכיפה.
לאחרונה בוצעה מתקפת פישינג משמעותית שאפשרה לתוקף מתוחכם לשלוח אימיילים מהדומיין של משרד המשפטים. המתקפה הזו הצליחה בין השאר בגלל שהדומיין לא היה במצב אכיפה, מה שיכול היה למנוע את המתקפה.
לניטור והטמעה של DMARC Policy אני ממליץ להשתמש בכלי חיצוני (ראו בהמשך רשימה של כלים) ולא להשתמש בהגדרות שמסופקות על ידי מערכות הדיוור השונות.
רצוי להגדיר 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 חדש
במהלך חודש אוגוסט 2026 אשיק שירות ניטור 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 החדש?
- להסיר את התגיות pct, rf ו-ri מהרשומה אם הן קיימות.
- להוסיף np=reject לחסימת סאב-דומיינים לא קיימים.
- לוודא שכלי ניטור ה-DMARC שלכם תומך בסכימת הדוחות החדשה ושרשומת ההרשאה החיצונית במקומה.
מה השתנה בדוחות ה-DMARC בתקן החדש?
- RFC 9990 הוסיף לסכימת ה-XML שדות חדשים (בהם discovery_method, אינדיקציית מצב הבדיקה ושדה generator).
- דרישות פורמט הפכה מ”רצוי” ל”חובה”.
- בוטלה מגבלת הגודל בתגית rua.
- אימות יעדי דיווח חיצוניים (אם הדוחות נשלחים לכתובת אימייל שאינה בדומיין המנוטר) הפכה לחובה. ללא רשומת ההרשאה החיצונית, דוחות לכלי ניטור חיצוני פשוט לא יישלחו.
מה קורה כשהשרת המקבל לא אוכף את מדיניות ה-DMARC שפרסמתי?
זו התנהגות לגיטימית ומתועדת. התקן החדש קובע במפורש ששרת מקבל רשאי לקבל הודעה שנכשלה ב-DMARC גם תחת מדיניות reject, ואף ממליץ לא לדחות את ההודעה רק על בסיס המדיניות.
בכלי ניטור DMARC התומכים בתקן החדש, הסטייה מהמדיניות מתועדת בדוח המצטבר בשדה reason, כך שבדוחות תוכלו לראות בדיוק מתי ולמה המדיניות שלכם לא יושמה כלשונה.
האם התקן החדש כולל את ARC כפתרון לבעיית ה-Forwarding?
לא. ARC (RFC 8617) נשאר מסמך נפרד במעמד Experimental, והוא אינו חלק מהמנגנון של תקן DMARC החדש.
התקן מתמודד עם הבעיה אחרת: הוא מנחה שרתים מקבלים שלא לדחות הודעה רק בגלל מדיניות reject שפורסמה, אלא דורש מהם להפעיל “שיקול דעת” נוסף.
שרת מקבל רשאי להשתמש ב-ARC כאחד הכלים לשיקול הדעת הזה, אבל זו החלטה מקומית שלו, ולא מוגדרת על ידי התקן.
למה Forwarding שובר את אימות הדומיין ומכשיל DMARC?
העברה של אימיילים על ידי שרתי דיוור לכתובות אחרות כמעט תמיד תשבור את האימות של SPF כי ה-SPF נבדק מול כתובת ה-IP של השרת האחרון ששלח, וזו של שרת הביניים אינה מופיעה ברשומת ה-SPF של דומיין המקור. רשומת DKIM לרוב לא תישבר אלא אם ההודעה השתנתה (למשל הוספת footer).
לדוגמא – הגדרתם חוק שמעביר אימיילים שקיבלתם מחברת הסלולר עם המילה “חשבונית” אל מנהל החשבונות שלכם. זו יכולה להיות הסיבה שהאימייל לא מגיע כלל, או נחסם ב-quarantine בהתאם למדיניות שהוגדרה על ידי השרת השולח (במקרה זה של חברת הסלולר).
התקן החדש אף מחדד שהבדיקה נעשית אך ורק מול זהות ה-MAIL FROM, ללא Fallback ל-HELO.
מה מחליף את תגית pct בתקן החדש?
בתקן החדש אין יותר התייחסות לתגית PCT.
היא מוחלפת על ידי תגית (Tag) חדשה t, שהיא בינארית: t=y מסמן מצב בדיקה שבו השרת המקבל מתבקש לא לאכוף את המדיניות (מקביל ל-pct=0 הישן), ו-t=n (ברירת המחדל) מסמן אכיפה מלאה.
אין יותר אחוזי ביניים – את המעבר ההדרגתי לאכיפה מנהלים תפעולית בעזרת דוחות DMARC המצטברים באמצעות כלי לניטור DMARC.
מה עושה תגית np החדשה?
תגית np מגדירה מדיניות נפרדת לסאב-דומיינים שאינם קיימים (מחזירים NXDOMAIN).
זו תגית שמאפשרת הגנה על סאב-דומיינים שלא קיימים ב-DNS.
סאב דומיין שאינו קיים, ממילא לא שולח אימיילים ולכן רצוי להגדיר np=reject כבר היום, גם אם הדומיין הראשי עדיין ב-p=none, בלי שום סיכון לאימיילים שלכם שנשלחים מהדומיין הראשי או מסאב דומיינים קיימים (להם אפשר להגדיר מדיניות באמצעות התגית sp).
אילו תגיות DMARC הוצאו משימוש בתקן החדש?
שלוש תגיות יצאו משימוש בתקן DMARC החדש:
- pct – אכיפה הדרגתית באחוזים, שבפועל לא יושמה בעקביות.
- rf – פורמט דוחות כשל, שהיה מיותר כי קיים רק פורמט אחד.
- ri – מרווח בין דוחות, שממילא זכה להתעלמות.
שרתים מקבלים יתעלמו מתגיות שיצאו מהתקן שקיימות ברשומת DMARC קיימות. כדאי להסיר אותן.
מה זה DNS Tree Walk?
DNS Tree Walk הוא האלגוריתם שבו שרת מקבל מאתר את המדיניות של רשומת DMARC ואת הדומיין הארגוני בתקן החדש. במקום להסתמך על ה-Public Suffix List חיצונית, השרת שואל את ה-DNS ישירות: הוא מחפש רשומה בדומיין השולח (במקרים רבים זה סאב דומיין), ואם לא מצא – מטפס במעלה ההיררכיה, עד שמונה רמות. הרשומה הראשונה שנמצאה היא הקובעת.
האם רשומת ה-DMARC הקיימת שלי תפסיק לעבוד?
לא. התאימות לאחור מלאה. שרתים מקבלים ממשיכים לקרוא רשומות קיימות. תגיות (tags) שהוצאו משימוש לא יזכו להתייחסות (השרתים יתעלמו מהן).
אין צורך לרוץ ולשנות את הרשומה הקיימת, אבל מומלץ להכיר את השינויים, ובעדכון הבא של ה-DNS למחוק תגיות ישנות.
סיבה אחת כן לרוץ לעשות את השינוי היא התגית החדשה np – שכדי להוסיף במצב reject על מנת להגן על סאב דומיינים לא קיימים.
מה ההבדל המהותי בין התקן הישן לתקן החדש?
- תקן DMARC החדש מעביר את התקן ממעמד Informational למעמד Proposed Standard במסלול התקינה הרשמי של ה-IETF.
- החלפת ה-Public Suffix List באלגוריתם DNS Tree Walk.
- הוצאת שלוש תגיות משימוש (pct, rf, ri).
- הוספת שלוש תגיות חדשות (np, t, psd).
- הנחיות מפורשות לשרתים מקבלים לגבי אכיפת מדיניות reject.
מהם מסמכי ה-RFC של תקן ה-DMARC החדש?
התקן החדש מורכב משלושה מסמכים שפורסמו במאי 2026: RFC 9989 (הפרוטוקול עצמו), RFC 9990 (דוחות מצטברים – Aggregate reports) ו-RFC 9991 (דוחות כשל – Failure Reports). שלושת מסמכי ה-RFC יחד מחליפים את RFC 7489 מ-2015 ואת RFC 9091.
האם קיים תקן שנקרא DMARC 2 או DMARC 2.0?
במאי 2026 פורסם תקן DMARC עדכני, שניתן לו כינוי בשלבי ההתהוות DMARC2.0 או DMARCbis. נכון להיום אפשר לקרוא לו פשוט: DMARC.
מזהה הגרסה ברשומה שב-DNS לא השתנה: רשומת DMARC ממשיכה להתחיל ב-v=DMARC1, ורשומות קיימות ממשיכות לעבוד ללא שינוי. התקן כולל מספר שינויים ותגיות (Tags) שאינן עוד בתוקף.
מה זה DMARC?
DMARC הוא פרוטוקול להגנה על דומיינים מפני התחזות ולניטור אימות האימייל. הוא לא מאמת את הדומיין (את זה עושים SPF ו-DKIM) אלא “רוכב” מעליהם ומאפשר לבעל הדומיין לפרסם מדיניות האומרת לשרתים המקבלים מה לעשות עם הודעות שנכשלות באימות (להעביר, לסמן כספאם או לדחות), ולאילו כתובות אימייל לשלוח דוחות DMARC.
לקריאה נוספת
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
