הפרדת דומיין לדיוור שיווקי מול מיילים טרנזקציוניים

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

למה עירוב בין דיוור שיווקי לטרנזקציוני מסוכן

ספקי תיבות כמו Gmail ו-Outlook — שני הענקים שדרכם עובר רוב הדיוור בישראל — לא מנתחים כל מייל בבידוד. הם בונים ציון מוניטין לפי דומיין (ולעיתים תת-דומיין) ולפי כתובת ה-IP השולחת. אם קמפיין שיווקי גדול נשלח בבת אחת, גורם לתלונות ספאם, ל-bounce גבוה או להרבה מחיקות בלי פתיחה — הציון הזה יורד. הבעיה: אם מייל איפוס סיסמה או קוד אימות דו-שלבי יוצא מאותו דומיין בדיוק, הוא "יורש" את אותו מוניטין פגום, אף שהוא מייל שהנמען ביקש בפירוש וממתין לו עכשיו.

אצל ESP ישראליים כמו ActiveTrail, smoove או InforUMobile זה קורה בקלות במיוחד — עסקים רבים משתמשים באותה פלטפורמה גם לניוזלטר וגם לאישורי תשלום מ-Cardcom או Grow, ולא תמיד שמים לב שברירת המחדל היא לשלוח הכול מאותו דומיין מאומת.

איך נראית הפרדה נכונה: תת-דומיינים ייעודיים

הפתרון המקובל בתעשייה הוא לפצל את הדומיין הראשי לכמה תת-דומיינים, כל אחד עם תפקיד אחד בלבד:

• mail.example.co.il — לניוזלטרים, קמפיינים ומיילים שיווקיים.
• tx.example.co.il או notify.example.co.il — לאישורי הזמנה, קבלות, קודי אימות ואיפוס סיסמה.
• הדומיין הראשי example.co.il נשאר לתעבורת דואר "אנושית" רגילה — תכתובת מול לקוחות מהצוות עצמו.

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

SPF, DKIM ו-DMARC — לכל תת-דומיין הרשומות שלו

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

דוגמה לרשומת SPF שמוגדרת רק על תת-הדומיין הטרנזקציוני, כדי שרק שרתי מערכת ההזמנות יוכלו לשלוח ממנו:

פלטפורמות נפוצות בישראל: איפה ההפרדה נשברת בפועל

כמה תרחישים שחוזרים על עצמם אצל עסקים ישראלים:

• Grow (וGrow) — מיילים טרנזקציוניים של החנות (אישור הזמנה, מעקב משלוח) נשלחים לעיתים מתשתית הפלטפורמה עצמה, בלי דומיין מותאם אישית. חייבים לחבר ולאמת דומיין עצמאי כדי לקבל שליטה על SPF/DKIM.
• WooCommerce — פונקציית wp_mail() הבסיסית שולחת דרך שרת האחסון, בלי SPF/DKIM תקינים לדומיין העסק. תוסף SMTP חיצוני עם תת-דומיין ייעודי הוא הפתרון הסטנדרטי.
• Shopify — מאפשר לחבר דומיין שולח משלכם בפאנל, אך רבים משאירים את הגדרת ברירת המחדל ומאבדים את היכולת להפריד בין שיווקי לטרנזקציוני.
• ActiveTrail / smoove / InforUMobile — כל אלה תומכים בהגדרת תת-דומיין מאומת בקבצי ה-DNS, אבל זה שלב שצריך להפעיל באופן יזום בקבועת הפאנל — לא קורה אוטומטית.

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

איך בודקים שההפרדה באמת עובדת

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

1. האם המייל מהתת-דומיין השיווקי נוחת ב-Inbox או בקטגוריית Promotions ב-Gmail.
2. האם המייל מהתת-דומיין הטרנזקציוני נוחת ב-Inbox הראשי, לא בספאם, בכל אחד מהספקים הרלוונטיים לקהל שלכם — כולל Walla! Mail ו-iCloud.
3. האם רשומות SPF, DKIM ו-DMARC מאומתות בנפרד לכל תת-דומיין, ולא רק לדומיין הראשי.

אם תוצאות שני התת-דומיינים נראות זהות — כנראה שההפרדה לא באמת הושלמה, ועדיין יש נקודת כשל משותפת. שווה גם לעקוב אחרי מגמות אימות דומיינים כלליות בשוק דרך נתוני /email-stats/, כדי להבין לאן התעשייה נעה.

סדר פעולות מומלץ למעבר

1. מיפוי כל סוגי המיילים היוצאים היום (שיווקי, טרנזקציוני, תפעולי-פנימי) ומאיזה דומיין/כלי כל אחד יוצא.
2. יצירת תת-דומיין ייעודי לטרנזקציוני קודם, כי הוא הכי קריטי לתפקוד השוטף של הלקוחות.
3. הגדרת SPF, DKIM ו-DMARC נפרדים לתת-הדומיין הזה בקבועת ה-DNS.
4. בדיקת מסירה בפועל לפני מעבר לייצור — כולל בדיקה חוזרת אחרי כל שינוי DNS, כי הטמעה שגויה שכיחה יותר ממה שנדמה.
5. חזרה על התהליך לתת-הדומיין השיווקי, ורק אז — הפסקת השימוש בדומיין הראשי לדיוור המוני.