וורדפרס לא שולח מיילים? מדריך אבחון מ-SMTP ועד Gmail

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

הבעיה הזו מתסכלת כי היא שקטה. האתר עצמו יכול להיראות כאילו הכול עובד כרגיל, ואף אחד לא מקבל הודעת שגיאה. אתם פשוט מגלים בדיעבד שמייל חשוב לא הגיע.

במדריך הזה אני עובר על התהליך שאני עצמי משתמש בו כשמגיע אליי אתר עם התקלה הזו: קודם לוודא מה בדיוק קורה, אחר כך לאתר את הגורם האמיתי, ורק בסוף – לחבר שירות שליחה חיצוני ומאומת, כולל הגדרה מלאה מול Gmail או Google Workspace.

קודם כל – לוודא שזאת בעיית שליחה ולא בעיית קבלה

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

בדקו את תיקיית הספאם או קידומי מכירות אצל הנמען. בקשו ממישהו אחר לבצע את הפעולה (למשל למלא את הטופס) ולוודא שגם אצלו המייל לא מגיע. אם המייל כן מגיע אבל לתיקיית הספאם – זה כבר רמז חשוב: זו כבר לא תקלה שבה המייל כלל לא נשלח, אלא בעיית מסירה או סינון. אימות השולח הוא אחד הדברים הראשונים שכדאי לבדוק, וזה מוביל ישר לסעיף על SPF/DKIM/DMARC בהמשך.

רק אם וידאתם שהמייל באמת לא מגיע לאף אחד, ובשום תיקייה – ממשיכים לשלב הבא.

(אם, לעומת זאת, האתר כולו מתנהג מוזר בזמן האחרון – לא רק המיילים – שווה לבדוק גם אם האתר נפרץ, כי לפעמים אלה שני סימפטומים של אותה בעיה.)

שלב 1: להשיג לוג או הודעת שגיאה על ניסיון השליחה

הצעד הראשון שלי הוא תמיד לנסות לקבל לוג או הודעת שגיאה על ניסיון השליחה – לפני שמחליטים על פתרון, כדאי לדעת מה בדיוק קורה. הדרך הפשוטה ביותר לרוב בעלי אתרים היא להתקין תוסף SMTP קליל שמספק גם בדיקת שליחה וגם לוג. יש כמה תוספים טובים לזה – למשל Post SMTP או WP Mail SMTP – זה לא ש"חייבים" דווקא אחד מהם, אלה פשוט שני שמות נפוצים מתוך כמה אפשרויות סבירות.

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

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

וורדפרס לא שולח מיילים: איך מאבחנים איפה התקלה

לפני שנכנסים לגורמים הספציפיים, שווה לחשוב על התהליך כשרשרת של כמה חוליות נפרדות – וכל אחת מהן יכולה להיכשל בנפרד:

• האם המייל אמור היה להיווצר בכלל? (למשל: האם ההגדרה הרלוונטית בווקומרס או בטופס פעילה, ומכוונת לכתובת הנכונה)
• האם וורדפרס מסר אותו למנגנון השליחה?
• האם שירות השליחה קיבל וטיפל בו?
• האם הנמען קיבל אותו בפועל, או שהוא נדחה או סונן בדרך?

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

חסימה ברמת האחסון

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

בעיית אימות (SPF/DKIM/DMARC)

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

קונפליקט תוסף או הגדרה שגויה

לפעמים הבעיה פשוטה יותר: כתובת "שולח" שהוגדרה בטעות, שני תוספי מייל שמתנגשים אחד בשני, או הגדרת SMTP ישנה שנשארה מפרויקט קודם ומפריעה לתוסף החדש. שווה לבדוק אם יש יותר מתוסף אחד שמנסה לשלוט על שליחת המיילים באתר.

הפתרון: לחבר שירות שליחה חיצוני ומאומת

לפני שעוברים על האפשרויות: כשוורדפרס שולח מייל במנגנון המובנה שלו, הוא בעצם אומר לשרת "שלח את ההודעה הזו בשם הדומיין הזה" בלי שום הוכחה שהוא מורשה לכך – כמו מישהו שמתקשר ומציג את עצמו בשם חברה, בלי תעודה מזהה. שירות שליחה חיצוני (Gmail, שירות SMTP ייעודי, או שירות שמתחבר דרך API) מעביר את ההודעה דרך תשתית ייעודית, שבה אפשר להגדיר את אימות השולח בצורה מסודרת, לעקוב אחרי תקלות ולקבל מידע ברור יותר על ניסיון השליחה.

תוסף SMTP (כמו Post SMTP או WP Mail SMTP שהזכרתי למעלה) עושה בדיוק את זה: הוא לוקח את כל המיילים שהאתר מנסה לשלוח, ומעביר אותם דרך חיבור מאומת לשירות חיצוני – בין אם דרך SMTP קלאסי (באמצעות פרטי התחברות) ובין אם דרך חיבור API, שתוספי SMTP מובילים תומכים בו יותר ויותר.

השאלה הבאה היא לאן לחבר את זה – אין כאן "ספק אחד נכון", וכדאי לבחור לפי מה שכבר יש לכם:

• Gmail או Google Workspace – הכי נגיש אם כבר יש לכם חשבון גוגל עסקי או אישי. אני מסביר את שתי דרכי החיבור בהמשך.
• Brevo (לשעבר Sendinblue) – שירות שליחה ייעודי, עם מסלול חינמי בכפוף למגבלות השירות הנוכחיות. זה הפתרון שאני אישית נוטה להשתמש בו בהרבה פרויקטים, אבל זו העדפה אישית שלי, לא המלצה בלעדית – יש עוד ספקים דומים (כמו SendGrid, Mailgun ואחרים) שעושים עבודה דומה.
• ספק אחר לגמרי – אם כבר יש לכם שירות מייל עסקי (Microsoft 365, ספק אחסון עם SMTP משלו וכו') אפשר לרוב לחבר גם אותו, באותה שיטה כללית.

שווה תמיד לבדוק קודם אצל ספק האחסון או שירות שכבר יש לכם – לפעמים הפתרון הכי פשוט הוא זה שכבר משלמים עליו ולא נעשה בו שימוש.

איך מחברים Gmail או Google Workspace לוורדפרס

בין אם מדובר בחשבון Gmail רגיל ובין אם ב-Google Workspace (חשבון גוגל עסקי עם הדומיין שלכן), יש שתי דרכים עיקריות להתחבר.

האפשרות המועדפת – חיבור דרך OAuth ("התחברות עם Google"): אם תוסף ה-SMTP שבחרתם תומך בחיבור Gmail דרך OAuth (Post SMTP, לדוגמה, תומך בזה), אני מעדיף להשתמש בזה. במקום להזין סיסמה, מתחברים ישירות דרך חשבון הגוגל שלכם – בדומה ל"Sign in with Google" המוכר מאתרים אחרים – והתוסף מקבל הרשאה דרך Google במקום לשמור את הסיסמה באתר. ההרשאות המדויקות תלויות בתוסף ובשיטת החיבור.

אפשרות נוספת – חיבור ישיר עם App Password: בתוספים שמתחברים ישירות ל-smtp.gmail.com (ולא דרך OAuth), אפשר להשתמש ב-App Password – סיסמה ייעודית בת 16 תווים, נפרדת מהסיסמה הרגילה שלכם. גוגל ממליצה על OAuth כשהוא זמין, ומאפשרת App Password רק בחשבונות עם אימות דו-שלבי מופעל. App Password לא זמין בכל חשבון, במיוחד בחשבונות ארגוניים מסוימים או בחשבונות עם הגדרות אבטחה מחמירות.

אם אתם משתמשים ב-App Password, התהליך הוא:

1. הפעילו אימות דו-שלבי וצרו App Password בהגדרות האבטחה של חשבון הגוגל (האימות הדו-שלבי הוא תנאי הכרחי ליצירת App Password).
2. הזינו את פרטי החיבור בתוסף ה-SMTP באתר:
   • שרת (Host): smtp.gmail.com
   • פורט (Port): 587
   • הצפנה: TLS
   • שם משתמש: כתובת ה-Gmail המלאה שלכם
   • סיסמה: ה-App Password (לא הסיסמה הרגילה)
3. שלחו מייל בדיקה מהתוסף עצמו ווודאו שהוא מגיע, כולל לבדוק אם הוא נחת בתיקיית הדואר הרגילה ולא בספאם.

אם אתן מנהלות כמות גדולה של מיילים תפעוליים (למשל חנות ווקומרס פעילה עם הרבה הזמנות ביום), שווה לבדוק גם אפשרות של שירות שליחה ייעודי לכמות גדולה יותר, כי לחשבון Gmail רגיל יש מגבלה יומית על כמות המיילים הנשלחים.

חשוב גם להבחין בין שני סוגי מיילים: כל מה שהסברתי כאן מתאים למיילים תפעוליים – אישור הזמנה, איפוס סיסמה, פנייה מהטופס. אבל ניוזלטר תקופתי או תוכן שיווקי לרשימת תפוצה גדולה עדיף לא לדחוף דרך אותו חיבור תפעולי – לשליחה כזו כדאי כלי ייעודי לדיוור (Brevo עצמו יודע לשמש גם ככלי דיוור, וכך גם Mailchimp ודומיהם), שמספק ניהול רשימות, הסרות, לחיצות ומדדי מסירה.

תשומת לב מיוחדת לחנויות ווקומרס

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

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

רשת ביטחון: לא לסמוך רק על מייל למידע קריטי

אם מדובר במידע שממש לא יכול "להיעלם" – הזמנה נכנסת, ליד חם מטופס יצירת קשר – שווה לשקול ערוץ נוסף שלא תלוי במייל בכלל, כגיבוי. אוטומציה (למשל ב-Make, n8n או Zapier) יכולה לקבל את האירוע ישירות מהטופס או מהחנות, ולשלוח התראה גם בערוץ נפרד לגמרי – הודעת וואטסאפ, הודעה בסלאק, או רישום אוטומטי בגיליון גוגל. ככה גם אם המייל נכשל מסיבה כלשהי, הפרטים לא הולכים לאיבוד.

כתבתי בהרחבה על איך בוחרים כלי אוטומציה לעסק, אם זה מעניין אתכן.

מה זה בעצם SPF, DKIM ו-DMARC (ולמה זה משנה לכם)

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

חיבור לשירות מייל חיצוני הוא רק חלק מהפתרון: אם המיילים יוצאים מכתובת בדומיין שלכן, למשל orders@example.co.il, הדומיין עצמו צריך להיות מוגדר לפי הוראות ה-SPF וה-DKIM (ובמקרה הצורך גם DMARC) שספק השליחה מספק – אבל ההוספה בפועל של הרשומות ל-DNS נעשית בממשק הניהול של הדומיין שלכן, ולא קורית מאליה רק כי חיברתן שירות חיצוני. DMARC עצמו הוא מדיניות שאתן בעצם בוחרות (מה לעשות עם מייל שנכשל באימות), לא ערך קבוע שהספק פשוט מוסר לכן.

סיכום

אם וורדפרס לא שולח לכם מיילים, כדאי לעצור לרגע לפני שמתקינים עוד תוסף. תבדקו קודם אם המייל בכלל נשלח, תאתרו אם מדובר בחסימת אחסון, בעיית אימות או קונפליקט הגדרות, ורק אז תחברו שירות שליחה חיצוני ומאומת – Gmail, Google Workspace, Brevo או כל ספק אחר שמתאים לכם, כמו שהראיתי למעלה. ברוב המקרים זו תשתית הרבה יותר אמינה משליחה ישירה משרת האחסון, וגם קלה יותר לאבחון אם משהו משתבש בהמשך.

רוצים שמישהו ידאג לאתר בשבילכם, כולל בעיות כאלה? ספרו לי עליו ואחזור עם הצעה.