אם הגדרתם DMARC לדומיין שלכם, בטח הסתכלתם על תגית המדיניות ותהיתם מה בעצם בחרתם. p=none, p=quarantine, p=reject. הן נראות דומות, אבל הן אומרות לשרתי הדואר המקבלים לעשות דברים שונים מאוד עם הודעות שנכשלות באימות.
טעות כאן חשובה. אם תבחרו מדיניות מחמירה מדי מוקדם מדי, אתם עלולים לחסום את הניוזלטרים או החשבוניות שלכם. אם תשאירו את המדיניות רופפת מדי לזמן ארוך מדי, אתם בעצם לא מגינים על הדומיין שלכם מפני זיוף. בואו נעבור על מה שכל מדיניות עושה ואיך לעבור ביניהן בצורה בטוחה, כחלק מהגדרת DKIM SPF DMARC תקינה.
תזכורת קצרה למה ש-DMARC בעצם בודק
DMARC יושב מעל SPF ו-DKIM. הוא לא מבצע אימות משלו, הוא רק אומר לשרתים המקבלים מה לעשות כאשר בדיקות SPF או DKIM נכשלות, והוא דורש התאמה בין הדומיין בכותרת ה-"From" לבין הדומיינים שאותם בדיקות אלה מאמתות.
בלי DMARC, גם SPF וגם DKIM יכולים להיכשל בשקט וההודעה עדיין תגיע לתיבת הדואר של מישהו. זה הפער ש-DMARC סוגר. אם עוד לא עברתם על היסודות, כיסינו אותם במדריך מדריך בשפה פשוטה להגדרת DKIM, SPF ו-DMARC לדומיין שלכם.
מדיניות ראשונה: p=none
זו נקודת ההתחלה כמעט לכל דומיין. עם p=none, אתם אומרים לשרתים המקבלים: "בדקו את המייל מול רשומות ה-SPF וה-DKIM שלנו, אבל אל תעשו שום דבר מיוחד אם הבדיקה נכשלת. פשוט שלחו לנו דוח."
שום דבר לא נחסם או מועבר להסגר. זרימת הדואר שלכם נשארת בדיוק כפי שהייתה לפני שהוספתם DMARC. הערך כאן נמצא כולו בדיווח. תתחילו לקבל דוחות מצטברים (בדרך כלל יומיים, בפורמט XML) שמראים כל שרת ששולח דואר באמצעות הדומיין שלכם, האם ההודעות עברו אימות, ומאיפה הן הגיעו.
זה שלב הגילוי. לרוב תופתעו ממה שתמצאו. כלי שיווק, אינטגרציות CRM ישנות, פלטפורמת ניוזלטר ששכחתם ממנה, כולם שולחים דואר "מטעם" הדומיין שלכם בלי אימות תקין. אתם רוצים לתפוס את אלה לפני שאתם מחמירים את המדיניות, לא אחרי.
תכננו להישאר ב-p=none במשך לפחות שבועיים עד ארבעה שבועות. יותר מזה אם הדומיין שלכם שולח דואר דרך הרבה כלים חיצוניים.
מדיניות שנייה: p=quarantine
ברגע שהדוחות שלכם מראים שדואר לגיטימי עובר SPF ו-DKIM בעקביות, אתם יכולים לעבור ל-p=quarantine. זה אומר לשרתים המקבלים להתייחס להודעות שנכשלות בחשדנות, בדרך כלל על ידי הפניה שלהן לתיקיית הספאם במקום דחייה מוחלטת.
Quarantine הוא אזור הביניים. הוא נותן לכם הגנה אמיתית, מיילים מזויפים לא יגיעו לתיבה הראשית, אבל עדיין נותן לכם רשת ביטחון. אם משהו שלא תפסתם בשלב הניטור מתחיל להיכשל, הוא מסתיים בספאם במקום להיעלם לגמרי. אתם עדיין יכולים למצוא אותו, לאבחן את הבעיה ולתקן אותה.
אפשר גם להחיל את מדיניות ה-quarantine בהדרגה באמצעות תגית ה-pct. הגדרת pct=25 מחילה את מדיניות ה-quarantine רק על 25% מההודעות שנכשלות, מה שמאפשר לכם להעלות את האחוז בהדרגה ולעקוב אחרי בעיות תוך כדי תנועה.
מדיניות שלישית: p=reject
זו המדיניות המחמירה. שרתי דואר מקבלים יסרבו לגמרי להודעות שנכשלות ב-DMARC. לא תיבת דואר, לא תיקיית ספאם, רק דחייה ברמת השרת.
Reject הוא מה שאתם רוצים עבור דומיין מוגן במלואו, במיוחד עבור דומיינים המשמשים לתקשורת פיננסית, איפוס סיסמאות, או כל דבר שתוקפים ירצו להתחזות אליו. זה גם מה שספקי תיבות דואר גדולים יותר ויותר מצפים לראות משולחים לגיטימיים, במיוחד אחרי ש-Gmail ו-Yahoo החמירו את הדרישות שלהם לשולחים בכמות גדולה.
אבל reject אמור להיות הצעד האחרון, לא הראשון. לקפוץ ישר ל-p=reject בלי לעבור קודם דרך ניטור ו-quarantine היא אחת הטעויות הנפוצות ביותר שאנחנו רואים ב-DMARC. אם אפילו מקור שליחה לגיטימי אחד לא מאומת כראוי, המיילים האלה פשוט נעלמים. שום הודעת דחייה לא מגיעה לשולח, כי הדחייה קורית בצד המקבל. ייתכן שלא תבינו שמשהו לא בסדר עד שלקוח יגיד לכם שהוא מעולם לא קיבל חשבונית.
איך לעבור בין המדיניויות בצורה בטוחה
הנתיב הכללי נראה כך:
- התחילו עם p=none ואספו דוחות במשך כמה שבועות.
- בדקו כל מקור שליחה בדוחות האלה ותקנו SPF או DKIM לכל מקור שנכשל אבל הוא לגיטימי.
- עברו ל-p=quarantine עם ערך pct נמוך, ואז העלו אותו בהדרגה.
- ברגע שדוחות ה-quarantine נראים נקיים, עברו ל-p=reject, שוב תוך העלאה הדרגתית עם pct אם אתם רוצים זהירות נוספת.
לקרוא דוחות מצטברים ידנית זה כואב. רוב האנשים משתמשים בכלי דיווח DMARC כדי לפרש את ה-XML למשהו קריא. זה הגורם המשמעותי ביותר בשאלה האם הגדרת DKIM SPF DMARC שלכם באמת מצליחה. לדלג על שלב הדיווח ולנחש את הדרך ל-reject זו הדרך הכי בטוחה לגרום למיילים לגיטימיים להיעלם.
מה לגבי מדיניות תת-הדומיינים?
DMARC מאפשר לכם להגדיר מדיניות נפרדת לתת-דומיינים באמצעות התגית sp. זה חשוב יותר ממה שאנשים חושבים. אם לדומיין הראשי שלכם יש מדיניות reject מחמירה אבל לא הגדרתם sp, תת-דומיינים עשויים לרשת מדיניות חלשה יותר, או שתוקפים עשויים לכוון ספציפית לתת-דומיין לא מוגן כדי לזייף דואר שעדיין נראה אמין לנמענים. הגדרת sp=reject לצד המדיניות הראשית שלכם סוגרת את הפער הזה.
בדיקה שהמדיניות שלכם באמת עובדת
ברגע שהגדרתם מדיניות, אל תניחו סתם שהיא עושה את העבודה. שלחו מיילי בדיקה ממקורות לא מאומתים, בדקו את דוחות ה-DMARC שלכם באופן קבוע, ושימו לב לכל ירידה באחוזי המסירה מיד אחרי שינוי מדיניות. עברנו על התהליך הזה בפירוט רב יותר במאמר איך לבדוק אם הגדרת DKIM SPF DMARC שלכם באמת עובדת כראוי.
אם אתם מנהלים דואר אלקטרוני עבור דומיין עסקי, ספק אחסון טוב אמור להיות מסוגל לעזור לכם לבדוק את רשומות ה-DNS שלכם ולוודא שרשומות ה-SPF, ה-DKIM וה-DMARC שלכם מעוצבות נכון. שגיאת הקלדה אחת ברשומת TXT של DMARC יכולה להפוך את כל המדיניות ללא פעילה בלי שום אזהרה.
לסיכום
None, quarantine ו-reject הם לא שלושה פיצ'רים נפרדים, הם שלבים באותו מסע. התחילו בצפייה, עברו לאכיפה רכה, ונעלו את הדלת רק כשאתם בטוחים שלכל שולח לגיטימי יש מפתח. אם תמהרו, אתם מסתכנים באובדן דואר אמיתי. אם תדלגו על זה לגמרי, הדומיין שלכם יישאר פתוח לרווחה לזיופים. בכל מקרה, היעד זהה: מדיניות p=reject אכופה במלואה, מגובה ברשומות SPF ו-DKIM נקיות בכל מקורות השליחה שבבעלותכם.
