Alle Fachartikel

SPF, DKIM und DMARC: damit geschäftliche E-Mails ankommen

Veröffentlicht · 9 Min. Lesezeit

Artikel anhören · vorgelesen von einer KI-Stimme

Eine Rechnung, ein Angebot, eine Terminbestätigung: Geschäftliche E-Mails sind nur nützlich, wenn sie im Posteingang des Empfängers landen. Ob das gelingt, entscheidet der empfangende Mailserver. Er prüft, ob er dem Absender trauen kann, und er verlässt sich dabei auf Nachweise, die Ihre Domain selbst im DNS veröffentlicht.

Diese Nachweise heißen SPF, DKIM und DMARC. Der Artikel erklärt, was jeder Eintrag leistet, was Google und Yahoo seit Februar 2024 von Absendern verlangen und wie Sie die Einträge Schritt für Schritt einführen. Als Beispiel dienen die echten Einträge von esn.ge.

Warum E-Mails im Spam landen: Absender ohne Nachweis

Stellen Sie sich vor, Ihre Buchhaltung verschickt eine Rechnung von info@your-company.ge. Beim Empfänger kommt nur ein Text an, der behauptet, von dieser Adresse zu stammen. Das Absenderfeld lässt sich beliebig eintragen, genauso wie man auf einen Brief jeden Absender schreiben kann. Der empfangende Server kann also nicht erkennen, ob die Mail wirklich von Ihnen kommt oder von jemandem, der Ihre Domain missbraucht.

Hat Ihre Domain keine Nachweise veröffentlicht, bleibt dem Empfänger nur das Misstrauen. Die Folge: Ihre Rechnung landet im Spam oder wird abgewiesen. Mit den drei Einträgen beantworten Sie die Frage selbst:

  • SPF nennt die Server, die für Ihre Domain senden dürfen.
  • DKIM versieht jede Mail mit einer Signatur.
  • DMARC legt fest, was mit Mails ohne gültigen Nachweis geschieht, und liefert Berichte darüber.

SPF: welche Server für die Domain senden dürfen

SPF ist ein TXT-Eintrag im DNS Ihrer Domain, der mit v=spf1 beginnt. Er funktioniert wie eine Gästeliste an der Tür: Der empfangende Server vergleicht den sendenden Server mit der Liste. Steht er darauf, besteht die Mail die SPF-Prüfung. Der Standard dazu ist RFC 7208.

Der SPF-Eintrag von esn.ge lautet:

v=spf1 mx include:_spf.webhosting.systems include:_spf.protonmail.ch -all

Die Bestandteile im Einzelnen:

  • v=spf1 kennzeichnet den Eintrag als SPF-Eintrag.
  • mx erlaubt die Server, die in den MX-Einträgen der Domain stehen, also die Server, die auch Ihre Mails empfangen.
  • include: übernimmt die erlaubten Server einer anderen Domain.
  • -all am Ende bedeutet: Alle anderen Server bestehen die Prüfung nicht.

Eine Grenze sollten Sie kennen: Nach RFC 7208 Abschnitt 4.6.4 darf die Auswertung eines SPF-Eintrags höchstens 10 Angaben umfassen, die eine DNS-Abfrage brauchen. Die Abfrage des SPF-Eintrags selbst zählt nicht mit. Wer immer neue include:-Angaben anhängt, kann diese Grenze überschreiten. Prüfen Sie deshalb nach jeder Änderung, ob die Grenze noch eingehalten wird.

Auch Mails aus Ihren Webanwendungen, etwa Bestellbestätigungen oder Kontaktformulare, müssen über einen Server laufen, den der Eintrag abdeckt. Der quelloffene Smarthost von epicsoft (Postfix auf Alpine) ist ein SMTP-Relay für ausgehende Mails aus Containern. Die Anwendungen übergeben ihre Mails an ihn, und er liefert sie mit Authentifizierung und TLS an den Mailserver des Unternehmens. Die Mails verlassen das System dadurch über den Mailserver, den SPF, DKIM und DMARC abdecken. Seine Option SMARTHOST_FORCE_FROM schreibt dabei nur den sichtbaren From:-Header um, nicht den Absender im Umschlag der Mail.

DKIM: die Signatur jeder E-Mail

SPF prüft den Server, DKIM prüft die Mail selbst. Der sendende Server signiert jede Mail mit einem privaten Schlüssel und fügt die Signatur in einem Header namens DKIM-Signature hinzu. Darin stehen unter anderem die Domain (d=) und ein Selektor (s=). Den privaten Schlüssel behält der Server für sich.

Der empfangende Server liest den passenden öffentlichen Schlüssel aus dem DNS. Er steht in einem TXT-Eintrag, dessen Name sich aus dem Selektor, ._domainkey. und der Domain zusammensetzt, in der Form v=DKIM1; k=rsa; p=…. Hinter p= steht der öffentliche Schlüssel. Passt die Signatur zum Schlüssel, ist belegt, dass die Mail von einem Server mit dem Schlüssel Ihrer Domain stammt (RFC 6376).

Ein Beispiel mit Platzhaltern, nicht mit echten Werten:

mail._domainkey.your-company.ge   TXT   "v=DKIM1; k=rsa; p=…"

Hier ist mail der frei gewählte Selektor, your-company.ge steht für Ihre Domain, und an die Stelle der Auslassungspunkte tritt der öffentliche Schlüssel. Wichtig bei der Schlüssellänge: Laut Google erfordert das Senden an persönliche Gmail-Konten einen DKIM-Schlüssel von 1024 Bit oder länger. Fragen Sie Ihren Mailanbieter, welche Länge er verwendet.

DMARC: was mit E-Mails ohne gültigen Nachweis geschieht, und die Berichte darüber

SPF und DKIM liefern Prüfergebnisse, aber sie sagen dem Empfänger nicht, was er mit einem Fehlschlag tun soll. Das übernimmt DMARC. Der Eintrag ist ein TXT-Eintrag unter _dmarc. vor Ihrer Domain, für your-company.ge also unter _dmarc.your-company.ge.

Alignment. Eine Mail besteht die DMARC-Prüfung, wenn SPF oder DKIM besteht und die jeweilige Domain zur Domain im sichtbaren From:-Feld passt („aligned“). So lässt sich nicht mit einem fremden, korrekt authentifizierten Server eine Mail mit Ihrer Absenderadresse verschicken.

Die drei Richtlinien (p=):

  • p=none: Es werden nur Berichte gesammelt, Mails werden nicht beanstandet.
  • p=quarantine: Empfänger sollen durchfallende Mails als verdächtig behandeln, zum Beispiel im Spam-Ordner.
  • p=reject: Empfänger sollen durchfallende Mails abweisen.

Berichte. Mit rua nennen Sie die Adresse für Sammelberichte (Aggregate Reports), mit ruf die Adresse für Fehlerberichte (Failure Reports). Daran sehen Sie, wer in Ihrem Namen sendet und welche Mails durchfallen.

Neue Spezifikation. Im Mai 2026 ist die Neufassung von DMARC erschienen, in der Community als DMARCbis bekannt, und zwar als drei RFCs: RFC 9989 (das Kernprotokoll), RFC 9990 (Sammelberichte) und RFC 9991 (Fehlerberichte). RFC 9989 wurde am 19. Mai 2026 veröffentlicht und ersetzt RFC 7489 (DMARC, 2015) sowie RFC 9091 (experimentelles PSD-DMARC). DMARC ist damit vom Status „Informational“ zum „Proposed Standard“ auf dem Standardisierungspfad der IETF aufgestiegen. RFC 7489 ist überholt und sollte nicht mehr als aktuelle Grundlage dienen.

Was Google und Yahoo von Absendern verlangen

Google und Yahoo prüfen Absender seit Februar 2024 strenger. Für ein Unternehmen heißt das: Ohne die Einträge riskieren Rechnungen und Angebote, im Spam zu landen oder abgewiesen zu werden.

Google, Anforderungen an alle Absender. Seit dem 1. Februar 2024 müssen alle, die an Gmail-Konten senden, diese Punkte erfüllen:

  • SPF oder DKIM für die sendenden Domains einrichten.
  • Die in den Postmaster Tools gemeldete Spam-Rate unter 0,3 % halten. Der Abschnitt zur Überwachung empfiehlt, unter 0,10 % zu bleiben und nie 0,30 % oder mehr zu erreichen.
  • Für persönliche Gmail-Konten einen DKIM-Schlüssel von mindestens 1024 Bit verwenden.

Google, zusätzliche Anforderungen ab mehr als 5.000 Nachrichten pro Tag an Gmail-Konten. Diese Absender müssen zusätzlich:

  • SPF und DKIM für die Domain einrichten (nicht nur eines von beiden).
  • DMARC einrichten. Die Richtlinie darf dabei none sein.
  • Bei direkt gesendeten Mails dafür sorgen, dass die Domain im From:-Header zur SPF-Domain oder zur DKIM-Domain passt. Das ist nötig, um das DMARC-Alignment zu bestehen.
  • In Marketing- und abonnierten Nachrichten das Abmelden mit einem Klick unterstützen und im Text einen gut sichtbaren Abmeldelink zeigen. Dafür gehören die Header List-Unsubscribe-Post: List-Unsubscribe=One-Click und List-Unsubscribe in die Mail (RFC 2369, RFC 8058).

Yahoo. Die Durchsetzung der Anforderungen begann im Februar 2024. Yahoo führte sie schrittweise ein und beobachtete die Einhaltung im ersten Halbjahr. Als Minimum verlangt Yahoo, SPF oder DKIM einzurichten.

Auch wenn Sie weit unter 5.000 Mails am Tag versenden, ist es sinnvoll, alle drei Einträge zu setzen. Die strengeren Regeln zeigen, in welche Richtung sich Empfänger bewegen.

Schrittweise einführen: von p=none über p=quarantine bis p=reject

Eine zu strenge DMARC-Richtlinie kann auch echte Mails blockieren, etwa die eines Newsletter-Dienstes, den Sie vergessen haben. Führen Sie DMARC deshalb in Stufen ein:

  1. p=none: Sie sammeln nur Berichte und sehen, wer in Ihrem Namen sendet. Beheben Sie, was durchfällt.
  2. p=quarantine: Sind die eigenen Quellen sauber authentifiziert, lassen Sie durchfallende Mails als verdächtig behandeln.
  3. p=reject: Zuletzt lassen Sie sie abweisen.

Der DMARC-Eintrag von esn.ge steht auf der mittleren Stufe:

v=DMARC1;p=quarantine;sp=quarantine;pct=100;rua=mailto:dmarc@reports.epicsoft.email;ruf=mailto:dmarc@reports.epicsoft.email;ri=86400;aspf=r;adkim=r;fo=1;rf=afrf;

Alle Angaben sind durch Semikolons getrennt, ohne Leerzeichen. Im Einzelnen:

  • v=DMARC1 kennzeichnet den Eintrag als DMARC-Eintrag.
  • p=quarantine gilt für die Domain, sp=quarantine für ihre Subdomains.
  • pct=100 bezieht die Richtlinie auf alle Mails.
  • rua=… und ruf=… nennen die Adresse für Sammel- und Fehlerberichte, hier ein Berichtspostfach unter der Domain epicsoft.email.
  • ri=86400 (Berichtsintervall) und rf=afrf (Berichtsformat) stammen aus der alten Spezifikation.
  • aspf=r und adkim=r stehen für ein „relaxed“ (lockeres) Alignment bei SPF und DKIM.
  • fo=1 verlangt einen Fehlerbericht, sobald eine der Prüfungen durchfällt.

Was sich mit RFC 9989 ändert. Drei Angaben dieses Eintrags, nämlich pct, ri und rf, sind in RFC 9989 entfallen. Wir nennen sie hier nur, weil der Eintrag noch so besteht; für einen neuen Eintrag brauchen Sie sie nicht. An die Stelle von pct tritt das Tag t (Testmodus), das nur „alles“ (100 %) oder „nichts“ (0 %) kennt.

Neu sind außerdem np und psd. np legt die Richtlinie für Subdomains fest, die es nicht gibt. Fehlt np, gilt stattdessen sp. psd kennzeichnet eine Public-Suffix-Domain. Die Organisationsdomain wird jetzt über einen „DNS Tree Walk“ ermittelt statt über die Public Suffix List.

Bestehende Einträge bleiben nutzbar: Sie beginnen weiterhin mit v=DMARC1. Deshalb müssen die meisten produktiven Einrichtungen nach Einschätzung von DMARCTrust nicht sofort angepasst werden.

Ergänzend: MTA-STS für die Transportverschlüsselung

SPF, DKIM und DMARC belegen, von wem eine Mail kommt. Sie sagen nichts darüber, ob die Mail unterwegs verschlüsselt wird. Das regelt MTA-STS (RFC 8461). Damit erklärt eine Domain, dass Mails an sie nur über TLS mit gültigem Zertifikat zugestellt werden dürfen.

Dazu gehören zwei Teile. Erstens ein TXT-Eintrag unter _mta-sts. vor der Domain, etwa _mta-sts.your-company.ge, der v=STSv1 und eine id enthält. Die id ändert sich, sobald sich die Richtlinie ändert. Zweitens die Richtlinie selbst: die Datei /.well-known/mta-sts.txt, per HTTPS abrufbar unter der Subdomain mta-sts der Domain, mit dem Modus enforce, testing oder none.

Bei esn.ge ist _mta-sts.esn.ge ein CNAME auf _mta-sts.epicsoft.email. Dort steht der TXT-Eintrag:

v=STSv1;id=20261012084000

esn.ge übernimmt den MTA-STS-Eintrag also von der Mail-Domain epicsoft.email.

So richtet epicsoft das ein

Beim E-Mail-Dienst von epicsoft networks legen wir bei der Einrichtung die Postfächer und die DNS-Einträge Ihrer Domain an: MX, SPF, DKIM und DMARC. Ihre Domain können Sie behalten. Entweder setzen wir die Einträge gemeinsam mit Ihnen bei Ihrem DNS-Anbieter, oder wir verwalten das DNS der Domain. Die Mails liegen auf unseren eigenen Mailservern in Finnland und Deutschland. Alle Leistungen finden Sie unter Leistungen.

Quellen

Weitere Fachartikel

Bereit für den nächsten Schritt?

Es gab nie einen besseren Zeitpunkt, um anzufangen. Erzählen Sie uns von Ihrem Projekt.

Kontakt aufnehmen