מחולל DMARC: איך בונים רשומת policy בלי לתקוע קמפיין מכירות

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

למה SPF ו-DKIM לבד לא מספיקים

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

DMARC סוגר את הפער הזה: הוא דורש alignment בין דומיין ה-From לבין הדומיין שאומת ב-SPF או ב-DKIM, ומגדיר מדיניות (policy) למה לעשות עם מייל שלא עומד בזה - none (רק לדווח), quarantine (לספאם) או reject (לחסום לגמרי). בלי רשומת DMARC בכלל, ספקי תיבות דואר גדולים מתייחסים לדומיין כפחות אמין, וזה משפיע על deliverability גם כשה-SPF וה-DKIM תקינים.

לקמפיין B2B ממוקד המשמעות מעשית: תשובה חמה מ-CFO שמעניין אותו הפתרון שלכם עלולה פשוט לא להגיע, כי המערכת מצד הנמען לא סמכה על הדומיין השולח. לכן DMARC הוא לא רק אבטחה - הוא תשתית חובה ל-deliverability.

שימוש במחולל DMARC לבניית הרשומה

מחולל DMARC (dmarc generator) הוא כלי שמייצר עבורכם את שורת ה-TXT הנכונה בלי שתצטרכו לזכור את התחביר. הכלים הנפוצים - MXToolbox, dmarcian, EasyDMARC - עובדים לפי אותה לוגיקה כללית, גם אם הממשק שונה.

השלבים המעשיים: קודם מזינים את הדומיין, ואז בוחרים כתובת rua (Reporting URI for Aggregate) - כתובת מייל שתקבל דוחות יומיים על מי שולח בשם הדומיין ואיך הוא מתיישר מול SPF/DKIM. זו הכתובת החשובה ביותר בכל הרשומה, כי בלעדיה אתם עובדים בלי נתונים. אחר כך בוחרים policy (מתחילים תמיד ב-none), ולבסוף המחולל בונה שורת TXT שמפרסמים תחת _dmarc.הדומיין-שלכם.com.

אימות: אחרי הפרסום, בדקו עם dig TXT _dmarc.domain.com או עם אותו dmarc generator tool בפונקציית ה-checker שלו, וחכו 24-48 שעות לתפוצת DNS מלאה לפני שמסיקים מסקנות מהדוחות הראשונים.

• בחרו rua שנקרא בפועל - לא תיבה מתה, כי דוחות DMARC הם XML גולמי שדורש כלי קריאה כמו dmarcian
• אל תשכחו rp=none גם ל-subdomain (sp=) אם יש תת-דומיינים ששולחים מייל בנפרד
• לפני שמפעילים את הרשומה, ודאו שה-SPF כולל את כל השולחים החוקיים - כולל CRM ופלטפורמת ה-cold email
• שמרו את הרשומה הישנה בצד לפני עדכון, למקרה שצריך לחזור אחורה

המסלול מ-p=none ל-quarantine ועד reject

השגיאה הנפוצה ביותר היא לקפוץ ישר ל-p=reject אחרי שהמייל "נראה מוגדר". reject הוא בלתי הפיך ברמת המייל הבודד: אם מייל נכשל ביישור, הוא נחסם, נקודה. אם עדיין יש שולח לגיטימי שלא הוגדר נכון - למשל פלטפורמת ה-outreach ששולחת follow-up אוטומטי מדומיין שירותים - הוא ייעלם בלי שום התראה לשולח או לנמען.

לכן העלייה חייבת להיות הדרגתית ומבוססת נתונים מדוחות ה-rua: מתחילים ב-none ובודקים מי שולח בשם הדומיין ומהו אחוז היישור. כשרוב השולחים מיושרים, עוברים ל-quarantine עם pct חלקי (למשל 25%) ומעלים בהדרגה. רק כשה-quarantine המלא לא מייצר תלונות אמיתיות, עוברים ל-reject.

Google Workspace ו-Office 365: מה שונה

מחולל DMARC בונה את הרשומה בצורה זהה בלי קשר לספק, אבל ההכנה לפניו שונה. ב-Google Workspace צריך קודם להפעיל DKIM signing דרך Admin Console (ברירת המחדל כבויה) ולוודא שה-SPF include כולל _spf.google.com, וגם כל כלי שליחה חיצוני שמחובר לגוגל דרך SMTP relay או API.

ב-Office 365 / Microsoft 365 ה-DKIM מופעל בברירת מחדל דרך selector1/selector2 CNAME שחייבים להתפרסם ב-DNS לפני שה-DKIM נחשב תקין, וה-SPF כולל את include:spf.protection.outlook.com. בשני המקרים, אם משתמשים בפלטפורמת cold email או CRM שמזריקים מיילים דרך API ולא דרך שרתי גוגל/מיקרוסופט, צריך DKIM נפרד עבור אותו שולח - אחרת הוא ייכשל ביישור ברגע שעולים ל-quarantine או reject.

בנצ'מארק: שיעורי יישור לפני ואחרי תיקון

כדי לדעת מתי בטוח לעלות שלב, כדאי להסתכל על אחוז המיילים שעוברים יישור DMARC מלא לפני ואחרי תיקון SPF/DKIM. דומיין שנשלח ממנו רק דרך Google Workspace או Office 365 בלי שולחים צדדיים, בדרך כלל מגיע ליישור גבוה כמעט מיד. דומיין עם כלי outreach, CRM ומערכת signature נוספת דורש עבודה נוספת.

טעויות שחוסמות מיילי מכירות לגיטימיים

רוב הפניות שמגיעות אחרי מעבר ל-reject נכשל הן אותן שגיאות חוזרות.

• מעבר ישיר ל-reject בלי לקרוא אף דוח rua - אין דרך לדעת מי ייחסם
• שכחת include עבור פלטפורמת ה-cold email או ה-CRM ב-SPF, כך שכל הודעת מכירות נכשלת ביישור
• הזנחת subdomain policy (sp=) כשיש תת-דומיין נפרד לשיווק או ל-follow-up אוטומטי
• התעלמות מ-forwarders בצד הלקוח (למשל כתובת שמועברת אוטומטית) ששוברים SPF alignment אבל לא DKIM - סימן שחייבים DKIM תקין ולא להסתמך רק על SPF
• פרסום רשומת DMARC כפולה בטעות (שתי שורות TXT ב-_dmarc) שגורמת לרוב הפרשנים להתעלם מהרשומה כולה

רשימת בדיקה לפני p=reject וגישת LDM

לפני כל שדרוג policy, ודאו שכל שולח לגיטימי מזוהה בדוחות rua עם alignment תקין, שאין עוד תעבורה "אלמונית" שלא זיהיתם, ושיש לכם כלי קריאה (לא XML גולמי) שמציג את הדוחות בצורה ברורה.

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

ב-LDM אנחנו לא מפעילים p=reject ללקוח לפני שרואים לפחות שבועיים של דוחות rua נקיים, ולעולם לא מפעילים אותו בו-זמנית עם קמפיין שליחה חדש - כל שינוי בdeliverability צריך תקופת בידוד כדי לדעת מה גרם למה.

שאלות נפוצות