DMARC RUA: הגדרת כתובת דוחות וניתוח התאמה

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

חוסר מידע מקשה על חקירה. מערכת CRM מוגדרת לא נכון, תוסף WordPress שנשכח שולח בשם הדומיין הראשי או הודעה מועברת נכשלת ב-SPF. הטיפול בדואר משתנה ולא תמיד ברור מדוע. RUA מסייע לאסוף רמזים שניתן לבדוק.

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

מהו dmarc rua?

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

ברשומת DMARC, rua=mailto:... מבקש לשלוח דוחות ליעד הזה. לפי RFC 7489, התג rua מגדיר יעד משוב. הדוחות עשויים להכיל תוצאות אימות, התאמה, דומייני שליחה וקבלה, מספרי הודעות וטיפול שיושם.

RUA מסייע להעריך p=none, p=quarantine או p=reject. שלבו דוחות עם מלאי המקורות ובדיקות: הדיווח לבדו אינו מוכיח שכל תעבורה לגיטימית מוכנה לאכיפה.

מה דוחות RUA מראים?

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

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

בדרך כלל מתחילים ב-RUA ובוחנים ruf רק לצורך מסוים ועם אמצעי פרטיות מתאימים. דוחות מצטברים נפוצים; דיווח פורנזי נתמך פחות ומעלה יותר שאלות פרטיות.

לדוגמה: אתם משתמשים ב-Google Workspace, ביישום חיוב ובמערכת תמיכה. שלושת המקורות יכולים להופיע ככל שנמענים משתתפים מדווחים על תעבורתם. גם כשל התאמת DKIM בתמיכה עשוי להתגלות. אבל שרת לא מוכר במדינה אחרת אינו בהכרח מתחזה; חקרו את המקור והנתיב לפני מסקנות.

פרסום רשומת RUA

הוסיפו TXT תחת _dmarc.yourdomain.com וציינו כתובת rua=mailto: תקינה. ניטור הוא בדרך כלל התחלה מתאימה לפני החמרת אכיפה.

הדוגמה הבאה משתמשת בהתאמה מחמירה אופציונלית. זו אינה ברירת המחדל הטובה ביותר לכל סביבה; בדקו את ההשלכות של דרישת התאמה מלאה:

_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=s; aspf=s"

החלופה הפשוטה הבאה משתמשת בהתאמה גמישה כברירת מחדל. אל תפרסמו את שתי רשומות המדיניות יחד:

_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

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

בהגדרת TrekMail, היעזרו ברשומות DNS נדרשות. בדיקות מובנות עשויות לסייע בזיהוי שגיאות SPF, DKIM ו-DMARC, אך אינן מחליפות בדיקת כל נתיב שליחה.

בדיקת רשומת RUA

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

השתמשו ב-dig או ב-nslookup:

dig +short TXT _dmarc.example.com
nslookup -type=TXT _dmarc.example.com

אמורה להופיע רשומת DMARC בתשובה. הדוגמה הבאה היא חלופה מתאימה לפי RFC 7489, לא רשומת מדיניות נוספת לפרסום יחד:

"v=DMARC1; p=none; rua=mailto:dmarc-feedback@example.com"

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

קריאת דוח RUA בצורה מסודרת

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

בדקו לפי הסדר:

1. בחנו כתובת מקור ו-DNS הפוך והשוו למערכות וליומנים שלכם. PTR או מיקום גאוגרפי אינם מוכיחים זהות שולח או שימוש לרעה.
2. בדקו את מספר ההודעות. מקור עם 2 הודעות עשוי להיות חשוב עסקית לא פחות ממקור עם 20,000; התחשבו בנפח ובחשיבות.
3. בדקו SPF, DKIM והתאמה. אימות שעובר ללא התאמה עדיין עלול שלא להספיק ל-DMARC.
4. בחנו טיפול: none אינו מוכיח מסירה או ניטור בלבד, quarantine אינו מציין תיקייה קבועה ו-reject אינו מבטיח חסימה. הטיפול המקומי עשוי להשתנות.
5. חקרו אם המקור תקין, מוגדר לא נכון או לא מורשה. כתובת לא מוכרת יכולה להיות ממסר משותף או שרת העברה.

Google דורשת משולחי Gmail כלליים SPF או DKIM, ומספקי תפוצה רחבה את שניהם עם DMARC והתאמה ל-From: לפי התנאים החלים. RUA מסייע לחקור התאמה, אך אימות שעובר או דיווח אינם מוכיחים תוכן בטוח או הגעה לתיבת הדואר הנכנס.

דפוסי כשל נפוצים ב-RUA

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

1. שולח תקין, הגדרה שגויה

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

ב-TrekMail התאימו DNS לשולח בפועל. ל-SMTP משלכם ראו שימוש ב-SMTP משלכם. TrekMail SMTP מנוהל מתאר שליחה וחתימת דומיין בנתיב המנוהל הנתמך.

2. SPF נכשל בגלל העברה

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

קראו על העברת דואר ועל העברת דואר מהדומיין ל-Gmail. כשל SPF אינו בהכרח כשל DMARC.

3. מקור לא מוכר ושימוש לרעה אפשרי

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

הפניית RUA לשירות חיצוני

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

RFC 7489 מסביר שיעד rua מחוץ לדומיין הארגוני עשוי לדרוש רשומת אישור בדומיין היעד. מנהל היעד מפרסם לדוגמה:

example.com._report._dmarc.thirdparty.example.net. IN TXT "v=DMARC1"

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

מעבר מ-p=none ל-quarantine או reject

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

מסלול אפשרי:

1. פרסמו RUA עם p=none.
2. צפו בדוחות למשל במשך 1 עד 2 שבועות לבדיקה ראשונית, והאריכו לפי תעבורה נדירה או תקופתית.
3. תקנו מקורות תקינים כך ש-SPF או DKIM יעברו עם התאמה.
4. שקלו p=quarantine אחרי הערכת מקורות, כשלים והשפעות.
5. שקלו p=reject אחרי בדיקה מספקת של תעבורה תקינה ועם תוכנית התאוששות.

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

תהליך משולב לתפעול RUA

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

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

המחירים המוזכרים מתחילים ב-$3.50 לחודש. Nano מתואר כחינמי ללא כרטיס. למסלולים בתשלום עשויה להיות תקופת ניסיון חינמית של 14 יום; בדקו תנאים עדכניים, כולל דרישת כרטיס אשראי לפי העניין.

סיכום: RUA תומך בנראות התפעולית

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

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

ארגנו גם את שאר הסביבה. TrekMail עשוי לספק לפי המסלול אירוח למספר דומיינים, אחסון משותף, הקמת תיבות באמצעות הזמנות והעברת IMAP. בדקו יכולות ותמחור ב-trekmail.net; פלטפורמת ניהול אינה מחליפה בדיקת נתיבי שליחה.