מייל מטופס יצירת קשר נכנס לספאם? הנה הפתרון

כשטופס יצירת קשר באתר "לא שולח מייל", הבעיה כמעט אף פעם לא בטופס עצמו — הוא עשה את העבודה שלו, שלח בקשה לשרת. הבעיה מתחילה ברגע שהשרת מנסה בפועל להעביר את המייל לתיבה שלכם. אם המייל לא הגיע בכלל, כנראה שהוא נחסם עוד לפני שהגיע לספק שלכם. אם הוא כן הגיע אבל בתיקיית הספאם — זה סימן ברור שהשליחה לא עברה אימות SPF/DKIM תואם לדומיין של האתר. שני המקרים חולקים אותו שורש: השרת ששלח את המייל אינו "מורשה" בעיני Gmail, Outlook או Walla! לשלוח בשם הדומיין שלכם.

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

באתר וורדפרס טיפוסי, טופס יצירת קשר (Contact Form 7, WPForms, Elementor Forms וכו׳) לא שולח מייל בעצמו — הוא קורא לפונקציה הפנימית wp_mail(), וזו מעבירה את המשימה לשרת האחסון. שרת אחסון משותף בדרך כלל שולח מיילים מכתובת IP שמשמשת עוד אלפי אתרים אחרים, בלי שום קשר אמיתי לדומיין שלכם. התוצאה: המייל "טוען" שהוא נשלח מ-info@your-domain.co.il אבל אין רשומת SPF שמאשרת שה-IP הזה מורשה לשלוח בשם הדומיין, ואין חתימת DKIM שמוכיחה שהתוכן לא שונה בדרך. אותו דבר קורה בפלטפורמות כמו Grow, שבהן מיילים טרנזקציוניים לרוב יוצאים מתשתית הפלטפורמה עצמה בלי התאמה אישית לדומיין הלקוח, אלא אם מגדירים זאת ידנית. גם Shopify דורש אימות דומיין נפרד (רשומות SPF/DKIM ייעודיות בפאנל) לפני שהוא מאפשר לשלוח בשם הדומיין שלכם ולא מכתובת ברירת המחדל של Shopify.

איך לאבחן את הבעיה בפועל

לפני שמשנים כל הגדרה, כדאי לאתר בדיוק איפה זה נשבר. שתי דרכים מהירות:

• בדקו את כותרות המייל (Show Original / הצג מקור) בתיבה שקיבלה אותו — חפשו את השורות spf=fail או spf=none, ו-dkim=none. אם שתיהן שליליות, זה בדיוק מה שקורה.
• שלחו את הטופס בעצמכם אל בדיקת מיקום תיבת דואר חינמית — תקבלו בבירור לאיזו תיקייה המייל נוחת אצל 20+ ספקים שונים, כולל תוצאות SPF/DKIM/DMARC מפורטות וללא צורך בהרשמה.

הפתרון: להוציא את השליחה מהשרת המשותף ולעבור ל-SMTP מאומת

הפתרון היחיד שעובד לאורך זמן הוא להפסיק לשלוח מיילים דרך פונקציית ברירת המחדל של השרת, ולנתב אותם דרך שירות SMTP חיצוני שמאמת את הדומיין שלכם בפועל. בוורדפרס, זה אומר להתקין תוסף כמו WP Mail SMTP ולחבר אותו לספק שליחה — יכול להיות ESP בינלאומי (Mailchimp, Brevo, SendGrid) או ESP ישראלי מקומי כמו ActiveTrail, smoove או InforUMobile, שכולם מציעים פאנל שמנחה אתכם להוסיף רשומות SPF/DKIM לדומיין שלכם. באתרי Shopify — עברו לפאנל הדומיינים ובצעו את תהליך אימות הדומיין (Verify Domain), שמוסיף בעצמו את רשומות ה-DNS הנדרשות. בפלטפורמות כמו Grow או Cardcom, פנו לתמיכה ובקשו הגדרת שליחה מהדומיין שלכם עם SPF/DKIM ייעודיים במקום שליחה מדומיין ברירת המחדל של הפלטפורמה.

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

שלושת הרכיבים האלה עובדים יחד, ולא מספיק להגדיר רק אחד מהם:

רשומת SPF טיפוסית שכוללת ספק SMTP חיצוני נראית כך:

DKIM נוסף בנפרד לכל ספק שליחה — בפאנל של ה-ESP או של Shopify תראו מפתח ציבורי שצריך להכניס כרשומת TXT או CNAME תחת שם המארח שהם מציינים. DMARC, לבסוף, מוגדר ברמת הדומיין עצמו (רשומת _dmarc.your-domain.co.il) ולא ברמת ספק בודד, ולכן הוא צריך לכסות את כל השולחים שלכם — גם את הטופס באתר, וגם כל מייל טרנזקציוני או שיווקי אחר שיוצא מהדומיין.

למה כדאי להפריד את דומיין השליחה של הטופס מדיוור שיווקי

מייל מטופס יצירת קשר הוא טרנזקציוני מטבעו — מישהו ביקש אותו במפורש, ולכן חוק התקשורת (תיקון 40) והדרישה לסימון "פרסומת" בשורת הנושא לא חלים עליו. עם זאת, שווה לחשוב על תשתית השליחה בראייה רחבה: אם אותו דומיין משמש גם לדיוור שיווקי, תקלה במוניטין של קמפיין שיווקי (למשל שיעור תלונות גבוה) עלולה לפגוע גם באמינות של המיילים הטרנזקציוניים החשובים — כולל התשובות מהטופס. הפרדת תת-דומיין ייעודי לשליחה טרנזקציונית (למשל mail.your-domain.co.il מול news.your-domain.co.il) עם רשומות SPF/DKIM נפרדות מבודדת את הסיכון בין שני העולמות.

איך לוודא שהתיקון באמת עבד

אחרי שהגדרתם SMTP חיצוני ורשומות DNS, אל תסתפקו בזה שהמייל "הגיע הפעם" לתיבה שלכם — זה עדיין לא אומר שהוא יתנהג כך אצל כל שולח שממלא את הטופס. השלב האחרון הוא בדיקה שיטתית: שלחו את הטופס אל כתובות הבדיקה החינמיות ובדקו בבירור אם המייל נוחת ב-Inbox אצל Gmail, Outlook, Walla! ו-iCloud, מה תוצאות SPF/DKIM/DMARC בפועל, ואיך המייל נראה בתצוגה אמיתית של תיבת דואר — כולל בדיקת RTL, כי מיילים בעברית עם טקסט מעורב באנגלית ומספרים נוטים להישבר בוויזואל אם לא בודקים בפועל.