ניטור הגעת דואר: שגרת בדיקה שבועית של 15 דקות

שרת SMTP השיב 250 OK. האם ההודעה נמסרה?

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

ללא ניטור עלולים להחמיץ סימנים חשובים. Gmail אינו מזהה עבורכם כל משתמש שדיווח על ספאם; להגבלות Microsoft עשוי להידרש עיון בתשובות SMTP מלאות ובלוגים. דוגמאות מחיר היסטוריות לפלטפורמות כגון Return Path או Validity מציינות $2,000-$5,000 לחודש, לא מחיר עדכני מובטח. Google ו-Yahoo החמירו דרישות שולחים מפברואר 2024. קמפיין לא רצוי עשוי להשפיע על מוניטין השליחה גם בתרחיש של 24 שעות, אך התוצאות משתנות. בנו תהליך חוזר בעזרת כלים זמינים.

מהו ניטור מסירת דואר?

ניטור מסירת דואר עוקב אחר תוצאות אימות, תלונות ספאם, תשובות SMTP ורשימות חסימה כדי לחקור בעיות לפני שהן גדלות. כלי יחיד אינו רואה כל כשל שקט או החלטת נמען. Google Postmaster Tools, MXToolbox ושאילתות DNS עשויים לספק נתונים חינמיים או אחרים במסגרת התנאים והכיסוי שלהם.

1. אימות: הבסיס הטכני

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

A. SPF: מגבלת 10 רכיבים גורמי חיפוש

SPF בודק את זהות SMTP בפועל, לרוב MAIL FROM. RFC 7208 מגביל ל-10 רכיבים שגורמים לחיפוש DNS בהערכה רקורסיבית. אלה כוללים include, a, mx, ptr, exists ו-redirect. ip4, ip6 ו-all אינם נכללים במגבלת הרכיבים הזאת. זו אינה ספירת כל חבילות DNS.

שילוב הרשאות Google Workspace, Mailchimp, HubSpot ו-CRM עשוי לחרוג מ-10 בהתאם לתלויות המקוננות. הערכה שהייתה תקינה לפני שישה חודשים יכולה להשתנות. PermError מציין שגיאת הערכת SPF, לא דחייה עולמית מובטחת. בדקו מסלולים מורשים והסירו רק שירותים שאינם בשימוש בפועל. ראו את המדריך לרשומות SPF לדואר.

B. DKIM: אורך מפתח ושינוי בורר

Google דורשת מפתח DKIM של לפחות 1024 סיביות וממליצה על 2048 במסגרת דרישות Gmail הרלוונטיות. מפתחות ישנים של 512 סיביות אינם בטוחים ועשויים להידחות. במעבר ספק בדקו בורר, מפתח ציבורי ואימות קריפטוגרפי אמיתי של החלקים החתומים. מפתח DNS קיים לבדו אינו מוכיח חתימה תקפה.

C. DMARC: ההתאמה היא הדרישה המעשית

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

דוגמה: Mailchimp שולח עם דומיין Return-Path של bounce.mailchimp.com, בעוד From הוא team@yourcompany.com. SPF של המעטפה עשוי להצליח, אך התאמת SPF נכשלת בין הדומיינים. DKIM תקף ומתואם יכול להספיק ל-DMARC. אם גם הוא חסר, הנמען עשוי לדחות או לסנן בהתאם למדיניותו.

אפשר להתחיל ניטור עם p=none. תקופה ראשונית של 30 ימים היא דוגמה לתכנון בדיקה, לא תקופת בטיחות קבועה. גם בהמשך, p=none אינו מוכיח לבדו חשיפה מלאה לזיוף. בדקו דוחות וכל מסלול לגיטימי לפני מעבר מבוקר ל-p=quarantine.

בדיקות DNS חינמיות מהמסוף

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

# Check SPF record
dig txt yourdomain.com +short

# Check DMARC policy
dig txt _dmarc.yourdomain.com +short

# Check DKIM (replace "google" with your actual selector)
dig txt google._domainkey.yourdomain.com +short

ב-Windows:

nslookup -type=txt yourdomain.com
nslookup -type=txt _dmarc.yourdomain.com

חקרו יותר מ-10 רכיבי SPF גורמי חיפוש רקורסיבי, מדיניות p=none שנותרה אחרי בדיקה מתוכננת של 30 ימים, או רשומת DKIM שמחזירה NXDOMAIN. בדיקת רשומות אינה מחליפה אימות הודעות ומסלולים מורשים.

2. שיעור תלונות ספאם: גבול 0.3%

הימנעו מהגעה ל-0.3% במדד הדומיין הרלוונטי של Google ל-Gmail אישי. חישוב של 3 תלונות לכל 1,000 הודעות מדגים יחס, אך המכנה האמיתי ב-Gmail אינו כל הדואר ששלחתם. ל-Yahoo הגדרות ודרישות נפרדות. שאפו לפחות מ-0.1% במדד Google; חריגה אינה הוכחה לנזק בלתי הפיך.

סיווג מתמשך לפי מדיניות שולחים בכמות גדולה כיום

לפי מדיניות Google הנוכחית, כ-5,000 הודעות לחשבונות Gmail אישיים במשך 24 שעות עשויות להביא לסיווג שולח בכמות גדולה. הפחתת נפח בהמשך אינה מבטלת את הסיווג במסגרת המדיניות. בדקו דרישות עדכניות ורלוונטיות כגון ביטול הרשמה בלחיצה אחת ו-DMARC.

מגבלות נראות וסימנים משלימים

Gmail אינו מזהה כל מתלונן בדוח אישי. Google Postmaster Tools מציג נתונים מצטברים לדומיינים זכאים. אמתו שליטה בדומיין בדרך הנדרשת, כגון DNS TXT, ובדקו למשל מדי שבוע. זה אינו רישום מלא של כל הודעה.

בנפח לדוגמה של פחות מ-~100 הודעות Gmail ביום, עשוי להופיע "No Data", אך זה אינו סף פרסום קבוע. פרטיות ונפח נמוך יכולים להגביל נתונים. בדיקות חשבונות ניסיון ומגמות פתיחה הן סימנים עקיפים; תכונות פרטיות וסורקים אוטומטיים יכולים להטות אותן, ולכן אינן הוכחת מסירה.

3. חקירת החזרות: קריאת תשובות SMTP

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

קודים חשובים בלוגים

550 5.1.1: משתמש לא מוכר. בדקו תשובה מלאה וכתובת. יותר מ-2% יכול לשמש סף בדיקה פנימי, לא קביעה כללית של ספקי אינטרנט שרכשתם רשימה. בדקו מקור והסכמה, והעריכו פרטיות ואיכות של שירותים כגון ZeroBounce או Bouncer לפני שימוש.

550 5.7.1 / 550 5.7.515 (Microsoft). הראשון תלוי במדיניות כללית. השני עשוי לעסוק בדרישות Outlook.com לשולחים בנפח גדול: הצלחת SPF וגם DKIM, לצד DMARC עם לפחות שיטה מתואמת אחת. קוד לבדו אינו מוכיח רישום ברשימת חסימה.

421 RP-001 / 451 4.7.500 (Microsoft). אלה עשויים להצביע על הגבלת קצב או דחייה זמנית, לא בהכרח IP חדש. השתמשו בתור מוגבל ובדקו סיבה, הסכמה ונפח. ב-TrekMail BYO עם IP ייעודי שהוקצה בפועל, למשל מ-Amazon SES, אפשר להשתמש ב-4-6 שבועות כדוגמת תכנון להגדלה מבוקרת, לא תקופה מחייבת או ערובה לשיקום.

4. רשימות חסימה: Tier 1 והקשר אמיתי

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

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

5. רשימת בדיקה שבועית של 15 דקות

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

1. Google Postmaster Tools. האם המדד הזמין מתחת ל-0.1% וכיצד משתנה מוניטין הדומיין? מעל 0.1% בדקו קמפיין רלוונטי, ואל תחשיבו היעדר נתונים להצלחה.
2. רשימות חסימה. בדקו דומיין ו-IP וחקרו רישום Tier 1, במיוחד Spamhaus, לפי קטגוריה ודחיות נמען בפועל.
3. לוגי כשל. קראו תשובות SMTP מלאות, למשל מ-TrekMail, SES או SendGrid. 5.7.x אינו רק אימות או חסימה; גם תשובות 421 של Microsoft דורשות הקשר.
4. בדיקת חשבון ניסיון. שלחו בדיקה מורשית ל-Gmail אישי ול-Outlook אישי ובדקו היכן נחתה. Promotions אינו כשל; ספאם דורש חקירה. בדיקה אחת אינה מוכיחה את מיקום כל הדואר בפועל.

6. תוכנית תגובה לעלייה במדדים

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

תרחיש A: המדד מגיע ל-0.2%

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

תרחיש B: דחיית Microsoft בקוד 550 5.7.515

בדקו את דרישות Outlook.com הרלוונטיות לשולחים גדולים: SPF וגם DKIM מצליחים, ו-DMARC מצליח עם לפחות בדיקה מתואמת אחת ל-From. זו אינה הכללה ש-Microsoft תמיד מחמירה יותר. בדקו גם נפח אמיתי ותשובה מלאה, והעבירו IP וקודים מדויקים לתמיכה מורשית כשנדרשת הסלמה.

תרחיש C: רישום Spamhaus

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

TrekMail בשגרת הניטור

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

לעסקים קטנים: בדיקות מצב DNS

השתמשו במסכי DNS ובבדיקות רשומות תקופתיות הזמינות ב-TrekMail. בדקו SPF כשעוברים 10 רכיבי חיפוש, בורר DKIM אחרי מעבר, ואת התאמת DMARC באמצעות הודעות ודוחות. שגיאות מתמשכות מסוימות עשויות להפעיל התראות לפי הגדרות ותנאים, בלי להבטיח התרעה מוקדמת על כל שגיאה ראשונה או בעיית דואר נכנס.

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

→ בדקו את האפשרות החינמית הזמינה ב-TrekMail ואת תכונות מצב DNS הכלולות.

לסוכנויות: ניהול מרכזי ל-1,000+ דומיינים כדוגמה

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

ב-BYO SMTP, TrekMail מנהל תיבות ואחסון ומחברים שירות שליחה נתמך כגון Amazon SES, SendGrid או Mailgun. מודל Nano המתואר דורש SMTP חיצוני לכל הודעה יוצאת ותשובה, בעוד Managed SMTP בתשלום כפוף להרשאות ולהגדרות לקוח נפרדות. החלפת ספק עשויה לדרוש שינויי DNS או לקוח ובדיקות. היעדר מעבר תיבות אינו מבטיח אפס השבתה או מוניטין דומיין עצמאי.

→ ראו trekmail.net/pricing לתנאים עדכניים; $23.25 לחודש עבור 1,000+ דומיינים הוא דוגמת Agency היסטורית.

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

ארבעה מקורות שבועיים יכולים לתת בסיס שימושי: Postmaster Tools, בדיקות רשימות חסימה, לוגי SMTP ובדיקת חשבון ניסיון. ארבעת הסימנים יחד ממקדים חקירה, אך אינם מוכיחים תקינות מלאה של התשתית או מסירת כל הודעה.

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