כך מגדירים נכון SPF, DKIM ו-DMARC ב-Google Workspace וב-Office 365
כל מנהל IT או צוות שיווק ב-B2B שמתכנן להריץ קמפיין דיוור ממוקד נתקל באותה שאלה: איך בכלל מגדירים SPF, DKIM ו-DMARC נכון ב-Google Workspace או ב-Office 365, בלי לפגוע בתיבות דוא"ל קיימות בדרך? המדריך הזה עובר שלב-שלב על ההגדרה בשני הספקים, כולל דוגמאות רשומות DNS, טווחי המדיניות המומלצים ל-DMARC, והטעויות שהכי הרבה עסקים עושים לפני שהם שולחים את הקמפיין הקר הראשון שלהם.
- בלי SPF, DKIM ו-DMARC פעילים, גם הודעת cold email מנוסחת מצוין תיפול לספאם או תיחסם
- SPF מוגבל ל-10 DNS lookups ולרשומה אחת בלבד לדומיין - איחוד כל ספקי השליחה לרשומה משותפת הוא קריטי
- DMARC יש להקשיח בהדרגה: p=none לניטור, ואז quarantine ורק לבסוף reject, אחרי בדיקת דוחות
- אימות טכני לא מחליף עמידה בתיקון 40 לחוק התקשורת - צריך גם הסכמה או יחסי לקוח קיים וגם מנגנון הסרה
- תת-דומיין ייעודי עם warmup הדרגתי מגן על המוניטין של הדומיין הראשי בזמן קמפיינים קרים
למה SPF, DKIM ו-DMARC הם תנאי סף לפני כל קמפיין B2B
גוגל ויאהו דורשות SPF, DKIM ו-DMARC פעילים מכל שולח בנפח משמעותי, וגם דומיינים ששולחים כמויות קטנות של דוא"ל B2B ממוקד מרגישים את ההשפעה - הודעה בלי שלושת הרשומות הללו נוטה לנחות בתיקיית ספאם או להיחסם עוד לפני שהנמען פותח אותה. עבור עסק ששולח cold email ממוקד לאנשי קשר ספציפיים בחברות ספציפיות, זה לא עניין טכני שולי אלא תנאי סף - בלי אימות תקין, גם ההודעה המדויקת והמנוסחת ביותר בעולם לא תגיע לתיבה.
אנשי IT ומנהלי שיווק ב-B2B מחפשים לעיתים קרובות בגוגל ביטויים כמו dmarc setup google workspace או dmarc setup 365, כי שני הספקים האלה מארחים את רוב תיבות הדואר העסקיות בישראל, וההגדרה בכל אחד מהם שונה בפרטים הטכניים אף שהעיקרון זהה.
חשוב להבהיר את הכיוון: המטרה כאן היא לא 'לעקוף' מסנני ספאם אלא להוכיח לשרתי היעד שהדומיין שלכם אכן מורשה לשלוח בשמו, כך שהודעה עסקית לגיטימית מקבלת יחס לגיטימי.
הגדרת SPF ב-Google Workspace וב-Office 365
SPF (Sender Policy Framework) היא רשומת TXT ברמת הדומיין שמפרסמת אילו שרתים מורשים לשלוח דוא"ל בשמו. ב-Google Workspace הרשומה נמצאת תחת לוח הבקרה - אפליקציות - Google Workspace - Gmail - אימות דוא"ל, שם המערכת מציגה את הערך המומלץ, אבל בפועל צריך להוסיף אותו ידנית כרשומת TXT אצל ספק ה-DNS של הדומיין.
ב-Office 365 מוסיפים רשומת TXT עם include:spf.protection.outlook.com, דרך Microsoft 365 admin center - Setup - Domains, או ישירות אצל ספק ה-DNS אם הדומיין לא מנוהל דרך מיקרוסופט.
אם שולחים גם דרך כלים חיצוניים לצד Google Workspace או Office 365 - כמו פלטפורמת דיוור B2B, CRM או מערכת תמיכה - יש לאחד את כל ה-include-ים לרשומת SPF אחת בלבד, כי DNS מתיר רשומת SPF יחידה לדומיין. חשוב גם לא לחרוג מ-10 חיפושי DNS מצטברים, אחרת התוצאה היא permerror וה-SPF כולו נכשל.
רשומת SPF משולבת לדומיין ששולח גם מ-Google Workspace וגם דרך פלטפורמת דיוור B2B חיצונית: v=spf1 include:_spf.google.com include:mail.esp-vendor.com ~all - שימו לב שיש כאן include אחד לכל ספק שולח, ולא יותר מרשומת SPF אחת לדומיין.
הגדרת DKIM: חתימה קריפטוגרפית לכל הודעה יוצאת
DKIM מוסיף לכל הודעה חתימה קריפטוגרפית שנוצרת עם מפתח פרטי, כשהמפתח הציבורי המקביל מפורסם כרשומת TXT ב-DNS. כך שרת היעד יכול לוודא שההודעה אכן יצאה מהדומיין ולא זויפה או שונתה בדרך.
ב-Google Workspace: לוח הבקרה - אפליקציות - Google Workspace - Gmail - אימות דוא"ל - Generate new record. עדיף לבחור מפתח 2048 סיביות אם האפשרות קיימת. מוסיפים את רשומת ה-TXT שגוגל מציגה (בדרך כלל תחת סלקטור בשם google._domainkey) אצל ספק ה-DNS, וממתינים להפצת הרשומה (DNS propagation, עד 48 שעות) לפני שלוחצים על Start authentication בחזרה בקונסולה.
ב-Office 365: דרך Microsoft Defender portal - Email & collaboration - Policies & rules - Threat policies - Email authentication settings - DKIM. בוחרים את הדומיין, מיקרוסופט מספקת שני רשומות CNAME (בשם selector1 ו-selector2) שיש להוסיף אצל ספק ה-DNS, ואז מפעילים את המתג. אפשר גם דרך PowerShell עם הפקודה Set-DkimSigningConfig לשליטה מלאה יותר, למשל בהגדרת סבב סלקטורים (key rotation).
DMARC: מדיניות, יישור (alignment) ומעבר הדרגתי מ-none ל-reject
DMARC היא רשומת TXT בכתובת _dmarc.domain.co.il שמחברת בין SPF ל-DKIM וקובעת מה שרת היעד צריך לעשות כשהודעה נכשלת באחד מהם - להעביר, להעביר לספאם (quarantine) או לדחות (reject). היא גם מפיקה דוחות (RUA) שמראים בדיוק אילו מקורות שולחים בשם הדומיין.
רשומת בסיס טיפוסית: v=DMARC1; p=none; rua=mailto:dmarc@domain.co.il; pct=100. p=none חשוב במיוחד בשלב הראשון - היא רק אוספת דוחות בלי להשפיע על מסירת הדוא"ל, כדי לוודא שכל מקורות השליחה הלגיטימיים (כולל פלטפורמות B2B חיצוניות) אכן עוברים אימות.
יישור (alignment) הוא הנקודה שהכי מבלבלת: יישור SPF דורש שהדומיין ב-envelope-from יתאים (או יהיה תת-דומיין) לדומיין שמופיע בכתובת ה'מאת' הגלויה, ויישור DKIM דורש שהדומיין החתום (d=) יתאים לאותה כתובת. הודעה יכולה לעבור SPF ו-DKIM בנפרד ועדיין להיכשל ב-DMARC אם אין יישור.
רק אחרי כמה שבועות של דוחות נקיים עוברים בהדרגה ל-p=quarantine עם pct נמוך, מעלים בהדרגה, ולבסוף עוברים ל-p=reject - קפיצה ישירה ל-reject בלי שלב ניטור עלולה לחסום גם דוא"ל לגיטימי.
הנתונים להמחשה בלבד, מתוך ניסיון עבודה עם קמפיינים B2B ממוקדים
כמה זה משפיע בפועל על שיעור הנחיתה בתיבה
מספר הרשומות שמוגדרות נכון מתואם ישירות לשיעור ההודעות שמגיעות ל-Inbox ולא ל-Spam או Promotions, בפרט כשמדובר בדומיין חדש או תת-דומיין שמתחיל להתחמם (warmup) לקראת קמפיין קר.
אצל לקוחות B2B שמריצים קמפיינים ממוקדים דרך LDM רואים דפוס עקבי: כל שכבת אימות שמתווספת מקטינה משמעותית את אחוז ההודעות שנתקעות בספאם, במיוחד אצל Gmail ו-Outlook, שהם היעד הדומיננטי של רוב הקמפיינים ל-B2B בישראל.
טווחים אינדיקטיביים בלבד, מתוך ניסיון עבודה עם דומיינים עסקיים בישראל
טעויות נפוצות שהורסות deliverability גם כשההגדרה 'כמעט' נכונה
רוב הכשלים לא נובעים מחוסר ידע אלא מפרטים קטנים שנשכחים בזמן ההטמעה, במיוחד כשיש כמה ספקי שליחה במקביל.
- יותר מרשומת SPF אחת לדומיין - DNS מתיר רק אחת, יש לאחד ל-include בודד
- חריגה מ-10 חיפושי DNS מצטברים ב-SPF, שגורמת ל-permerror ולכישלון שקט
- שימוש ב-~all או ?all במקום -all כשבפועל רוצים אכיפה מלאה
- שכחת יצירת DKIM נפרד לכלי דיוור חיצוני, לצד Google Workspace או Office 365
- קפיצה ישירה ל-p=reject בלי שלב ניטור ב-p=none - חוסמת גם דוא"ל לגיטימי
- forwarding שובר יישור SPF - לכן מומלץ לא להסתמך רק על SPF alignment
- אי-חידוש או סבב (rotation) של מפתחות DKIM לאורך זמן
הרשימה שLDM עובר איתה לפני כל קמפיין B2B
אימות טכני תקין הוא תנאי הכרחי אך לא מספיק. תיקון 40 לחוק התקשורת (בזק ושידורים), התשמ"ב-1982, קובע כי אסור לשלוח 'דבר פרסומת' בדוא"ל ללא הסכמה מפורשת מראש של הנמען (אופט-אין), למעט החריג הידוע כ'לקוח קיים' - כשקיימים יחסי מסחר קודמים אפשר לפנות בלי הסכמה מוקדמת, בתנאי שמוצעת אפשרות סירוב ברורה (אופט-אאוט) בכל הודעה. החוק מחייב גם ציון מפורש שההודעה היא פרסומת ופרטי זיהוי של השולח, ומאפשר לנמען שקיבל הודעה שלא כדין לתבוע פיצוי סטטוטורי של עד 1,000 ש"ח להודעה, ללא צורך להוכיח נזק.
לכן ב-LDM כל קמפיין B2B נבנה כך שהאימות הטכני (SPF, DKIM, DMARC) הולך יד ביד עם תשתית ההסכמה וההסרה, ולא מחליף אותה.
- בדיקת DNS לפני כל שיגור (dig TXT, dig _dmarc, כלי כמו MXToolbox) לוודא שהרשומות פעילות ותקינות
- תת-דומיין ייעודי לקמפיינים קרים, למשל outreach.domain.co.il, עם תוכנית warmup הדרגתית לפני עלייה בנפח
- ניטור שוטף של דוחות RUA מ-DMARC לאיתור מקורות שליחה לא מזוהים
- הסכמה מתועדת או יחסי לקוח קיים, ומנגנון הסרה ברור בכל הודעה, בהתאם לתיקון 40
- בדיקת placement בפועל (seed test ב-Gmail וב-Outlook) לפני שליחה בנפח מלא ללקוח
שאלות נפוצות
האם חובה להגדיר DMARC אם שולחים פחות מ-5,000 הודעות ביום?
מבחינת הדרישה הפורמלית של גוגל ויאהו הסף הרשמי הוא סביב 5,000 הודעות ביום מאותו דומיין, אבל בפועל גם דומיינים קטנים יותר שמריצים קמפיינים ממוקדים נהנים מ-DMARC באותה מידה - הוא מגן על המותג מפני spoofing ומשפר deliverability גם בנפחים נמוכים, ולכן מומלץ להגדיר אותו תמיד.
מה בדיוק ההבדל בין SPF, DKIM ו-DMARC?
SPF מפרסם אילו שרתים מורשים לשלוח בשם הדומיין, DKIM מוסיף חתימה קריפטוגרפית שמוכיחה שההודעה לא שונתה בדרך, ו-DMARC הוא שכבת המדיניות שמחברת בין השניים וקובעת מה השרת המקבל צריך לעשות כשהודעה נכשלת באחד מהם.
כמה זמן לוקח עד שהרשומות נכנסות לתוקף אחרי ההגדרה?
הפצת DNS (propagation) בדרך כלל אורכת בין כמה דקות ל-48 שעות, אבל את התועלת האמיתית רואים רק אחרי שבועיים-שלושה של איסוף דוחות DMARC, שמאפשרים לוודא שכל מקורות השליחה הלגיטימיים אכן עוברים אימות לפני שמקשיחים את המדיניות.
אפשר להגדיר SPF ו-DKIM גם כששולחים דרך פלטפורמה חיצונית לצד Google Workspace?
כן, וזה למעשה המצב הנפוץ ביותר אצל לקוחות B2B - יש להוסיף include נוסף לרשומת ה-SPF הקיימת עבור ספק הדיוור, ולוודא שה-DKIM שהוא מספק מיושר עם הדומיין השולח, כדי שגם ההודעות שיוצאות מהפלטפורמה יעברו DMARC.
מה גורם ל-DMARC להיכשל למרות ש-SPF ו-DKIM תקינים בנפרד?
לרוב הבעיה היא alignment - הדומיין שמופיע בכתובת ה'מאת' הגלויה לנמען שונה מהדומיין שמאומת בפועל ב-SPF (envelope-from) או חתום ב-DKIM (d=), למשל כשמשתמשים בדומיין שליחה טכני של ספק חיצוני בלי להתאים אותו לדומיין הארגוני.
איך תיקון 40 לחוק התקשורת קשור להגדרות SPF, DKIM ו-DMARC?
מדובר בשתי שכבות נפרדות: האימות הטכני קובע אם ההודעה בכלל מגיעה לתיבה, ותיקון 40 קובע אם מותר לשלוח אותה מלכתחילה - קמפיין B2B תקין חייב לעמוד בשתיהן, כלומר גם דומיין מאומת וגם הסכמה או יחסי לקוח קיימים בהתאם לחוק.
רוצים ליישם את זה באאוטריץ׳ שלכם?
נראה לכם איך זה עובד על הסגמנט והמוצר שלכם — לפני שמתחילים.
דברו איתנו