מייל איפוס סיסמה לא מגיע? למה “נשלח בהצלחה” לא אומר שהמייל הגיע, ואיך בודקים

מאת גל לוי · 4.11.2026 · חזרה לבלוג

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

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

בקיצור, לפי מה שרואים:

מה “נשלח בהצלחה” באמת אומר

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

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

תחנה ראשונה: למה התראות מהאתר לא מגיעות לאף אחד

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

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

תחנה שנייה: למה המייל מגיע רק לצוות

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

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

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

תחנה שלישית: למה המייל מגיע לספאם או נדחה

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

מאז פברואר 2024, Gmail דורשת מכל מי ששולח לחשבונות Gmail להגדיר לפחות SPF או DKIM, וממי ששולח יותר מ-5,000 הודעות ביום, את שלושתן. מייל שלא עומד בזה עלול להגיע לספאם או להידחות, ומבחינת המערכת ששלחה אותו הוא עדיין “נשלח”.

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

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

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

מבחינה טכנית הכול עבד: המייל נשלח, הגיע, והקישור היה תקף. מבחינת המשתמש, הוא ביקש לשנות סיסמה ומצא את עצמו מחובר, בלי המסך שבו בוחרים סיסמה חדשה. ההמלצה של OWASP היא בדיוק ההפך: לא לחבר את המשתמש אוטומטית, אלא לתת לו לבחור סיסמה חדשה ולהתחבר איתה כרגיל. זה נמצא רק כשמישהו לחץ על הקישור מתוך התיבה, כי “המייל נשלח” לא אומר כלום על מה שקורה אחרי הלחיצה.

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

למה קישור “פג תוקף” עוד לפני שלחצו עליו

תקלה נפוצה אחרת היא הודעה כמו “הקישור אינו תקף” כבר בלחיצה הראשונה. יש לזה שלוש סיבות שחוזרות:

1. מערכת אבטחה לחצה ראשונה. חלק מספקי המייל, למשל בתיבות של ארגונים, פותחים את הקישורים שבמייל כדי לבדוק אותם לפני שהמשתמש לוחץ. קישור חד-פעמי מתבזבז על הבדיקה. Supabase מתעדת את זה כסיבה הנפוצה ביותר לקישורים שנראים פגי תוקף, ומציעה שתי דרכים: קוד חד-פעמי שמקלידים במקום קישור, או קישור שמוביל לדף עם כפתור אישור.
2. בקשה כפולה. משתמש שלא קיבל מייל מבקש שוב, ואז לוחץ על המייל הראשון. בוורדפרס, למשל, כל בקשה יוצרת מפתח חדש במקום הקודם, ולכן הקישור מהמייל הקודם כבר לא עובד.
3. זמן. קישור איפוס תקף לזמן מוגבל, וכך גם צריך. בוורדפרס ברירת המחדל היא יממה, ובכל מערכת אחרת יש הגדרה משלה.

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

איך בודקים שמיילים של מערכת באמת מגיעים

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

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

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

מה מתקנים כשמשהו נכשל

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

שירות שליחה אמיתי. שירות שנועד למיילים של מערכות ומתחבר לפלטפורמה דרך SMTP או API, כמו Resend או Postmark, וגם Amazon SES או Brevo. ב-Supabase זה נקרא SMTP מותאם, ובוורדפרס עושים את זה עם תוסף SMTP.

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

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

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

שאלות שחוזרות

לא קיבלתי מייל איפוס סיסמה. מה בודקים?

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

המייל מגיע לספאם. מה עושים?

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

למה המייל מגיע ל-Gmail ולא לכתובת של ארגון?

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

אפשר להמשיך עם שירות המייל המובנה של הפלטפורמה?

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

ובאתר וורדפרס או בחנות?

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

איך מתחילים?

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

השורה התחתונה

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

ספרו לי מה בניתם

אתר וורדפרס או חנות? ניהול אתר, כולל בדיקת טפסים וקליטת פניות