/
SPF DKIM DMARC Record Generator

SPF DKIM DMARC Record Generator

Vollständige E-Mail-DNS-Einträge für SPF, DKIM, DMARC, MX und BIMI generieren. BIND-Zonendateien exportieren, Spoofing verhindern und maximale Zustellrate sichern.

Vorkonfigurierte Profile

E-Mail-Authentifizierungs-Pipeline

Aktive RichtliniePolicy-Präfixnone
Absender-Serveracme-corp.comSPF-IP-Validierung~all (1/10 Lookups)RFC 7208 (SPF-Spezifikation)DKIM-Signaturprüfunggoogle (RSA-2048)RFC 6376 (DKIM-Standard)DMARC-RichtlinienprüfungPolicy-Präfixnone (100%)RFC 7489 (DMARC-Spezifikation)PosteingangÜberwachtSpam-QuarantäneBypassAbgewiesenInaktiv
Domain & E-Mail-Provideracme-corp.com
SPF (Sender Policy Framework)1/10 Lookups
DKIM (DomainKeys Identified Mail)
DMARC (Domain-based Message Authentication)_dmarc.acme-corp.com
Rollout-Prozentsatz (pct=)100%
MX (Mail Exchanger Records)1 Anzahl der Mailserver
1smtp.google.com.
BIMI (Brand Indicators for Message Identification)
Apex-Domain (Stammdomain) acme-corp.comDNS-Lookups 1/10
Authentifizierungsmatrix und Verarbeitungslogik4 Einträge gesamt
TypHost / NameTTLWert / Record-InhaltAktion
MX@1 (TTL (Time to Live) 3600)smtp.google.com.
TXT@3600v=spf1 include:_spf.google.com ~all
TXTgoogle._domainkey3600v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0w9Z8fGk3wIDAQAB
TXT_dmarc3600v=DMARC1; p=none; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1
Generierte Records 4Sicherheits-Status B (65/100)
DNS-Lookups
1 / 10Innerhalb des DNS-Limits
TXT-Länge & Chunks
RSA-2048Einzeiliger TXT-String
Sicherheits-Score
Policy-Präfixnone100% Rollout aktiv

Clientseitige Verarbeitung

Hochperformante Validierung und Schlüsselgenerierung direkt im Browserspeicher.

Zero-Server-Upload Datenschutz

Alle Daten und kryptografischen Schlüssel verbleiben strikt lokal ohne Serverübertragung.

Produktionsreifer Export

Saubere, syntaktisch geprüfte BIND-Zonendateien für den sofortigen Produktiveinsatz.

Technische Referenz & Architektur-Leitfaden

E-Mail DNS Generator (SPF & DMARC) — Referenzhandbuch

Erstellen Sie vollständige E-Mail-DNS-Einträge für SPF, DKIM, DMARC, MX und BIMI. BIND-Zonendateien exportieren, Phishing abwehren und maximale Zustellbarkeit sichern.

E-Mail DNS Generator (SPF & DMARC) — Referenzhandbuch — Client-seitige In-Memory-Architektur und Datenfluss
E-Mail DNS Generator (SPF & DMARC) — Referenzhandbuch — Client-seitige In-Memory-Architektur und Datenfluss

Wichtige Parameter & Einstellungen

v=spf1 (Sender-Policy-Framework-Version)String ("v=spf1")

Kennzeichnet den TXT-Eintrag als SPF-Versionsrichtlinie nach RFC 7208. Muss zwingend als erstes Präfix-Tag im Eintrag stehen; vorangestellte Zeichen oder Kleinschreibung führen dazu, dass empfangende MTAs die Syntax als PermError verwerfen.

Standard: v=spf1
include (Autorisierte SPF-Domain-Delegierungen)Domain-String-Liste ("include:domain.de")

Delegiert die SPF-Autorisierung an den SPF-Eintrag eines Drittanbieter-Versanddienstes. Jede include-Anweisung löst eine rekursive DNS-Abfrage aus und zählt direkt gegen das verbindliche 10-DNS-Lookup-Limit nach RFC 7208.

Standard: _spf.google.com
all (SPF-Fallback-Qualifier)Enum ("-all" | "~all" | "?all" | "+all")

Legt die Richtlinienbehandlung für Nachrichten fest, die von nicht autorisierten IP-Adressen stammen. -all erzwingt eine harte Ablehnung (Hard Fail); ~all signalisiert Soft Fail (akzeptiert, aber verdächtig); ?all definiert ein neutrales Verhalten.

Standard: ~all
k & p (DKIM-Schlüsselalgorithmus & Public-Key)Enum ("rsa" | "ed25519") & Base64-Schlüsselstring

Wird im TXT-Eintrag unter <selector>._domainkey.<domain> publiziert. Definiert den kryptografischen Algorithmus k und den base64-kodierten öffentlichen Schlüssel p, mit dem empfangende MTAs DKIM-Signature-Header gemäß RFC 6376 und RFC 8463 validieren.

Standard: k=rsa; p=...
p & sp (DMARC-Richtlinie & Subdomain-Richtlinie)Enum ("none" | "quarantine" | "reject")

Steuert, wie empfangende Mailserver Nachrichten behandeln, die das DMARC-Alignment gemäß RFC 7489 verfehlen. none sammelt Telemetrieberichte ohne Filterung; quarantine leitet fehlerhafte Mails in den Spam-Ordner um; reject weist die Zustellung komplett ab.

Standard: none
rua & ruf (DMARC-Reporting-URIs für Feedback)URI-Liste (mailto:[email protected])

rua empfängt tägliche aggregierte XML-Telemetrieberichte über Versandvolumen und Authentifizierungsraten; ruf empfängt forensische Echtzeit-Fehlermeldungen bei Authentifizierungsbrüchen im RFC-6591-AFRF-Format.

Standard: mailto:[email protected]
aspf & adkim (DMARC-Identifier-Abgleichsmodi)Enum ("r" | "s")

r (relaxed) erlaubt eine Abstimmung von Subdomains auf die übergeordnete Organisationsdomain; s (strict) verlangt eine exakte Byte-für-Byte-Übereinstimmung zwischen der sichtbaren RFC 5322 From-Domain und dem SPF-Return-Path bzw. der DKIM-Domain (d=).

Standard: r
BIMI-Speicherort & Zertifikatsautorität (l= & a= Tags)HTTPS-URI-String

Wird unter default._bimi.<domain> veröffentlicht. Das l=-Tag verweist auf ein quadratisches Markenlogo im Profil SVG Tiny Portable/Secure; das a=-Tag referenziert optional ein Verified Mark Certificate (VMC) im PEM-Format.

Standard: Keine

Profi-Tipps & Best Practices

Das fatale 10-DNS-Lookup-Limit bei SPF vermeiden

RFC 7208 begrenzt SPF-Prüfungen strikt auf maximal 10 DNS-Abfragen über die Direktiven include, a, mx, ptr und redirect hinweg. Wird das Limit überschritten, resultiert dies in einem permanenten PermError, woraufhin große Mailprovider (Gmail, Microsoft 365, Yahoo) Ihre E-Mails als nicht authentifiziert oder Spam einstufen. Verwenden Sie direkte IPv4/IPv6-CIDR-Blöcke statt dynamischer a- oder mx-Tags und reduzieren Sie verschachtelte include-Ketten externer Dienstanbieter durch regelmäßiges Flattening.

2048-Bit-DKIM-Schlüssel für BIND und DNS-Server aufteilen

DNS-TXT-Einträge erzwingen nach RFC 1035 ein Zeichenlimit von maximal 255 Oktetts pro Teilzeichenkette. Standardmäßige 2048-Bit-RSA-Schlüssel erzeugen jedoch rund 400 Base64-Zeichen. Kürzen Sie den Schlüssel niemals ab, sondern teilen Sie die Zeichenkette in zusammenhängende Anführungszeichen auf: ("v=DKIM1; k=rsa; p=ERSTE_200_ZEICHEN" "RESTLICHE_ZEICHEN"). Moderne DNS-Provider wie Cloudflare teilen dies im Hintergrund automatisch auf; in BIND-Zonendateien ist die explizite Klammerung mit getrennten Strings jedoch zwingend erforderlich.

DMARC schrittweise in 3 Phasen produktiv ausrollen

Setzen Sie auf Produktiv-Domains niemals direkt p=reject. Starten Sie für 2 bis 4 Wochen mit p=none; rua=mailto:..., um alle legitimen Schatten-IT-Versender (CRM-Systeme, Ticket-Tools, Buchhaltung, Newsletter) über RUA-Telemetriedaten zu identifizieren. Wechseln Sie anschließend zu p=quarantine mit schrittweiser Steigerung über das pct-Tag (z. B. pct=25 bis pct=100). Sobald sämtliche legitimen E-Mail-Ströme SPF- und DKIM-konform signiert sind, aktivieren Sie die strikte Richtlinie p=reject; sp=reject.

Subdomain-Spoofing gezielt mit sp=reject unterbinden

Angreifer nutzen für Phishing-Kampagnen häufig ungenutzte Subdomains (z. B. rechnung.ihredomain.de). Wenn Ihre Hauptdomain während der Einführungsphase noch auf p=none läuft, ergänzen Sie den Eintrag explizit um sp=reject. Dadurch sperren Sie unkonfigurierte Subdomains sofort für Angreifer, während der reguläre E-Mail-Verkehr Ihrer Hauptdomain unberührt und risikofrei weiterläuft.

Häufige Fehlerquellen & Fehlerbehebung

⚠️DMARC-Alignment schlägt fehl, obwohl SPF und DKIM jeweils PASS melden

Ein rein technisches Bestehen der Prüfungen reicht für DMARC nicht aus; entscheidend ist der Identitätsabgleich (Identifier Alignment). Überprüfen Sie, ob die für den Empfänger sichtbare Domain im From:-Header (RFC 5322) mit der Return-Path-Domain (RFC 5321 Mail From) für SPF oder dem d=-Tag in der DKIM-Signatur übereinstimmt. Richten Sie beim Versand über Drittanbieter (wie Mailchimp, SendGrid oder Zendesk) eigene DKIM-Schlüssel und eine dedizierte Return-Path-Subdomain (via CNAME) ein, damit die Header direkt Ihrer Unternehmensdomain zugeordnet werden.

⚠️Gmail und Yahoo lehnen E-Mails mit Fehler 550-5.7.26 (Authentication Checks Failed) ab

Seit Februar 2024 fordern Google und Yahoo zwingend gültiges SPF, DKIM und DMARC für alle Massenversender (ab 5.000 Nachrichten täglich). Stellen Sie sicher, dass für Ihre Domain ein aktiver DMARC-Eintrag (mindestens p=none) publiziert ist, ein valider Reverse-DNS-Eintrag (rDNS/PTR) zum Hostnamen Ihres versendenden Mailservers existiert und bei Massen-Mails ein 1-Klick-Abmeldelink nach RFC 8058 integriert ist. Prüfen Sie zudem zwingend, dass Ihr SPF-Eintrag das Limit von 10 DNS-Lookups nicht überschreitet.

⚠️DNS-Provider meldet Fehler wie String exceeds 255 characters oder ungültige TXT-Syntax

Dieser Fehler tritt auf, wenn ein 2048- oder 4096-Bit-DKIM-Schlüssel in eine DNS-Verwaltungsoberfläche eingefügt wird, die kein automatisches Aufteilen langer Zeichenketten unterstützt. Aktivieren Sie in unserem Generator die Option für die 255-Byte-sichere Aufteilung, um den Schlüssel als formatierte Sequenz mehrerer Teilzeichenketten zu exportieren, oder stellen Sie auf moderne Ed25519-Schlüssel (RFC 8463) um, sofern Ihr Mail Transfer Agent dies unterstützt.

Häufig gestellte Fragen (FAQ)

Wie wirkt sich das SPF-Limit von 10 DNS-Lookups auf die E-Mail-Zustellbarkeit aus?▼

RFC 7208 schreibt verbindlich vor, dass die Auswertung eines SPF-Eintrags maximal 10 direkte oder geschachtelte DNS-Abfragen über die Mechanismen include:, a, mx, ptr, exists: und redirect umfassen darf. Löst eine eingehende E-Mail eine elfte Abfrage aus, bricht der empfangende Mailserver (MTA) die Validierung sofort mit einem permanenten Fehler (PermError) ab. Führende E-Mail-Provider wie Google Workspace, Microsoft 365 und Yahoo werten einen PermError als Authentifizierungsfehlschlag, wodurch Nachrichten im Spam-Ordner landen oder direkt abgewiesen werden. Um das Limit einzuhalten, sollten überflüssige a- und mx-Mechanismen entfernt, IP-Adressbereiche als direkte ip4:- und ip6:-CIDR-Blöcke hinterlegt und verschachtelte SaaS-Dienste konsolidiert werden.

Warum schlägt das DMARC-Alignment fehl, obwohl SPF und DKIM als bestanden gelten?▼

Für ein erfolgreiches DMARC-Ergebnis reicht es nicht aus, dass SPF oder DKIM technisch gültig sind. Entscheidend ist das Identitäts-Alignment: Die authentifizierte Domain muss exakt mit der im E-Mail-Programm sichtbaren Absenderadresse im From:-Header (RFC 5322) übereinstimmen. Beim Versand über Drittanbieter wie SendGrid, Salesforce oder HubSpot ohne eigenes Domain-Branding besteht SPF typischerweise für die Domain des Anbieters (z. B. sendgrid.net im Return-Path) und DKIM nutzt dessen Schlüssel – keine davon passt jedoch zu Ihrer Unternehmensdomain. Da die Domains voneinander abweichen, schlägt das DMARC-Alignment fehl. Zur Behebung müssen Sie eine eigene Return-Path-Subdomain für SPF per CNAME konfigurieren und dedizierte DKIM-Schlüssel hinterlegen, die Signaturen direkt im Namen Ihrer Domain ausstellen.

Wie werden 2048-Bit-DKIM-Schlüssel über 255 Zeichen in DNS-TXT-Einträgen aufgeteilt?▼

Nach RFC 1035 darf eine einzelne Zeichenkette (Character-String) innerhalb eines DNS-TXT-Eintrags maximal 255 Oktetts lang sein. Ein base64-kodierter 2048-Bit-RSA-Schlüssel umfasst jedoch rund 400 Zeichen und muss daher in zwei oder mehr Teilstrings aufgeteilt werden. In BIND-Zonendateien und PowerDNS erfolgt dies durch Klammerung des gesamten Eintrags und separate Anführungszeichen für jeden Teilstring: ( "v=DKIM1; k=rsa; p=TEIL_1" "TEIL_2" ). DNS-Resolver setzen diese aneinandergrenzenden Teilstrings bei Abfragen automatisch und ohne Leerzeichen zu einem Gesamtschlüssel zusammen. Moderne DNS-Provider wie Cloudflare, AWS Route 53 oder Hetzner führen diese Aufteilung bei langen Strings oft automatisch durch, während ältere Verwaltungsoberflächen eine manuelle Aufteilung verlangen.

Was unterscheidet die DMARC-Richtlinien p=none, p=quarantine und p=reject?▼

Das p=-Tag definiert die verbindliche Aktion, die empfangende Mailserver ausführen müssen, wenn eine E-Mail unter Ihrem Domainnamen das DMARC-Alignment verfehlt. p=none ist ein reiner Überwachungsmodus: E-Mails werden regulär zugestellt, während aggregierte XML-Telemetrieberichte an Ihre rua=-Adresse gesendet werden. p=quarantine weist empfangende Server an, nicht konforme E-Mails in den Spam- oder Quarantäne-Ordner des Empfängers zu verschieben, was Phishing eindämmt und eine manuelle Überprüfung ermöglicht. p=reject ist die höchste Sicherheitsstufe: Empfangende Mailserver weisen nicht konforme E-Mails bereits während des SMTP-Dialogs mit einem 550-Fehlercode endgültig ab, sodass gefälschte Mails den Empfänger niemals erreichen.

Wie werden BIMI-Einträge mit Verified Mark Certificate (VMC) für Gmail und Apple Mail eingerichtet?▼

Brand Indicators for Message Identification (BIMI) blendet verifizierte Markenlogos im Posteingang von Gmail, Apple Mail und Yahoo ein. Die Umsetzung erfolgt in vier Schritten: 1) Durchsetzung einer aktiven DMARC-Richtlinie mit mindestens p=quarantine (und pct=100) oder p=reject auf der Versanddomain; 2) Erstellung eines quadratischen Vektorlogos, das strikt dem Standard SVG Tiny Portable/Secure entspricht (keine externen Skripte, keine Animationen, valides XML); 3) Erwerb eines Verified Mark Certificate (VMC) bei einer zugelassenen Zertifizierungsstelle (z. B. DigiCert oder Entrust) zur Bestätigung der eingetragenen Wort-Bild-Marke; 4) Veröffentlichung eines DNS-TXT-Eintrags unter default._bimi.ihredomain.de mit dem Inhalt v=BIMI1; l=https://ihredomain.de/bimi-logo.svg; a=https://ihredomain.de/vmc-cert.pem. Während Yahoo Logos teils ohne VMC darstellt, verlangen Gmail und Apple Mail für die Anzeige zwingend ein gültiges VMC.

Verwandte Tools & Hilfsprogramme

Alle Tools →