איך להגדיר SPF, DKIM ו-DMARC בלי לשבש את הדואר מהאתר

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

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

מפו את השולחים האמיתיים לפני עריכת DNS

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

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

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

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

הוסיפו אימות בלי לשבור שולח קיים

מפרט SPF אינו מאפשר כמה רשומות SPF לאותו שם דומיין. כשספק שני זקוק להרשאה, עדכנו את המדיניות הקיימת במכוון במקום להוסיף עוד רשומת v=spf1 עצמאית. כמה רשומות TXT שאינן קשורות זו לזו הן דבר רגיל; הבעיה היא כמה מדיניויות SPF מתחרות.

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

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

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

השתמשו בדוחות DMARC לפני שמפעילים דחייה

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

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

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

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

בדקו דרישות של נמענים ומסירה בפועל

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

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

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

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