SPF, DKIM & DMARC für Apple iCloud+ Custom Email Domain.
Mit der iCloud+ Custom Email Domain von Apple können Sie über iCloud Mail unter Ihrer eigenen Domain (sie@ihredomain.com) senden und empfangen, und Apple authentifiziert diese E-Mails mit einer Reihe von DNS-Einträgen, die während der Einrichtung für Sie generiert werden: zwei MX-Einträge, die Ihr gesamtes Postfach an iCloud übergeben, ein apple-domain TXT-Eintrag, der den Nachweis Ihres Domain-Besitzes erbringt, ein SPF-Eintrag, der Apples gemeinsam genutztes include:icloud.com hinzufügt, und ein einzelner DKIM-CNAME (sig1._domainkey), der die Signierung an Apple delegiert. Es gibt keinen öffentlichen DKIM-Schlüssel zum Einfügen und nichts zu rotieren — Apple verwahrt den privaten Schlüssel hinter diesem CNAME. Der einzige Eintrag, den Apple NICHT generiert, ist DMARC; das ist das Element, das Sie selbst hinzufügen, um aus SPF und DKIM echten Spoofing-Schutz zu machen.
Warum Apple iCloud+ Custom Email Domain authentifizieren?
Diese Einträge bei iCloud richtig zu setzen, hat höhere Einsätze als bei einem reinen Sendedienst, denn Custom Email Domain macht iCloud zu Ihrem Postfach-Host und nicht nur zu einem ausgehenden Relay — dieselbe MX-Änderung, die Ihnen das Senden ermöglicht, leitet auch jede eingehende Nachricht für die Domain an Apple um. Konfigurieren Sie es falsch, landen Sie nicht bloß im Spam, sondern empfangen überhaupt keine E-Mails mehr. Auf der Zustellbarkeitsseite gelten weiterhin die modernen Regeln: Seit Februar 2024 verlangen Gmail und Yahoo, dass jeder Absender SPF oder DKIM besteht (und Massenversender zusätzlich DMARC mit Alignment veröffentlichen), und Microsoft hat 2025 damit begonnen, ähnliche Prüfungen für Versender mit hohem Volumen durchzusetzen. iCloud ist hier einer der guten Fälle — weil es Ihr tatsächlicher Postfach-Host ist, wird ausgehende E-Mail als Ihre Domain DKIM-signiert und SPF löst über Apples autorisierte IPs auf, sodass beide Mechanismen sich zu ihredomain.com ausrichten und einen DMARC-Pass speisen können. Aber Apple veröffentlicht immer nur SPF und DKIM; bis Sie den DMARC-Eintrag selbst hinzufügen, haben Empfänger keine Richtlinie zum Durchsetzen und Ihre Domain bleibt fälschbar. Beachten Sie außerdem, dass iCloud+ Custom Email Domain ein persönliches Postfach für kleine Teams ist (jede kostenpflichtige iCloud+ Speicherstufe enthält es) und keine Marketing- oder Transaktionsplattform — authentifizieren Sie es als Ihr menschliches Postfach und belassen Sie Massenversand auf einem dedizierten ESP.
Die SPF-Realität bei Apple iCloud+ Custom Email Domain
iCloud ist ein echter "include"-Anbieter: Sie fügen einen gemeinsam genutzten Mechanismus, include:icloud.com, zum einzelnen SPF-TXT-Eintrag Ihrer Root-Domain hinzu, und Apples Einrichtungsassistent schreibt ihn als v=spf1 include:icloud.com ~all. Dieser Teil ist Standard. Was fast jede Anleitung falsch macht, sind die Kosten. include:icloud.com ist KEIN günstiger Include mit nur einem Lookup — es ist einer der teuersten gemeinsam genutzten Includes, die gebräuchlich sind. Lösen Sie ihn auf, so lautet der SPF-Eintrag von icloud.com v=spf1 redirect=_spf.icloud.com; dieser redirect zeigt auf _spf.icloud.com, dessen Eintrag v=spf1 include:_nets0.icloud.com include:_nets1.icloud.com include:_nets2.icloud.com ~all lautet (jeder _nets-Eintrag enthält nur ip4/ip6-Bereiche, sodass die Kette dort endet). Zählt man gemäß RFC 7208, ergibt das den Include selbst (1) + den redirect (1) + drei verschachtelte _nets-Includes (3) = FÜNF Ihrer 10 zulässigen SPF-DNS-Lookups, die allein für iCloud aufgewendet werden. Wenn Sie außerdem über Google Workspace, Microsoft 365 oder SendGrid senden, können Sie schnell den 10-Lookup-PermError auslösen; behandeln Sie den Include von iCloud daher als schweren Posten und halten Sie den Rest Ihres SPF schlank. Zwei weitere Regeln: Behalten Sie genau einen SPF-Eintrag auf der Domain (führen Sie include:icloud.com in Ihre bestehende v=spf1 Zeile zusammen, statt einen zweiten TXT zu veröffentlichen — zwei SPF-Einträge ergeben einen automatischen PermError), und verwechseln Sie die Include-Form nicht mit der redirect=icloud.com Form, die einige ältere Tutorials zeigen. redirect=icloud.com ersetzt Ihre gesamte SPF-Richtlinie durch die von Apple und lässt jeden anderen Absender stillschweigend fallen (und kostet dieselben 5 Lookups, bringt Ihnen also nichts), sodass es nur dann korrekt ist, wenn iCloud das EINZIGE ist, das als Ihre Domain sendet. Apple endet mit ~all (softfail), was der richtige Standard ist, während Sie bestätigen, dass jeder Absender erfasst ist.
Zwei Wege zur Einrichtung
include:icloud.com (Apples Standard — andere Absender behalten)
- Was Apples Einrichtungsassistent tatsächlich generiert: v=spf1 include:icloud.com ~all
- Koexistiert mit anderen Absendern — Sie können Google Workspace, M365, SendGrid usw. in dieselbe Zeile zusammenführen
- Kostet 5 Ihrer 10 SPF-DNS-Lookups (redirect + drei verschachtelte _nets-Includes), also planen Sie entsprechend
- Endet auf ~all softfail, dem sicheren Standard, während Sie bestätigen, dass jeder Absender autorisiert ist
redirect=icloud.com (nur wenn iCloud Ihr EINZIGER Absender ist)
- Ersetzt Ihre GESAMTE SPF-Richtlinie durch die von Apple — alles, was nicht im Eintrag von icloud.com steht, schlägt hart fehl
- Bricht stillschweigend jeden anderen Dienst, der als Ihre Domain sendet (Newsletter, Formulare, CRM)
- Keine Lookup-Ersparnis — er löst dieselbe 5-Lookup-Kette von icloud.com auf, nur ohne jede Flexibilität
- Verwenden Sie es nur bei einer Domain, bei der iCloud Mail die einzige, exklusive Sendequelle ist
Schritt für Schritt
- 1
Bestätigen Sie, dass Sie iCloud+ haben
Custom Email Domain ist ein iCloud+ Feature, Sie benötigen also eine kostenpflichtige iCloud+ Stufe (jeder Speicherplan qualifiziert sich). Der Kontoorganisator kann eine Domain mit den Mitgliedern der Familienfreigabe teilen, oder Sie richten sie nur für sich selbst ein.
- 2
Custom Email Domain öffnen
Im Web melden Sie sich unter icloud.com an, öffnen Sie die Konto-/Mail-Einstellungen und wählen Sie Custom Email Domain (icloud.com/settings listet es direkt auf). Auf einem iPhone/iPad: Einstellungen → tippen Sie auf Ihren Namen → iCloud → scrollen Sie zu Custom Email Domain unter iCloud+ Funktionen.
- 3
Ihre Domain hinzufügen
Wählen Sie, ob die Domain für "Nur Sie" oder "Sie und andere Personen" (Familienfreigabe) ist, und geben Sie dann Ihre Domain ein, z. B. ihredomain.com. iCloud+ erlaubt bis zu 5 Domains, mit bis zu 3 Adressen pro Person und Domain.
- 4
Erstellen Sie die E-Mail-Adressen, die Sie nutzen werden
Fügen Sie die Postfächer hinzu, die Sie auf der Domain möchten (sie@ihredomain.com, hallo@ihredomain.com, …). Apple veröffentlicht die DNS-Anweisungen erst, wenn Sie mindestens eine Adresse definiert haben — dies ist eine Postfach-Migration, nicht nur ausgehende Signierung, also legen Sie Ihre Adressen im Voraus fest.
- 5
Ihre DNS-Einträge abrufen
Apple zeigt die hinzuzufügenden Einträge — zwei MX, einen apple-domain TXT-Verifizierungswert, die SPF-Zeile und den sig1._domainkey DKIM-CNAME. Verwenden Sie "E-Mail-Anweisungen", um sie sich selbst zuzusenden, oder kopieren Sie jeden Wert. Apples Anweisungen führen eine TTL von 3600 (1 Stunde) auf; jede Standard-TTL ist in Ordnung.
- 6
MX auf iCloud umleiten
Bei Ihrem DNS-Host ENTFERNEN Sie alle bestehenden MX-Einträge und fügen Sie mx01.mail.icloud.com und mx02.mail.icloud.com hinzu, beide mit Priorität 10. Das ist der wichtige Schritt: Er verschiebt ALLE eingehenden E-Mails der Domain zu iCloud, also führen Sie ihn nur aus, wenn Sie bereit sind, iCloud zum Postfach für diese Adressen zu machen.
- 7
Den Verifizierungs-TXT und SPF-Eintrag hinzufügen
Auf der Root (Host @): Fügen Sie einen TXT-Eintrag mit Apples apple-domain=… Verifizierungswert hinzu und fügen Sie den SPF-Eintrag v=spf1 include:icloud.com ~all hinzu oder FÜHREN Sie ihn ZUSAMMEN. Wenn bereits ein v=spf1 Eintrag existiert, falten Sie include:icloud.com in diese eine Zeile — veröffentlichen Sie niemals einen zweiten SPF-TXT.
- 8
Den DKIM-CNAME hinzufügen
Erstellen Sie einen CNAME mit Host sig1._domainkey und Ziel sig1.dkim.ihredomain.com.at.icloudmailadmin.com (Apple setzt Ihre echte Domain in das Ziel ein). Wenn Ihr DNS bei Cloudflare liegt, stellen Sie ihn auf DNS only (graue Wolke) — ein proxied/orange-Wolke-Eintrag oder CNAME-Flattening bricht die DKIM-Auflösung.
- 9
Ihren eigenen DMARC-Eintrag veröffentlichen
Apple erstellt kein DMARC. Fügen Sie einen TXT-Eintrag beim Host _dmarc mit v=DMARC1; p=none; rua=mailto:dmarc@ihredomain.com hinzu. p=none ist reines Monitoring, sodass nichts blockiert wird, während Sie bestätigen, dass iCloud-E-Mails ausgerichtetes SPF und DKIM bestehen.
- 10
Einrichtung abschließen und eine echte Nachricht testen
Zurück in iCloud klicken Sie auf Einrichtung abschließen, damit Apple die Einträge verifiziert (die Verbreitung kann Minuten bis einige Stunden dauern). Senden Sie dann eine Nachricht von Ihrer neuen Adresse an ein Gmail-Konto, öffnen Sie ⋮ → Original anzeigen und bestätigen Sie SPF: PASS, DKIM: PASS (signed-by ihredomain.com, Selector sig1) und DMARC: PASS. Senden Sie außerdem eine Nachricht AN die Adresse, um zu bestätigen, dass iCloud nun empfängt.
Einzutragende Einträge
Apple iCloud+ Custom Email Domain erzeugt die genauen Werte in seinem Einrichtungsassistenten — diese zeigen die Struktur dessen, was Sie bei Ihrem DNS-Anbieter hinzufügen werden.
| Typ | Host | Wert |
|---|---|---|
| MX | @ | mx01.mail.icloud.comPriorität 10 — leitet alle eingehenden E-Mails an iCloud um (bestehende MX zuerst entfernen) |
| MX | @ | mx02.mail.icloud.comPriorität 10 — zweiter iCloud-Mailserver |
| TXT | @ | apple-domain=Ab12Cd34Ef56Gh78Beispielhaft — Apple generiert pro Domain einen eindeutigen Verifizierungswert; behalten Sie ihn veröffentlicht, Apple prüft ihn erneut |
| TXT | @ | v=spf1 include:icloud.com ~allFühren Sie ihn in Ihre einzelne SPF-Zeile zusammen, falls eine existiert. include:icloud.com kostet 5 DNS-Lookups (redirect + 3 verschachtelte _nets-Includes) |
| CNAME | sig1._domainkey | sig1.dkim.yourdomain.com.at.icloudmailadmin.comBeispielhaft — Apple fügt Ihre echte Domain ein. Der DKIM-Schlüssel wird von Apple verwahrt/rotiert; belassen Sie ihn auf DNS-only (kein Cloudflare-Proxy) |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comDies fügen Sie hinzu — Apple nicht. Ein DMARC-Eintrag pro Domain; starten Sie bei p=none, dann verschärfen |
Behalten Sie genau einen SPF-TXT-Eintrag (v=spf1) auf Ihrer Root-Domain — führen Sie jeden Absender darin zusammen. Zwei SPF-Einträge sind bereits an sich ein Fehler.
Das Budget von 10 Lookups
SPF ist auf harte 10 DNS-Lookups begrenzt — wird dieser Wert überschritten, gibt SPF einen permerror zurück und validiert überall nicht mehr. Hier sehen Sie, was die Einrichtung von Apple iCloud+ Custom Email Domain von diesem Budget verbraucht.
Apple iCloud+ Custom Email Domain verbraucht 5 Ihrer 10 Lookups; ip4:- und ip6:-Mechanismen sind kostenlos.
DKIM
DKIM für iCloud ist delegiert, nicht eingefügt. Apple lässt Sie einen einzelnen CNAME veröffentlichen — Host sig1._domainkey.ihredomain.com zeigt auf sig1.dkim.ihredomain.com.at.icloudmailadmin.com (Apple setzt während der Einrichtung Ihre echte Domain in dieses Ziel ein). Es gibt keinen v=DKIM1; p=… öffentlichen Schlüssel zum Kopieren und keinen Selector zum Erfinden: Apple verwahrt den privaten Schlüssel hinter diesem CNAME, signiert Ihre ausgehende iCloud-E-Mail mit d=ihredomain.com unter Verwendung des sig1-Selectors und kann den veröffentlichten Schlüssel auf seiner Seite rotieren, ohne dass Sie jemals wieder DNS bearbeiten müssen. Zwei praktische Punkte. Erstens stellt iCloud genau EINEN Selector bereit, sig1 — wenn ein Tutorial Ihnen sagt, Sie sollten auch sig2 hinzufügen, ist das nicht Teil von Apples aktuellem Ablauf; ein einzelner sig1-CNAME ist korrekt und vollständig. Zweitens muss er, weil es ein CNAME auf Apples Hostname ist, wie ein normaler delegierter Eintrag auflösen: Wenn Ihr DNS bei Cloudflare liegt, stellen Sie ihn auf DNS only (graue Wolke) und vermeiden Sie CNAME-Flattening oder jeden Proxy, der das Ziel umschreiben würde, da dies die Delegation bricht und DKIM stillschweigend nicht mehr signiert. DKIM ist hier der Mechanismus, der sich am zuverlässigsten zu Ihrer Domain ausrichtet (das d= ist ihredomain.com), sodass er einen DMARC-Pass trägt, selbst wenn eine Nachricht weitergeleitet wird und SPF bricht — bringen Sie diesen CNAME richtig ein.
DMARC
DMARC ist der Eintrag, den Apple nie für Sie erstellt, und ohne ihn ergeben das gerade veröffentlichte SPF und DKIM keine durchsetzbare Richtlinie. Fügen Sie einen TXT-Eintrag unter _dmarc.ihredomain.com mit v=DMARC1; p=none; rua=mailto:dmarc@ihredomain.com hinzu. p=none ist reines Monitoring — es ändert nichts an der Zustellung, bittet Empfänger aber, Ihnen aggregierte (rua) Berichte zuzusenden, damit Sie beobachten können, wie iCloud-E-Mails authentifizieren. Weil iCloud mit DKIM als Ihre eigene Domain signiert und über Apples SPF-autorisierte IPs sendet, sollten Sie schnell saubere, ausgerichtete Passes sehen. Lassen Sie die Berichte ein bis zwei Wochen laufen, bestätigen Sie, dass iCloud plus alle anderen legitimen Absender (ein Newsletter-Tool, ein Kontaktformular, ein weiterer Postfach-Anbieter) alle ausgerichtet bestehen, verschärfen Sie dann auf p=quarantine und schließlich p=reject, um Spoofing tatsächlich zu stoppen. Behalten Sie genau einen _dmarc-Eintrag für die gesamte Domain, unabhängig davon, wie viele Dienste Sie nutzen — fügen Sie niemals einen zweiten DMARC-Eintrag speziell für iCloud hinzu. Wenn Sie DNS irgendwo hosten, wo Sie auch die Berichte empfangen können, richten Sie rua auf ein Postfach, das Sie tatsächlich lesen, oder speisen Sie sie in einen DMARC-Analyzer ein.
Prüfen, ob es wirklich funktioniert hat
Verlassen Sie sich nicht allein auf Apples grünes Häkchen bei "Einrichtung abschließen" — bestätigen Sie die Authentifizierung an einer echten Nachricht. Senden Sie von Ihrer neuen iCloud-Adresse an ein Gmail-Konto, öffnen Sie die Nachricht und wählen Sie ⋮ → Original anzeigen: Sie wollen SPF: PASS, DKIM: PASS mit signed-by: ihredomain.com und Selector sig1 sowie DMARC: PASS — alle auf Ihre Domain verweisend, nicht auf icloud.com. Weil iCloud nun auch Ihr empfangender Host ist, senden Sie auch eine Nachricht AN die Adresse und stellen Sie sicher, dass sie ankommt, was beweist, dass die MX-Änderung gegriffen hat. Für eine reine Prüfung sollte dig TXT ihredomain.com Ihren einzelnen v=spf1 include:icloud.com ~all zeigen, dig CNAME sig1._domainkey.ihredomain.com sollte zu sig1.dkim.ihredomain.com.at.icloudmailadmin.com auflösen, und dig TXT _dmarc.ihredomain.com sollte Ihre Richtlinie zurückgeben. Lassen Sie die Domain anschließend durch Qualisends Domain-Health-Check laufen, um zu bestätigen, dass jeder Eintrag auflöst und — wichtig für iCloud — dass Ihr SPF unter dem 10-Lookup-Limit bleibt, angesichts der 5 Lookups, die include:icloud.com verbraucht. Sobald aggregierte Berichte eintreffen, ziehen Sie einen in den DMARC-Report-Analyzer, um zu bestätigen, dass iCloud als ausgerichtete, vollständig bestehende Quelle auftaucht.
Häufige Stolperfallen
- Bricht die Authentifizierung
include:icloud.com ist teuer: Es kostet 5 Ihrer 10 SPF-DNS-Lookups, nicht 1. icloud.com leitet per redirect auf _spf.icloud.com um, das _nets0/_nets1/_nets2.icloud.com verschachtelt. Kombinieren Sie es mit Google Workspace oder Microsoft 365 und Sie können den 10-Lookup-PermError auslösen — halten Sie den Rest Ihres SPF schlank und prüfen Sie den Zähler.
- Abdeckung
Dies ist eine vollständige Postfach-Migration, nicht nur ausgehende Signierung. Die mx01/mx02.mail.icloud.com Einträge leiten ALLE eingehenden E-Mails der Domain zu iCloud um. Sie können dieselben Adressen nicht auf iCloud und einen anderen Anbieter aufteilen — fügen Sie den MX erst hinzu, wenn Sie bereit sind, dass iCloud diese E-Mails empfängt.
- DNS-Einrichtung
Verwenden Sie die Include-Form, nicht redirect=icloud.com. redirect ersetzt Ihre gesamte SPF-Richtlinie durch die von Apple und lässt jeden anderen Absender stillschweigend fallen — und es kostet dieselben 5 Lookups, hat also keinen Vorteil. Es ist nur korrekt, wenn iCloud der einzige, exklusive Absender für die Domain ist; andernfalls beginnen Ihre Formulare, Newsletter und CRM, bei SPF zu scheitern.
- DNS-Einrichtung
Der DKIM-Eintrag ist ein CNAME, den Sie nicht proxen oder flatten dürfen. Stellen Sie sig1._domainkey bei Cloudflare auf DNS only (graue Wolke); ein Orange-Wolke-Proxy oder CNAME-Flattening schreibt das Ziel um und DKIM signiert nicht mehr. Apple verwahrt den Schlüssel — Sie fügen niemals einen öffentlichen Schlüssel ein oder rotieren ihn.
- DNS-Einrichtung
Apple veröffentlicht SPF und DKIM, aber niemals DMARC. Ohne Ihren eigenen _dmarc-Eintrag gibt es keine durchzusetzende Richtlinie und die Domain bleibt fälschbar — fügen Sie zum Start v=DMARC1; p=none hinzu, dann verschärfen.
- DNS-Einrichtung
iCloud stellt einen einzelnen DKIM-Selector bereit (sig1). Wenn eine Anleitung sagt, Sie sollten auch sig2 hinzufügen, ist das nicht Apples aktueller Ablauf — ein einzelner sig1-CNAME ist korrekt.
- Bricht die Authentifizierung
Behalten Sie genau einen SPF-TXT-Eintrag. Führen Sie include:icloud.com in Ihre bestehende v=spf1 Zeile zusammen; zwei separate SPF-Einträge ergeben einen automatischen PermError, der SPF vollständig scheitern lässt.
- Abdeckung
iCloud+ Custom Email Domain ist ein persönliches Postfach für kleine Teams, kein ESP. Apple begrenzt das Sendevolumen und untersagt Massen- und kommerzielle Massen-E-Mails, leiten Sie also keine Marketing- oder hochvolumigen Transaktionskampagnen darüber — nutzen Sie dafür eine dedizierte Sendeplattform.
- DNS-Einrichtung
Löschen Sie den apple-domain TXT nach der Einrichtung nicht. Apple prüft den Domain-Besitz regelmäßig anhand dessen erneut; das Entfernen kann die Domain deaktivieren und Ihre E-Mails lahmlegen.
Erstellen Sie Ihren SPF-Eintrag
Apple iCloud+ Custom Email Domain ist unten bereits vorausgewählt. Fügen Sie alle weiteren Plattformen hinzu, über die Sie versenden, und veröffentlichen Sie anschließend den einen zusammengeführten Eintrag.
This domain's own servers
Authorize the domain itself, if it sends mail directly (not through a platform above).
Other senders & IPs
Anything not in the list — another provider's SPF host, or specific IP addresses.
We add the include: prefix — enter the hostname your provider documents.
Policy for everyone else
What receivers should do with mail from any server not listed above (the all mechanism).
- Publish it as a TXT record at your root domain — host @ (the bare domain), value the full string above.
- Keep only one SPF record per domain. Merge every sending source into this single line — a second TXT record starting v=spf1 makes both invalid.
- Stay at or under 10 DNS lookups. Each include:, a and mx counts, and an include can trigger more lookups inside itself — ip4: and ip6: are free.
Authentication published? The next step is sending to a clean, verified list.
Verify a listApple iCloud+ Custom Email Domain SPF — FAQ
Weiterführende Lektüre
Sobald der Eintrag veröffentlicht ist, prüfen Sie mit dem Domain-Health-Check, ob alles korrekt aufgelöst wird, und lesen Sie mit der DMARC-Berichtsanalyse nach, wer in Ihrem Namen versendet. Durchsuchen Sie alle Versandquellen im Generator. Authentifizierung ist allerdings nur die halbe Zustellbarkeit — eine gelistete Absender-IP oder -Domain bringt Sie unabhängig davon, wie sauber Ihr SPF ist, im Spam-Ordner unter, deshalb lohnt es sich, mit Blacklist-Überwachung die Blacklists im Blick zu behalten.
Authentifiziert — jetzt die Liste sauber halten
SPF, DKIM und DMARC zu bestehen bringt Sie in den Posteingang; eine saubere Liste hält Sie dort. Verifizieren Sie Ihre — starten Sie kostenlos mit 100 Credits, ohne Kreditkarte.