מייל עם דומיין, איך מקימים מייל מקצועי לעסק

מייל של חברת האחסון

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

Google Workspace

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

Microsoft 365

Outlook ו-Exchange עם הדומיין, יחד עם Word, Excel ו-Teams. מתאים לעסקים שעובדים עם כלי Microsoft ולארגונים עם דרישות ניהול מתקדמות. גם כאן, תשלום לכל משתמש.

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

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

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

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

SPF

רשומת TXT שמפרטת אילו שרתים מורשים לשלוח מייל בשם הדומיין: למשל Google, מערכת הדיוור, והאתר. חשוב שתהיה רשומת SPF אחת בלבד לדומיין, שכוללת את כל השולחים.

DKIM

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

DMARC

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

חשוב לדעת: Gmail ו-Yahoo החמירו מאז 2024 את הדרישות מאימות מייל, ובמיוחד משולחים בכמויות גדולות, שנדרשים ל-SPF, DKIM ו-DMARC. גם אם אתם לא שולחים בכמויות, הגדרה נכונה משפרת את הגעת המיילים.

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

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

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

מדריך מעשי להעברת אתר יש באיך מעבירים אתר בין שרתים.

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

ב-Google Workspace וב-Microsoft 365 משלמים לפי משתמש, ולכן כדאי לתכנן. לא כל כתובת צריכה להיות תיבה נפרדת:

• כינויים (Aliases): כתובת נוספת שמגיעה לתיבה קיימת, למשל info שמגיעה לתיבה של הבעלים.
• קבוצות: כתובת כמו sales שמגיעה לכמה אנשים.
• תיבות משותפות: תיבה שכמה עובדים מנהלים יחד, למשל שירות לקוחות.
• העברה: כתובת שמעבירה לתיבה חיצונית, בזהירות, כי העברות עלולות להיפגע באימות.

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

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

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

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

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

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

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