מדיניות DMARC: בחירת none, quarantine ו-reject

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

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

מסלול מקובל הוא שימוש ב-p=none לזיהוי מקורות שליחה, מעבר מבוקר ל-p=quarantine אחרי בדיקת אימות שעובר עם התאמה, ובהמשך בחינת p=reject. חקרו את הכשלים שנותרו: לא כל כשל מעיד על התחזות. קצב המעבר המתאים תלוי בתעבורה ובנתונים שיש לכם.

מהי מדיניות DMARC?

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

הנמען בודק SPF ו-DKIM ומשווה את הדומיינים ששימשו לאימות לדומיין From המוצג. התאמה לבדה אינה מספיקה: גם האימות המתאים צריך לעבור.

אם SPF עובר ויש התאמה לדומיין, DMARC עובר.

אם DKIM עובר ויש התאמה לדומיין, DMARC עובר.

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

איזו מדיניות כדאי לבחור תחילה?

בדרך כלל מתחילים ב-p=none, אלא אם כבר יש נתונים מייצגים והוכח שכל המקורות הלגיטימיים עוברים SPF או DKIM עם התאמה. ניטור מאפשר להעריך את השפעת האכיפה לפני ההחמרה.

דוגמה לרשומת התחלה:

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

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

מקורות שליחה שקל לשכוח:

1. תוכנת הנהלת חשבונות ששולחת חשבוניות.
2. כלי משאבי אנוש או גיוס ששולחים הצעות.
3. מערכות CRM ושיווק ששולחות קמפיינים.
4. מערכות תמיכה שמשיבות בשם הדומיין הראשי.
5. כללי העברה אישיים שעלולים לפגוע ב-SPF בשלב הבא.

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

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

כמה זמן להשאיר את המדיניות על none?

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

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

כללו בבדיקה:

1. דואר עסקי שוטף.
2. שליחות שיווקיות.
3. מחזורי חיוב.
4. הסלמות תמיכה.
5. דואר מועבר.
6. אוטומציות של צדדים חיצוניים.

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

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

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

מדוע העברה משפיעה על DMARC?

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

גם מנהלים מנוסים עלולים לפספס את ההבדל בין זהויות השליחה.

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

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

לכן שתי האמירות יכולות להיות נכונות יחד:

1. SPF נכשל אחרי העברה.
2. DMARC עדיין עובר משום ש-DKIM עובר עם התאמה.

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

ARC מעביר הקשר אימות לאורך מערכות ביניים ורשימות תפוצה. הנמען מחליט אם לתת בו אמון ולהשתמש בו, והוא אינו מחליף את עבודת ההתאמה שלכם. ראו RFC 8617.

מתי לעבור ל-quarantine?

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

דוגמה לרשומה:

v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com

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

כשיש בעיה, אפשר לפעול כך:

1. משתמש מדווח על דואר חסר.
2. בודקים את השולח ואת ההתאמה.
3. מתקנים SPF, DKIM או את שניהם.
4. בודקים מחדש לפני מעבר ל-reject.

יש צוותים שמשתמשים ב-pct=25 או ב-pct=50 למעבר הדרגתי. התמיכה והיישום משתנים בין נמענים, ולכן אין לראות בכך חלוקת תעבורה מדויקת או הבטחת בטיחות. גם quarantine עבור 100% מהתעבורה דורש הערכה זהירה.

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

מתי לעבור ל-reject?

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

דוגמה לרשומה:

v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com

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

יתרונות אפשריים:

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

Google מתארת דחייה והגבלת קצב של דואר לא מאומת או לא מותאם. עשויים להופיע קודים כגון 4.7.31 לבעיות DMARC, 4.7.32 להתאמה וגם 5.7.26 בהחזרות Gmail. קראו את ההודעה המלאה וראו שאלות נפוצות על הנחיות לשולחי דואר ב-Google.

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

איזו רשומת DMARC לפרסם ב-DNS?

פרסמו את המדיניות כרשומת TXT תחת _dmarc.yourdomain.com. השתמשו ברשומת מדיניות DMARC אחת בלבד לכל דומיין; כמה רשומות מדיניות עלולות לפסול את גילוי המדיניות.

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

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

הגדרת דומיין TrekMail עשויה לכלול MX, SPF, DKIM ו-DMARC. המבנה הבא הוא להמחשה ואינו מתאים לכל נתיב שליחה. ערך quarantine בדוגמה אינו המלצה לדלג על ניטור:

@                MX   10 mail.trekmail.net.
@                TXT  "v=spf1 include:spf.trekmail.net -all"
dkim._domainkey  TXT  "<unique value from dashboard>"
_dmarc           TXT  "v=DMARC1; p=quarantine;"

אל תפרסמו SPF כפול, השתמשו בערכי DKIM האמיתיים ובדקו רשומות MX קיימות בעת שינוי. בספק שליחה משלכם פעלו לפי הוראות SPF ו-DKIM שלו; ה-include של TrekMail אינו חל אוטומטית על כל נתיב BYO. ראו SMTP משלכם (BYO).

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

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

שימו לב במיוחד ל:

1. השארת none ללא בדיקת דוחות או בחינת אכיפה. המדיניות אינה מבקשת חסימה.
2. דילוג על התאמת DKIM כי SPF נראה תקין. העברה עשויה לחשוף את התלות הזאת.
3. שכחת תת-דומיינים. אפשר להגדיר ב-sp= את המדיניות שהם יורשים.
4. התעלמות ממגבלות SPF. יותר מ-10 איברים שמפעילים חיפוש DNS בזמן הערכה עלולים לגרום ל-PermError; אין מדובר פשוט במספר חבילות שאילתת DNS.
5. אמון בפלטפורמה ששולחת בשם הדומיין בלי לבדוק כיצד היא חותמת.

דוגמה למדיניות תת-דומיינים:

v=DMARC1; p=reject; sp=none; rua=mailto:dmarc@yourdomain.com

זו בקשת reject לדומיין הראשי ו-none לתת-דומיינים שיורשים את המדיניות. היא אינה מוגבלת לתת-דומיין בדיקה יחיד; רשומת מדיניות מפורשת בתת-דומיין עשויה לקבל קדימות.

כיצד TrekMail יכול לסייע בהכנה?

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

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

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

בהתאם להגדרות, אפשר עם TrekMail:

1. לנהל כמה דומיינים מלוח בקרה אחד.
2. לבדוק רשומות DNS נדרשות לפני התחלת שימוש.
3. להשתמש ב-SMTP מנוהל במסלולים מתאימים או להגדיר SES/SendGrid משלכם ב-Nano.
4. להפריד אירוח תיבות מבחירת ספק השליחה.
5. למשוך דואר קיים באמצעות העברת IMAP, לפי יכולות המקור והרשאות הגישה.

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

סיכום: מעבר מדורג המבוסס על ראיות

מסלול מקובל הוא להתחיל ב-none, לתקן אימות והתאמה, לבחון quarantine ובהמשך לשקול reject. DMARC דורש תחזוקה והחלטות מבוססות, לא רק סימון משימה כהושלמה.

בקצרה:

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

גישה זו עשויה לצמצם התחזות ישירה לדומיין ולסייע בניהול הסיכון לדואר תקין, ללא הבטחת מסירה או הגנה מלאה. בדקו את התיעוד, היכולות והתמחור העדכניים של TrekMail ב-https://trekmail.net/pricing.