שליחה מנוהלת היא ברירת המחדל המתאימה, ו-SMTP מותאם אישית הוא החלופה. בשליחה מנוהלת, גורם אחר מתחזק את מוניטין ה-IP, עוקב אחר רשימות חסימה, מטפל בלולאות משוב ומגיב אם IP משותף נחסם בשלוש לפנות בוקר. עבור רוב השולחים זו בדרך כלל אפשרות טובה יותר מניהול עצמאי.
SMTP מותאם אישית מנתב את הדואר היוצא דרך חשבון Amazon SES, SendGrid, Mailgun או Postmark שלכם. הוא עדיף באמת בשלושה מצבים מסוימים, אך נבחר לעתים קרובות גם משתי סיבות שאינן עומדות במבחן.
כך תזהו את המצב שלכם, וכך פועל ניתוב SMTP לכל דומיין אם תבחרו בו.
מה באמת משנה SMTP מותאם אישית
רק הנתיב היוצא משתנה. דואר נכנס עדיין מגיע לשרתים שלנו דרך רשומות MX, עובר סינון ונכנס לאותה תיבה. השינוי הוא בתחנה האחרונה: במקום למסור את ההודעה לתשתית השליחה שלנו, אנו מתחברים לספק שלכם ומוסרים אותה אליו.
כל מה שמתרחש בהמשך עובר אליו: כתובות ה-IP, המוניטין, מגבלות הקצב, טיפול בהחזרות ורשימת הדיכוי. החלפתם מפעיל אחד באחר וקיבלתם את האחריות לקשר עם החדש.
בפועל, הנושאים הבאים עוברים לצד שלכם:
| נושא | שליחה מנוהלת | SMTP משלכם |
|---|---|---|
| מוניטין IP | אנו מתחזקים אותו | שייך לספק שלכם ומושפע מהשימוש שלכם |
| מגבלות קצב | מכסות יומיות ושעתיות לפי המסלול | מה שהספק מאפשר |
| טיפול בהחזרות ובתלונות | מטופל ומוצג בלוח הבקרה | המסוף וה-webhooks של הספק |
| הסרה מרשימות חסימה | אנו מטפלים בה | אתם מטפלים בה מול הספק |
| עלות להודעה | כלולה | מחויבת בידי הספק |
שלוש סיבות טובות ל-SMTP מותאם אישית
1. נפח מעבר לייעוד המסלול. מגבלות המסלולים מגיעות לכמה אלפי הודעות לתיבה ביום. אם אתם שולחים מאות אלפי הודעות תפעוליות בחודש, ספק שליחה ייעודי עשוי להיות זול ומתאים יותר. אין טעם להעביר עומס המוני דרך פלטפורמת תיבות דואר.
2. כבר יש לכם קשר עם הספק. אם היישום שולח קבלות ואיפוסי סיסמה דרך SES עם IP ייעודי שעבר חימום, ניתוב דואר העובדים דרך אותו מקום מאחד את המוניטין במקום לפצל אותו בין שני שולחים. יש פחות רכיבים ומסוף יחיד לבדיקת בעיות.
3. אתם במסלול Nano. Nano אינו כולל שליחה מנוהלת, ולכן SMTP מותאם אישית הוא נתיב השליחה המיועד ולא פתרון עוקף.
שתי סיבות שאינן עומדות במבחן
"אקבל עבירות טובה יותר." בדרך כלל לא, ולעתים ההפך בתחילת הדרך. מאגר משותף של ספק ותיק נושא מוניטין שנבנה בידי אלפי שולחים. תת-חשבון חדש ב-SES מתחיל ללא מוניטין. בלי נפח שמספיק לחימום ולתחזוקת IP ייעודי, אתם מחליפים מוניטין טוב שלא נדרשתם לבנות במוניטין ריק שעליכם לבנות.
"אני רוצה לעקוף את מגבלות השליחה." המגבלות קיימות משום שנפח גבוה מדומיין צעיר עשוי להיראות כמו חשבון שנפרץ. ניתוב מסביב למגבלה אינו משנה את האופן שבו Gmail מעריך דומיין שפתאום שולח עשרת אלפים הודעות. הספק יחיל תהליך הגברה משלו ועלול להשעות את החשבון אם תחרגו ממנו, תוצאה חמורה יותר מהגבלת קצב משום שהביטול ידני. ראו מגבלות שליחה וחימום דומיין.
SMTP מותאם לכל דומיין ופרופילים לשימוש חוזר
SMTP מותאם אישית מוגדר לכל דומיין, וזה שימושי יותר מכפי שנראה בתחילה.
כל דומיין מצביע לנתיב יוצא משלו. דומיין אחד יכול לעבור דרך SES, אחר להשתמש בשליחה מנוהלת ושלישי בספק שונה. כך סוכנות יכולה לתת ללקוח שמתעקש על תשתית משלו את מבוקשו בלי לשנות דבר ללקוחות האחרים.
פרטי הגישה נשמרים כ-פרופילים בחשבון במקום להיכתב בכל דומיין. הוסיפו SES פעם אחת וקשרו את הפרופיל לכמה דומיינים שתרצו. בעת החלפת פרטים, משנים אותם במקום אחד. הזנת אותם פרטים שש פעמים היא הדרך להשאיר חמישה מהם מיושנים.
להגדרה, פתחו את כרטיסיית SMTP של הדומיין, בחרו פרופיל שמור או צרו אחד עם שם מארח, יציאה, משתמש וסיסמה, ואז בצעו בדיקה לפני השמירה. הבדיקה פותחת הפעלת SMTP אמיתית ומבצעת אימות. אל תדלגו עליה: פרטים שלא נבדקו עלולים להיכשל כשנשלחת הודעה חשובה.
חלק ה-DNS שכמעט לא מוזכר
SMTP מותאם אישית משנה את השרתים ששולחים בשם הדומיין, וה-DNS חייב לציין זאת. אם תדלגו על כך, אימות ההודעות ייכשל.
SPF חייב לכלול את השולח החדש. הספק מפרסם מנגנון הכללה כמו include:amazonses.com, include:sendgrid.net או דומה. יש להוסיף אותו לרשומה הקיימת, ולא לפרסם רשומה שנייה. שתי רשומות SPF בדומיין אחד הן תצורה לא תקינה ושתיהן מפסיקות לעבוד.
עקבו אחר מכסת השאילתות. SPF מאפשר עשר שאילתות DNS. כל הכללה צורכת לפחות אחת, והכללות של ספקים מקוננות לעתים קרובות. הוספת שולח שלישי עלולה להעביר דומיין בשקט מעבר למגבלה ולהפוך את הרשומה לשגיאה קבועה. ראו מגבלת שאילתות SPF.
DKIM מגיע כעת מהספק. הספק חותם על הדואר במפתח משלו, ולכן רשומת DKIM שלו חייבת להתקיים לצד שלנו. רובם מספקים שתיים או שלוש רשומות CNAME לפרסום. דואר שיוצא דרכם וחתום רק על ידינו נכשל ב-DKIM.
יישור DMARC עדיין חייב לעבוד. DMARC דורש ש-SPF או DKIM יתיישר עם דומיין From הגלוי. תצורה שחותמת עם דומיין הספק עשויה לעבור DKIM ולהיכשל ביישור, ולכן להיכשל ב-DMARC. זו דרך נפוצה שבה מעבר ל-SMTP פרטי נשבר, והיא נסתרת עד להגעת הדוחות. ראו יישור DMARC.
לקוחות שולחן עבודה הם החלטה נפרדת
ניתוב SMTP מותאם חל על דואר שנכתב ב-webmail או נשלח דרך ה-API שלנו. לקוח שולחן עבודה מוסר ישירות לשרת SMTP שמוגדר בו.
יש שתי אפשרויות הגיוניות. הפנו את הלקוחות אלינו ותנו לנתיב הדומיין לפעול, כך יישאר מקום אחד לשינויים. או הפנו אותם ישירות לספק, פעולה שמסירה תחנה ומקצרת מעט את זמן התגובה.
אל תגדירו חלק מהלקוחות בדרך אחת ואחרים בדרך אחרת. שני נתיבים יוצאים יוצרים שתי קבוצות של תוצאות אימות ושני מקומות לחיפוש הודעה שנעלמה, ולא תזכרו איזה מחשב משתמש באיזה נתיב.
מה עובר לאחריותכם
טיפול בהחזרות. החזרות קבועות אצל הספק דורשות דיכוי אצל הספק. לוח הבקרה מציג את מה שהתשתית שלנו ראתה, אך אינו רואה את התור שלו.
לולאת המשוב של תלונות. תלונות ספאם מגיעות לבעלים של כתובת ה-IP השולחת. הגדירו את הספק להעביר או לשמור אותן וקראו אותן, משום ששיעור תלונות עולה הוא התרעה מוקדמת לפני ירידה בעבירות.
החלפת פרטי גישה. סיסמת SMTP שפגה נכשלת בשליחה הבאה. החליפו אותה בפרופיל, וכפתור הבדיקה יאשר אותה לפני שמישהו יבחין.
הכללים של הספק. SES מתחיל בארגז חול ששולח רק לכתובות מאומתות, והיציאה ממנו דורשת בקשת תמיכה המתארת את השימוש. הדבר עלול להפתיע צוות באמצע מעבר ביום שישי.
שאלות נפוצות
האם SMTP מותאם אישית משנה את קבלת הדואר?
לא. רק הנתיב היוצא משתנה. דואר נכנס עדיין מגיע דרך MX לשרתים שלנו ולאותה תיבה, עם אותו סינון.
האם דומיינים שונים יכולים להשתמש בספקי SMTP שונים?
כן. SMTP מותאם מוגדר לכל דומיין, ולכן אחד יכול לעבור דרך SES ואחר להשתמש בשליחה מנוהלת. פרטי הגישה נשמרים כפרופילים ברמת החשבון לשימוש חוזר.
האם SMTP מותאם אישית ישפר את העבירות?
לא בפני עצמו, ולעתים ההפך בתחילה. תת-חשבון חדש מתחיל בלי מוניטין. הוא יכול לעזור כשיש נפח לחימום ולתחזוקת IP ייעודי, או כשכבר יש קשר שליחה מבוסס שרוצים לאחד.
האם עדיין נחוצות רשומות SPF ו-DKIM?
יותר מבעבר. יש למזג את הכללת SPF של הספק ברשומה הקיימת ולפרסם את רשומות DKIM שלו. דואר שנשלח דרכו אך חתום רק על ידינו נכשל ב-DKIM, וחתימה שאינה מיושרת נכשלת ב-DMARC.
האם SMTP מותאם אישית מסיר את מגבלות השליחה?
מגבלות הספק חלות במקום שלנו. דרישות ההגברה שלו בדרך כלל מחמירות יותר, וחריגה עלולה להשעות את החשבון במקום להגביל את הקצב.
מה קורה אם הספק אינו זמין?
הדואר היוצא מדומיינים שמשתמשים בנתיב נכשל עד להתאוששות. שליחה מנוהלת אינה גיבוי, והדומיין משתמש בנתיב שהוגדר לו.
האם SMTP מותאם אישית נדרש במסלול Nano?
כן. Nano אינו כולל שליחה מנוהלת, ולכן SMTP מותאם אישית הוא הדרך לשלוח דואר יוצא במסלול זה.
האם אפשר להגדיר SMTP מותאם אישית דרך API?
כן. פרופילי SMTP מותאמים וניתוב לכל דומיין זמינים דרך REST API ובאמצעות MCP, כולל בדיקת החיבור.
