יצירת אימייל עם הדומיין שלך: מדריך הגדרה מלא

רכשתם את הדומיין. עכשיו אתם צריכים תיבת דואר.

יצירת דואר אלקטרוני בדומיין שלכם היא אחת מהחלטות התשתית החשובות ביותר שתקבלו כמפעילי עסק. זה ההבדל בין הופעה כ-someone@gmail.com לבין פעילות כ-name@yourcompany.com. הראשון נראה כמו פרויקט צדדי זמני. השני נראה כמו עסק אמיתי.

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

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

לפני שמתחילים: מה באמת צריך

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

1. הדומיין

דרושה הרשאה לנהל את הדומיין, למשל yourcompany.com. אם טרם רכשתם דומיין, השוו את התנאים העדכניים של רשמים כמו Namecheap, Cloudflare Registrar או Porkbun. הפרדת הרשם מאחסון האתר יכולה לצמצם תלות משותפת. בדקו גם מי מארח את ה-DNS ואילו הרשאות ואמצעי שחזור עומדים לרשותכם; הפרדה לבדה אינה מבטיחה זמינות.

2. גישה ל-DNS

דרושה לכם גישת כתיבה לאזור ה-DNS. בלוח הבקרה של הרשם האפשרות נקראת בדרך כלל "DNS Management", "Zone Editor" או "Advanced DNS". תערכו רשומות TXT, MX ו-CNAME. אם אין לכם גישה כזו, עצרו והשיגו אותה לפני כל פעולה אחרת.

3. ספק דואר אלקטרוני

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

• ברירת המחדל: Google Workspace או Microsoft 365. הטווח $72-$144 למשתמש בשנה הוא המחשה היסטורית, לא הצעת מחיר עדכנית. כתובות תפקידיות (info@, billing@) יכולות להיות כינויים, קבוצות או תיבות משותפות לפי השירות; לא כל כתובת מחייבת רישיון משתמש נפרד.
• הבחירה למפעילים: TrekMail. השוו תמחור ברמת החשבון ואחסון משותף לצרכים שלכם ובדקו מחירים, הרשאות ומגבלות עדכניים.

רשימת הבדיקה של 10 דקות

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

שלב 1: קודם יוצרים תיבות דואר (כן, קודם)

אי-הגדרת נמענים עלולה למנוע קבלת הודעות עסקיות אחרי המעבר.

אחרי החלפת ה-MX, שרתים שולחים משתמשים במסלול החדש כאשר נתוני ה-DNS שלהם מתעדכנים. אם contact@yourdomain.com אינו מוגדר, השרת עשוי לדחות את הנמען בתשובת 550 User Not Found. הודעת אי-מסירה תלויה במערכת השולחת, והנמען עשוי לא לדעת על הדחייה. בדקו יומנים ונמענים בפועל.

הגדירו כל תיבה דרושה לפני העברת ניתוב ה-MX. ייתכן שנדרש קודם שינוי DNS לצורך אימות הדומיין.

התהליך ב-TrekMail:

1. התחברו ללוח הבקרה של TrekMail.
2. עברו לכרטיסייה Mailboxes של הדומיין.
3. צרו את כל הכתובות שבהן אתם משתמשים כעת.

לעסקים קטנים ובינוניים: צרו לכל הפחות כתובת אישית (yourname@) וכתובת תפקידית (hello@ או info@).

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

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

שלב 2: הגדרת רשומות MX והמעבר

רשומות MX (Mail Exchange) מציינות את שרתי הדואר של הדומיין. ללא MX מפורש, SMTP יכול בתנאים המתאימים להסתמך על רשומות הכתובת של הדומיין, אבל אין לראות בכך תחליף לניתוב דואר מתוכנן.

כיצד להגדיר רשומות MX:

1. עברו לניהול אזור ה-DNS אצל הספק המוסמך, שעשוי להיות שונה מהרשם.
2. בדקו את רשומות ה-MX הקיימות. בררו עם המנהל המורשה את תפקיד רשומות "GoDaddy Secure Mail", "Google Workspace" או cPanel. הסירו רק מסלולים שאומתו כמבוטלים ושמרו על שער, ניתוב היברידי או גיבוי מכוונים.
3. השתמשו ברשומות העדכניות שבחשבון. הטבלה היא דוגמה היסטורית, לא הגדרה להעתקה ללא בדיקה; יעד ה-MX המוגדר כברירת מחדל כיום הוא mail.trekmail.net:

בנושא TTL: הפחתה ל-300 שניות לפני המעבר היא דוגמת תכנון, כלומר תוקף מטמון של 5 דקות. היא אינה גורמת לשרתים לבדוק עדכונים במחזוריות ואינה משנה מיד רשומה שנשמרה קודם בתוקף של, למשל, 24 שעות. אפשרו ל-TTL הקודם לפוג ובדקו את האזור המוסמך והמטמונים. אחרי אימות בחרו ערך מתאים, למשל 3600.

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

שלב 3: התחברות ראשונה ובדיקת שליחה וקבלה

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

התחברו תחילה לדואר בדפדפן ובדקו את זרימת ההודעות לפני הגדרת Outlook או iPhone. התחברות HTTPS אינה מוכיחה שחיבור IMAP או SMTP של לקוח נפרד פועל; בדקו כל חיבור בנפרד.

בדיקת שליחה: כתבו הודעה מהכתובת החדשה אל חשבון Gmail האישי שלכם.

• האם היא הגיעה?
• האם היא הגיעה לספאם? בדקו אימות, תוכן, מוניטין ומדיניות נמען. לבדיקות האימות עיינו בשלב 4 בהמשך.

בדיקת קבלה: השיבו מ-Gmail אל כתובת העסק החדשה.

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

אחרי ששתי הבדיקות עוברות, הגדירו לקוח נתמך. עיינו בתיעוד הגדרות IMAP ו-SMTP של TrekMail ובדקו TLS, תעודות ושיטות אימות מותרות. קיים גם מדריך לחיבור Gmail, אך האפשרויות משתנות לפי היישום והחשבון.

שלב 4: שלושת יסודות יכולת המסירה, SPF, DKIM ו-DMARC

MX מגדיר ניתוב לקבלה; SPF, DKIM ו-DMARC תומכים באימות הודעות יוצאות. בדקו את דרישות השולחים החלות אצל Google ו-Yahoo בשנים 2025-2026, ובפרט לשולחים בכמות גדולה. הגדרה נכונה חשובה אך אינה מבטיחה הגעה לתיבה הנכנסת.

SPF: מי רשאי לשלוח

SPF (Sender Policy Framework) מפרסם אילו שרתים רשאים לשלוח עבור זהות SMTP. אם yourcompany.com הוא דומיין MAIL FROM, או זהות HELO במצב המתאים, הנמען מעריך את כתובת ה-IP השולחת לפי מדיניות הדומיין הזה. כתובת From הגלויה אינה כשלעצמה זהות SPF.

להלן דוגמת SPF היסטורית, לא רשומה להעתקה ללא בדיקה. ברירת המחדל הנוכחית משתמשת ב-spf.trekmail.net. השתמשו ברשומה המלאה שבחשבון וכללו את כל שירותי השליחה המורשים:

v=spf1 include:_spf.trekmail.net -all

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

הסיומת -all מחזירה SPF Fail לשולח שאינו תואם. בחרו ב--all רק אחרי שכל שירות מורשה, לרבות דואר טרנזקציוני ו-CRM, נכלל ברשומת SPF תקינה אחת. מגבלת 10 חלה על מונחים שגורמים לפניות DNS לאורך ההערכה המלאה, כולל הערכות מקוננות, ולא על כל חבילות DNS או רק מספר רכיבי include. חריגה יכולה לגרום ל-SPF PermError.

DKIM: חותם שמגלה שינויים

כאשר חתימת DKIM (DomainKeys Identified Mail) מוגדרת, ההודעה נושאת חתימה קריפטוגרפית. הנמען מאמת אותה במפתח הציבורי של הבורר המתאים ב-DNS. שינוי חלקים חתומים עשוי לגרום לכשל, אבל לא כל שינוי נוגע בהם; גם מפתחות והגדרות יכולים לגרום לכשל. בדקו כותרות של הודעות בפועל.

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

DMARC: מנגנון המדיניות

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

התחילו עם מדיניות ניטור בלבד:

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

ההגדרה אינה מבקשת טיפול DMARC מגביל ומציינת יעד לדוחות. מסננים אחרים עדיין יכולים לדחות או לסווג הודעות כספאם. אמתו התאמה ואימות לכל מסלולי השליחה המורשים לפני שינוי לפי הצורך ל-p=quarantine או ל-p=reject.

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

למה לא להשתמש פשוט ב-Gmail?

"אי אפשר פשוט להשתמש ב-mycompany@gmail.com?" אפשר, אבל בדקו אם חשבון אישי מתאים לדרישות העסק לניהול גישה, שחזור והעברת אחריות.

בשימוש בכתובות אישיות לעסק, שקלו את סיכוני הניהול הבאים:

בעלות על הנתונים

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

תלות באדם יחיד

נציג המכירות משתמש ב-john.sales@gmail.com, ולכן גישה לרישומים עסקיים עלולה להישאר תלויה בחשבונו האישי אחרי עזיבתו. עם john@yourcompany.com אפשר לתכנן העברה לפי הרשאות ומדיניות שמירה. אמתו ביטול גישה של הפעלות ויישומים; שינוי סיסמה בלבד אינו תמיד מספיק. בדקו העברה מורשית וגישה לעובד החדש בלי להניח שהמעבר יהיה נטול הפרעות.

אובדן גישה לחשבונות SaaS

עזיבת בעל חשבון אישי שאליו קשורים הנהלת החשבונות, CRM ופלטפורמת הפרסום יכולה להקשות על שחזור גישה. כתובות מנוהלות כמו billing@yourcompany.com מסייעות בהעברה מסודרת. בדקו גם תפקידים, אמצעי שחזור ודרישות אימות זהות בפלטפורמה; שליטה בכתובת אינה קובעת את כל הרשאות השירות.

הסבר על דואר בדומיין מותאם אישית

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

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

ההגדרה הפשוטה ביותר עבור 1-5 תיבות דואר

Microsoft 365 ו-Google Workspace מספקים שיתוף פעולה לצד דואר. פלטפורמה שמשרתת גם ארגון של 500 אנשים יכולה להתאים לצוות של שלושה, אבל השוו את הצורך בשיתוף פעולה לצורך בתיבות וכתובות תפקידיות בלבד.

הדרך הישנה (מלכודת התשלום לכל מושב)

דוגמת חישוב היסטורית משתמשת ב-Google Workspace Starter במחיר $6 למשתמש בחודש. לצד שלושה עובדים דרושים info@, sales@ ו-billing@, אבל לא כל כתובת מחייבת משתמש נפרד בתשלום: בדקו כינויים וקבוצות. רק אם יוצרים בדוגמה 6 משתמשים בתשלום מגיעים ל-$36 בחודש ול-$432 בשנה. בדקו מחירים ורישיונות עדכניים.

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

הדרך החדשה (המאגר המשותף של TrekMail)

תיאור Starter ההיסטורי של TrekMail מציין $3.50 בחודש (או $42 בשנה), עם 50 דומיינים, 100 תיבות לדומיין ו-15GB אחסון משותף. בדקו מחירים, הרשאות ומגבלות עדכניים. אפשר לנתב את info@, billing@ ו-support@ ככינויים בהתאם לפעולות הזמינות בחשבון.

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

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

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

הסבר על רשומות MX בלי מונחים מסובכים

DNS הוא מושג מופשט, לכן הנה דימוי מוחשי.

חשבו על הדומיין כעל בניין מסחרי.

• רשומת A היא דלת הכניסה, שדרכה לקוחות מגיעים לאתר.
• רשומת MX היא רציף הפריקה, שאליו מגיע משלוח הדואר.

כשמישהו שולח לכם הודעה, השרת שלו מחפש את הדומיין בספריית ה-DNS העולמית. הוא שואל במיוחד על רשומת ה-MX.

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

האתר יכול לפעול דרך רשומת A כאשר ניתוב הדואר דרך MX נתקל בבעיה. לרשומות מטרות שונות אך הן עשויות לחלוק תשתית DNS ותלויות נוספות.

5 שגיאות DNS שפוגעות ביכולת המסירה

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

1. השארת "Backup MX" פעיל

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

2. התנגשויות CNAME בדומיין השורש

CNAME רגיל בדומיין השורש (@) אינו יכול להתקיים לצד SOA ו-NS הנדרשות או MX. בחיבור ל-Wix או Squarespace בדקו אילו רשומות כתובת ספק ה-DNS תומך בהן. ALIAS/ANAME או flattening הם מנגנונים של הספק, לא פרסום CNAME רגיל בשורש.

3. שינוי הרשומות שוב לפני סיום ההפצה

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

4. רשומת SPF חסרה

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

5. שם מארח שגוי ברשומת MX

בעת הוספת רשומות MX, השדה "Host" או "Name" צריך כמעט תמיד להיות @, שמייצג את דומיין השורש. אם תקלידו בו mail או www, תגדירו ניתוב דואר עבור user@mail.yourcompany.com ולא עבור user@yourcompany.com. בדקו שוב את השדה בכל רשומה שאתם מוסיפים.

אילו כתובות ליצור תחילה

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

1. מנהל החירום (ops@ או admin@)

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

2. כינויים תפקידיים (info@, support@, hello@)

אם אינכם רוצים לבדוק חמש תיבות נפרדות, בדקו אילו כתובות תפקידיות יכולות להיות כינויים. הגדירו ב-TrekMail את info@ ככינוי לתיבה הראשית בהתאם להרשאות הזמינות. שליחה בשם info@ דורשת זהות מורשית והגדרות SMTP ולקוח נתמכות. במודל Nano המתואר, כל הודעה יוצאת וגם תשובה דורשת שירות SMTP חיצוני משלכם. בדקו תנאים עדכניים ותיעוד הגדרת ההעברה.

3. חשבונות תפקיד לתשתיות (billing@, marketing@)

שקלו כתובות תפקיד מנוהלות לשירותי SaaS, פרסום ופיננסים. כאשר מנהלת חשבון Facebook Ads המקושר ל-sarah@yourcompany.com עוזבת, בדקו תפקידים, הפעלות, הרשאות יישומים ושחזור והעבירו אחריות בהרשאה. סיסמה והעברת דואר בלבד אינן תמיד מספיקות. חשבון Gmail אישי עשוי להאריך את השחזור; שלושה שבועות הם דוגמה, לא זמן תמיכה קבוע.

מוסכמות שמות והחלטות לגבי הפורמט

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

המלצה מעשית: התחילו ב-firstname@ אם הצוות קטן וכולם מכירים זה את זה. תכננו מעבר ל-first.last@ לאחר שתעברו 5-10 אנשים. בדקו אם אפשר לקשר את john@ ל-john.doe@ באמצעות הכינויים הזמינים ואמתו קבלה ושליחה מורשית. הדבר יכול לצמצם החמצת הודעות אך אינו מבטיח שלא תוחמץ אף הודעה.

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

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

"אני יכול לשלוח, אבל לא לקבל".

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

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

סיבה: אימות יכול להשפיע, לצד תוכן, מוניטין ומדיניות נמען.
פתרון: שלחו הודעה מייצגת אל mail-tester.com ובחנו כותרות ותוצאות; ציון יחיד אינו מוכיח טיפול אצל כל נמען. בדקו גם את Google Postmaster Tools אם הדומיין עומד בתנאי השימוש. הנתונים המצטברים מתייחסים לתעבורה בחשבונות Gmail אישיים, לא לכל מסירה. עיינו במדריך אבחון הספאם לחקירה רחבה יותר.

"Outlook ממשיך לבקש את הסיסמה".

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

• IMAP (נכנס): יציאה 993, TLS מובנה ואימות תעודה; הלקוח עשוי להציג את התווית SSL/TLS
• SMTP (יוצא): יציאה 465 (SSL/TLS כתווית לקוח ל-TLS מובנה) או 587 (STARTTLS), עם אימות תעודה ושיטת אימות מותרת
• שם משתמש: כתובת הדואר המלאה, כולל @domain, ולא רק החלק שלפניו

להגדרת הלקוח המלאה, עיינו בחיבור ל-Outlook או במדריך המלא להגדרות IMAP ו-SMTP.

"אני מקבל הודעת החזרה מסוג 550".

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

מחשבות לסיום

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

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

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

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

נסו את TrekMail בחינם, trekmail.net