אם אתם מנהלים חנות על Grow (וGrow) ולקוחות מתלוננים שחשבוניות, אישורי הזמנה או עדכוני משלוח לא מגיעים — או מגיעים ישר לתיקיית הספאם — הסיבה השכיחה ביותר היא שהמיילים האלה יוצאים מתשתית השליחה המשותפת של הפלטפורמה ולא מהדומיין של החנות עצמכם. ג׳ימייל, אאוטלוק ו-iCloud רואים כתובת "מאת" שנראית כמו הדומיין שלכם, אבל השרת ששלח בפועל שייך ל-Grow ולא מאומת עבור הדומיין הזה. הפער הזה בין "From" למקור השליחה בדיוק מה שמפעיל סינון אגרסיבי אצל ספקי התיבות הגדולים.
למה זה קורה בדיוק
פלטפורמות מסחר כמו Grow, בדומה ל-Shopify וגם ל-WooCommerce עם wp_mail() רגיל, שולחות בברירת מחדל מתשתית משותפת — כתובת ה-IP או שרת ה-SMTP משרתים אלפי חנויות אחרות ולא רק אתכם. כשה"From" בכותרת המייל מציג את הדומיין שלכם (למשל orders@your-store.co.il) אבל רשומת ה-SPF של הדומיין הזה לא כוללת את שרתי Grow, וגם אין חתימת DKIM תואמת — ג׳ימייל ואאוטלוק רואים חוסר יישור בין "From" למקור בפועל. זה בדיוק מה שדרישות ה-Bulk Sender של Google מ-2024 מכוונות אליו: SPF ו-DKIM חייבים להיות תקינים, ורצוי שיהיה גם DMARC ברמה כלשהי. בלי זה, אפילו מייל טרנזקציוני לגיטימי לגמרי — חשבונית על רכישה אמיתית — עלול להיתפס כחשוד.
איך מזהים שזו הבעיה אצלכם
הדרך המהירה ביותר לאבחן היא לשלוח מייל בדיקה — חשבונית אמיתית או הזמנת ניסיון — ולבדוק שלושה דברים: לאיזו תיקייה הוא נחת (Inbox, Promotions או Spam), האם SPF ו-DKIM עברו, והאם יש יישור DMARC. אפשר לעשות את זה בדיוק דרך בדיקת הגעה לאינבוקס בחינם, ששולחת לכם כתובות seed אצל 20+ ספקים ומחזירה דוח עם תיקיית הנחיתה, סטטוס SPF/DKIM/DMARC וגם צילום מסך של איך המייל נראה בפועל בתיבה — כולל בעברית ו-RTL, שם בעיות יישור טקסט נפוצות במיוחד.
איך מחברים SPF ו-DKIM לדומיין שלכם ב-Grow
הפתרון הקבוע הוא לא לשלוח מהתשתית המשותפת, אלא להסמיך את Grow לשלוח בשם הדומיין שלכם עם רשומות אימות תקינות. בפועל זה תהליך של שלושה שלבים:
- בהגדרות הדומיין/השליחה בפאנל הניהול של Grow, בדקו אם קיימת אפשרות "שליחה מדומיין מותאם אישית" או חיבור דומיין. אם קיימת — הפעילו אותה; המערכת אמורה לספק לכם ערכי CNAME או TXT ספציפיים להוספה ב-DNS.
- הוסיפו לדומיין רשומת SPF שכוללת את ה-include שסופק על ידי Grow, לצד כל ספקי דיוור נוספים שאתם משתמשים בהם (למשל שירות ניוזלטר נפרד). זכרו: SPF תומך רק ב-include אחד לרשומה, אבל אפשר לשרשר כמה include בתוך אותה שורה.
- הפעילו DKIM דרך ה-CNAME שהפאנל של Grow סיפק — כך שכל מייל שיוצא ייחתם עם מפתח פרטי שמשויך לדומיין שלכם, ולא רק לתשתית הכללית של הפלטפורמה.
DMARC: השכבה שסוגרת את הפינה
אחרי ש-SPF ו-DKIM מיושרים לדומיין, כדאי להוסיף רשומת DMARC — גם אם ברמת p=none להתחלה, רק כדי לקבל דוחות ולראות מי עוד שולח בשם הדומיין שלכם (כולל שירותים נוספים כמו Cardcom לחשבוניות, אם יש). ברגע שאתם בטוחים שכל מקורות השליחה הלגיטימיים מכוסים ב-SPF/DKIM, אפשר להעלות בהדרגה ל-p=quarantine כדי למנוע התחזות בשם החנות שלכם — תרחיש נפוץ בפישינג שמחקה חשבוניות מסחר.
חוק התקשורת (תיקון 40) — לא רק דיליברביליטי
חשוב לזכור שגם אם הבעיה הטכנית תוקנה, מיילים שיווקיים או פרסומיים דרך Grow (למשל מבצע או ניוזלטר ללקוחות קיימים) כפופים לתיקון 40 לחוק התקשורת: נדרשת הסכמה מפורשת מראש (אופט-אין), למעט חריג מוגבל של לקוחות קיימים לגבי מוצרים דומים. בנוסף, כותרת הנושא של מייל פרסומי חייבת להתחיל במילה "פרסומת", ובגוף המייל חייבים להופיע פרטי יצירת קשר של השולח ואפשרות הסרה פשוטה וברורה. חשבוניות ואישורי הזמנה עצמם הם טרנזקציוניים ולא כפופים לדרישת האופט-אין, אבל אם אתם משלבים בהם תוכן שיווקי — כדאי להפריד את הערוצים.
בדיקה שוטפת אחרי כל שינוי
אחרי חיבור SPF/DKIM ל-Grow, שינוי DNS יכול לקחת זמן להתפשט, ולפעמים הפאנל של הפלטפורמה לא מציג שגיאה ברורה כשמשהו לא הוגדר נכון. הדרך הבטוחה לוודא שהתיקון עבד היא לשלוח מייל בדיקה חדש ולבדוק שוב את סטטוס האימות והנחיתה בפועל — לא רק להסתמך על "הצליח" בפאנל. אפשר גם להיעזר בנתוני האימוץ של SPF/DKIM/DMARC בקרב דומיינים נוספים כדי להבין איפה החנות שלכם עומדת ביחס לשוק, דרך /email-stats/.