DMARC עם p=none רק צופה בהתחזות — כך עוברים לחסימה בלי לשבור דואר

כדי להגדיר DMARC ב־Google Workspace בלי לחסום דואר לגיטימי, ודאו שמקורות השליחה המורשים עוברים SPF או DKIM בהתאמה לדומיין שבשדה From:, פרסמו רשומת p=none עם כתובת לדוחות, ותקנו כשלים לפני החמרת המדיניות. הנחיות Google ל־DMARC מגדירות p=none כניטור ללא בקשה לחסום הודעה שנכשלה באימות, p=quarantine כבקשה להעבירה לספאם ו־p=reject כבקשה לדחותה. לכן p=none מאפשר לראות חשד להתחזות, אך אינו מבקש מהנמען לחסום אותה בגלל כשל DMARC.

רשומת DMARC מתפרסמת ב־DNS של הדומיין; אין צורך להפעיל אותה במסוף Google Admin. סדר העבודה הוא למפות גם מערכות ששולחות בשם הארגון מחוץ ל־Gmail, לאמת את הדואר שלהן, לבדוק דוחות לפי מקור שליחה, ואז לשנות את המדיניות. שיעור מעבר גבוה לכלל הדומיין אינו תנאי מספיק: תעבורה רבה מ־Gmail יכולה להסתיר כשל של מערכת חשבוניות ששולחת מעט הודעות.

ממפים את השולחים ומכינים SPF ו־DKIM

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

אם Google Workspace הוא מקור השליחה היחיד, הוראות Google ל־SPF נותנות את ערך ה־TXT הבא: v=spf1 include:_spf.google.com ~all. בדקו אם כבר קיימת רשומת SPF לפני פרסום הערך. אם שולחים גם דרך ספקים אחרים, יש לכלול את מקורותיהם ברשומת SPF המתאימה במקום לפרסם רשומות SPF נפרדות לאותו דומיין; את הערכים המדויקים מקבלים מכל ספק.

עבור דואר שנשלח דרך Google Workspace, מפיקים מפתח DKIM לדומיין במסוף הניהול, מפרסמים את הרשומה שהתקבלה ב־DNS ומפעילים חתימה. ספק חיצוני דורש הגדרת DKIM או Return-Path תואם אצלו; חתימת Google אינה חותמת אוטומטית על דואר שיוצא ישירות משרת אחר. שלחו הודעת בדיקה מכל מסלול פעיל לנמען חיצוני ובדקו בכותרותיה את תוצאות האימות ואת הדומיינים שנבדקו. חזרו על הבדיקה לאחר שרשומות ה־DNS והחתימה פועלות בפועל.

מתחילים בניטור ומזהים כשלים בדוחות

הכינו תיבה ייעודית לדוחות ופרסמו רשומת TXT בשם _dmarc.example.com, עם הערך v=DMARC1; p=none; rua=mailto:[email protected]. זו דוגמה לדומיין ולתיבה שיש להחליף בפרטים שבשליטתכם. אצל חלק מספקי ה־DNS מזינים בשם הרשומה רק _dmarc, משום שהספק מוסיף את שם הדומיין; בדקו לאחר השמירה שהשם שפורסם הוא השם שהתכוונתם אליו.

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

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

מפת ההחלטה לפני מעבר לאכיפה

• מקור מורשה נכשל: נשארים ב־p=none, מתקנים חתימת DKIM או דומיין Return-Path, ושולחים ממנו שוב הודעת בדיקה.
• מקור אינו מזוהה: בודקים אם הוא ספק פעיל, שרת ישן או שימוש בלתי מורשה. עצם הופעתו בדוח אינה סיבה להוסיף אותו ל־SPF.
• המקורות שנצפו עוברים, אך שליחה נדירה טרם נבדקה: ממשיכים לנטר עד שגם המסלול הזה נכלל בבדיקה.
• כל מקור מורשה שזוהה עובר, והכשלים שנותרו מוסברים: אפשר לעבור ל־p=quarantine ולבדוק כיצד נמענים מטפלים בדואר שנכשל.

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

עוברים ל־quarantine ובוחנים את גבולות pct

דוגמה מותנית לשלב ביניים היא v=DMARC1; p=quarantine; pct=10; rua=mailto:[email protected]. כאן pct=10 הוא בקשה להחיל את מדיניות quarantine על חלק מההודעות שנכשלו ב־DMARC, ולא תיאור של שיעור ההודעות שעברו אימות. המשיכו למדוד את תוצאות האימות של כל מקור מורשה ובדקו דיווחים על דואר תקין שהגיע לספאם לפני הגדלת האכיפה.

לתג pct יש גבול חשוב: RFC 9989 מסווג אותו כהיסטורי לאחר ששיעורי ביניים יושמו באופן לא עקבי אצל מקבלי דואר. לכן pct=10 אינו מבטיח שרק אותו שיעור מהדואר המושפע יטופל לפי המדיניות. גם מקבל הדואר מפעיל שיקול דעת משלו בטיפול בהודעות; הרשומה מביעה את בקשת בעל הדומיין ואינה מבטיחה תוצאת מסירה זהה אצל כל הנמענים.

מתי אפשר לשקול p=reject

לאחר ששליחה מורשית עברה את תקופת ה־quarantine בלי כשלים לא מוסברים, אפשר לשקול רשומה כגון v=DMARC1; p=reject; rua=mailto:[email protected]. לפני כן בדקו במיוחד דואר שעובר דרך העברות, כתובות מתווכות ורשימות תפוצה. העברה יכולה לשנות את שרת השליחה וכך לפגוע ב־SPF; שינוי גוף ההודעה ברשימת תפוצה עלול לפגוע גם בחתימת DKIM. אם שני המסלולים אינם מספקים עוד אימות תואם, הודעה לגיטימית עלולה להיכשל ב־DMARC.

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

קראו גם:

• מדיניות AI לעובדים: חמישה סעיפים שמונעים דליפה בלי לחסום עבודה