מה זה DMARC - מגן הדומיין | crm.buzz

מה זה DMARC – מגן הדומיין

DMARC

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

תוכן עניינים

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

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

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

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

כדי להפוך את האימייל לבטוח עוד יותר פותחו במשך השנים שורה של פרוטוקולים לאימות הדומיין השולח הנבדקים ע"י השרתים המקבלים (SPF, DKIM) וגם אמצעים הניתנים לזיהוי ויזואלי ע"י נמענים המקבלים את הודעות האימייל (BIMI). כל אלה מקנים לאימייל יתרונות והוא נחשב לערוץ האמין (trusted) ביותר בעיני לקוחות.

פרוטוקולי אימות דומיין נקראים SPF ו- DKIM והם חיוניים בתהליך אימות אימיילים ראשוני לצורך אימות הדומיין השולח.

יחד עם זאת, כדאי להדגיש שהגדרות נכונות של הטכנולוגיה מאחורי אימות הדומיין הם סף כניסה לעבירוּת. אימות הדומיין אינו מבטיח הגעה ל-INBOX.

מה זה DMARC ?

DMARC אינו פרוטוקול לאימות דומיין. פרוטוקולי אימות הדומיין SPF ו-DKIM מאמתים בשיטות שונות את זהות השולח. קשה לנטר אותם כשלעצמם וזה בדיוק הפער ש- DMARC מגשר עליו.

פרוטוקול DMARC נועד להגן על דומיינים (domains) ומותגים (brands) ולניטור הגדרות SPF ו-DKIM.

משמעות ראשי התיבות DMARC הן: Domain-based Message Authentication, Reporting & Conformance (קליט וקצר…)

מְדִינִיוּת (policy) DMARC מאפשרת להגדיר לספקיות אימייל ומסננות ספאם כיצד לטפל בהודעות אימייל שאינן מאומתות כהלכה באמצעות SPF ו- DKIM. 

ה-Policy מאפשר לספקיות לפעול בהתנהלות מול דומיניים המשתמשים ב-DMARC בצורה יעילה יותר וזולה יותר עבורן, להעביר את ההודעות תהליך סינון מהיר יותר וכדומה.

בנוסף DMARC מספק דוחות אגרגטיביים ופורנזיים שנשלחים על ידי שרתי אימייל מקבלים (receiving side) המספקים לצד השולח נתונים כיצד הצד המקבל רואה את תעבורת האימייל שלכם. הדיווח כולל סטטוס אימות דומיין (valid SPF / DKIM) והתאמה (aligned SPF / DKIM) של הגדרות אימות דומיינים.

DMARC schema
תיאור סכמטי של מנגנון DMARC

למה כדאי להגדיר DMARC?

בניגוד לדעה הרווחת יש יתרון גדול בביצוע הגדרת DMARC Policy נכונה (ראו בהמשך לגבי טעויות בהגדרה), גם אם אתם משוכנעים שהגדרתם SPF ו-DKIM באופן מדויק ונכון.

מאוד שכיח שאנשי ומנהלי IT אינם מטמיעים DMARC כי "אצלם הכל בסדר". אך הם לא תמיד מודעים למערכות SAAS שהשיווק מפעיל, שרתי SMTP שצדדי ג' מפעילים עבורכם, או שרתי דיוור שאנשי פיתוח הגדירו בסביבות פיתוח ובדיקות שונות.

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

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

האימוץ של DMARC עולה משנה לשנה והתגבר מאוד בשנים האחרונות, אך הטמעות רבות גם אם הן תקינות (הרשומה ב-DNS תקינה) אינן מבוצעות באמצעות כלי ניטור. דוחות DMARC הם קבצי XML שניתן לנתח בצורה יעילה רק באמצעות כלי ניטור (ראו המלצות בהמשך).

dmarc adoption 2022
לחצו למקור DMARC.ORG

DMARC Checker – כלי לבדיקת רשומת DMARC

הזינו את שם הדומיין לבדיקה

גם גופים מוסדיים עושים טעויות

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

גופים מוסדיים ללא DMARC

דומיין שם המוסד האם הטמיע DMARC
discountbank.co.il בנק דיסקונט לישראל בע"מ לא
bank-yahav.co.il בנק יהב לעובדי המדינה בע"מ לא
mercantile.co.il בנק מרכנתיל דיסקונט בע"מ לא
menora.co.il מנורה מבטחים לא
hcsra.co.il הכשרה לא
yashir.co.il ישיר לא
shirbit.co.il שרביט לא

לניטור והטמעה של DMARC Policy אני ממליץ להשתמש בכלי חיצוני (ראו בהמשך רשימה של כלים) ולא להשתמש בהגדרות שמסופקות על ידי מערכות הדיוור השונות.

רצוי להגדיר DMARC על כל הדומיינים שלכם, גם על דומיינים שאינם מדוורים (parked domains). על דומיינים שאינם מדוורים רצוי מאוד להגדיר רשומת SPF שתכשיל SPF ותנוטר ב-DMARC.

דוגמא לרשומת SPF לדומיינים שאינם מדוורים:

				
					parked-domain.co.il TXT v=spf1 -all
				
			

בצעו סריקת דומיין

איך מגידירים DMARC

רשומת TXT המוגדרת ב-DNS של הדומיין תחת תת דומיין: “_dmarc”

מבנה רשומת DMARC:

DMARC pr
רשומת DMARC לדוגמא במצב אכיפה
				
					V=DMARC1; p=reject; sp=reject; pct=50; rua=mailto:rua-email@domain.com; ruf=mailto:ruf-email@domain.com
				
			

DMARC tags

Tag ערך הסבר
v DMARC1 גירסת DMARC. ערך קבוע DMARC1
p none / quarantine / reject הפוליסי המורה לשרת המקבל מה לעשות אם כישלון אימות או איפוס (alignment) של SPF/DKIM: מצב none = השרת המקבל מחליט מה לעשות. מצב quarantine = לא להעביר (או להעביר לספאם). מצב reject = לדחות את האימייל.
sp none פוליסי עבור sub-domains. באופן עקרוני, dmarc מוגדר לרמת הדומיין הראשי ואותו פוליסי יחול על התת דומיינים. ב=במקרים בהם רוצים ליצור פוליסי שונים עבור תת דומיינים אפשר להגדיר dmarc בנפרד עבורם.
rua mailto:ruf-email@domain.com כתובת האימייל אליה ישלחו דוחות אגרגטיביים
ruf mailto:ruf-mail@domain.com כתובת האימייל אליה ישלנחו דוחות פורנזים. מומלץ לא להגדיר קבלה של דוחות פורנזיים
fo 1 רלוונטי לדוחות פורנזיים: 0=להפיק דוח עם כישלון של SPF + DKIM 1=להפיק דוח אם כישלון של SPF או DKIM d=להפיק דוח עבור כישלון DKIM בלבד s=להפיק דוח עבור כישלון של SPF בלבד

מנגנון DMARC בודק alignment בין ה- mfrom (נקרא גם  return-path addressאוenvelope-sender address או (bounce address, ה- from address (הכתובת המוצגת לנמענים), אליה נמעני יעשו reply ובודק את ה-alignment  עם SPF ו-DKIM.

DMARC defaulted tags

Tag ערך ברירת מחדל הסבר
pct 100 הערך באחוזים מורה לספקיות אימייל על כמה אחוזים להחיל את הפוליסי. 100% (100) הוא ערך ברירת המחדל. רלוונטי רק ל-p=quarantine / reject
adkim r פוליסי לבדיקת התאמת sub-domain ודומיין מדוורים ב- SPF. ברירת המחדר היא r כלומר relaxed. ערכים אפשרים r (relaxed) או s (sticked)
aspf r פוליסי לבדיקת התאמת sub-domain ודומיין מדוורים ב-DKIM ברירת המחדל היא r כלומר relaxed. ערכים אפשרים r או s
rf afrf פורמט דוחות פורנזיים. כאמור ההמלצה היא כלל לא לבקש דוחות פורנזטיים
ri 86400 כל כמה זמן שרת מקבל ישלח דוח

רשומת DMARC  התחלתית תראה כך (דוגמא):

DMARC initial
				
					V=DMARC1; p=none; sp=none; pct=100; rua=mailto:rua-email@domain.com
				
			

את כתובת האימייל עבור aggregates report שבדוגמא יש להחליף בכתובת שתקבלו מכלי ניטור ה-DMARC שלכם. רשימה של כמה כלים מומלצים בהמשך המאמר.

יש חשיבות רבה ל-Syntax של הרשומה. V=DMARC1 חייב להופיע בתחילת הרשומה ו-DMARC תמיד באותיות גדולות. 

ה-policy (p) חייב להופיע אחרי טאג (tag) ה-V מופרד בנקודה פסיק (כמו בתמונה).

משמעות רשומת ה-DMARC בדוגמא הנ"ל:

ה-policy = none ; אותו policy (none) חל גם על sub-domains ; תחולה על 100% אחוזים מהאימיילים; מקבל דוחות אגרגטיביים בלבד.

ה-Policy הראשוני תמיד יהיה none על מנת להתחיל לקבל דוחות. בהמשך, אחרי מספר חודשי פעילות ותיקון הליקויים שיציפו הדוחות אפשר יהיה לעבור ל-Polity p=quarantine ורק בהמשך ל-reject.

גם לאחר מעבר ל- P=reject (הגנה על הדומיין) לא תמה העבודה. צריך להמשיך לנטר דוחות בקביעות.

דוחות אגרגטיביים DMARC aggregate reports

דוחות DMARC נשלחים משרתי אימייל המקבלים (receiving side) אימיילים.

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

אם תגדירו את ה-DMARC עם ההגדרות שתקבלו ממערכת הדיוור, מערכת הדיוור תקבל את הדוחות (מה היא עושה איתם?) ולכם לא תצמח מכך שום תועלת.

הדוחות כוללים פרטים כגון: מי שלח (from, mfrom), כתובת ה-IP ממנה נשלח האימייל, מצב האוטנטיקציה (SPF, DKIM authentication and alignment), ה-policy שהתקבל וה-policy שיושם בפועל על ידי הצד המקבל (שכיח שהשרת המקבל עושה downgrade  ל-policy למשל במקרים בהם הוא "מבין" שההודעה הייתה מאומתת כהלכה אך לא עוד. למשל כתוצאה מ-forward של האימייל ש"שבר" את האימות. 

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

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

DMARC RECORD GENERATOR – כלי ליצירת רשומת DMARC

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

דוחות פורנזיים DMARC forensic reports

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

שגיאות נפוצות בהטמעת DMARC

מתחילים ב-p=none  ונשארים כך…

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

כאמור, אני ממליץ להטמיע ולנטר DMARC רק עם כלי חיצוני ולא להטמיע DMARC כמוגדר במערכת הדיוור.

השאיפה לעבור מ-p=none  (שלא נותן כל ערך בשיפור עבירוּת) ל- p= quarantine ולבסוף ל-  p=rejec.

מטרת p=none הוא על מנת להתחיל לקבל דוחות DMARC ולהבין את תמונת המצב, לערוך שיפורים בהתאם.

מטמיעים DMARC שגוי או חסר ערך

שכיח לגלות שגיאות כתיב (typo) בהגדרת DMARC, או אף להטמיע DMARC שגוי או DMARC חסר תועלת לחלוטין. למשל DMARC ללא קבלת דוחות.

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

useless dmarc record

מטמיעים DMARC על sub-domain בלבד ולא על הדומיין הראשי

טעות נוספת ששכיח לגלות היא ש-DMARC הוטמע רק על sub-domain  ולא על הדומיין הראשי. מטרת DMARC לרוב תהיה להגן על הדומיין הראשי וכל תת הדומיינים שתחתיו. אפשר להטמיע DMARC נפרד ל-sub-domains אך לרוב המדוורים אין צורך בזה.

לא מטמיעים בכל הדומיינים של העסק

כל עסק בעל דומיין צריך להטמיע DMARC כראוי ולא רק על דומיינים מדוורים. להפעיל על דומיינים כאלה hard fail ב- SPF (כמודגם קודם) ולהפעיל DMARC בפוליסי quarantine או reject.

לא נותנים הרשאות חיצוניות

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

זו רשומת TXT שמגדירים ב-DNS על מנת להיות בטוחים שהכלי החיצוני מקבל הרשאה לקבל דוחות DMARC.

the dmarc journey
המסע לקבלת וי כחול בג'ימייל
				
					domain.co.il._report._dmarc.external-dmarc-tool-domain.com
				
			

לא ממשיכים בניטור DMARC

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

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

כלי הטמעה וניטור DMARC נפוצים

שם הכלי הערות
easydmarc value for money
Uriports value for money
dmarcdigests value for money
dmarcly
dmarcian
kdmarc
dmarcanalyzer
dmarcreport

DMARC 2.0 – DMARCBIS

בקרוב (ככל הנראה לקראת סוף 2023) יושק תקן עדכני של DMARC שיקרא DMARCbis

התקן יעדכן את DMARC ויהיה תואם לאחור. כלומר לא יהיה צריך לעדכן רשומות קיימות.

חלק מהשינויים הם ביטול הטאג PCT (אחוזים) ו-ri הקובע את תדירות הדיווח.

a short interview with Jakub Olexa, Founder and CEO at Mailkit, talking about the upcoming DMARC 2.0:

Jakub, can you share what's the new DMARC 2.0, called DMARC new?

So the DMARC 2.0, also called DMARCbis is not that different from the current DMARC . It's backward compatible.

It just simplifies a lot of stuff that was not correctly understood by many or not properly used or was not implemented at all. So some of the features or attributes like the percentage are going away because those were misunderstood and difficult to implement by the receiving side.

The reporting interval is going away because that was essentially ignored by everyone and everyone generated reports on their own schedule because it kind of makes sense. And there is a change in how the DMARC will be fetched from the DNS record.

So this affects subdomains and their parent domains. And originally, this was based on the PSL, the public suffix list were either you had a DMARC record at that specific level you're from is so at a subdomain or it would go to the organizational level domain. But, this gets tricky to understand and implement when you have multiple levels of subdomains and led to confusions. Also, the dependence on public suffix list was a bit of a complication. So the new version will use Tree walk, so it will look to the next level above and then above and then above until it reaches the final one. So, those are essentially the major changes in DMARC 2.0.

Do we have a time frame when it's going to be released? 

Well, it's still a draft. It's going to be definitely discussed this next week (June 2023), at M3AAWG, but I'm not involved directly with the IETF process, so I have no idea when this is going to become an RFC. 

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

לקריאה נוספת

ארגון DMARC.ORG

הרשאה לקבל דוחות לדומיין חיצוני

בעיות נפוצות בהטמעת DMARC

שיחה בין מייסד SparkPost למנכ"ל Dmarcian

מתי כדאי להגדיר DMARC לתת דומיין?

בקרוב תקין DMARC חדש dmarcbis

אודות הכותב

sella
סלע יֹפֶה

מלווה חברות, עסקים, סטרטאפים ומערכות דיוור בארץ ובעולם בנושא עבירוּת אימיילים (email deliverability) ואסטרטגיית אימייל מרקטינג כדי שאימיילים שעסקים שולחים יגיעו ל-Inbox ולא אל ה-Spam.

יוצר הבלוג והפודקאסט crm.buzz

רוצה להתמקצע

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

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

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

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

הרשמה לניוזלטר פופ
דילוג לתוכן