הגדרת DNS לדוא״ל באופן אוטומטי: לחיצה לדומיין אחד, אסימון לכמה דומיינים

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

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

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

אילו רשומות DNS הדוא״ל צריך

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

ארבע טעויות נפוצות בהגדרת DNS ידנית

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

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

פרסום DMARC בשם הלא נכון. הרשומה צריכה להיות תחת _dmarc.example.com. אם היא בשורש הדומיין, שרת הקבלה לא ימצא אותה בחיפוש מדיניות DMARC של הדומיין.

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

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

דרך 1: הגדרת DNS בלחיצה, בלי אסימון

לדומיין שה-DNS שלו מנוהל ב-Cloudflare, זו הדרך הישירה. אין צורך למסור ל-TrekMail אסימון API או פרטי כניסה לחשבון.

1. פתחו את לשונית DNS ומצב של הדומיין.
2. לחצו על הגדרת DNS אוטומטית.
3. Cloudflare מציגה את שינויי הרשומות המוצעים לפני האישור.
4. לחצו על אישור.
5. תחזרו ל-TrekMail ותתבקש בדיקה. החזרה לבדה אינה מוכיחה שהרשומות פורסמו נכון.

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

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

דרך 2: הגדרת DNS באסימון API מוגבל

לכמה דומיינים, או כש-Domain Connect אינו זמין, אסימון מאפשר להגדיר את האזורים שאושרו בחשבון.

צרו ב-Cloudflare אסימון מתבנית Edit zone DNS, עם הרשאת Zone → DNS → Edit. במשאבי האזורים בחרו All zones לכל האזורים או Specific zone להגבלת הגישה. בדקו שהגבלות IP ומשך התוקף מאפשרים את השימוש המתוכנן; אין צורך לשנות אותם ללא סיבה. העתיקו את האסימון כשהוא מוצג והדביקו אותו ב-TrekMail.

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

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

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

התצוגה המקדימה וחמשת המצבים

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

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

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

למה ממזגים את רשומת ה-SPF הקיימת

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

נניח שהדומיין כבר מפרסם:

v=spf1 include:_spf.google.com ~all

המדיניות הזו מאשרת את תשתית Google, למשל Workspace או כלי ששולח דרכה. החלפה לרשומה שכוללת רק את TrekMail אינה רק הוספת שולח: היא מסירה את האישור הקודם. הודעות שהסתמכו עליו עלולות להתחיל להיכשל בבדיקת SPF.

לכן רשומת SPF קיימת ותקינה ממוזגת בדרך כלל:

v=spf1 include:_spf.trekmail.net include:_spf.google.com ~all

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

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

הגדרת DNS בקבוצות

עם אסימון שמורשה לכל האזורים, האשף יכול לעבור על דומיינים נתמכים, להוסיף חדשים, להגדיר רשומות ולהציג תוצאות לכל דומיין. המגבלה היא 50 דומיינים בקבוצה. דומיינים חדשים נספרים במכסת המסלול: 10 ב-Nano,‏ 50 ב-Starter,‏ 100 ב-Pro ו-1,000 ב-Agency, לפי ההגדרה שתוארה במאמר המקורי. בדקו את מגבלות החשבון העדכניות לפני שמתחילים.

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

טווח ההשפעה של השינויים

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

החיבור נועד לנהל רשומות דואר: MX, SPF, DKIM, DMARC, MTA-STS, TLS-RPT ורשומות CNAME להגדרה אוטומטית של דואר. הוא אינו אמור לשנות רשומות A, רשומות CNAME של האתר או TXT של שירותים אחרים. עם זאת, הרשאת ה-DNS של האסימון מאפשרת לערוך רשומות באזורים שאושרו, ולא רק רשומות דואר. השמירה על יתר הרשומות תלויה גם בהתנהגות היישום. ההרשאה הזו אינה מאפשרת לשנות שרתי שמות.

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

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

שאלות נפוצות

צריך חשבון Cloudflare להגדרה בלחיצה?

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

מה אם ה-DNS שלי אינו ב-Cloudflare?

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

ההגדרה האוטומטית יכולה להשפיע על האתר שלי?

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

מה קורה לרשומת ה-SPF הקיימת?

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

אפשר להחיל רק חלק מהרשומות?

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

כמה דומיינים אפשר להגדיר בהרצה אחת?

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

אסימון ה-API שלי מוגן?

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

למה רשומה שלא יצרתי מופיעה כ״כבר מוגדרת״?

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