תשובה מהירה
איך מגדירים MTA-STS ו-TLS-RPT?
פרסמו רשומת TXT ב-_mta-sts.yourdomain עם v=STSv1 ומזהה, הגישו קובץ מדיניות בכתובת https://mta-sts.yourdomain/.well-known/mta-sts.txt עם תעודה תקפה, והוסיפו רשומת TXT ב-_smtp._tls לדוחות TLS-RPT (RFC 8461 ו-RFC 8460). Postelva מארחת את רשומות ה-DNS; קובץ המדיניות דורש מארח אינטרנט עם HTTPS.
ארבעת החלקים של הגדרת MTA-STS ו-TLS-RPT
| חלק | היכן | תוכן | מאורח ב |
|---|---|---|---|
| רשומת MTA-STS | TXT ב-_mta-sts.example.com | v=STSv1; id=20261112T000000Z | ה-DNS שלכם (DNS חינמי ב-Postelva) |
| שם מארח האינטרנט | A, AAAA או CNAME ב-mta-sts.example.com | מצביע על שרת אינטרנט | ה-DNS שלכם |
| קובץ המדיניות | https://mta-sts.example.com/.well-known/mta-sts.txt | version, mode, שורות mx, max_age | מארח אינטרנט עם HTTPS ותעודה תקפה |
| רשומת TLS-RPT | TXT ב-_smtp._tls.example.com | v=TLSRPTv1; rua=mailto:[email protected] | ה-DNS שלכם |
הגדרת MTA-STS בשישה שלבים
רשמו את מארחי ה-MX שלכם
המדיניות חייבת לציין את מארחי הדואר של הספק שלכם. Proton Mail משתמשת ב-mail.protonmail.ch וב-mailsec.protonmail.ch, ו-Mailbox.org משתמשת ב-mxext1 עד mxext4.mailbox.org.
הגדירו את שם מארח האינטרנט
בעורך ה-DNS הוסיפו רשומה ל-mta-sts שמצביעה לשרת אינטרנט בשליטתכם, וקבלו תעודה תקפה ל-mta-sts.yourdomain.
פרסמו את קובץ המדיניות במצב בדיקה
צרו את הקובץ mta-sts.txt בתיקייה .well-known, עם mode: testing ו-max_age קצר.
הוסיפו את רשומת ה-TXT ב-_mta-sts
פרסמו v=STSv1; id= ואחריו ערך ייחודי, כמו תאריך ושעה.
הוסיפו את רשומת TLS-RPT
פרסמו את רשומת ה-TXT ב-_smtp._tls עם כתובת mailto ב-rua, וקראו את הדוחות היומיים.
עברו ל-enforce
כשהדוחות לא מציגים כשל עבור מארחי ה-MX שלכם, שנו את המצב ל-enforce, העלו את max_age ועדכנו את ה-id.
; DNS records
_mta-sts.example.com. IN TXT "v=STSv1; id=20261112T000000Z"
_smtp._tls.example.com. IN TXT "v=TLSRPTv1; rua=mailto:[email protected]"
mta-sts.example.com. IN CNAME webhost.example.net.
; File served at https://mta-sts.example.com/.well-known/mta-sts.txt
version: STSv1
mode: testing
mx: mail.protonmail.ch
mx: mailsec.protonmail.ch
max_age: 86400ממה MTA-STS מגן?
MTA-STS מאפשר לדומיין דואר להצהיר שהוא תומך ב-TLS, ושהשולחים חייבים לסרב למסור לכל מארח MX שאינו יכול להציג תעודה תקפה. RFC 8461, תקן מוצע מספטמבר 2018, מגדיר אותו. בלעדיו ההצפנה בין שרתים היא אופורטוניסטית: שולח מנסה STARTTLS, ואם תוקף מסיר אותו, ההודעה נשלחת בטקסט גלוי.
במצב enforce, שולח התומך ב-MTA-STS מביא את המדיניות שלכם, בודק שמארח ה-MX מופיע ברשימת mx, ודורש חיבור TLS תקף עם תעודה תואמת. אם בדיקה נכשלת, ההודעה ממתינה ולא נמסרת בערוץ חלש יותר. זה מגן רק על דואר נכנס, ועובד רק עם שולחים שמיישמים אותו. הוא לא מאמת הודעות: זה התפקיד של הרשומות בSPF לעומת DKIM לעומת DMARC.
מה נכנס לקובץ המדיניות?
קובץ המדיניות הוא קובץ טקסט רגיל של שורות מפתח: ערך, עם הגרסה, המצב, תבניות ה-MX המותרות ומשך חיים בשניות. RFC 8461 מגדיר את השדות האלה. version חייב להיות STSv1. mode הוא enforce (השולחים לא יכולים למסור למארחים שנכשלים בבדיקות), testing (המסירה יכולה להמשיך, ושולחים התומכים ב-TLS-RPT שולחים דוחות כשל) או none (כאילו לא הייתה מדיניות). כל שורת mx מציינת מארח במלואו, למשל mail.protonmail.ch, או משתמשת בתו כללי בתווית השמאלית, כמו *.example.net. max_age הוא מספר שניות, עד 31,557,600, וה-RFC אומר שבדרך כלל הוא צריך להיות שבועות או יותר. הדוגמה שלו משתמשת ב-604800, שבוע אחד.
הקובץ חייב להיות מוגש ב-HTTPS בכתובת mta-sts.yourdomain עם תעודה תקפה לשם הזה. רק תשובה HTTP 200 נחשבת, ואסור לעקוב אחרי הפניות, וזה שולל העברת כתובת URL, שירות שעונה בהפניה. יש להגיש את הקובץ כ-text/plain. השתמשו במארח אינטרנט קטן או במארח דפים סטטיים שבשליטתכם. שורות mx חייבות להתאים לרשומות של הספק שלכם, כפי שמופיעות במהי רשומת MX.
מה הם ה-id וסדר העדכון?
רשומת ה-id ב-TXT היא תווית של 1 עד 32 אותיות וספרות, ועליה להשתנות בכל פעם שהמדיניות משתנה, כדי ששולחים ידעו להביא את הקובץ מחדש. RFC 8461 קובע שהיא מזהה מופע אחד של מדיניות, ואין סדר בין מזהים, ולכן חותמת תאריך ושעה מתאימה מאוד.
עדכנו בסדר הזה: פרסמו קודם את קובץ המדיניות החדש, ורק אחר כך שנו את ה-id. שולח שרואה את ה-id החדש לפני הקובץ החדש יישמור במטמון את המדיניות הישנה שוב. כשמחליפים ספק דוא"ל, מארחי ה-MX משתנים גם הם, ולכן ערכו את שורות ה-mx לפני ששינוי רשומות MX, השאירו את המארחים הישנים ברשימה במהלך המעבר, ועדכנו את ה-id. שורת mx שנשכחה במצב enforce גורמת לכך שהדואר לא מגיע, ומדריך המעבר איך מעבירים דוא"ל לספק חדש נותן את הסדר הבטוח לשאר.
מהו TLS-RPT, ומה מכילים הדוחות?
TLS-RPT הוא פורמט דיווח, RFC 8460, שבו שרתים שולחים לכם מדי יום כמה חיבורי TLS אל הדומיין שלכם הצליחו וכמה נכשלו. מפרסמים רשומת TXT ב-_smtp._tls.yourdomain עם v=TLSRPTv1 ושדה rua שמכיל כתובת mailto: או https:. דוחות שנשלחים במייל חייבים לכלול חתימת DKIM תקפה מהדומיין המדווח.
כל דוח הוא מסמך JSON שמכסה יום UTC אחד. הוא מציין איזו מדיניות הופעלה (MTA-STS, DANE או none), סופר סשנים שהצליחו ונכשלו, ומציין את סוג הכשל, כמו certificate-expired או starttls-not-supported, עם כתובות ה-IP של השולח והמקבל. כך לומדים שתעודה פגה או שיש שגיאת הקלדה בשורת mx, לפני המעבר ל-enforce. התייחסו לשבועות הראשונים כאל ריצת הניסיון שמומלצת לDMARC.
האם צריך MTA-STS לדומיין דוא"ל אישי?
לא: MTA-STS הוא הקשחה אופציונלית, וכללי השולחים הגדולים אינם דורשים אותו. Google, Yahoo ו-Microsoft מבקשות משולחים המוניים SPF, DKIM ו-DMARC, ואינן מציינות את MTA-STS. לדומיין אישי ב-Proton Mail, ב-Fastmail או ב-Mailbox.org ההגדרה שווה את המאמץ רק אם אתם מוכנים לתחזק מארח אינטרנט ותעודה.
הספקים שונים זה מזה. לפי הקריאה של Postelva מ-12 בנובמבר 2026 של רשימות הגדרת ה-DNS של 4 ספקים (Proton Mail, Tuta, Mailbox.org ו-Fastmail), אחד מהם מציג רשומת MTA-STS בהגדרה שלו (Tuta, כ-CNAME), ועזרת הדפים של שלושת האחרים לא מתעדת אותה. כל ההגדרה היא 3 רשומות DNS וקובץ אחד. בדקו כל אחת בעזרת הפקודות באיך בודקים רשומות MX, SPF, DKIM ו-DMARC: dig TXT _mta-sts.example.com +short ו-dig TXT _smtp._tls.example.com +short.
הגדרה שניתנת לציטוט: MTA-STS הוא המדיניות שהופכת TLS לחובה כששרתים אחרים מוסרים דואר לדומיין שלכם, ו-TLS-RPT הוא הדוח היומי שמראה מתי זה נכשל.
שאלות על MTA-STS ו-TLS-RPT
האם אפשר לארח את קובץ המדיניות של MTA-STS אצל ספק ה-DNS?
לא אצל ספק DNS בלבד: הקובץ דורש שרת אינטרנט שעונה ב-HTTPS בכתובת mta-sts.yourdomain. העברת כתובת URL לא עובדת, כי אסור לעקוב אחרי הפניות.
איזה max_age כדאי להשתמש?
RFC 8461 אומר שהערך בדרך כלל נע משבועות ומעלה, עם 604800 שניות (שבוע אחד) בדוגמה שלו. התחילו בערך קצר במצב testing, והעלו אותו כשהדוחות נקיים.
האם MTA-STS זהה ל-DANE?
לא. שניהם מגנים על TLS בין שרתים, אבל DANE נשען על DNSSEC ורשומות TLSA, ואילו MTA-STS נשען על קובץ מדיניות ב-HTTPS. TLS-RPT מדווח על שניהם.
מה קורה אם התעודה שלי פגה במצב enforce?
שולחים התומכים ב-MTA-STS מפסיקים למסור למארחים שלכם כשהתעודה של מארח MX נכשלת, והדואר ממתין בתור שלהם. אותו דבר חל על שורת mx חסרה, ולכן עקבו אחרי TLS-RPT.
האם חייבים להשתמש במצב enforce?
לא. מצב testing כבר נותן לכם דוחות, ומצב none מכבה את המדיניות.
בקצרה
- MTA-STS (RFC 8461) הופך TLS לחובה לדואר שנמסר לדומיין שלכם.
- הגדרה: רשומת TXT ב-_mta-sts, קובץ מדיניות ב-HTTPS בכתובת mta-sts.yourdomain/.well-known/mta-sts.txt, ורשומת TXT ב-_smtp._tls ל-TLS-RPT (RFC 8460).
- המדיניות כוללת את mode (enforce, testing, none), מארחי mx ו-max_age, עד 31,557,600 שניות.
- אסור לעקוב אחרי הפניות, ולכן העברת כתובת URL לא יכולה להגיש את הקובץ.
- שנו את ה-id בכל פעם שהמדיניות משתנה; עדכנו קודם את הקובץ, ואז את רשומת ה-TXT.
- התחילו במצב testing וקראו את דוחות TLS-RPT לפני enforce.
- Postelva מארחת את רשומות ה-DNS בחינם; דומיין .com עולה 12.49 $/שנה בשנה.
מקורות (4)
- RFC 8461, אבטחת תעבורה מחמירה ל-SMTP (MTA-STS) — RFC Editor (נקרא 2026-11-12)
- RFC 8460, דיווח TLS ל-SMTP — RFC Editor (נקרא 2026-11-12)
- הנחיות לשולחי אימייל — Google Workspace Admin Help (נקרא 2026-11-12)
- הגנה על דומיין מותאם ומניעת זיוף — Proton (נקרא 2026-11-12)