מסירת דואר ו-DNS

הודעות מגיעות לספאם: מדריך בדיקה טכני ל-2026

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

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

דיווחים עלולים להצטבר במהירות. רשומת SPF שגויה, חתימת DKIM שאינה מיושרת או שבוע עתיר תלונות עשויים להשפיע על שליחה עתידית. עדיף לעבוד לפי ראיות ולא לנחש.

מדוע הודעה לגיטימית למראה מגיעה לספאם?

לעיתים השרת המקבל אינו נותן די אמון בשולח. Gmail, Yahoo ו-Outlook שוקלים אימות, יישור, תקינות DNS, תלונות והתנהגות שליחה, וגם לתוכן ולקישורים יכולה להיות השפעה.

ב-2025 וב-2026 ספקים מצפים משולחים שעליהם חלות הדרישות להגדיר SPF,‏ DKIM,‏ DMARC,‏ TLS,‏ PTR והסרה נאותה. הנחיות Google מסבירות שאי עמידה עשויה לתרום להגבלות קצב או לחסימות.

בניהול חמישים דומיינים של לקוחות זהו נטל תפעולי. לפי ההיצע הנוכחי, TrekMail עשויה לרכז דומיינים מותאמים, תיבות IMAP,‏ catch-all, העברה, BYO SMTP או SMTP מנוהל ומסלול הגירת IMAP. יש לבדוק תנאים עדכניים: תוכניות בתשלום מתחילות כיום ב-$3.50 לחודש, Nano עשויה להיות חינמית ולתוכניות בתשלום עשויה להיות תקופת ניסיון של 14 ימים.

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

כותרות ההודעה מספקות בדרך כלל רמז טכני מהיר. פתחו הודעה שסוננה ובדקו Authentication-Results שנוסף על ידי צד קולט מהימן, לרבות SPF,‏ DKIM,‏ DMARC ויישור עם דומיין From הגלוי.

DMARC יכול לעבור באמצעות SPF שעבר ומיושר או באמצעות DKIM תקף שעבר ומיושר; תוצאה שאינה מיושרת אינה מספיקה. לכן יש לבדוק את הקשר בין RFC5322 From לבין דומיין ה-envelope או החתימה.

התחילו ברשימה הזאת:

  1. פתחו כותרות גולמיות ב-Gmail,‏ Outlook או Apple Mail.
  2. מצאו את Authentication-Results.
  3. בדקו spf=pass,‏ dkim=pass ו-dmarc=pass.
  4. ודאו ש-From מיושר עם SPF שעבר או עם DKIM תקף ומיושר שעבר.
  5. אם DMARC נכשל, תקנו תחילה את היישור והמשיכו לבחון אותות אחרים.

אפשר להיעזר גם בשאלות ותשובות של TrekMail לפתרון בעיות ספאם.

שלושה כשלים טכניים נפוצים

מקרים רבים קשורים לחריגה מחיפושי SPF, ל-DKIM או לשגיאות יישור DMARC.

1. מגבלת החיפושים של SPF. ‏RFC 7208 מגביל ל-10 את המנגנונים והמשנים שמבצעים שאילתות DNS במהלך ההערכה. ספקים ו-include מקוננים עלולים לחרוג מהמגבלה ולגרום לשגיאה.

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

שינוי ב-include מקונן של ספק עשוי לשנות את התוצאה.

2. DKIM עובר אך אינו מיושר. חתימה עם d=vendor.com כאשר From הגלוי הוא yourdomain.com אינה שגויה כשלעצמה, אך היא עלולה לא להיות מיושרת בהתאם למצב organizational או strict. שיטה תקפה ומיושרת אחרת עדיין יכולה להעביר DMARC.

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

; baseline records
@      IN TXT "v=spf1 include:spf.trekmail.net -all"
dkim._domainkey IN TXT "v=DKIM1; k=rsa; p=YOUR_PUBLIC_KEY"
_dmarc IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com"

זו דוגמה ולא תבנית התחלה אוניברסלית. תיעוד DNS של TrekMail עשוי לסייע בניהול אירוח דוא"ל למספר דומיינים.

תקינות DNS והרשת

מקבלים עשויים לבחון PTR,‏ forward-confirmed reverse DNS ותשתית שליחה. רשומות MX ישנות משפיעות בראש ובראשונה על ניתוב נכנס, ואינן הסבר אוניברסלי לסיווג דואר יוצא כספאם.

הנחיות Google החלות דורשות PTR ו-DNS קדמי תואם ל-IP השולח בפועל.

אפשר לבדוק, למשל:

dig +short TXT example.com
dig +short TXT _dmarc.example.com
dig +short MX example.com
dig +short PTR 203.0.113.10
host mail.example.com

התוצאות הן רמזים ולא אבחנה בפני עצמה:

כשלמה רואיםהשפעהטיפול
יותר מדי חיפושי SPFכשלי SPF לסירוגיןאין מעבר SPF תקףצמצמו include; אם משתמשים ב-flattening, עדכנו ואמתו אותו ברציפות
רשומות MX ישנותניתוב מעורב והחזרותדואר נכנס עלול להיות מנותב לא נכוןהסירו רשומות מיושנות לאחר אימות
אין PTR/rDNSחסימה או סינוןחסר אות מצופה ל-IP השולחהגדירו PTR אם ה-IP בשליטתכם, או בקשו מהספק, ואמתו DNS קדמי
DKIM בדומיין הספקDKIM pass, DMARC failייתכן שחסר יישורהגדירו חתימה בדומיין שלכם אם היא נתמכת

לפי היכולות הנוכחיות, הגירת IMAP של TrekMail יכולה למשוך דואר מ-Gmail,‏ Microsoft 365 וספקי IMAP כלליים, אך אינה מעבירה אוטומטית DNS, יישומים או נתיבי שליחה ואינה מבטיחה מעבר ללא הפרעה. התחילו ברשומות DNS נדרשות.

מדוע המוניטין ממשיך להשפיע לאחר תיקון DNS?

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

שליחה מיידית של 20,000 הודעות לאחר תיקון יכולה להקשות על ההערכה. תוצאה יחידה אינה מוכיחה אם השינוי פעל.

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

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

לאחר התיקון הטכני:

  1. הפחיתו נפח זמנית ושלחו לנמענים עדכניים ופעילים שנתנו הסכמה.
  2. הפסיקו להשתמש ברשימות קנויות והשהו פלחים קרים או לא ודאיים.
  3. עקבו אחר האותות החלקיים ב-Google Postmaster Tools.

בדואר שיווקי שעליו חלות הדרישות, קישור mailto: לבדו אינו מספק הסרה בלחיצה אחת. RFC 8058 מגדיר כותרות ותהליך POST.

List-Unsubscribe: <https://example.com/unsub/abc123>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

השתמשו ב-List-Unsubscribe=One-Click וכללו את הכותרות הרלוונטיות בחתימת DKIM.

כאשר דואר עסקאות מגיע לספאם

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

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

ב-TrekMail, ריכוז הניהול הוא בחירה תפעולית.

הגישה הישנה: מוצר לכל משתמש בתוספת העברה, ספק שליחה ו-DNS נפרד לכל דומיין.

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

עיינו בSMTP המנוהל של TrekMail, במדריך יצירת דוא"ל עם דומיין ובתיעוד העדכני שמציין תמיכה ב-IMAP ולא ב-POP3.

תהליך בדיקה מהיר למפעיל

הסדר כותרות, DNS, מוניטין ולבסוף תוכן הוא מיון מועיל, לא ודאות לגבי הסיבה.

פעלו כך:

  1. בדקו כותרות גולמיות של הודעה מסוננת אחת.
  2. אמתו SPF,‏ DKIM,‏ DMARC ויישור.
  3. בדקו SPF,‏ MX,‏ DMARC,‏ DKIM ו-PTR.
  4. עיינו באותות Postmaster.
  5. הפרידו תעבורה עסקית ושיווקית כשנדרש.
  6. הוסיפו כותרות הסרה בלחיצה אחת לדואר שיווקי שעליו הכלל חל.
  7. הפחיתו נפח בזמן בחינת התלונות.

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

לפי הדף הנוכחי, Nano עשויה להתחיל ב-$0 לעד 10 דומיינים עם BYO SMTP,‏ Starter מתחילה ב-$3.50 לחודש, Pro ב-$10 לחודש ו-Agency ב-$23.25 לחודש; בחיוב שנתי מצוינת הנחה של 20%. תנאי Enterprise מותאמים. בדקו בhttps://trekmail.net/pricing.

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

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

קראו כותרות, תקנו רשומות, אמתו PTR של ה-IP השולח, הפרידו זרמים כשצריך והשתמשו ב-RFC 8058 בהיקף החל. TrekMail עשויה לרכז ניהול דומיינים ותיבות ואפשרויות SMTP בלי להבטיח הגעה לתיבה.

עיינו בשאלות Google על דרישות שולחים ובRFC 8058.

שתפו מאמר זה

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

התחברות ל-TrekMail

גישה ללוח הבקרה, לתיבות הדואר ול-DNS שלכם.

או

12 תווים הסיסמאות תואמות

או

דוא״ל האיפוס נשלח

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

בהמשך אתם מסכימים ל תנאי השימוש ול מדיניות הפרטיות של TrekMail.