שמתם לב שרשומת ה-SPF שלכם נכשלת. אולי לקוח סיפר לכם שהתגובה שלו חזרה. אולי הרצתם כלי בדיקה וראיתם אזהרה אדומה. בכל מקרה, התגובה הראשונית שלכם עשויה להיות להיכנס ללחץ ולהתחיל לערוך רשומות DNS מיד. אל תעשו את זה. תיקון חפוז של SPF הוא בדיוק הדרך שבה צוותים נתקעים עם שליחת מיילים שבורה למשך ימים במקום דקות.
בואו נעבור יחד על איך בפועל מאבחנים ומתקנים רשומת SPF כושלת מבלי להפיל את שליחת המיילים לכל מי ששולח מהדומיין שלכם.
מה המשמעות של רשומת SPF כושלת
SPF, או Sender Policy Framework, היא רשומת DNS שמפרטת אילו שרתי מייל רשאים לשלוח מיילים בשם הדומיין שלכם. כשהיא נכשלת, זה בדרך כלל אומר אחד משלושה דברים:
- שרת מייל ששולח בשמכם לא רשום ברשומה
- יש שגיאת תחביר ברשומה
- חרגתם ממגבלת 10 חיפושי ה-DNS ש-SPF מאפשר
כל אחד מהמקרים הללו יכול לגרום לשרתי המייל המקבלים לסמן את ההודעות שלכם כחשודות, או לדחות אותן לגמרי. זו גם הסיבה שהגדרת ניהול DNS תקינה כל כך חשובה לאמינות המייל, כי SPF חי כולו בתוך אזור ה-DNS שלכם.
תתחילו בלשלוף את הרשומה הנוכחית שלכם
לפני שאתם נוגעים בכל, הוציאו את רשומת ה-SPF הקיימת שלכם מול העיניים. אפשר לעשות זאת עם כלי חיפוש DNS פשוט או דרך שורת הפקודה:
dig TXT yourdomain.com
רשמו בדיוק מה כתוב שם. אתם רוצים נקודת ייחוס כדי לדעת אילו שינויים אתם עושים ולהיות מסוגלים לחזור אחורה אם משהו משתבש.
הסיבות הנפוצות להגדרת DKIM SPF DMARC שנכשלת
SPF לעיתים רחוקות נכשל לבדו. אם הגדרת ה-DKIM SPF DMARC שלכם נעשתה בשלבים לאורך השנים, על ידי אנשים שונים, באמצעות כלים שונים, סביר להניח שהמקורות הרשומים ברשומת ה-SPF שלכם לא עודכנו בהתאם לשירותים שאתם באמת משתמשים בהם. כמה חשודים שכיחים:
- פלטפורמת שיווק שהוספתם בשנה שעברה ומעולם לא נכללה
- שרת מייל ישן שהוצאתם משימוש אבל עדיין מוזכר
- כלי CRM או תמיכה ששולח מיילים בשם הדומיין שלכם
- יותר מדי הצהרות "include", שדוחפות אתכם מעבר למגבלת 10 החיפושים
עברו על כל שירות ששולח מיילים בשם הדומיין שלכם, ספק המייל העסקי שלכם, כלי השיווק, ה-CRM, תוכנת החשבוניות, שירות המייל הטרנזקציוני, ווודאו שכל אחד מהם נכלל ברשומה.
תיקון הרשומה מבלי לשבור כלום
זה החלק שאנשים ממהרים בו, ולא צריך. בצעו לפי הסדר הזה:
1. בנו את הרשומה המתוקנת קודם בעורך טקסט. לעולם אל תערכו SPF ישירות בפאנל ה-DNS שלכם בלי שיש לכם את הגרסה הסופית מוכנה להדבקה. רשומה חצי מוכנה גרועה יותר מהרשומה השבורה שהתחלתם ממנה.
2. שמרו על פחות מ-10 חיפושים. כל מנגנון "include:" נספר כחיפוש. אם אתם קרובים למגבלה, שקלו לאחד כמה includes או להסיר שירותים שאתם כבר לא משתמשים בהם.
3. השתמשו ב-TTL נמוך בזמן הבדיקה. הגדירו TTL לערך כמו 300 שניות לפני שאתם מבצעים את השינוי. כך, אם משהו לא בסדר, התיקון יתפשט מהר במקום לקחת 24 שעות עד שיתעדכן.
4. שנו את ה-SPF לפני שאתם נוגעים ב-DKIM או ב-DMARC. אם כל הגדרת ה-DKIM SPF DMARC שלכם צריכה טיפול, תקנו חלק אחד בכל פעם. שינוי הכל בבת אחת הופך את זה לבלתי אפשרי לדעת איזה שינוי גרם לאיזו בעיה אם מיילים מתחילים לחזור.
5. בדקו עם שליחה אמיתית, לא רק כלי בדיקה. אחרי עדכון הרשומה, שלחו מייל בדיקה לכתובת Gmail או Outlook ובדקו את הכותרות. חפשו ספציפית "spf=pass" בכותרות שהתקבלו.
למה זה חשוב לכל הצוות, לא רק ל-IT
רשומת SPF שבורה או מגבילה מדי לא משפיעה רק על מיילים אוטומטיים. היא משפיעה על כל אדם בחברה ששולח מהדומיין הזה. תגובות מכירות, פניות תמיכה, שרשורי CC פנימיים דרך כתובת משותפת, הכל עובר דרך אותה רשומת SPF. אם אתם מחמירים את המדיניות מבלי לקחת בחשבון כל מקור שליחה, אתם עלולים בשקט לשבור את שליחת המיילים למחלקות שאין להן שום קשר לשינוי שביצעתם.
זו הסיבה שכדאי להתייחס להגדרת ה-DKIM SPF DMARC שלכם כתשתית, ולא כעריכת DNS חד פעמית. תעדו כל שירות שמורשה לשלוח בשם הדומיין שלכם. בדקו זאת בכל פעם שאתם מוסיפים כלי חדש. חזרו על הבדיקה לפחות פעמיים בשנה גם אם נראה שהכל תקין.
אל תשכחו את DMARC בדרך
אם אתם מתקנים SPF, בדקו גם את מדיניות ה-DMARC שלכם. רשומה שמוגדרת ל-"p=reject" עם SPF שבור תגרום למיילים אמיתיים לחזור, לא רק להיות מסומנים כחשודים. אם אתם לא בטוחים איזו רמת מדיניות מתאימה לדומיין שלכם כרגע, כדאי להבין את ההבדל בין מצבי ניטור לאכיפה לפני שאתם מחמירים משהו. כיסינו את זה בהרחבה במאמר מדיניות DMARC מוסברת: ההבדל בין None, Quarantine ו-Reject.
אם אתם רוצים הסבר רחב יותר על איך שלוש הרשומות עובדות יחד, מדריך בשפה פשוטה להגדרת DKIM, SPF ו-DMARC לדומיין שלכם הוא קריאה משלימה טובה. ואם אתם לא בטוחים שהגדרת ה-DKIM SPF DMARC הנוכחית שלכם אפילו עובדת, המאמר איך לבדוק אם הגדרת ה-DKIM SPF DMARC שלכם באמת עובדת כמו שצריך עובר על שלבי האימות המדויקים.
רשימת בדיקה מהירה לפני שאתם שומרים
- רשמתם כל שירות ששולח מיילים בשם הדומיין שלכם?
- הרשומה שלכם מתחת למגבלת 10 חיפושי ה-DNS?
- הורדתם את ה-TTL לפני ביצוע השינויים?
- בדקתם עם שליחת מייל אמיתית ובדקתם את הכותרות?
- מדיניות ה-DMARC שלכם תואמת לאמינות ה-SPF הנוכחית שלכם?
תיקון SPF לא מסובך ברגע שמאטים ומתייחסים אליו כתשתית משותפת כמו שהוא. הטעות שרוב הצוותים עושים היא לערוך את הרשומה בתגובה למשבר, בלי למפות מראש את כל מה שתלוי בה. הקדישו עשרים דקות נוספות מראש. זה הרבה יותר זול מאשר להסביר לצוות המכירות שלכם למה המיילים שלהם הפסיקו להגיע לתיבת הדואר של מישהו.
