שיפור הגעת דואר: רשימת בדיקה ראשונית של 30 דקות

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

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

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

רשימת הבדיקה של 30 דקות למסירת דואר

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

1. בדקו אם כתובת ה-IP השולחת מופיעה ב-Spamhaus או ברשימת חסימה רלוונטית אחרת.
2. ודאו שההודעות אכן יוצאות מהשרת או מספק SMTP.
3. בדקו תחביר SPF ואת מגבלת 10 הרכיבים שגורמים לחיפוש DNS.
4. בדקו בורר DKIM, אורך מפתח ודומיין חתימה.
5. בדקו התאמת DMARC, לא רק קיום רשומה.
6. אמתו את הקישור בין DNS קדימה והפוך ובדקו תלונות ספאם.

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

שלב 1: בדיקת רשימות חסימה מרכזיות מסוג Tier 1

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

דוגמה: תיבה אחת שנפרצה שולחת נוזקה במשך 20 דקות וה-IP נרשם ברשימה. נמענים המיישמים אותה עשויים לדחות גם חשבוניות ותשובות תמיכה רגילות.

שלב 2: אימות שהדואר יוצא מהמערכת

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

• Queued: למשל עומס פנימי, מכסה, חריגה מזמן המתנה או דחייה זמנית של הנמען.
• Bounced: כשל סופי; בדקו את התשובה המלאה ואת המערכת שהפיקה אותה.
• Sent אך ההודעה חסרה: הבינו מה הסטטוס מאשר ואז בדקו העברה נוספת וסינון.

בדיקת DNS ואימות לפי סדר

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

1. בדיקת מגבלת החיפושים ב-SPF

שתי דוגמאות לתקלות SPF הן רשומות מרובות ויותר מדי רכיבים גורמי חיפוש בהערכה רקורסיבית. מגבלת 10 חלה על רכיבים כגון a, mx, include, exists, ptr ו-redirect, כולל הערכתם הרקורסיבית. זו אינה ספירה של כל חבילות DNS או רק של include. חריגה עלולה לגרום לשגיאת הערכה קבועה. גם dig עשוי להשתמש במטמון של שרת הפענוח, ולכן תוצאה אחת אינה מוכיחה מה רואים כל הנמענים.

dig txt example.com +short

בדקו:

• רשומת SPF מסוג TXT אחת לזהות SMTP שבשימוש, שמתחילה ב-v=spf1; כמה מקטעי טקסט במירכאות בתוך אותה רשומה מחוברים יחד ואינם רשומות SPF נפרדות.
• אין הרשאה גורפת באמצעות +all.
• סיום שנבחר במכוון, כגון ~all או -all, לפי מסלולי השליחה שנבדקו.
• שרשרת include מובנת שההערכה המלאה שלה נשארת בגבול המותר.

דוגמה שדורשת בדיקה:

example.com. IN TXT "v=spf1 include:_spf.google.com include:servers.mcsv.net include:sendgrid.net include:spf.trekmail.net ~all"

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

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

2. אימות בורר DKIM וחוזק המפתח

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

dig txt selector._domainkey.example.com +short

נקודות לבדיקה:

• הרשומה של הבורר שבשימוש קיימת ושמישה.
• אם מופיע v=DKIM1, הגרסה תקינה; השדה עשוי להיות אופציונלי.
• p= מכיל מפתח ציבורי תקף שלא בוטל; המראה לבדו אינו מוכיח זאת.
• החותם משתמש בבורר המופיע בכותרות ואימות החתימה של ההודעה עצמה מצליח.

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

3. בדיקת התאמת DMARC ולא רק הרשומה

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

dig txt _dmarc.example.com +short

רשומת ניטור להמחשה:

_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

ה-ESP עשוי להשתמש ב-Return-Path: bounce.provider.com כקיצור לדומיין שבכתובת מעטפת SMTP בפועל, ולא ככותרת Return-Path מלאה ותקינה, ולחתום ב-d=provider.com, בעוד From הוא team@example.com. SPF ו-DKIM יכולים להצליח בנפרד, אך DMARC עלול להיכשל אם אף אחד מהם אינו מתואם עם From.

אבחון ההתאמה עשוי להימשך שעות. בדקו את מסלול השליחה וההרשאות בפועל ב-TrekMail: Managed SMTP בתוכניות בתשלום שתומכות בו, או שירות משלכם באמצעות BYO SMTP. הפרדת קבלה ושליחה יכולה להקל על החלפת מסלול, אך אינה מעניקה מוניטין עצמאי אוטומטית.

4. אימות DNS הפוך המאושר קדימה

ב-FCrDNS, רשומת PTR של ה-IP השולח מצביעה לשם מארח, ורשומת A או AAAA שלו כוללת שוב את אותו IP. נמענים עשויים להתחשב בקישור הזה, אך הוא אינו מבטיח הגעה לדואר הנכנס.

dig -x 203.0.113.10 +short
dig A mail.example.com +short

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

מעקב מתמשך אחר שיעור תלונות

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

SPF, DKIM ו-DMARC תקינים אינם מונעים ממשתמשים לדווח על ספאם. בדקו Google Postmaster Tools למשל מדי שבוע כשהנתונים זמינים, וחקרו דיווחים בפועל, הסכמה לקבלה והתנהגות שליחה.

השתמשו בערכים במסגרת המדד הזה:

• מתחת ל-0.1%: בטווח המומלץ למדד, לא אישור כללי למצב המסירה.
• 0.1% - 0.3%: בדקו עלייה בתלונות ואת הקמפיינים הקשורים.
• ב-0.3% ומעלה: שקלו לעצור קמפיינים לא חיוניים ותקנו את הסיבה שנמצאה.

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

קריאת קוד הכשל לפני שינוי הגדרות

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

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

מה לא לשנות ללא אבחון

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

1. אל תחליפו IP כדי לעקוף רשימות חסימה; בדקו את הסיבה והליך השיקום המורשה.
2. אל תסירו כתובת בכשל הזמני הראשון. 4xx דורש הקשר מלא ומדיניות תור מוגבלת.
3. אל תוסיפו ספקי SPF ללא סוף; הסירו רק שירותים שאינם בשימוש בוודאות.
4. אל תאכפו p=reject לפני אימות ההתאמה בכל זרימות השליחה המורשות.
5. בדקו גם תת-דומיינים; מדיניות, תשתית ומוניטין יכולים להיות קשורים למותג הראשי.

מודל משולב לעומת הפרדת קבלה ושליחה

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

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

מודל מופרד: בדקו את שירותי TrekMail העדכניים לאחסון, מקום משותף, מעבר IMAP וניהול דומיינים. במודל Free/Nano המתואר נדרש SMTP חיצוני משלכם לכל הודעה יוצאת ותשובה. דוגמאות התוכניות ההיסטוריות בתשלום מתחילות ב-$3.50 לחודש עם Managed SMTP; בדקו מחירים, הרשאות והגדרות לקוח תואמות כיום. בדקו זמינות ניסיון של 14 ימים ותנאי כרטיס. Nano עשוי להיות כיום אפשרות לקבלת דואר, אך זמינות חינם או פטור מכרטיס אינם הבטחה קבועה.

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

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

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

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

כשבוחנים מודל שיעזור לשפר מסירת דואר, השוו את אחסון TrekMail למספר דומיינים, האחסון המשותף, מעבר IMAP הנתמך ובחירה ב-BYO SMTP או Managed SMTP לצרכים ולהרשאות שלכם. בדקו מגבלות תיבות ועלות כוללת ב-מחירי TrekMail.

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