SPF, DKIM und DMARC in AWS Route 53 einrichten

AWS Route 53 ist ein schneller, zuverlässiger Ort, um die drei DNS-Einträge zu veröffentlichen, die Ihre E-Mails authentifizieren — SPF, DKIM und DMARC —, doch seine Konsole hat ein paar Eigenheiten, über die Anwender stolpern: vollqualifizierte Eintragsnamen und das verpflichtende Setzen jedes TXT-Werts in doppelte Anführungszeichen. Die Einträge selbst sind identisch mit dem, was Sie bei jedem beliebigen DNS-Hoster veröffentlichen würden; nur der Editor ändert sich. Diese Anleitung zeigt Ihnen genau, wo in der Route-53-Konsole Sie jeden Eintrag hinzufügen, was Sie im Feld für den Eintragsnamen für die Root-Domain gegenüber _dmarc gegenüber Ihrem DKIM-Selektor eingeben und die eine Anführungszeichen-Eigenheit, die lange DKIM-Schlüssel unbemerkt zerstört, wenn Sie sie übersehen.

Die kurze Antwort#

Alle drei Einträge sind gewöhnliche TXT-Einträge in Ihrer Route-53-Hosted Zone. Was sich von einem Hoster zum nächsten unterscheidet, ist nur die Benennungskonvention und das Eingabeformat:

• SPF — ein TXT-Eintrag auf der Root-Ebene Ihrer Domain. In Route 53 lassen Sie das Feld für den Eintragsnamen leer, und der Eintrag gilt für den Zone Apex.
• DKIM — ein TXT-Eintrag unter <selector>._domainkey.ihredomain.com. Sie geben nur den Teil <selector>._domainkey im Feld für den Eintragsnamen ein; der Selektor und der lange Schlüsselwert stammen beide von Ihrem E-Mail-Anbieter.
• DMARC — ein TXT-Eintrag unter _dmarc.ihredomain.com. Sie geben _dmarc im Feld für den Eintragsnamen ein, und Route 53 hängt die Zone für Sie an.

Die Werte sind anbieterspezifisch, schreiben Sie sie also nicht von Hand. Erzeugen Sie Ihre SPF-Zeile mit dem SPF-Record-Generator, Ihre Policy-Zeile mit dem DMARC-Record-Generator und kopieren Sie Ihren DKIM-Schlüssel direkt aus dem Dashboard Ihrer E-Mail-Plattform. Für die Konzepte hinter jedem Eintrag erklärt der Erklärartikel zu SPF, DKIM und DMARC, was sie tun und warum sie wichtig sind.

Wie SPF, DKIM und DMARC auf Route-53-Einträge abgebildet werden#

Route 53 organisiert DNS rund um eine Hosted Zone — eine Zone pro Domain. Innerhalb einer Zone hat jeder Eintrag einen vollqualifizierten Namen relativ zum Zone Apex, und die Konsole macht das explizit: Neben dem Feld „Record name" zeigt sie Ihr Domain-Suffix an, und was auch immer Sie eingeben, wird davor gestellt. Dieses eine Detail erklärt alle drei Eintragsspeicherorte.

Wo Sie Einträge in der Route-53-Konsole hinzufügen#

Der Weg ist für alle drei Einträge derselbe. Öffnen Sie die Route-53-Konsole, wählen Sie in der linken Navigation Hosted zones und klicken Sie auf die Zone der Domain, von der aus Sie E-Mails versenden. Klicken Sie auf Create record, und falls die Konsole eine Umschaltung zwischen „Quick create" und „Wizard" anbietet, ist „Quick create" der einfachere Weg für einen einzelnen TXT-Eintrag.

Im Formular zum Erstellen des Eintrags legen Sie drei Dinge fest: den Record name (das Präfix gemäß der Tabelle oben), den Record type (TXT für alle drei) und den Value. Belassen Sie die Routing-Richtlinie beim Standard „Simple routing" — dies sind reine informative Einträge, kein Traffic-Routing. Die TTL kann beim Standard bleiben (300 oder 3600 Sekunden ist in Ordnung); eine kürzere TTL bedeutet nur, dass sich Änderungen schneller verbreiten, während Sie testen.

Ihren SPF-Eintrag auf der Root-Domain veröffentlichen#

SPF autorisiert, welche Server E-Mails über Ihre Domain versenden dürfen. Erstellen Sie einen TXT-Eintrag, lassen Sie den Eintragsnamen leer, damit er auf der Root-Domain landet, und fügen Sie Ihren SPF-Wert ein. Ein typischer Wert sieht so aus:

"v=spf1 include:amazonses.com include:_spf.google.com ~all"

Beachten Sie die umschließenden doppelten Anführungszeichen — Route 53 erwartet TXT-Werte in Anführungszeichen, und die Konsole ergänzt sie in der Regel, wenn Sie sie vergessen, aber es ist sauberer, sie selbst einzuschließen. Das ~all am Ende ist ein Soft-Fail; -all ist ein Hard-Fail, der Empfängern sagt, nicht autorisierte Absender direkt abzuweisen.

Zwei Regeln zählen hier mehr als alles andere. Erstens: Veröffentlichen Sie genau einen SPF-Eintrag. Wenn ein zweiter TXT-Eintrag auf der Root-Ebene ebenfalls mit v=spf1 beginnt, wird SPF ungültig und jede Prüfung schlägt fehl — wenn Sie also bereits über einen anderen Dienst versenden, führen Sie alle include:-Mechanismen in einer einzigen Zeile zusammen, statt einen neuen Eintrag hinzuzufügen. Zweitens: Bleiben Sie innerhalb von zehn DNS-Lookups; jedes include: zählt, und ein Überschreiten verursacht einen dauerhaften SPF-Fehler. Der SPF-Record-Generator erstellt aus den Anbietern, die Sie tatsächlich nutzen, eine einzige gültige Zeile und weist Sie auf das Lookup-Limit hin.

Ihren DKIM-Eintrag beim Selektor hinzufügen#

DKIM veröffentlicht die öffentliche Hälfte eines Signaturschlüssels, damit Empfänger überprüfen können, dass Ihre Nachrichten nicht gefälscht oder verändert wurden. Ihr E-Mail-Anbieter gibt Ihnen zwei Dinge: einen Selektor (eine kurze Bezeichnung wie s1, google oder eine zufällige Zeichenfolge) und den langen öffentlichen Schlüsselwert. Diesen Schlüssel veröffentlichen Sie als TXT-Eintrag unter <selector>._domainkey.

Erstellen Sie einen TXT-Eintrag, geben Sie den Selektor plus ._domainkey im Feld für den Eintragsnamen ein — zum Beispiel s1._domainkey — und fügen Sie den Wert ein, den Ihr Anbieter Ihnen gegeben hat. Der Wert sieht so aus:

"v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ..."

Erfinden oder bearbeiten Sie diesen Wert nicht — kopieren Sie ihn wortwörtlich aus den Authentifizierungseinstellungen Ihrer E-Mail-Plattform, denn der öffentliche Schlüssel muss exakt mit dem privaten Schlüssel übereinstimmen, der die Signatur erstellt. Einige Anbieter (Amazon SES gehört dazu) stellen drei CNAME-basierte DKIM-Einträge statt eines einzelnen TXT-Eintrags aus; erstellen Sie in diesem Fall drei CNAME-Einträge mit den Namen und Zielen, die sie bereitstellen, und folgen Sie derselben Regel „Präfix eingeben, Route 53 hängt die Zone an". Welche Form Ihr Anbieter auch nutzt, die Werte kommen von ihm, niemals von Ihnen.

Ihren DMARC-Eintrag unter _dmarc veröffentlichen#

DMARC verknüpft SPF und DKIM mit der sichtbaren „From"-Adresse, teilt Empfängern mit, was mit E-Mails geschehen soll, die fehlschlagen, und sendet Ihnen Berichte. Erstellen Sie einen TXT-Eintrag, geben Sie _dmarc im Feld für den Eintragsnamen ein und fügen Sie eine Einstiegs-Policy ein:

"v=DMARC1; p=none; rua=mailto:dmarc@example.com"

Beginnen Sie bei p=none. Das ist der Überwachungsmodus — er ändert nichts daran, wie Ihre E-Mails behandelt werden, aktiviert aber die täglichen Aggregatberichte, die einen sicheren Rollout erst möglich machen. Erst wenn die Berichte bestätigen, dass jeder legitime Versandstrom in Ausrichtung authentifiziert wird, sollten Sie auf p=quarantine und dann p=reject verschärfen. p=reject am ersten Tag zu veröffentlichen, ist der schnellste Weg, Ihre eigenen E-Mails in den Spam zu schicken. Der DMARC-Record-Generator erstellt eine syntaktisch korrekte Policy, und die vollständige Schritt-für-Schritt-Anleitung zum DMARC-Rollout behandelt die Abfolge „erst überwachen, dann durchsetzen" im Detail; sobald Berichte eintreffen, erklärt DMARC-Aggregatberichte lesen, wie Sie darauf reagieren.

Die Anführungszeichen-Eigenheit, die lange DKIM-Schlüssel zerstört#

Dies ist das Route-53-spezifische Detail, bei dem es sich lohnt, langsamer zu werden, denn es schlägt unbemerkt fehl. Ein einzelner DNS-TXT-String ist auf 255 Zeichen begrenzt. Kurze Werte — Ihre SPF-Zeile, Ihre DMARC-Policy — passen bequem in einen einzelnen String in Anführungszeichen. Aber ein 2048-Bit-DKIM-Schlüssel ist länger als 255 Zeichen und kann daher nicht in einem einzelnen String stehen.

Die Antwort von Route 53 ist, den Wert in mehrere Strings in Anführungszeichen aufzuteilen, jeder mit 255 Zeichen oder weniger, gemeinsam im selben Eintragswert platziert. DNS-Resolver fügen die Strings wieder zu einem Schlüssel zusammen. Im Feld „Value" der Konsole sieht das wie zwei benachbarte Strings in Anführungszeichen aus:

"v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ...up-to-255-chars"
"...the-remaining-characters-of-the-public-key"

Der Haken: Die beiden Strings werden zu einem durchgehenden Schlüssel ohne Leerzeichen dazwischen zusammengefügt, fügen Sie also keine Zeichen an der Trennstelle ein und behalten Sie beide Strings in einem einzigen TXT-Eintragswert, statt sie zu zwei separaten Einträgen werden zu lassen. Wenn Ihre DKIM-Prüfung direkt nach der Einrichtung fehlschlägt und der Schlüssel vollständig aussieht, ist eine falsche Aufteilung der übliche Schuldige. Fügen Sie den gesamten Schlüssel ein, überlassen Sie die Aufteilung der Konsole oder Ihrem Tooling, wo es das kann, und überprüfen Sie das Ergebnis, statt ihm zu vertrauen.

Die Einträge als Code verwalten#

Route 53 ist ein Favorit für Teams, die ihre Infrastruktur als Code betreiben, und Sie müssen die Konsole überhaupt nicht verwenden. Die AWS CLI veröffentlicht Einträge mit aws route53 change-resource-record-sets und übergibt einen JSON-Change-Batch, der den Namen, den TXT-Typ, die TTL und den Wert angibt. In Terraform ist jeder Eintrag eine aws_route53_record-Ressource:

resource "aws_route53_record" "dmarc" {
  zone_id = aws_route53_zone.primary.zone_id
  name    = "_dmarc.example.com"
  type    = "TXT"
  ttl     = 3600
  records = ["v=DMARC1; p=none; rua=mailto:dmarc@example.com"]
}

Dieselben Regeln gelten weiterhin: ein SPF-Eintrag am Apex, der DKIM-Wert direkt von Ihrem Anbieter, DMARC beginnend bei p=none. Die 255-Zeichen-Grenze pro String gilt auch hier — ein langer DKIM-Schlüssel muss weiterhin in mehrere Strings innerhalb des Eintragswerts aufgeteilt werden, wenden Sie also den Eintrag an und überprüfen Sie das veröffentlichte Ergebnis.

Überprüfen, bevor Sie durchsetzen#

DNS-Änderungen in Route 53 verbreiten sich in der Regel innerhalb von ein bis zwei Minuten, obwohl Ihre TTL und nachgelagerte Caches das strecken können. Sobald die Einträge live sind, bestätigen Sie mit dem SPF-, DKIM- und DMARC-Checker, dass alle drei korrekt aufgelöst und geparst werden — er erkennt einen fehlenden oder doppelten SPF-Eintrag, einen DKIM-Schlüssel, der falsch aufgeteilt oder eingefügt wurde, und eine DMARC-Policy mit einem Syntaxfehler, also die drei Dinge, die bei Route 53 am ehesten schiefgehen. Erst wenn der Checker grün ist, sollten Sie beginnen, die DMARC-Policy von none in Richtung reject hochzustufen.

Alle drei veröffentlicht und bestanden zu haben, ist das, was die Absenderanforderungen von Google und Yahoo für Massenversender erfüllt. Aber denken Sie an die Grenze: Authentifizierung beweist, wer Sie sind, nicht, dass Sie ein guter Absender sind. Eine perfekt authentifizierte Nachricht an eine Liste voller toter Adressen landet trotzdem im Spam. Der Leitfaden zur E-Mail-Zustellbarkeit behandelt die Reputations- und Listenhygienearbeit, die aus einer vertrauenswürdigen Identität eine Platzierung im Posteingang macht.

Häufig gestellte Fragen#

Was trage ich im Route-53-Feld für den Eintragsnamen bei einem SPF-Eintrag auf Root-Ebene ein?#

Lassen Sie es leer. Route 53 wendet einen Eintrag mit leerem Namen auf den Zone Apex an — die Root-Domain selbst — genau dort, wohin der SPF-TXT-Eintrag gehört. Setzen Sie den Typ auf TXT und fügen Sie Ihren einzelnen v=spf1 ...-Wert ein. Tragen Sie kein @ und keinen Domainnamen in das Feld ein; ein leerer Eintragsname ist die Art, wie Route 53 die Root ausdrückt.

Warum schlägt mein DKIM-Eintrag in Route 53 fehl, obwohl der Schlüssel korrekt aussieht?#

Fast immer wegen der 255-Zeichen-Grenze pro String. Ein 2048-Bit-DKIM-Schlüssel ist zu lang für einen einzelnen TXT-String, deshalb verlangt Route 53, ihn in mehrere in Anführungszeichen gesetzte Strings aufzuteilen, die Resolver wieder zusammenfügen. Wenn die Aufteilung ein zusätzliches Leerzeichen einfügt, ein Zeichen verschluckt oder die Teile als zwei separate Einträge statt eines Werts enden, wird der Schlüssel nicht validiert. Fügen Sie den vollständigen Schlüssel erneut ein, belassen Sie ihn als einen einzelnen Eintragswert und bestätigen Sie ihn mit einem DKIM-Checker.

Trage ich _dmarc ein oder den vollständigen Namen _dmarc.example.com in das Feld für den Eintragsnamen?#

Tragen Sie nur _dmarc ein. Route 53 zeigt Ihr Domain-Suffix neben dem Feld an und hängt es automatisch an, sodass aus _dmarc ein _dmarc.example.com wird. Wenn Sie den vollständigen Namen eintragen, entsteht ein doppeltes _dmarc.example.com.example.com, das kein Empfänger jemals abfragen wird. Dieselbe Voranstellungsregel gilt für Ihren DKIM-Selektor.

Kann ich SPF, DKIM und DMARC in Route 53 mit Terraform oder der CLI verwalten?#

Ja. Jeder Eintrag ist eine aws_route53_record-Ressource in Terraform oder ein Change Batch für aws route53 change-resource-record-sets in der CLI. Die Eintragsnamen, -typen und -werte sind identisch mit dem, was Sie in der Konsole eingeben würden, und dieselbe 255-Zeichen-Aufteilung für lange DKIM-Schlüssel gilt. Generieren Sie zuerst die Werte, übertragen Sie sie dann in Code und prüfen Sie das veröffentlichte Ergebnis.

Route 53 macht die drei Einträge unkompliziert, sobald Sie seine Benennungs- und Anführungszeichen-Konventionen kennen — aber Authentifizierung ist nur die Eintrittskarte in den Posteingang. Erstellen Sie Ihre Einträge mit den kostenlosen Tools und säubern Sie dann die Liste dahinter mit dem kostenlosen E-Mail-Checker: Er erkennt tote Domains, Tippfehler und Spam-Fallen, bevor sie zu Bounces werden, denn eine vertrauenswürdige Identität verdient sich nur dann eine Platzierung, wenn die Liste, für die sie signiert, sauber ist.