imported>PerfektesChaos: tk k

2026-01-28T11:25:20Z

tk k

Neue Seite

'''DomainKeys Identified Mail''' ('''DKIM''') ist ein [[Identifikationsprotokoll]] zur Sicherstellung der [[Authentizität]] von [[E-Mail]]-Absendern. Es wurde konzipiert, um bei der Eindämmung unerwünschter E-Mails wie [[Spam]] oder [[Phishing]] zu helfen.

== Funktionsweise ==
DKIM basiert auf [[Asymmetrisches Kryptosystem|asymmetrischer Kryptographie]]. Die E-Mail wird vom sendenden [[Mail Transfer Agent]] (MTA) mit einer [[Digitale Signatur|digitalen Signatur]] versehen, die der empfangende MTA anhand des [[Öffentlicher Schlüssel|öffentlichen Schlüssels]], der über das [[Domain Name System]] (DNS) bei der [[Domain (Internet)|Absender-Domain]] abrufbar ist, verifizieren kann. Schlägt dies fehl, hat der empfangende MTA oder der empfangende [[E-Mail-Programm|Mail User Agent]] die Möglichkeit, die E-Mail zu verweigern oder auszusortieren.

Um eine E-Mail mit DKIM zu signieren, wird der Inhalt zunächst in ein einheitliches Format abgebildet ({{enS|canonicalization}}). Mit einer [[Kryptographische Hashfunktion|kryptographischen Hashfunktion]] wird ein Hashwert berechnet, der sich über den vereinheitlichten Inhalt der E-Mail erstreckt ({{enS|body hash}}). Über diesen Hashwert, sowie vom Sender ausgewählte Header-Zeilen, die vor einer Modifikation geschützt werden sollen, wird ein weiterer Hashwert berechnet, der mit einem Public-Key-Verfahren signiert wird. Der Body-Hashwert und die Signatur werden mit [[Base64]] kodiert und zusammen mit weiteren Parametern in einem neuen [[Header (E-Mail)|Header]] namens „DKIM-Signature“ in die E-Mail eingefügt.<ref name="RFC6376" /> Der so entstandene Header besteht ausschließlich aus [[American Standard Code for Information Interchange|ASCII]]-Zeichen, was für den E-Mail-Versand über das [[Simple Mail Transfer Protocol]] vorausgesetzt wird.

Als Hashfunktion kommt [[SHA-256]] zum Einsatz. Ursprünglich wurde [[SHA-1]] verwendet, was jedoch aufgrund seiner Sicherheitsschwächen seit 2018 nicht mehr mit dem DKIM-Standard konform ist.<ref name="RFC8301" /> Als Signaturverfahren kommen [[RSA-Kryptosystem|RSA]] (1024–4096 bit)<ref name="RFC8301" /> oder [[Ed25519]]<ref name="RFC8463" /> zum Einsatz. Beide Signaturverfahren können nebeneinander eingesetzt werden, sodass eine E-Mail mehrere DKIM-Signaturen enthalten kann. Die Signierung mit RSA ist verpflichtend.<ref name="RFC8301" />

Für die Verifikation einer DKIM-Signatur wiederholt der Empfänger die Hashwert-Berechnung über den Inhalt der empfangenen E-Mail und vergleicht ihn mit dem Base64-dekodierten Body-Hashwert aus dem „DKIM-Signature“-Header. Anschließend ruft der Empfänger über das Domain Name System den öffentlichen Schlüssel des Absenders ab. Der Domainname ergibt sich aus den Parametern der „DKIM-Signature“ (Absender-Domain und Selektor). Mit dem öffentlichen Schlüssel wird nun die Signatur verifiziert.<ref name="RFC6376" /> Falls die Signaturprüfung erfolgreich ist, stammt die E-Mail tatsächlich von der angegebenen Absender-Domain und wurde auf dem Weg der Zustellung nicht durch Dritte verändert. Das DNS dient bei DKIM als [[Vertrauensanker]] und [[Public-Key-Infrastruktur]].

'''Beispiel'''
<pre>
"k=rsa; t=s; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDDmzRmJRQxLEuyYiyMg4suA2Sy
MwR5MGHpP9diNT1hRiwUd/mZp1ro7kIDTKS8ttkI6z6eTRW9e9dDOxzSxNuXmume60Cjbu08gOyhPG3
GfWdg7QkdN6kR4V75MFlw624VY35DaXBvnlTJTgRg/EW72O1DiYVThkyCgpSYS8nmEQIDAQAB"
</pre>

== Abgrenzung ==
Bei DKIM handelt es sich um einen Authentifizierungsmechanismus, sodass ein Empfänger feststellen kann, ob eine E-Mail tatsächlich von der angegebenen Domain versendet wurde. Dies schützt vor [[E-Mail-Spoofing]].

DKIM dient nicht dazu, [[Spam]] zu erkennen. Durch die Nachvollziehbarkeit der Absender-Domain kann es aber verwendet werden, Bewertungssysteme und Filtertechniken von [[Spamfilter]]n wirkungsvoller zu gestalten. Zudem kann DKIM den Datendiebstahl durch [[Phishing]] begrenzen, da teilnehmende Mailversender ihre E-Mails als authentisch beglaubigen.

Ein Nachteil von DKIM ist die fehlende Aussagekraft bei Fehlen einer Signatur. Es ist für den Empfänger nicht ersichtlich, ob der Absender DKIM nicht einsetzt oder ob es sich um Spoofing handelt. Diese Informationslücke wird mit [[DMARC]] geschlossen. Der Absender kann eine Policy definieren, wie der Empfänger mit E-Mails umgehen soll, die keine gültige DKIM-Signatur enthalten.

== Standardisierung ==
Das Verfahren wurde von [[Altaba#Unternehmensgeschichte|Yahoo]] unter dem Namen ''DomainKeys'' entwickelt und bei der [[Internet Engineering Task Force|IETF]] zur Standardisierung eingereicht. Die IETF veröffentlichte im Jahr 2007 das historische Verfahren DomainKeys als <nowiki>RFC 4870</nowiki><ref>{{RFC-Internet |RFC=4870 |Titel=Domain-Based Email Authentication Using Public Keys Advertised in the DNS (DomainKeys) |Datum=2007}}</ref> und am selben Tag den Nachfolger DomainKeys Identified Mail als <nowiki>RFC 4871</nowiki>.<ref>{{RFC-Internet |RFC=4871 |Titel=DomainKeys Identified Mail (DKIM) Signatures |Datum=2007}}</ref><ref>[https://www.heise.de/newsticker/meldung/RFC-gegen-Spam-133080.html RFC gegen Spam.] heise online.</ref> Im Jahr 2009 folgte mit <nowiki>RFC 5672</nowiki><ref>{{RFC-Internet |RFC=5672 |Titel=<nowiki>RFC 4871</nowiki> DomainKeys Identified Mail (DKIM) Signatures – Update |Datum=2009-09}}</ref> eine Aktualisierung. Mit der Veröffentlichung von <nowiki>RFC 6376</nowiki><ref name="RFC6376" /> im Jahr 2011 erhielt DKIM den Status eines [[Internetstandard]]s.

Derzeit gültig ist die folgende Fassung mit vier Ergänzungen (Updates):
* {{RFC-Internet |RFC=6376 |Titel=DomainKeys Identified Mail (DKIM) Signatures |Datum=2011}}
* {{RFC-Internet |RFC=8301 |Titel=Cryptographic Algorithm and Key Usage Update to DomainKeys Identified Mail (DKIM) |Datum=2018}}
* {{RFC-Internet |RFC=8463 |Titel=A New Cryptographic Signature Method for DomainKeys Identified Mail (DKIM) |Datum=2018}}
* {{RFC-Internet |RFC=8553 |Titel=DNS AttrLeaf Changes: Fixing Specifications That Use Underscored Node Names |Datum=2019}}
* {{RFC-Internet |RFC=8616 |Titel=Email Authentication for Internationalized Mail |Datum=2019}}

Yahoo hält ein Patent auf das Verfahren<ref>{{Patent| Land=US| V-Nr=6986049| Code=B2| Titel=Method and system for authenticating a message sender using domain keys| A-Datum=2003-09-24| V-Datum=2006-01-10| Anmelder=Yahoo Inc| Erfinder=Mark Delany}}</ref> und stellt es unter zwei Lizenzen zur kostenlosen Nutzung zur Verfügung. Es kann wahlweise unter den Bedingungen der [[GNU General Public License|GPL]] 2.0 oder den Bedingungen des proprietären „Yahoo DomainKeys Patent License Agreement“ verwendet werden.<ref>[http://antispam.yahoo.com/domainkeys#license DomainKeys Lizenzierung.] antispam.yahoo.com</ref>

Ein zu DKIM alternatives Verfahren war das von [[Microsoft]] entwickelte [[Sender ID]], welches ebenfalls patentiert war. Die Standardisierung von Sender ID scheiterte in der IETF, weil die Lizenz von Microsoft keine Nutzung durch [[freie Software]] unter einer Open-Source-Lizenz ermöglichte.

== Vorteile ==
Ein Vorteil von DKIM für Empfänger besteht darin, dass Absenderdomains zuverlässig legitime E-Mails kennzeichnen können. Dadurch werden Blacklists und [[Positivliste|Whitelists]] effektiver, was unter anderem das Erkennen von [[Phishing]] erleichtert.<ref name="Searching">{{Internetquelle |url=https://circleid.com/posts/20090317_searching_for_truth_in_dkim_part_3 |titel=Searching for Truth in DKIM: Part 3 of 5 |werk=circleid.com |sprache=en |abruf=2025-07-28}}</ref>

DKIM filtert keine Nachrichten, sondern dient der Kennzeichnung. Eine weite Verbreitung kann jedoch das Fälschen von Absenderadressen – eine gängige Methode bei [[Spam]] – verhindern. So lassen sich andere Filtermethoden wie Reputationssysteme gezielter einsetzen. Signierte Mails vertrauenswürdiger Domains können anhand von Whitelists erkannt und eventuell ohne Filterung zugestellt werden.<ref name="Searching" />

DKIM kann beim Schutz vor Phishing helfen, insbesondere bei häufig betroffenen Domains. Das Fehlen einer gültigen Signatur kann auf Fälschung hindeuten. Die frühere Option Author Domain Signing Practices (ADSP) wurde 2013 aufgegeben.<ref>{{Internetquelle |url=https://datatracker.ietf.org/doc/status-change-adsp-rfc5617-to-historic/ |titel=Change the status of ADSP (RFC 5617) to Historic |werk=ietf.org |sprache=en |abruf=2025-07-28}}</ref> Stattdessen wird heute häufig [[DMARC]] verwendet, das angibt, welche Techniken (z. B. [[Sender Policy Framework|SPF]] und DKIM) eine Domain einsetzt.<ref>{{Internetquelle |url=https://dmarc.org/wiki/FAQ#What_happens_if_a_sender_uses_DMARC_and_ADSP.3F |titel=FAQ |werk=DMARC Wiki |abruf=2025-07-28}}</ref><ref name="google">{{Internetquelle |url=https://support.google.com/a/answer/2466580?hl=en&visit_id=638892846835300916-628356069&rd=1 |titel=Set up DMARC |werk=support.google.com |abruf=2025-07-28}}</ref> Dienste wie [[eBay]] und [[PayPal]] verlangen über DMARC die Ablehnung nicht signierter Nachrichten.<ref name="google" />

DKIM ist mit der bestehenden E-Mail-Infrastruktur kompatibel, da es auf [[Domain Name System|DNS]]-Einträgen und einem zusätzlichen Header nach <nowiki>RFC 5322</nowiki> basiert.<ref>{{RFC-Internet |RFC=5585 |Titel=DomainKeys Identified Mail (DKIM) Service Overview |Datum=2009-07 |Autor=Dave Crocker, Phillip Hallam-Baker, Tony Hansen}}</ref> Es funktioniert auch mit Systemen ohne DKIM-Unterstützung und ist mit Standards wie [[S/MIME]], [[OpenPGP]], [[Domain Name System Security Extensions|DNSSEC]] und SPF vereinbar.

Da für jede Nachricht eine kryptografische Signatur erzeugt wird, verursacht DKIM zusätzlichen Rechenaufwand. Dies erschwert den massenhaften Versand von Spam und erinnert in seiner Wirkung an [[Hashcash]], wobei die Verifikation auf Empfängerseite sehr ressourcenschonend ist.<ref>{{Internetquelle |url=http://blogs.office.com/b/microsoft-outlook/archive/2007/07/05/postmarking-helping-the-fight-against-spam.aspx |titel=Outlook Blog – Postmarking: helping the fight against SPAM |werk=blogs.office.com |sprache=en |offline=1 |archiv-url=https://web.archive.org/web/20110717141250/http://blogs.office.com/b/microsoft-outlook/archive/2007/07/05/postmarking-helping-the-fight-against-spam.aspx |archiv-datum=2011-07-17 |abruf=2025-07-28}}</ref>

DKIM ermöglicht eine eingeschränkte Nichtabstreitbarkeit: Ein Absender kann das Versenden signierter Nachrichten nicht glaubhaft abstreiten. Dies wurde z. B. von [[WikiLeaks]] genutzt, um die Echtheit geleakter E-Mails zu bestätigen.<ref>{{Internetquelle |url=https://www.wikileaks.org/DKIM-Verification.html |titel=DKIM Verification |hrsg=WikiLeaks |abruf=2025-07-28}}</ref>

Diese Eigenschaft ist umstritten. Zwar erlaubt das Protokoll eine Ablaufzeit der Signatur (mittels des x-Tags), doch kann sie von Empfängern ignoriert werden. Auch durch Entfernen eines öffentlichen Schlüssels aus dem DNS kann eine Signaturprüfung verhindert werden. Um die Nichtabstreitbarkeit vollständig aufzuheben, kann ein abgelaufener privater Schlüssel veröffentlicht werden, sodass gefälschte Signaturen erzeugt werden können.<ref>{{Internetquelle |url=https://blog.cryptographyengineering.com/2020/11/16/ok-google-please-publish-your-dkim-secret-keys/ |titel=Ok Google: please publish your DKIM secret keys |werk=blog.cryptographyengineering.com, A Few Thoughts on Cryptographic Engineering |datum=2020-11-16 |sprache=en |abruf=2025-07-28}}</ref><ref>{{Internetquelle |url=https://manpages.ubuntu.com/manpages//lunar/man7/dkim-rotate.7.html#key%20publication |titel=dkim-rotate – Principles of Operation |werk=Ubuntu Manpages |abruf=2025-07-28}}</ref><ref>{{Internetquelle |url=https://www.iecc.com/dkimkeys/ |titel=Index of/dkimkeys |werk=iecc.com |abruf=2025-07-28}}</ref>

== Nachteile ==
Das RFC selbst identifiziert mehrere potenzielle Angriffsvektoren.<ref name="RFC6376" />

DKIM-Signaturen umfassen nicht den Nachrichtenumfang, wie [[Envelope Sender|Return-Path]] und Empfänger, bieten jedoch weiterhin Schutz gegen Fälschungen.<ref>{{RFC-Internet |RFC=4686 |Titel=Analysis of Threats Motivating DomainKeys Identified Mail (DKIM) |Datum=2006-09 |Autor=Jim Fenton}}</ref> Mehrere Bedenken wurden 2013 bei der Standardisierung geprüft und zurückgewiesen.<ref>{{Internetquelle |url=https://www.ietf.org/iesg/appeal/response-to-otis-2013-05-30.html |titel=Response to otis |hrsg=[[Internet Engineering Task Force|IETF]] |offline=1 |archiv-url=https://web.archive.org/web/20130906090352/https://www.ietf.org/iesg/appeal/response-to-otis-2013-05-30.html |archiv-datum=2013-09-06 |abruf=2026-01-07}}</ref>

DKIM verwendet zwei Canonicalization-Algorithmen, {{Monospace|simple}} und {{Monospace|relaxed}}, die jedoch nicht [[MIME]]-aware sind.<ref>{{Internetquelle |autor=Ned Freed (mit Zustimmung von [[John Klensin]]) |url=http://www.ietf.org/mail-archive/web/yam/current/msg00381.html |titel=secdir review of draft-ietf-yam-rfc1652bis-03 |werk=YAM mailing list |hrsg=[[Internet Engineering Task Force|IETF]] |datum=2010-03-05 |sprache=en |abruf=2026-01-07}} {{" |Sprache=en |Text=DKIM WG opted for canonical form simplicity over a canonical form that’s robust in the face of encoding changes. It was their engineering choice to make and they made it.}}</ref> Änderungen wie Zeichensatzkonvertierungen oder MIME-Umschreibungen können Signaturen ungültig machen; nur einfache ASCII-Nachrichten ohne signierte MIME-Header behalten volle Integrität.<ref>{{RFC-Internet |RFC=4871 |Titel=DomainKeys Identified Mail (DKIM) Signatures |Datum= |Autor=Eric P. Allman, Jon Callas, Jim Fenton, Miles Libbey, Michael Thomas, Mark Delany}}</ref>

Mailinglisten und einige [[Antivirenprogramm|Antivirus]]-Systeme verändern häufig Nachrichten, was Signaturen bricht. Eine mögliche Maßnahme ist das Signieren nur eines bestimmten Teils des Nachrichtenkörpers mit dem '''l'''-Tag, was bei MIME-Nachrichten jedoch nicht zuverlässig funktioniert.<ref>{{RFC-Internet |RFC=6377 |Titel=DomainKeys Identified Mail (DKIM) and Mailing Lists |Datum=2011-09 |Autor=Murray Kucherawy}}</ref> Alternativ können vertrauenswürdige Weiterleitungsstellen auf eine Whitelist gesetzt oder Nachrichten nach Änderungen erneut signiert werden, wobei Risiken bei Drittanbieter-Signaturen mit [[Author Domain Signing Practices|ADSP]] bestehen.<ref>{{Literatur |Autor=Eric P. Allman, Mark Delany |Titel=DKIM Sender Signing Practices |Nummer=draft-allman-dkim-ssp-02 |Verlag=Internet Engineering Task Force |Datum=2006-08-31 |Online=https://datatracker.ietf.org/doc/draft-allman-dkim-ssp/02/ |Abruf=2026-01-07}}</ref>

Das [[Authenticated Received Chain]] (ARC)-Protokoll ermöglicht es Zwischenservern, wie Mailinglisten, die ursprünglichen Authentifizierungsergebnisse zu erhalten und zu prüfen, wodurch Signaturbrüche durch Weiterleitungen reduziert werden. ARC ist in <nowiki>RFC 8617</nowiki><ref name="RFC8617" /> definiert und als „Experimentell“ eingestuft.<ref name="ARC-Overview-2016Q3-v01.pdf">{{Internetquelle |url=https://dmarc.org/presentations/ARC-Overview-2016Q3-v01.pdf |titel=Authenticated Received Chain Overview |werk=dmarc.org |hrsg=The Trusted Domain Project |datum=2016 |format=PDF |sprache=en |abruf=2026-01-07}}</ref><ref name="RFC8617" /><ref>{{Internetquelle |autor=chrisda |url=https://learn.microsoft.com/en-us/defender-office-365/email-authentication-arc-configure |titel=Configure trusted ARC sealers – Microsoft Defender for Office 365 |sprache=en-US |abruf=2026-01-07}}</ref>

2012 zeigte Zach Harris, dass kurze DKIM-Schlüssel (384–512 Bit) schnell gebrochen werden können, darunter für <code>google.com</code> und andere Domains. Organisationen wurden informiert, und längere Schlüssel (>1024 Bit) werden empfohlen.<ref>{{Literatur |Autor=Anthony Overmars, Sitalakshmi Venkatraman |Titel=Mathematical Attack of RSA by Extending the Sum of Squares of Primes to Factorize a Semi-Prime |Sammelwerk=Mathematical and Computational Applications |Band=25 |Nummer=4 |Verlag=[http://bimicertifications.de/ BIMI] |Datum=2020-09-28 |ISSN=2297-8747 |Seiten=63 |Online=https://www.mdpi.com/2297-8747/25/4/63 |Abruf=2026-01-07 |DOI=10.3390/mca25040063}}</ref> Google bestätigte, dass nach der Veröffentlichung längere Schlüssel verwendet wurden. <nowiki>RFC 6376</nowiki><ref name="RFC6376" /> verlangt Empfängerunterstützung für 512–2048-Bit-Schlüssel und empfiehlt mindestens 1024 Bit für langlebige Signaturen.<ref name="RFC6376" />

== Unterstützung ==
Eine Herausforderung bei dieser und allen anderen Methoden zur Sicherstellung der Absender-Authentizität ist, dass es einen langen Zeitraum benötigt, um ein solches System zu verbreiten, da zuerst die Software angepasst werden muss und diese dann auch noch auf den Mailservern zum Einsatz kommen muss.

DKIM wird in gängigen Mail Transfer Agents wie [[Postfix (Mail Transfer Agent)|Postfix]] oder [[Sendmail]] durch Tools wie [[Amavis]], [[Rspamd]] oder ''openDKIM'' unterstützt, [[Exim]] bietet nativen Support. Alle größeren [[E-Mail-Anbieter]] unterstützen DKIM, neben [[Yahoo Mail|Yahoo]] beispielsweise [[Gmail]] und [[Microsoft Office 365]].

Laut einer im Oktober 2015 veröffentlichten Studie waren 83 % der E-Mails, die Gmail im April 2015 empfangen hatte, mit DKIM signiert. Von den signierten E-Mails schlug die Verifikation jedoch bei 6 % aus unterschiedlichen Gründen fehl.<ref>{{Literatur |Autor=Zakir Durumeric, David Adrian, Ariana Mirian, James Kasten, Elie Bursztein, Nicolas Lidzborski, Kurt Thomas, Vijay Eranti, Michael Bailey, J. Alex Halderman |Hrsg=[[Association for Computing Machinery|ACM]] |Titel=Neither Snow Nor Rain Nor MITM...: An Empirical Analysis of Email Delivery Security |Sammelwerk=IMC '15: Proceedings of the 2015 Internet Measurement Conference |Datum=2015-10-28 |Sprache=en |DOI=10.1145/2815675.2815695}}</ref>

Im Januar 2021 veröffentlichte die Zeitschrift ''[[c’t]]'' einen Test der Verbreitung und Umsetzungsqualität von DKIM bei 37 deutschen [[Webhosting]]-Anbietern mit dem Resultat, dass nur 16 davon DKIM anbieten und es nur bei 6 fehlerfrei konfiguriert war (keine falschen Absenderdomains mit DKIM signiert).<ref name="ct-2021-01" /> Einige der Anbieter korrigierten ihre DKIM-Umsetzung umgehend bereits vor Veröffentlichung der Ausgabe.<ref name="ct-2021-01" />

== Weblinks ==
* [http://opendkim.org/ opendkim.org] – Tool zur Integration in Postfix oder Sendmail per [[Milter]]-API
* [https://www.heise.de/ct/artikel/E-Mails-signieren-mit-DKIM-221505.html E-Mails signieren mit DKIM, Kryptographie gegen Phishing und Spam.] In: ''[[c’t]]'', ''heise Netze''
* [https://addons.thunderbird.net/de/thunderbird/addon/dkim-verifier/ Add-on für Thunderbird.] thunderbird.net, zur Überprüfung und Anzeige des DKIM-Status in eingehenden E-Mails. [https://github.com/lieser/dkim_verifier Sourcecode] github.com
* [https://wander.science/projects/email/dkimtest/ DKIM Test.] wander.science, zur Überprüfung der DKIM-Signatur in ausgehenden E-Mails.

== Einzelnachweise ==
<references>
<ref name="ct-2021-01">
{{Literatur
|Autor=Leo Dessani, Jan Mahn
|Titel=DKIM-Fail. Fehler bei Hostern gefährden die Sicherheit von DKIM
|Sammelwerk=[[c’t]]
|Nummer=1
|Datum=2021
|Seiten=126-129
|Online=https://www.heise.de/select/ct/2021/1/seite-126
|Abruf=2021-01-17}}
</ref>
<ref name="RFC6376">
{{RFC-Internet |RFC=6376 |Titel=DomainKeys Identified Mail (DKIM) Signatures |Datum=2011-09 |Autor=D. Crocker, T. Hansen, M. Kucherawy}}
</ref>
<ref name="RFC8301">
{{RFC-Internet |RFC=8301 |Titel=Cryptographic Algorithm and Key Usage Update to DomainKeys Identified Mail (DKIM) |Datum=2018-01 |Autor=S. Kitterman}}
</ref>
<ref name="RFC8463">
{{RFC-Internet |RFC=8463 |Titel=A New Cryptographic Signature Method for DomainKeys Identified Mail (DKIM) |Datum=2018-09 |Autor=J. Levine}}
</ref>
<ref name="RFC8617">
{{RFC-Internet |RFC=8617 |Titel=The Authenticated Received Chain (ARC) Protocol |Datum=2019-07 |Autor=Kurt Andersen, Brandon Long, Seth Blank, Murray Kucherawy}}
</ref>
</references>

[[Kategorie:E-Mail]]
[[Kategorie:Identifikationsprotokoll]]
[[Kategorie:Internetstandard]]

DomainKeys Identified Mail - Versionsgeschichte

imported>PerfektesChaos: tk k