Apple Private Email Relay
כאשר מישהו מתחבר לאפליקציה או לאתר שלכם באמצעות Sign in with Apple ובוחר ב-Hide My Email, Apple מוסרת לכם כתובת העברה אקראית במקום הכתובת האמיתית שלו - לדוגמה [email protected]. שירות Private Email Relay של Apple מעביר דואר שנשלח לכתובת הזו לתיבת הדואר האמיתית של האדם, אבל רק משולחים שרשמתם אצל Apple. דואר מכל שולח אחר מוחזר על ידי שירות ההעברה ולעולם אינו מגיע לאדם.
הדף הזה מסביר מה צריך לרשום, מי צריך לרשום אותו, ואיך לבדוק שזה עובד בדרך שבה סביבת העבודה שלכם שולחת אימייל.
Apple הודיעה באוגוסט 2026 שכתובות Sign in with Apple חדשות יונפקו בדומיין private.icloud.com במקום privaterelay.appleid.com, החל ממועד מאוחר יותר השנה. כתובות קיימות ב-privaterelay.appleid.com ממשיכות לעבוד. שני הדומיינים הם כתובות העברה, וכל מה שכתוב בדף הזה חל על שניהם. Joryio מקבלת כתובות בכל אחד מהדומיינים כמו כל כתובת אימייל אחרת.
למה דואר לכתובות העברה נכשל בשקט
שירות ההעברה אינו תיבת דואר רגילה. עבור כל הודעה שהוא מקבל, Apple בודקת שני דברים:
- האם ההודעה מאומתת? היא חייבת לעבור SPF או DKIM בדרך הספציפית ש-Apple דורשת (ראו מה Apple בודקת).
- האם השולח רשום? דומיין השליחה או הכתובת חייבים להופיע ברשימת מקורות האימייל הרשומים עבור צוות ה-Apple Developer שלכם.
אם אחת הבדיקות נכשלת, שירות ההעברה מחזיר החזרה (bounce). שום דבר לא נשבר בקמפיין שלכם: ספק האימייל מקבל את השליחה, ההחזרה מגיעה מאוחר יותר, ואיש הקשר פשוט לא מקבל את ההודעה. מכיוון שכתובות העברה הן לרוב חלק קטן מהרשימה, הבעיה עלולה לעבור בלי שתורגש זמן רב.
מי צריך לעשות את זה
הרישום מתבצע בחשבון ה-Apple Developer שבבעלותו האפליקציה או האתר שמשתמשים ב-Sign in with Apple - כלומר החשבון שלכם, לא של Joryio. Joryio אינה יכולה לרשום דומיינים אצל Apple בשמכם.
- Apple דורשת תפקיד Account Holder או Admin בחשבון המפתחים הזה.
- כתובות העברה שייכות לצוות (team) מפתחים: אותו אדם מקבל אותה כתובת העברה בכל אפליקציה של צוות אחד, וכתובת אחרת באפליקציה של צוות אחר. רשמו את דומייני השליחה שלכם בצוות שהאפליקציות שלו אוספות את הכתובות. אם האפליקציות שלכם מפוזרות בין כמה צוותים, רשמו בכל אחד מהם.
- Apple מאפשרת עד 32 מקורות אימייל בהרשמה של יחיד ועד 100 בהרשמה של ארגון. כל דומיין, תת-דומיין או כתובת בודדת נחשבים כמקור אחד.
מה Apple בודקת
Apple מקבלת הודעה אם היא עוברת אחת מהבדיקות הבאות, וממליצה להגדיר את שתיהן היכן שאפשר:
| בדיקה | מה צריך להתאים | עוברת כאשר |
|---|---|---|
| SPF | הדומיין של שולח המעטפה (envelope sender, נקרא גם MAIL FROM, Return-Path או כתובת החזרה - לא כתובת ה-From שאנשים רואים) | הדומיין המדויק הזה רשום אצל Apple וגם עובר SPF |
| DKIM | הדומיין d= בחתימת ה-DKIM | החתימה מאומתת, היא מכסה את כותרת ה-From, והדומיין d= הוא בדיוק הדומיין של כתובת ה-From, שרשום אצל Apple |
לאחר האימות, Apple גם משווה את הדומיין או הכתובת של From למקורות הרשומים שלכם. לכן, בכל בדיקה שעליה אתם מסתמכים, הדומיין של כל כתובת From שממנה אתם שולחים חייב להיות רשום.
ההתאמה היא מדויקת. רישום acme.com אינו מכסה את news.acme.com: כל תת-דומיין שממנו אתם שולחים הוא מקור נפרד וחייב להירשם בפני עצמו (או שתרשמו במקומו את הכתובות הבודדות).
ספקי אימייל רבים משתמשים בדומיין שלהם כשולח המעטפה, אלא אם אתם מספקים להם דומיין החזרות מותאם אישית (נקרא גם custom MAIL FROM או דומיין return-path) על הדומיין שלכם. בלעדיו, רק בדיקת ה-DKIM יכולה לעבור. איתו, גם SPF וגם DKIM יכולים לעבור על הדומיינים שלכם, וזה מה ש-Apple ממליצה - לכן הגדירו דומיין החזרות מותאם אישית בכל מקום שהספק שלכם מציע אותו.
אילו דומיינים לרשום
אימייל ב-Joryio נשלח באחת משתי דרכים, ש-Joryio מגדירה עבור הארגון שלכם: דרך האימייל המנוהל של Joryio (Amazon SES המופעל על ידי Joryio), או דרך חשבון הספק של הארגון שלכם (Amazon SES, SendGrid, Mailgun או Bird). אם אינכם בטוחים באיזו דרך סביבת העבודה שלכם משתמשת, פנו לתמיכה של Joryio.
| איך סביבת העבודה שלכם שולחת | מה לרשום אצל Apple | הבדיקה שעוברת | הערות |
|---|---|---|---|
| אימייל מנוהל של Joryio | כל דומיין From שהשולחים שלכם משתמשים בו, בדיוק כפי שהוא משויך (לדוגמה mail.acme.com), וגם את דומיין ההחזרות שלו e.<sending domain> (לדוגמה e.mail.acme.com) | DKIM - Joryio חותמת עם הדומיין המשויך שלכם; וגם SPF ברגע שרשומות דומיין ההחזרות שבהמשך נמצאות ב-DNS שלכם | כל דומיין משויך מקבל דומיין החזרות (MAIL FROM) e.<sending domain>. הוסיפו את שתי רשומות ה-DNS שלו ו-SPF יעבור על הדומיין שלכם. בלעדיהן הדואר עדיין נשלח, אבל שולח המעטפה חוזר לדומיין של Amazon SES עצמו ורק DKIM יכול לעבור. |
| חשבון Amazon SES שלכם | כל דומיין From | DKIM, כאשר דומיין ה-From עצמו הוא זהות מאומתת ב-SES עם Easy DKIM | אם רק דומיין האב מאומת ב-SES, SES חותמת על דואר מתת-דומיין עם דומיין האב וההתאמה המדויקת של Apple נכשלת - אמתו את תת-הדומיין כזהות נפרדת. הגדירו דומיין MAIL FROM מותאם אישית על הזהות ב-SES ורשמו גם את הדומיין הזה אצל Apple, כדי שגם SPF יעבור. |
| חשבון SendGrid שלכם | כל דומיין From; ואופציונלית את תת-דומיין ה-return-path ש-SendGrid יצרה (לדוגמה em1234.acme.com) | DKIM לאחר אימות דומיין ב-SendGrid; וגם SPF אם רושמים את תת-דומיין ה-return-path | ללא אימות דומיין, SendGrid חותמת עם הדומיין שלה ושתי הבדיקות נכשלות. אימות הדומיין מגדיר גם את תת-דומיין ה-return-path המותאם אישית - השאירו אותו פעיל. |
| חשבון Mailgun שלכם | כל דומיין From וגם את דומיין השליחה של Mailgun שהוגדר עבור הארגון שלכם (לדוגמה mg.acme.com) | SPF על דומיין השליחה של Mailgun; DKIM רק כאשר דומיין ה-From הוא דומיין ה-Mailgun עצמו | Mailgun משתמשת בדומיין השליחה שלה כשולח המעטפה ובדרך כלל חותמת DKIM איתו. אם כתובת ה-From שלכם בדומיין אחר (לדוגמה acme.com), DKIM אינו תואם במדויק, ולכן מסלול ה-SPF דרך דומיין ה-Mailgun הרשום הוא זה שעובר. ודאו שרשומות ה-SPF וה-MX של דומיין ה-Mailgun עצמו קיימות. |
| חשבון Bird שלכם | כל דומיין From | DKIM, כאשר Bird חותמת עם דומיין ה-From שלכם | בדקו עם איזה דומיין Bird חותמת ובאיזה דומיין מעטפה היא משתמשת (ראו בדקו לפני שאתם מסתמכים על זה). אם Bird מציעה דומיין return-path (החזרות) מותאם אישית, הגדירו אותו על הדומיין שלכם ורשמו גם אותו, כדי שגם SPF יעבור. |
כל דומיין From פירושו כל דומיין שסביבת העבודה שלכם שולחת ממנו בפועל: השולח המוגדר כברירת מחדל, כל שולח שמור תחת Settings → Email Configuration, וכל Custom From שבו נעשה שימוש בקמפיין או במסע. המסנן דומיין שליחה ב-Analytics → Deliverability מציג את הדומיינים שמהם שלחתם בפועל בטווח תאריכים, וזו דרך מהירה למצוא דומיין ששכחתם.
רשומות DNS לאימייל מנוהל
באימייל המנוהל, לכל דומיין שליחה משויך יש דומיין החזרות (שולח המעטפה, או MAIL FROM) בכתובת e.<sending domain> - עבור mail.acme.com הוא e.mail.acme.com. הוא צריך שתי רשומות DNS, ש-Joryio שולחת לכם יחד עם שלוש רשומות ה-CNAME של DKIM ורשומת ה-DMARC כשהדומיין שלכם משויך:
| סוג | שם | ערך | עדיפות |
|---|---|---|---|
| MX | e.<sending domain> | feedback-smtp.<region>.amazonses.com (לדוגמה feedback-smtp.eu-central-1.amazonses.com) | 10 |
| TXT | e.<sending domain> | v=spf1 include:amazonses.com ~all | - |
השתמשו בערכים המדויקים מהרשומות ש-Joryio שולחת לכם; האזור (region) בערך ה-MX הוא האזור שממנו הדואר שלכם נשלח.
- עם הרשומות האלה, שולח המעטפה נמצא על הדומיין שלכם, כך ש-SPF עובר ומיושר (aligned) שם, ו-DKIM עובר דרך רשומות ה-CNAME של Easy DKIM. שתי הבדיקות של Apple יכולות לעבור. כדי ש-Apple תספור את בדיקת ה-SPF, רשמו את
e.<sending domain>כמקור אימייל בנוסף לדומיין השליחה. - בלעדיהן, הדואר עדיין נשלח: שולח המעטפה חוזר לדומיין ברירת המחדל של Amazon SES (
amazonses.com). DKIM עדיין עובר, אבל SPF אינו על הדומיין שלכם.
אם הדומיין שלכם שויך לפני שהרשומות האלה היו קיימות, בקשו מהתמיכה של Joryio את שתי הרשומות החדשות.
טבלת Email Sources של Apple מציגה תוצאת SPF לכל דומיין רשום. דומיין ההחזרות עובר ברגע שרשומת ה-TXT שלו מפורסמת. אם הטבלה מציגה גם בדיקת SPF שנכשלה על דומיין השליחה עצמו (האימייל המנוהל אינו מציב שם רשומת SPF), תוכלו להוסיף את אותה רשומת TXT v=spf1 include:amazonses.com ~all על דומיין השליחה. לדומיין יכולה להיות רק רשומת SPF אחת: אם כבר יש לו רשומה כזו (נפוץ כששולחים מדומיין השורש), הוסיפו include:amazonses.com לרשומה הקיימת במקום ליצור רשומה שנייה.
רישום הדומיינים שלכם אצל Apple
בצעו זאת בחשבון ה-Apple Developer שבבעלותו אפליקציית Sign in with Apple שלכם, כשאתם מחוברים כ-Account Holder או כ-Admin.
- עברו אל Certificates, Identifiers & Profiles.
- לחצו על Services בסרגל הצד.
- תחת Sign in with Apple for Email Communication, לחצו על Configure.
- במקטע Email Sources, לחצו על כפתור ההוספה (+).
- הזינו את הדומיינים ותתי-הדומיינים שלכם כרשימה מופרדת בפסיקים - לדוגמה
acme.com, mail.acme.com- ולחצו על Next. - בדקו את הרשימה ולחצו על Register.
- הטבלה מציגה כל מקור והאם הוא עבר את בדיקת ה-SPF של Apple.
Apple אינה מבקשת מכם להעלות קובץ לשרת שלכם כדי לרשום דומיין.
רישום כתובות בודדות במקום
אם אינכם שולטים ב-DNS של דומיין שממנו אתם שולחים, תוכלו לרשום כתובות From בודדות במקום את הדומיין כולו. בצעו את אותם שלבים, ובשלב 5 הזינו את הכתובות (לדוגמה [email protected], [email protected]). כל כתובת נחשבת כמקור אימייל אחד, כך שכאשר יש לכם שולחים רבים, רישום הדומיין צורך פחות מתוך 32 או 100 המקורות שלכם.
ההודעה עדיין חייבת לעבור SPF או DKIM כפי שמתואר במה Apple בודקת.
בדיקת האימות ב-Joryio
דומייני השליחה שלכם ומצב ה-DNS שלהם מופיעים ב-Analytics → Deliverability, במקטע Domain Health: SPF, DKIM, DMARC, ובאימייל המנוהל גם ה-MX של דומיין ההחזרות (Bounce MX), לכל דומיין משויך, עם Check Now לרענון. ראו אימות DNS.
שני דברים שכדאי לזכור:
- Joryio בודקת רשומות DNS; Apple בודקת כל הודעה. מצב DKIM ירוק ב-Joryio פירושו שרשומות ה-DKIM שלכם מפורסמות. Apple דורשת בנוסף שהדומיין
d=של החתימה יהיה זהה בדיוק לדומיין ה-From, וזה תלוי באופן שבו הספק שלכם חותם. הבדיקה שבהמשך מאשרת זאת. - באימייל המנוהל, SPF מוצג כ-"handled by Amazon SES". Domain Health קורא את ה-SPF בדומיין השליחה עצמו, בעוד ש-SPF של האימייל המנוהל נמצא על דומיין ההחזרות
e.<sending domain>. Domain Health בודק את רשומת ה-MX של דומיין ההחזרות (Bounce MX) אך לא את רשומת ה-SPF TXT שלו. כדי לאמת את ה-SPF, חפשו את רשומת ה-TXT של דומיין ההחזרות ב-DNS, או בדקו אתsmtp.mailfromבהודעת בדיקה (ראו בהמשך).
בדקו לפני שאתם מסתמכים על זה
- השיגו כתובת העברה שבשליטתכם. באייפון, התחברו לאפליקציה שלכם עם Sign in with Apple ובחרו ב-Hide My Email. הכתובת מוצגת בהגדרות חשבון ה-Apple שלכם (באייפון: Settings → השם שלכם → iCloud → Hide My Email, ואז האפליקציה). מאמר התמיכה של Apple Manage your apps with Sign in with Apple מתאר היכן למצוא אותה.
- שלחו אליה אימייל בדיקה מעורך האימייל של הקמפיין או המסע (Send Test), עם השולח שאתם רוצים לבדוק. ראו בדיקת אימייל.
- ודאו שהוא מגיע לתיבת הדואר האמיתית שאליה חשבון ה-Apple מעביר.
- אם הוא לא מגיע, קראו את הכותרות של עותק רגיל. שלחו את אותה בדיקה לתיבת דואר רגילה (למשל Show original ב-Gmail) ובדקו את:
DKIM-Signature: ... d=- חייב להיות בדיוק דומיין ה-From שלכם עבור מסלול ה-DKIM.Authentication-Results: ... smtp.mailfrom=- דומיין המעטפה; הוא חייב להיות רשום אצל Apple ולעבור SPF עבור מסלול ה-SPF.From:- הדומיין שלו חייב להיות רשום אצל Apple.
חזרו על הבדיקה עבור כל דומיין From, ושוב בכל פעם שאתם מוסיפים שולח בדומיין או בתת-דומיין חדש.
איך Joryio מתייחסת לכתובות העברה
- הן כתובות אימייל רגילות. Joryio אינה מזהה, משכתבת או מסננת כתובות
privaterelay.appleid.comאוprivate.icloud.com. הן נשמרות, עוברות אימות, מסוגמנות ומקבלות דיוור כמו כל כתובת אחרת. - כתובת העברה אינה הכתובת האמיתית של האדם. אם אותו אדם מוסר לכם גם את כתובת האימייל האמיתית שלו במקום אחר, שתי הכתובות אינן תואמות. זהו אנשים לפי מזהה המשתמש שלכם ולא לפי כתובת האימייל, כדי ששתיהן יגיעו לפרופיל אחד.
- בפילוח לפי ספק תיבת דואר ב-Analytics → Deliverability, כתובות העברה נספרות תחת Other domains, ולא תחת Apple iCloud, כי הקיבוץ נעשה לפי הדומיין של הנמען.
- החזרות משירות ההעברה מטופלות כמו כל החזרה. אם הספק שלכם מדווח על החזרה משירות ההעברה כקבועה (קשה), Joryio מסמנת את הכתובת כלא תקינה ומפסיקה לשלוח אליה, בכל סביבת העבודה. ראו טיפול בהחזרות.
בעיות נפוצות
הדואר מגיע לכולם חוץ מכתובות העברה.
דומיין ה-From אינו רשום אצל Apple, או שההודעה אינה עוברת אף אחת מהבדיקות של Apple. השוו את הדומיינים של From, d= ו-smtp.mailfrom בהודעת בדיקה למקורות הרשומים שלכם.
זה עבד, ואז הפסיק לעבוד בקמפיין אחד.
סביר שהקמפיין הזה משתמש בשולח בדומיין או בתת-דומיין שלא רשמתם - לדוגמה Custom From ב-promo.acme.com. רשמו אותו.
הטבלה של Apple מציגה שבדיקת ה-SPF נכשלה בדומיין של אימייל מנוהל.
עבור דומיין ההחזרות e.<sending domain>: רשומות ה-MX וה-TXT שלו חסרות - הוסיפו את רשומות ה-DNS לאימייל מנוהל. עבור דומיין השליחה עצמו: האימייל המנוהל אינו מציב שם רשומת SPF; DKIM עדיין עובר, ותוכלו להוסיף את רשומת ה-TXT המתוארת באותו מקטע.
DKIM עובר בכל מקום, אבל שירות ההעברה עדיין מחזיר.
הדומיין d= קרוב לדומיין ה-From אך אינו זהה לו - בדרך כלל דומיין האב (acme.com) חותם על דואר מתת-דומיין (mail.acme.com), או הדומיין של הספק עצמו. הגדירו DKIM על דומיין ה-From המדויק אצל הספק שלכם.
לאחר תיקון הרישום, חלק מכתובות ההעברה עדיין לא מקבלות דיוור. הודעות שהוחזרו לפני התיקון עשויות היו לסמן את הכתובות האלה כלא תקינות, ו-Joryio אינה מסירה החזרה קשה מעצמה. נקו אותה באיש הקשר: פתחו את הפרופיל תחת Users, לחצו על Edit בכרטיס Subscriptions, סמנו את Clear bounce status and mark email as valid ושמרו. אפשר לעשות את אותו הדבר גם דרך ה-API עם נקודת הקצה לניקוי החזרה. שליחות בדיקה לכתובות האלה נדחות עד שההחזרה מנוקה.
אדם אחד אף פעם לא מקבל דואר, וכל השאר כן. ייתכן שהאדם כיבה את ההעברה עבור האפליקציה שלכם בחשבון ה-Apple שלו, או שינה את הכתובת שאליה היא מועברת. זו בחירה שלו ואי אפשר לשנות אותה מהצד שלכם.
נגמרו לכם מקורות האימייל. רשמו דומיינים במקום כתובות בודדות, והסירו מקורות שאינכם שולחים מהם עוד.
מקורות
- Apple Developer: Configure private email relay service
- Apple Developer News: Update: New domain for Sign in with Apple (24 באוגוסט 2026)
- Apple Support: Manage your apps with Sign in with Apple ו-How to use Hide My Email with Sign in with Apple
קישורים קשורים
- תצורת אימייל - זהויות שולח ו-Custom From
- ניטור יכולת מסירה - מצב אימות הדומיינים והחזרות
- ניהול הרשמות - טיפול בהחזרות וניקוין