שירותי בדיקת כתובות דוא״ל מפרסמים לפעמים דיוק של 97%, 98% או 99%. בלי הסבר על אופן החישוב, המספר לבדו לא אומר הרבה. הוא מאחד בדיקות שרמת האמינות שלהן שונה מאוד.
יש בדיקות שעונות על שאלה מוגדרת. אפשר לבדוק ב־DNS אם דומיין מפרסם רשומות MX, בכפוף לזמינות השירות ולעדכניות המטמון. השאלה אם קיימת בו תיבת דואר מסוימת היא עניין אחר. שאילתה חיצונית רגילה לא תמיד מאפשרת לאשר זאת בוודאות, במיוחד אצל ספקי הדוא״ל הגדולים.
כדי להשתמש בתוצאה נכון, צריך לדעת אילו בדיקות עומדות מאחורי הסיווג. נבחין בין עובדות שאפשר לבדוק, סימנים שמספקים רק רמז, ומקרים שבהם אין תשובה אמינה.
למה שיעור ההחזרות חשוב?
שירותי הדוא״ל המקבלים מתחשבים בתדירות השליחה לכתובות שאינן קיימות. ריבוי כשלי מסירה קבועים עשוי להעיד על ניהול לקוי של הרשימה ולהגדיל את הסיכון להגבלות או לסינון. גם תלונות, אימות השולח וגורמים נוספים משפיעים. החזרות לבדן אינן מוכיחות שהרשימה נקנתה.
המקור מציג שיעור כשלי מסירה קבועים מעל 2% כסימן שמצריך תשומת לב. זו אינה תקרה אחידה לכל השירותים וגם לא סף החזרות שקבעה Google. ההנחיות של Google לשולחי דוא״ל עוסקות באיכות השליחה, באימות ובתלונות. דיווחים על ספאם והחזרות הם מדדים שונים. ההשפעה עשויה להימשך אחרי הקמפיין ולפגוע בהודעות מאוחרות יותר, כגון חשבוניות, איפוס סיסמה ואישורי הזמנה. משך ההשפעה והיקפה תלויים בשירות.
בדיקת כתובות יכולה לצמצם את הסיכון הזה. היא לא משפרת את תוכן ההודעה ולא מחליפה את הסכמת הנמען. היא מאתרת חלק מהבעיות לפני השליחה, אבל לא מבטיחה מסירה. להרחבה, קראו מה אפשר ללמוד משיעור החזרות הדוא״ל?
שלוש רמות של ודאות בבדיקת כתובות דוא״ל
קל יותר להבין את ההבדלים כשמחלקים את הבדיקות לפי מידת הביטחון שאפשר לייחס לתוצאה.
רמה 1: בדיקות ישירות
כאן בודקים את מבנה הכתובת, את ה־DNS ואת ההופעה ברשימות מוכרות. התוצאות מתייחסות לכללים מסוימים ולנתונים הזמינים, ולא מוכיחות את כל המאפיינים של הכתובת.
| בדיקה | מה היא בודקת? |
|---|---|
| תחביר | עמידה בכללי מבנה הכתובת ששירות הבדיקה תומך בהם |
| Punycode / IDN | עמידה במגבלות השירות על שמות דומיין בינלאומיים, ולא שלילה של כל ניסיון התחזות באמצעות שם דומה |
| רשומות MX | פרסום נתיב לקבלת דואר ב־DNS, ולא אישור שהשרת או התיבה פועלים |
| כתובת IP ציבורית של MX | שה־MX אינו מפנה לטווח פרטי כמו 10.x או לכתובת לולאה מקומית כמו 127.x |
| דומיין של דוא״ל זמני | הופעה ברשימת שירותי דוא״ל זמניים מוכרים. המקור מציין יותר מ־5,000 דומיינים, אך הרשימה משתנה |
| הופעה ב־DNSBL | רישום ב־Spamhaus DBL או ב־SURBL. זה מידע על מוניטין, לא הוכחה שהתיבה אינה קיימת |
| חסימת שליחה בעקבות החזרה | הופעת הכתובת ברשימת חסימת השליחה של החשבון בעקבות כשל מסירה קבוע |
כישלון בשלב הזה עשוי להביא מיד לסיווג הכתובת כלא תקינה לפי כללי השירות. אין בכך קביעה גורפת לגבי אפשרות המסירה בכל סביבה. שירות הבדיקה הזה דורש רשומת MX מפורשת, בעוד SMTP מאפשר נתיב משתמע דרך רשומות הכתובת של הדומיין כשאין MX. מגבלות על דומיינים בינלאומיים עשויות גם לפסול כתובות קיימות. לפני החלטה חשובה, בדקו את הסיבה המסוימת.
רמה 2: בדיקות הסתברותיות
בדיקת SMTP מתחברת לשרת המקבל, מתחילה חילופי פקודות, שואלת אם הוא מקבל את הנמען ומסיימת את החיבור לפני שליחת הודעה. אם מתקבלת תשובת 550 שמציינת במפורש שהנמען לא נמצא, והיא ניתנה בתגובה לפקודת RCPT TO, זהו סימן משמעותי. עם זאת, אותו קוד יכול לציין גם סירוב גישה או דחייה לפי מדיניות השרת.
זהו סימן, לא הוכחה שאין לה חריגים. האמינות תלויה בשרת המקבל. נרחיב על כך בחלק הבא.
רמה 3: כללים היוריסטיים
אלה סימנים עקיפים לסיכון. הם משנים את הציון בהתאם לכללי השירות, אך לא מוכיחים שהכתובת בעייתית.
| סימן | השפעה על הציון |
|---|---|
| החלק שלפני @ נראה כמו רצף אקראי | −15 |
| אין רשומת SPF | −10 |
| אין רשומת DMARC | −10 |
| הדומיין נרשם לפני פחות מ־30 יום | −10 |
כתובת עם תג נוסף (user+tag@) | −5 |
| דומיין פרטי עם MX, SPF ו־DMARC | +5 |
כתובת של מחלקה או תפקיד (info@, support@) | 0, מציגים את המידע ללא הפחתה |
| שירות חינמי כמו Gmail או Yahoo | 0, ניטרלי |
חשד לשגיאת הקלדה (gmial.com) | 0, מציגים מידע והצעת תיקון |
שני סימנים כאן ראויים להסבר נוסף, משום שחלק מהשירותים מתייחסים אליהם אחרת.
לא מפחיתים נקודות בגלל כתובת מחלקתית.חברות מקבלות הודעות אמיתיות ב־info@ וב־sales@. בפנייה עסקית למי שלא מכירים, זו עשויה להיות עדות לכך שאינכם יודעים מי איש הקשר המתאים. אבל אין בכך חיסרון בכל שימוש. אנחנו מציגים את המידע כדי שתוכלו לסנן לפי הצורך, בלי להפחית נקודות.
שירותים חינמיים מקבלים יחס ניטרלי.כתובת Gmail אינה נחותה רק משום שאינה משתמשת בדומיין פרטי. אנשים רבים משתמשים בשירותים האלה.
בדיקה באמצעות SMTP והמגבלות שלה
זו הבדיקה שרבים חושבים עליה כשמדברים על בדיקת כתובות דוא״ל. אלא שלעיתים מצפים ממנה ליותר ממה שהיא יכולה לספק.
היא עשויה להועיל בדומיינים של חברות, למשל בשרת פרטי, באחסון דוא״ל או במערכת שמפעילים עצמאית. דחייה מפורשת של נמען לא מוכר בשלב RCPT TO מספקת מידע שימושי. אבל ייתכן שהדחייה מכוונת לחיבור הבדיקה עצמו ולא לתיבה.
אצל ספקי דוא״ל גדולים, השיטה אינה מאפשרת לאשר באופן אמין שתיבה קיימת. Gmail, Yahoo, Outlook.com, iCloud ו־AOL עשויים להגביל חיבורי בדיקה או לקבל נמען בלי אישור סופי, כדי למנוע גילוי כתובות מבחוץ. אין פירוש הדבר שכולם משיבים תמיד באותו אופן. כאן מדלגים על בדיקת SMTP חיצונית בדומיינים המתאימים. גם כשהבדיקות האחרות עוברות, קיום התיבה לא אושר.
לכן כתובות בדומיינים שברשימת החריגים מחויבות לפי תעריף הבדיקה המהירה, גם בבדיקה מעמיקה. הן צורכות קרדיט אחד במקום שניים, משום שמדלגים על בדיקת SMTP הנוספת. פירוט העלות מוצג לפני ההפעלה ונכלל גם בתשובת API. בדקו את האומדן העדכני לכתובות שתבדקו.
לסיכום, בדיקת SMTP עשויה לחזק את הביטחון בתוצאה אצל שרתי חברות שתומכים בשיטה. היא אינה הבטחה כללית לקיום כתובות Gmail ושירותים דומים. אם ספק מבטיח תשובה ודאית, שאלו באילו נתונים הוא משתמש ומה מגבלות השיטה.
למה קבלת דואר לכל כתובת מקשה על הבדיקה?
דומיין שמקבל דואר לכל כתובת, או Catch-all, מקבל כל שם נמען גם אם אין לו תיבה נפרדת. שאילתה על anything@catchall-domain.com עשויה לקבל תשובה חיובית. התשובה הזאת לבדה לא מאשרת שקיימת התיבה שאתם מחפשים.
תוצאת Catch-all מציינת אי־ודאות. ההודעה עשויה להגיע לאדם, לתיבה משותפת שאיש אינו בודק או למערכת קבלה אחרת. הסימן הזה לבדו גם לא מוכיח שקיימת מלכודת ספאם. שאילתה חיצונית לא מבדילה בין היעדים האלה. בדקו את סימון Catch-all לצד הסטטוס הסופי. לפי החישוב הנוכחי, הוא לא בהכרח גורר סיווג כמסוכן.
זהו מחיר שלא תמיד מביאים בחשבון כשמפעילים קבלת דואר לכל כתובת בדומיין פרטי: לשירותים חיצוניים קשה יותר לבדוק את הכתובות. על יתרונות ומגבלות נוספים קראו איך פועלת קבלת דואר לכל כתובת?
בדיקה מהירה לעומת בדיקה מעמיקה
| מהירה | מעמיקה | |
|---|---|---|
| מספר הבדיקות שמתואר במקור | 22 | 25 |
| בדיקת תיבה באמצעות SMTP | לא | כן, בדומיינים נתמכים שאינם ברשימת החריגים |
| כללים היוריסטיים לזיהוי מלכודות ספאם | לא | כן |
| קרדיטים לכתובת בדומיין של חברה | 1 | 2 |
| קרדיטים לכתובת בשירות שמוחרג מהבדיקה | 1 | 1 |
| הערכת זמן גסה לבדיקת 10,000 כתובות | 1-5 דקות | 5-15 דקות |
| שימוש עיקרי | תחזוקה שוטפת של רשימה מוכרת | רשימה חיצונית או רשימה שהועברה אליכם לאחר בדיקת הרשאת השליחה, ובייחוד משלוחים חשובים |
אם אספתם את הרשימה בעצמכם ואתם מנהלים אותה בקביעות, לרוב הבדיקה המהירה מספיקה. אם המקור לא ברור, בדקו קודם אם מותר לכם לפנות לנמענים ורק אחר כך החליטו אם דרושות בדיקות נוספות. מספר הבדיקות בפועל והזמן תלויים בכישלונות מוקדמים, בהגדרות, בתור ובתשובות השרתים. הטבלה אינה הבטחה שכל כתובת תעבור כל בדיקה.
איך מפרשים את הסטטוסים?
כל כתובת מקבלת סטטוס וציון ביטחון בין 0 ל־100. זהו סולם פנימי, לא הסתברות למסירה מוצלחת.
| סטטוס | ציון | מה לעשות? |
|---|---|---|
| בטוח | 90-100 | אפשר לשקול שליחה כשיש הסכמה מתאימה, אך אין הבטחת מסירה |
| תקין | 60-89 | בדקו את סיבות הסיווג ועקבו אחר החזרות |
| מסוכן | 20-59 | לא להשתמש לפנייה עסקית לאנשים שאינכם מכירים. גם בהודעות עסקה ללקוחות מוכרים, בדקו את הסיבה המסוימת |
| לא תקין | 0-19 | הוציאו מרשימת השליחה ובדקו את הסיבה |
| לא ידוע | לא מצוין בטבלה | אם מופיע סטטוס זה, בדקו שוב בהמשך. בדקו גם חריגות זמן ושגיאות זמניות בתוצאות המפורטות |
חשוב במיוחד להבחין בין מסוכן ל־לא תקין. כתובת לא תקינה עשויה להיכשל בכללי הבדיקה, להיות חסומה לשליחה או להידחות בשרת. אין פירוש הדבר תמיד שהתיבה אינה קיימת. גם סיכון דורש הקשר. בדיקה אינה נותנת רשות לשלוח לכתובת לא ודאית ברשימה שנקנתה. אצל לקוח שמשלם כבר שנתיים, אותה תוצאה יכולה לנבוע מ־Catch-all. ובכל זאת, לפני שליחת חשבונית בדקו את הפרטים, את היסטוריית המסירה ואת דרך יצירת הקשר.
הבדיקה לא מכירה את הקשר שלכם עם הנמען. צריך להביא את המידע הזה בחשבון בנפרד.
הרשימה מתיישנת עם הזמן: בדיקה היא תחזוקה מתמשכת
המקור מציג אומדן של כ־2% מהכתובות שמתיישנות מדי חודש. אנשים מחליפים עבודה, חברות נסגרות וכתובות יוצאות משימוש. הקצב בפועל משתנה. אחרי שמונה עשר חודשים, חלק משמעותי מהכתובות עשוי להיות מיושן, אבל הטענה שרבע מהן יהיה שגוי אינה תחזית כללית. הסתמכו על התוצאות ועל היסטוריית ההחזרות שלכם.
עדיף לשלב את הבדיקה בניהול הרשימה במקום להסתפק בניקוי חד־פעמי.
- בעת הזנת הכתובת.בדיקה בהרשמה מאפשרת לזהות שגיאות כמו
gmial.comכשהמשתמש עדיין יכול לתקן אותן. הציעו תיקון ואל תחליפו את הכתובת בלי להודיע. - לפני משלוח גדול.בייחוד לקבוצות שלא פניתם אליהן במשך חודשים.
- מדי רבעון ברשימות פעילות.זו נקודת פתיחה. התאימו את התדירות למצב בפועל.
- כשמקבלים רשימה.אחרי רכישה, מיזוג או העברת גיליון נתונים, בדקו את הכתובות ואת הרשאת השליחה.
איך משלבים בדיקה בניהול הרשימה?
בדקו בזמן האיסוף, לא חודשים אחר כך.אפשר לתקן שגיאת הרשמה יחד עם המשתמש. אחרי חצי שנה ייתכן שיהיה קשה ליצור קשר מחדש. בדיקות מבנה ומוניטין אינן מחליפות אישור של בעל הכתובת.
חסמו שליחה, אל תסתפקו במחיקה.שמרו את המידע הדרוש ברשימת חסימת השליחה כדי שהכתובת לא תקבל שוב הודעות אחרי ייבוא CSV נוסף. התחשבו גם בדרישות שמירת הנתונים ובאפשרות לתקן חסימה שגויה.
אל תקנו רשימות.הבדיקה מאתרת חלק מהבעיות הטכניות, ולא מוכיחה שהנמען הסכים לקבל הודעות. גם כתובת תקינה יכולה להוביל לתלונות או לבעיות עם הכללים החלים. רשימה שנקנתה ועברה את הבדיקות עדיין אינה מקנה הרשאת שליחה.
אחרי הפסקה ארוכה, הגדילו את היקף השליחה בהדרגה.ניקוי הרשימה לבדו לא מספיק. עקבו אחר תגובות הנמענים והשרתים, ולא רק אחר מספר הכתובות שנמחקו. קראו גם איך משפרים את יכולת המסירה של דוא״ל?
בדיקת כתובות לא מתקנת שיטות שליחה לקויות.היא מצמצמת חלק מהסיכונים הקשורים לכתובות, אך לא מגדירה SPF, DKIM או DMARC. שירותי הקבלה מתחשבים באימות, במוניטין ובגורמים נוספים. אין סדר בדיקות אחיד שהופך רשימה שנבדקה להבטחת מסירה.
שאלות נפוצות
אפשר לבדוק אם כתובת Gmail קיימת?
לא באופן אמין באמצעות שאילתת SMTP חיצונית רגילה. השירות עשוי להגביל חיבורים או להסתיר מידע על הנמען, והתשובות לא תמיד זהות. כאן מדלגים על בדיקת SMTP ב־Gmail. הצלחה בבדיקות מבנה, MX ומוניטין אינה מאשרת שהתיבה קיימת.
למה בדיקה מעמיקה זולה יותר ב־Gmail?
מפני שבדומיינים שברשימת החריגים מדלגים על בדיקת SMTP הנוספת. גם בבדיקה מעמיקה, הכתובות האלה מחויבות בתעריף המהיר. פירוט העלות מוצג לפני ההפעלה. בדקו את האומדן העדכני.
מה זה Catch-all? אפשר לשלוח לכתובות כאלה?
השרת מקבל כל שם נמען, ולכן תשובה חיובית לא מאשרת תיבה נפרדת. אצל לקוח מוכר, התחשבו בהיסטוריית המסירה ובמטרת ההודעה. אי־ודאות אינה הצדקה לפנייה עסקית לאנשים שאינכם מכירים.
כתובות כמו info@ הן בעייתיות?
לא. לא מפחיתים נקודות בגלל הסימן הזה. מציגים אותו כדי שתוכלו לסנן לפי השימוש. ההתאמה להודעות עסקה או ליצירת קשר תלויה בהקשר, ולא בשם התיבה בלבד.
הבדיקה יכולה לפגוע במוניטין השולח?
חיבור הבדיקה מסתיים לפני העברת הודעה, ולכן שום הודעה לא מגיעה לתיבת הדואר הנכנס. עם זאת, אי אפשר להבטיח שלא תהיה כל השפעה על מוניטין ה־IP. שאילתות רבות עלולות להיראות כניסיון לגלות כתובות ולהוביל לחסימה. הגבלות לכל שרת מקבל מצמצמות את הסיכון, אך אינן מבטלות אותו.
באיזו תדירות כדאי לבדוק שוב?
התחילו בבדיקה רבעונית לרשימות פעילות, לפני משלוח גדול ובכל פעם שמקבלים רשימה. הדוגמה של 2% בחודש אינה חוק כללי. התאימו את התדירות לגיל הרשימה, להיסטוריית המסירה ולשינויים בפועל בכתובות.
אפשר להפעיל את הבדיקה דרך API?
כן. אפשר לבדוק כתובת בודדת או לבצע בדיקה מרוכזת, ולקבל סטטוסים ותוצאות באופן תכנותי. הפעולות וההרשאות הזמינות מפורטות ב־מדריך העזר ל־API של הבדיקה.
מה ציון הביטחון באמת אומר?
החישוב מתחיל ב־100 ומשקף סימנים חיוביים, כמו הגדרות הדומיין, לצד גורמי סיכון. כישלון בבדיקה עשוי לאפס את הציון מיד לפי כללי השירות. זהו סיכום של כללים, לא מדידה עצמאית ולא הסתברות לכך שהתיבה קיימת. בהחלטות חשובות, בדקו את הפרטים ואת הבדיקות שדולגו.
