SPF, DKIM, DMARC: המדריך המעשי לצוותי מכירות ששולחים cold email

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

למה זה מתחיל להישבר: הקשר בין DNS לתיבת הדואר הנכנס

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

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

SPF: רשימת השרתים המורשים לשלוח בשם הדומיין

SPF (Sender Policy Framework) הוא רשומת TXT ב-DNS שמפרטת אילו שרתי דואר רשאים לשלוח בשם הדומיין. כשמייל מגיע, השרת המקבל בודק את כתובת ה-IP של השולח מול הרשימה הזו - אם היא לא שם, זה סימן ראשון לחשד בזיוף.

רשומת SPF טיפוסית לעסק שמשתמש בגוגל וורקספייס ובפלטפורמת שליחה נוספת נראית בערך כך: v=spf1 include:_spf.google.com include:sendgrid.net ~all. כל include מוסיף ספק חיצוני לרשימת המורשים, וה-~all בסוף אומר לספק המקבל להתייחס בחשדנות למי שלא ברשימה, בלי לדחות אוטומטית.

התקלה הנפוצה ביותר: DNS מאפשר עד 10 חיפושים מקוננים לבדיקת SPF אחת. עסקים שמצרפים ספק אחרי ספק - CRM, כלי cold email, מערכת ניוזלטר, פלטפורמת חתימות - בלי לנקות ישנים, חוצים את המכסה ומקבלים כשל שקט (permerror) שרוב הצוותים לא שמים לב אליו עד שה-deliverability צונח. תקלה שנייה שכיחה: יותר מרשומת SPF אחת לאותו דומיין, מה שגורם לכישלון אוטומטי אצל רוב הספקים.

DKIM: חתימה דיגיטלית שמוכיחה שהתוכן לא שונה בדרך

DKIM (DomainKeys Identified Mail) עובד אחרת מ-SPF: במקום לבדוק מי שלח, הוא בודק אם המייל שהגיע זהה למייל שנשלח. השרת השולח חותם כל מייל יוצא במפתח פרטי, וה-DNS של הדומיין מפרסם את המפתח הציבורי המתאים ברשומת TXT עם selector ייחודי, למשל selector1._domainkey.company.co.il.

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

טעות נפוצה: מעבר בין פלטפורמות שליחה (למשל מגוגל וורקספייס לכלי cold email ייעודי) בלי להגדיר selector DKIM חדש בהתאם. הפלטפורמה החדשה חותמת עם מפתח שהדומיין לא מכיר, וה-DKIM נכשל בשקט בזמן שה-SPF עדיין עשוי לעבור בהצלחה.

DMARC: המדיניות שמחברת בין SPF ל-DKIM

DMARC (Domain-based Message Authentication, Reporting and Conformance) הוא השכבה שרוב העסקים מדלגים עליה. הוא לא בודק דבר בעצמו - הוא מגדיר מדיניות שאומרת מה לעשות כש-SPF או DKIM נכשלים, ומוסיף דרישת alignment: הדומיין שמופיע בשדה From חייב להתאים לדומיין שעבר את ה-SPF או את ה-DKIM, לא רק לעבור בנפרד.

רשומת DMARC היא TXT תחת _dmarc.company.co.il, ומכילה מדיניות אחת מתוך שלוש: p=none (דיווח בלבד, בלי חסימה), p=quarantine (מייל שנכשל הולך לספאם) או p=reject (נדחה לגמרי). ההמלצה המקצועית היא להתחיל תמיד מ-p=none, לצפות בדוחות rua שמגיעים מגוגל ומיקרוסופט, לוודא שכל השרתים הלגיטימיים עוברים, ורק אז לעלות בהדרגה ל-quarantine ואחר כך reject.

קפיצה ישירה ל-p=reject בלי תקופת ניטור היא הטעות היקרה ביותר: כל שרת שולח לגיטימי שנשכח - מערכת CRM, כלי חתימת מייל, מערכת פרונטית - יתחיל להיחסם לגמרי, ולא רק להיכנס לספאם.

טעויות שחוזרות שוב ושוב אצל צוותי מכירות

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

• שימוש בדומיין הראשי של החברה לשליחת cold email בנפח גבוה, בלי סאב-דומיין נפרד - מה שמסכן את המוניטין של כתובות billing ו-support.
• הוספת פלטפורמת שליחה חדשה לרשומת SPF בלי להסיר ספקים ישנים, עד לחריגה ממכסת ה-10 lookups.
• הפעלת DMARC p=reject ביום הראשון, בלי שבועיים-שלושה של דוחות ניטור לפני כן.
• שכחה לעדכן selector DKIM אחרי מעבר ספק דואר או פלטפורמת שליחה.
• הנחה ש"התוכן טוב אז זה יגיע" - אימות הדומיין קודם לתוכן בהחלטת הפילטר.
• אי-הפרדה בין דומיין למשלוח שיווקי לדומיין תפעולי, כך שכישלון בקמפיין אחד פוגע בכל התקשורת העסקית.

צ'קליסט מהיר, המסגרת החוקית בישראל, ואיך LDM מטפלת בזה

מעבר לצד הטכני, שליחת מייל שיווקי לגורם עסקי בישראל כפופה לסעיף 30א לחוק התקשורת (בזק ושידורים), התשמ"ב-1982, כפי שתוקן בתיקון 40. הסעיף מחייב זיהוי ברור של המפרסם, ציון שמדובר בפרסומת, ומנגנון הסרה נגיש - גם כשמדובר בפנייה ממוקדת לבעל תפקיד ספציפי בחברה ולא בתפוצה המונית. אימות SPF, DKIM ו-DMARC תקין לא פוטר מהחובות האלה, הוא רק מוודא שהמייל בכלל מגיע ליעד.

צ'קליסט מינימלי לפני הפעלת קמפיין: רשומת SPF אחת בלבד, עם פחות מ-10 lookups; DKIM פעיל ומאומת דרך כלי כמו mail-tester או MXToolbox; DMARC קיים לפחות ברמת p=none עם כתובת rua לניטור; דומיין שליחה נפרד (סאב-דומיין) לתפוצה בנפח; חימום הדרגתי של הדומיין החדש לפני שליחה בקצב מלא.

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

שאלות נפוצות