יכולת מסירת דוא״ל: מדריך לאימות, מוניטין ואבחון

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

זו הבעיה האמיתית של יכולת מסירת דוא״ל. לא רק שגיאות כתיב או שורות נושא, אלא גם תשתית. התוצאה תלויה בשכבות ששולחים רבים אינם בודקים. מאז הקשחת הדרישות בתחילת 2024, Google ו-Yahoo מחילות דרישות נוספות על קבוצות של שולחי דואר בהיקף גדול; Microsoft פועלת לפי דרישות ולוח זמנים משלה. רשומות DNS שגויות ומוניטין בעייתי עלולים להוביל לסינון או לדחייה, בהתאם למדיניות המקבל.

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

קבלת הודעה לעומת יכולת מסירה

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

כך אפשר להבחין בין שלושת המונחים:

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

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

מודל האבחון: אימות → מוניטין → תוכן → מיקום

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

1. אימות (בדיקת זהות): איזו זהות שולח המקבל יכול לאמת? SPF, DKIM ו-DMARC הם הבסיס הטכני. כישלונות עלולים להביא לסינון או לדחייה, בהתאם למדיניות ולתוצאות אימות תקינות אחרות.
2. מוניטין (היסטוריית שליחה): האם הדומיין וכתובת ה-IP מזוהים עם דואר רצוי או עם ספאם? Google ו-Microsoft משתמשות באותות פנימיים משלהן. שיעור תלונות של 0.3% הוא רמת אזהרה חשובה במסגרת כללים מסוימים, לא חסימה מיידית ואחידה.
3. תוכן והתנהגות (ההודעה ואופן השליחה): הקהל, הקצב והתוכן משפיעים. שליחת 10,000 הודעות מכתובת IP חדשה בשעה הראשונה עלולה להיות מסוכנת. בדקו קישורים שבורים ועיצוב בעייתי, אך אל תתייחסו למילה מסוימת או ליחס תמונות וטקסט כאל כלל ספאם אוניברסלי.
4. מיקום (התוצאה): התיבה הראשית, קידומי מכירות, ספאם או הסגר. המקבל קובע את התוצאה, וקידומי מכירות אינה תיקיית ספאם.

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

מפת תסמינים: פירוש שגיאות

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

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

שלב 1: הבסיס של SPF, DKIM ו-DMARC

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

להגדרה מלאה, עיינו בהסבר על אימות דוא״ל באמצעות SPF, DKIM ו-DMARC. דרישות TrekMail מופיעות בתיעוד רשומות DNS הנדרשות.

SPF (Sender Policy Framework)

SPF משתמש ברשומת DNS מסוג TXT כדי לאשר מערכות שליחה לדומיין המעטפת ב-MAIL FROM, או לזהות HELO במקרים המתאימים. זה אינו בהכרח דומיין From הגלוי. המקבל מעריך את כתובת ה-IP השולחת ומחליט כיצד לטפל בתוצאה לפי מדיניותו.

רשומת SPF מתחילה ב-v=spf1. רשומות רבות מסתיימות ב-~all (softfail) או ב--all (fail), אך זו אינה התצורה האפשרית היחידה. המנגנונים והמשנים שביניהם מגדירים את ההרשאות. בדקו ערכי ספק עדכניים לפני הפרסום.

שתי הבעיות הבאות נפוצות ועלולות להשפיע על יכולת המסירה:

• בעיית ההעברה: אם Bob ב-Gmail מעביר את ההודעה לחשבון Yahoo, ייתכן ש-Yahoo יראה את כתובת Gmail ולא את כתובת השרת שלכם. SPF עלול להיכשל. חתימת DKIM תקינה ומיושרת יכולה לאפשר ל-DMARC להצליח, אם התוכן החתום נשאר תקין לאחר ההעברה.
• מגבלת 10 רכיבי DNS: SPF מגביל מנגנונים ומשנים רלוונטיים המחייבים חיפוש DNS ל-10 במהלך ההערכה, כולל רכיבים מקוננים במסלול שנבדק בפועל. הכללת Gmail, Outlook, Mailchimp, Zendesk, מערכת CRM ושירות הודעות תפעוליות אינה מוכיחה חריגה. חריגה עשויה לגרום ל-PermError, וגם שגיאות אחרות עשויות להפיק אותה תוצאה. ראו מגבלת החיפושים ב-SPF ואת מדריך הגדרת רשומת SPF.

DKIM (DomainKeys Identified Mail)

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

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

בדקו אורך מפתח RSA: Google מציינת מינימום של 1024 סיביות וממליצה על 2048 סיביות. מפתחות ישנים של 512 סיביות אינם מספיקים לכך. בסבב החלפה פרסמו תחילה מפתח לבורר חדש, עברו לחתימה החדשה והשאירו את המפתח הציבורי הישן כל עוד הודעות שבדרך עשויות להזדקק לו. ראו הגדרת DKIM.

DMARC (מדיניות טיפול באימות)

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

רשומת DMARC מסוג TXT מתפרסמת ב-_dmarc.yourdomain.com. האפשרויות הן:

• p=none: אין בקשה להסגר או לדחייה בגלל כישלון DMARC. דיווח מוגדר בנפרד ועשוי להיות חלקי; המדיניות אינה מבטיחה מסירה.
• p=quarantine: בקשה להסגר או לטיפול בהודעות שנכשלו כספאם, בכפוף להחלטת המקבל. שקלו זאת לאחר מיפוי, ניטור ובדיקת מסלולי השליחה התקינים.
• p=reject: בקשה לדחות הודעות שנכשלו. הפעילו אותה בזהירות, עם ניטור ותוכנית חזרה לאחור; זה אינו יעד בלתי מותנה לכל סביבה.

מכשול נפוץ הוא יישור DMARC. אצל ESP כגון Mailchimp, דומיין Return-Path עשוי להיות mailchimp.com. SPF יכול לעבור עבורו בלי להיות מיושר עם From שלכם. DMARC נכשל במצב זה רק אם גם אין חתימת DKIM תקינה ומיושרת.

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

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

שלב 2: יכולת מסירה והשלכות המוניטין

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

רמת האזהרה של 0.3%

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

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

סיווג כשולח בהיקף גדול

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

מוניטין דומיין לעומת מוניטין IP

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

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

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

שלב 3: תחזוקת התשתית

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

רשומות PTR ו-DNS הפוך

בדקו רשומת DNS הפוך (PTR) מתאימה לכתובת השליחה. DNS הפוך מאומת קדימה (FCrDNS) דורש ששם המארח יחזור דרך A או AAAA לכתובת הרלוונטית. ב-VPS פרטי, ספק כתובת ה-IP בדרך כלל מנהל את PTR. זה מתואר לעיתים כתיקון של 10 דקות, אך אבחון והחלת שינוי עשויים להימשך יותר.

הצפנת TLS

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

ההבדלים בין Gmail, Outlook ו-Yahoo

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

Google (Gmail)

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

Google Postmaster Tools מציע מידע על תלונות וקטגוריות מוניטין (High / Medium / Low / Bad) עבור תעבורה נתמכת. זהו כלי מומלץ, לא דרישה מחייבת או רישום מלא של כל הודעה. הביאו בחשבון כיסוי, עיכובים וספי זמינות נתונים.

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

ראו הנחיות Google לשולחי דוא״ל לדרישות העדכניות ולתחולתן.

Microsoft (Outlook / Office 365)

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

Microsoft SNDS (Smart Network Data Services) מציג נתונים זמינים עבור כתובות IP שאליהן יש הרשאת גישה, ובהם אותות תלונות ותעבורה לא רצויה.

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

ראו את כללי חימום הדומיין של TrekMail להנחיות תפעול נוספות.

Yahoo / AOL

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

המקור הרשמי הוא Yahoo Sender Hub.

Yahoo מתארת את מכנה התלונות כהודעות שהגיעו לתיבת הדואר הנכנס, לא כלל ההודעות שנשלחו. דוגמה פשוטה: מתוך 1,000 הודעות, 900 מגיעות לספאם ו-100 לתיבה, ו-1 נמען מדווח על ספאם. היחס הוא 1% (1/100), ולא 0.1% (1/1000). זו המחשה להשפעת המכנה, לא הידרדרות בלתי נמנעת או תחזית מדויקת לעיבוד של Yahoo.

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

תגובה מהירה: בדיקה ראשונית בתוך 24 שעות

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

ראו גם את רשימת הבדיקה לשיפור מסירה ב-30 דקות. זהו מסלול הבדיקה הראשוני:

צעד 1: צמצום נזק נוסף

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

צעד 2: בדיקת רשימות חסימה

בדקו את כתובת השליחה ב-MXToolbox ואמתו רישום ישירות אצל Spamhaus. רישום ב-SBL (Spamhaus Block List) עשוי להשפיע על מסננים שמשתמשים בה, אך אינו עוצר אוטומטית את כל השליחה. בדקו כתובת, תחולת הרישום, סיבה ודרישות הסרה; בקשה לבדה אינה מבטיחה מחיקה.

צעד 3: תיקון DNS

השתמשו במאמת כגון Email Health Check של MXToolbox ובדקו בעצמכם:

• SPF PermError, עקב חריגה ממגבלת 10 רכיבי DNS רלוונטיים או שגיאות תצורה אחרות
• בורר DKIM חסר או שגוי
• רשומת DMARC חסרה, או p=none ללא אסטרטגיית ניטור ואכיפה מכוונת; המדיניות עצמה אינה שגיאה
• כשלי יישור DMARC בדוחות המצטברים הזמינים, תוך התחשבות בכיסוי דיווח חלקי

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

צעד 4: תחזוקת הרשימה

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

אסטרטגיה לטווח ארוך: מניעה

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

ארגון שיווק בתת-דומיין

אפשר להקצות לשיווק את @marketing.yourdomain.com או @newsletter.yourdomain.com. הדבר מקל על תצורה וניטור, אך אינו מבטיח שדואר המנכ״ל מהדומיין הראשי יישאר ללא כל השפעה על המוניטין.

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

חימום IP

לכתובת חדשה יש מעט היסטוריית שליחה רלוונטית. לוח של 20 הודעות ביום 1, אחריו 40 ביום 2 והכפלה מדי כמה ימים לאורך 4-6 שבועות הוא דוגמה בלבד. התאימו קצב לדואר רצוי, לתשובות ולמדיניות. תקלה ביום 3 אינה בהכרח הגבלת Microsoft, והלוח אינו מבטיח קבלה.

להקשר תפעולי ראו את כללי חימום הדומיין של TrekMail.

ניטור שבועי

בדקו בקביעות Google Postmaster Tools, שיעורי תלונות ונתוני מוניטין זמינים. מעבר מ-High ל-Medium מצדיק בירור, אך אינו תחזית ודאית לחסימה. המדריך לניטור יכולת מסירת דוא״ל מתאר שגרה של כ-10 דקות בשבוע; היקף ותקלות יכולים לדרוש יותר.

התפקיד של TrekMail בתשתית הדוא״ל

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

אפשרות A: תמחור לפי משתמש. ההשוואה מדגימה Google Workspace או Microsoft 365 במחיר $6-$30 למשתמש לחודש. בדקו תוכניות עדכניות ושירותים כלולים. עבור 50 לקוחות עם 10 משתמשים כל אחד העלות יכולה להיות משמעותית, אך שירותים נוספים עשויים לשנות את ההשוואה.

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

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

מחיר פלטפורמה קבוע ואחסון משותף

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

• Free: מתוארת עם עד 10 דומיינים, 10 משתמשים לדומיין ו-5GB אחסון משותף, ספק SMTP משלכם וללא דרישת כרטיס אשראי. בדקו תנאים נוכחיים.
• Starter ($3.50/mo או $42/year): מתוארת עם 50 דומיינים, 100 משתמשים לדומיין ו-15GB אחסון משותף, SMTP מנוהל וכלי העברת IMAP בצד השרת. אמתו זמינות וגבולות.
• Pro ($8/mo או $96/year): מתוארת עם 100 דומיינים, 300 משתמשים לדומיין ו-50GB אחסון משותף, מגבלות שליחה גבוהות יותר, העברה עם SRS, כלי העברה ותמיכה בעדיפות. התצורה והתנאים העדכניים קובעים.
• Agency: מתוארת עם 1,000+ דומיינים ו-200GB+ אחסון משותף לספקי שירותים מנוהלים עם תיקי לקוחות גדולים. בדקו את ההצעה המתאימה.

SMTP משלכם: בחירה מודעת של תשתית

TrekMail יכולה לטפל באחסון IMAP, בשטח האחסון ובניהול תיבות, ובמקביל לאפשר חיבור ספק SMTP נתמך משלכם לשליחה, כגון Amazon SES, SendGrid או Mailgun. בדקו את האינטגרציה, התצורה וחלוקת האחריות הנוכחיות.

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

להגדרה ראו את תיעוד חיבור SMTP משלכם.

אשף DNS מונחה

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

העברה בצד השרת

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

ניתוב catch-all והעברה עם SRS

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

בעת העברה, SRS (Sender Rewriting Scheme) משכתב את כתובת המעטפת ואת Return-Path לדומיין של שירות ההעברה, ויכול לאפשר SPF תקין עבורו. הוא אינו משחזר אוטומטית יישור SPF לדומיין From המקורי. לצורך DMARC ייתכן שתידרש חתימת DKIM תקינה ומיושרת שנשמרה; גם מדיניות מקומית של המקבל למסלולי העברה מהימנים יכולה להשפיע.

השורה התחתונה על יכולת מסירת דוא״ל

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

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

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

להעמקה בזהות השליחה ראו את המדריכים על מוניטין דומיין ועל מוניטין שולח. בדקו את ההצעה החינמית הנוכחית של TrekMail ואת תנאיה ב-trekmail.net.