E-Mail Authentifizierung —
alle Begriffe erklärt.

adkim steht für Alignment Mode for DKIM und ist ein Parameter im DMARC-Record. Er bestimmt wie streng die Übereinstimmung zwischen der From:-Absenderadresse und der DKIM-signierten Domain geprüft wird.

adkim=r (Relaxed, empfohlen): Subdomains sind erlaubt. newsletter.firma.de gilt als übereinstimmend mit firma.de.

adkim=s (Strict): Exakte Übereinstimmung erforderlich. newsletter.firma.de ≠ firma.de — DMARC-Alignment schlägt fehl.

Für die meisten Unternehmen ist adkim=r die richtige Wahl, da viele E-Mail-Dienstleister von Subdomains aus senden.

Alignment beschreibt ob die im From:-Header sichtbare Absenderdomain mit der technisch authentifizierten Domain übereinstimmt. DMARC verlangt dieses Alignment für SPF oder DKIM — sonst schlägt der DMARC-Check fehl, selbst wenn SPF und DKIM einzeln bestanden werden.

Eine Mail kann SPF-Pass haben (die sendende IP ist autorisiert) aber DMARC-Fail (weil die authentifizierte Domain nicht zur From:-Domain passt). Das ist ein häufiger Konfigurationsfehler bei der Nutzung externer ESPs.

aspf steht für Alignment Mode for SPF und funktioniert analog zu adkim — nur für SPF. Er bestimmt ob die Envelope-From-Domain (technische Absenderdomain) mit der Header-From-Domain (sichtbare Absenderdomain) übereinstimmen muss.

aspf=r (Relaxed, empfohlen): Subdomains sind erlaubt.

aspf=s (Strict): Exakte Übereinstimmung nötig.

BIMI ist ein Standard der es Unternehmen ermöglicht, ihr Logo direkt im Posteingang des Empfängers anzuzeigen — noch bevor die Mail geöffnet wird. Unterstützt von Gmail, Apple Mail, Yahoo und weiteren Anbietern.

Voraussetzungen: DMARC muss auf p=quarantine oder p=reject stehen. Das Logo muss im SVG Tiny PS Format vorliegen. Bei Gmail ist zusätzlich ein VMC (Verified Mark Certificate) von einer akkreditierten Zertifizierungsstelle erforderlich (ca. 1.000–1.500 €/Jahr).

Wann sinnvoll: Für Unternehmen mit starker Markenidentität und aktivem E-Mail-Marketing, die bereits alle anderen Authentication-Standards korrekt konfiguriert haben.

Eine Blacklist (auch RBL, DNSBL oder Sperrliste) ist eine öffentlich zugängliche Liste von IP-Adressen oder Domains, von denen bekannt ist oder vermutet wird, dass sie Spam versenden. Empfangende Mailserver prüfen eingehende Mails automatisch gegen diese Listen.

Domain-Blacklists (DBL) wie die Spamhaus DBL prüfen die Domain selbst — unabhängig von der sendenden IP. Eine Listung hier betrifft alle Mails von dieser Domain, auch über externe ESPs.

IP-Blacklists prüfen die sendende IP-Adresse. Bei Shared IPs (ESP-Servern) können auch harmlose Absender betroffen sein, wenn ein anderer Nutzer derselben IP Spam versendet hat.

Bekannte Blacklists: Spamhaus SBL/XBL/DBL, Barracuda BRBL, Microsoft SNDS, SURBL, URIBL.

Bounces sind automatische Rückmeldungen dass eine E-Mail nicht zugestellt werden konnte.

Hard Bounce: Permanenter Fehler — die Adresse existiert nicht (mehr). Diese Adressen müssen sofort aus der Versandliste entfernt werden. Hohe Hard-Bounce-Raten schädigen die Sender Reputation dauerhaft.

Soft Bounce: Temporärer Fehler — Postfach voll, Server vorübergehend nicht erreichbar. Meist automatisch nach einigen Versuchen erneut zugestellt.

Eine Bounce-Rate über 2% ist ein ernstes Signal dass die Listenhygiene vernachlässigt wurde oder die Authentifizierungskonfiguration fehlerhaft ist.

DKIM ist ein kryptografisches Signaturverfahren für E-Mails. Der sendende Mailserver signiert jede ausgehende Mail mit einem privaten Schlüssel. Der Empfänger prüft die Signatur anhand des öffentlichen Schlüssels, der als DNS-Record hinterlegt ist.

Damit wird sichergestellt dass die Mail auf dem Weg vom Absender zum Empfänger nicht verändert wurde und tatsächlich vom angegebenen Mailserver stammt.

Selektor: DKIM-Records werden unter einem Selektor abgelegt (z.B. google, mail, k1). Eine Domain kann mehrere DKIM-Selektoren für verschiedene ESPs haben.

Schlüssellänge: Mindestens 2048 Bit — ältere 1024-Bit-Schlüssel gelten als unsicher und sollten rotiert werden.

DMARC ist das übergeordnete Protokoll das SPF und DKIM zusammenführt und dem Domaininhaber die Kontrolle darüber gibt, wie Empfänger mit nicht-authentifizierten Mails umgehen sollen.

Die drei Policies:

p=none — Nur beobachten, keine Aktion. Reports werden gesendet aber Mails werden nicht blockiert. Startpunkt für die Konfiguration.

p=quarantine — Nicht-konforme Mails landen im Spam-Ordner.

p=reject — Nicht-konforme Mails werden komplett abgewiesen. Maximaler Schutz.

Seit Februar 2024 verlangen Google und Yahoo DMARC für alle Bulk-Sender (5.000+ Mails/Tag). Microsoft folgte im Mai 2025. PCI DSS 4.0 macht DMARC seit März 2025 zur Pflicht für alle Zahlungsdienstleister.

DNSSEC ist eine Erweiterung des DNS-Systems die alle DNS-Records kryptografisch signiert. Damit wird verhindert dass Angreifer DNS-Records fälschen und z.B. SPF-, DKIM- oder DMARC-Einträge manipulieren (DNS Cache Poisoning).

Ohne DNSSEC könnte ein Angreifer theoretisch den DMARC-Record einer Domain auf p=none zurücksetzen oder einen gefälschten SPF-Record einschleusen — und damit die gesamte E-Mail-Authentifizierung aushebeln.

DNSSEC ist die Sicherheitsebene unter SPF/DKIM/DMARC und sollte bei jedem seriösen E-Mail-Setup aktiviert sein. Die Einrichtung erfolgt beim Domainregistrar und erfordert die Koordination zwischen Registrar und DNS-Provider.

Der Envelope-From ist die technische Absenderadresse die im SMTP-Protokoll übertragen wird — unsichtbar für den Empfänger. Sie wird für Bounce-Benachrichtigungen und SPF-Prüfungen verwendet.

Im Gegensatz dazu ist der Header-From die sichtbare Absenderadresse im E-Mail-Client. DMARC prüft ob Envelope-From und Header-From zur selben Domain gehören (Alignment). Viele ESPs setzen den Envelope-From auf ihre eigene Domain, was DMARC-Alignment-Probleme verursachen kann.

Ein ESP ist ein Dienstleister für den Massenversand von E-Mails — typischerweise für Newsletter, Marketing-Kampagnen oder Transaktionsmails. Bekannte ESPs: Brevo (ehem. Sendinblue), Mailchimp, HubSpot, Klaviyo, Postmark, SendGrid.

Shared IP vs. Dedizierte IP: Im Günstigsegment teilen sich viele Kunden dieselbe IP-Adresse. Das kann die eigene Zustellbarkeit beeinflussen wenn andere Nutzer dieser IP Spam versenden. Ab einem gewissen Versandvolumen (meist 50.000+ Mails/Monat) empfiehlt sich eine dedizierte IP.

Wichtig für die Konfiguration: Jeder ESP muss explizit im SPF-Record der Domain eingetragen und mit einem eigenen DKIM-Selektor konfiguriert sein. Fehlt das, schlägt DMARC-Alignment fehl.

Der Header-From ist die Absenderadresse die im E-Mail-Client sichtbar ist — also die Adresse die der Empfänger sieht. DMARC verwendet ausschließlich den Header-From als Referenzpunkt für Alignment-Prüfungen.

Das ist der entscheidende Unterschied zu SPF: SPF prüft den technischen Envelope-From, DMARC verlangt dass dieser zur sichtbaren Header-From-Domain passt. Stimmen beide nicht überein, schlägt DMARC-Alignment fehl — selbst wenn SPF technisch korrekt konfiguriert ist.

Der SPF-Standard (RFC 7208) erlaubt maximal 10 DNS-Lookups pro SPF-Auswertung. Wird diese Grenze überschritten, gibt SPF den Fehler permerror zurück — die Mail verhält sich als hätte sie keinen SPF-Record.

Jedes include:, a:, mx: oder exists: im SPF-Record kostet einen Lookup. Das Problem: Die eingebundenen Includes können selbst wieder Includes enthalten, die ebenfalls zählen.

Die Lösung: SPF-Flattening — alle Include-Ketten werden aufgelöst und durch direkte IP-Adressen ersetzt. Diese zählen nicht gegen das Lookup-Limit.

Der MX-Record (Mail Exchanger) ist ein DNS-Eintrag der angibt welcher Mailserver für den Empfang von E-Mails einer Domain zuständig ist. Ohne korrekte MX-Records können keine Mails an die Domain empfangen werden.

Mehrere MX-Records mit unterschiedlichen Prioritäten (niedrigere Zahl = höhere Priorität) ermöglichen Redundanz: Wenn der primäre Mailserver nicht erreichbar ist, übernimmt automatisch der nächste.

Korrekte MX-Records sind auch eine Voraussetzung für einen validen PTR/Reverse-DNS-Eintrag und werden von manchen Mailservern als Vertrauenssignal gewertet.

Der pct-Parameter im DMARC-Record bestimmt auf wie viel Prozent der nicht-konformen Mails die DMARC-Policy angewendet wird. Er ermöglicht einen schrittweisen, risikoarmen Rollout von DMARC.

Bei p=quarantine; pct=10 werden nur 10% der nicht-konformen Mails in den Spam-Ordner verschoben — die restlichen 90% werden normal zugestellt. So kann die Auswirkung der Policy beobachtet werden bevor sie vollständig durchgesetzt wird.

Empfohlener Rollout: pct=10 → pct=25 → pct=50 → pct=100, jeweils mit 1–2 Wochen Beobachtungszeit.

Ein normaler DNS-Record löst einen Domainnamen zu einer IP-Adresse auf. Ein PTR-Record macht das Gegenteil: Er löst eine IP-Adresse zurück zu einem Hostnamen auf (Reverse-DNS).

Empfangende Mailserver prüfen ob die IP des sendenden Servers einen gültigen PTR-Record hat und ob dieser mit dem Hostnamen im SMTP-Greeting übereinstimmt (Forward-Confirmed Reverse DNS, FCrDNS). Fehlt der PTR-Record oder stimmt er nicht überein, gilt das als starkes Spam-Signal.

Wer PTR-Records setzt: Nicht der Domaininhaber, sondern der Hoster der die IP-Adresse vergibt. Bei Google Workspace und Microsoft 365 ist der PTR automatisch korrekt konfiguriert. Bei eigenen Mailservern muss der PTR beim Hoster beantragt werden.

Für shared ESPs: Der PTR-Record der ESP-Server ist in der Verantwortung des ESPs — kein direkter Handlungsbedarf für den Kunden.

Die Sender Reputation ist ein Score den Mailbox-Provider wie Google, Microsoft und Yahoo einer sendenden Domain und IP-Adresse zuweisen. Sie ist das wichtigste Kriterium dafür ob eine Mail in der Inbox, im Spam oder gar nicht zugestellt wird.

Einflussfaktoren: Spam-Beschwerden (Complaint Rate), Bounce-Rate, Versandvolumen und -konsistenz, Blacklist-Status, Authentifizierungsstatus (SPF/DKIM/DMARC), Engagement der Empfänger (Öffnungen, Klicks).

Google Postmaster Tools zeigt die Domain-Reputation direkt für Gmail an: High, Medium, Low oder Bad. Eine schlechte Reputation ist schwer zu reparieren und erfordert Wochen bis Monate konsequenter sauberer Versandpraktiken.

Complaint Rate: Google empfiehlt eine Spam-Beschwerderate unter 0,1% und warnt ab 0,3% vor ernsthaften Zustellproblemen.

SPF ist ein DNS-basiertes Verfahren das festlegt welche Mailserver berechtigt sind E-Mails im Namen einer Domain zu versenden. Der Empfänger prüft ob die sendende IP-Adresse im SPF-Record der Absenderdomain aufgelistet ist.

All-Mechanismus: Am Ende jedes SPF-Records steht eine Standardregel für alle nicht explizit genannten IPs.

-all (Hardfail): Alle anderen IPs sind nicht autorisiert — empfohlen wenn alle legitimen Sender bekannt sind.

~all (Softfail): Andere IPs sind wahrscheinlich nicht autorisiert — mildere Behandlung, häufig verwendet während der Konfigurationsphase.

+all: Alle IPs sind autorisiert — gefährlich, niemals verwenden.

Wichtig: SPF hat ein Limit von 10 DNS-Lookups. Bei mehreren ESPs muss dieses Limit im Auge behalten werden.

SPF Flattening ist eine Technik um das SPF Lookup-Limit zu umgehen. Dabei werden alle include:-Direktiven rekursiv aufgelöst und die resultierenden IP-Ranges direkt in den SPF-Record eingetragen. Direkte IP-Adressen (ip4:, ip6:) zählen nicht gegen das Lookup-Limit.

Nachteil: ESPs ändern ihre IP-Ranges gelegentlich. Ein geflatteter SPF-Record muss manuell aktualisiert werden wenn sich die IPs eines ESPs ändern — sonst können legitime Mails plötzlich SPF-Fail haben.

Als Teil eines professionellen E-Mail-Authentication-Setups wird SPF-Flattening mit regelmäßiger Überprüfung kombiniert.

E-Mail Spoofing bezeichnet das Fälschen der Absenderadresse einer E-Mail. Angreifer versenden Mails die aussehen als kämen sie von einer vertrauenswürdigen Domain — etwa von der Geschäftsführung eines Unternehmens oder einer bekannten Marke — um Empfänger zu täuschen (Phishing, CEO-Fraud, BEC).

Das SMTP-Protokoll überprüft Absenderadressen von Haus aus nicht — technisch kann jeder behaupten, von beliebigen Domains zu senden. SPF, DKIM und vor allem DMARC wurden entwickelt um genau das zu verhindern.

Solange DMARC auf p=none steht, können Angreifer weiterhin im Namen der Domain fälschen — die Reports zeigen es, aber es wird nichts blockiert. Erst p=reject verhindert Spoofing zuverlässig.

TLS (Transport Layer Security) verschlüsselt die Verbindung zwischen Mailservern während der Übertragung. Es schützt den Mailinhalt vor Abhören auf dem Transportweg — verhindert aber kein Spoofing (dafür sind SPF/DKIM/DMARC zuständig).

STARTTLS ist eine Erweiterung die eine bestehende unverschlüsselte Verbindung auf TLS upgradet. Google verlangt TLS-verschlüsselte Verbindungen als Grundvoraussetzung für alle Sender.

MTA-STS (Mail Transfer Agent Strict Transport Security) ist ein ergänzender Standard der verhindert dass die TLS-Verschlüsselung durch einen Angreifer deaktiviert wird (Downgrade-Angriff).

IP-Warmup ist der Prozess des schrittweisen Aufbaus einer Sender Reputation für eine neue oder bisher wenig genutzte IP-Adresse. Neue IPs haben keine Versandhistorie — Mailbox-Provider behandeln sie mit Misstrauen.

Beim Warmup wird das Versandvolumen über mehrere Wochen langsam gesteigert: beginnend mit wenigen Hundert Mails täglich, gradual auf die gewünschte Menge erhöht. Dabei ist eine niedrige Beschwerden- und Bounce-Rate entscheidend.

Relevant für: Unternehmen die von Shared IPs auf dedizierte IPs wechseln, neue Domains für Marketingmails einführen oder nach einer Blacklisting-Situation eine neue IP beziehen.

Nicht verwechseln mit der normalen Authentication-Konfiguration — Warmup ist ein eigenständiger Prozess der außerhalb des Scopes von mailauth.de liegt.

E-Mail Zustellbarkeit (Deliverability) beschreibt die Fähigkeit einer E-Mail tatsächlich im Posteingang des Empfängers anzukommen — nicht im Spam-Ordner und nicht abgewiesen zu werden.

Zustellbarkeit hängt von mehreren Faktoren ab:

Technische Infrastruktur (Scope von mailauth.de): SPF, DKIM, DMARC korrekt konfiguriert, PTR/Reverse-DNS, keine Blacklist-Einträge, DNSSEC.

Sender Reputation: Historische Versandqualität, Complaint Rate, Bounce Rate.

Listenhygiene (nicht im Scope von mailauth.de): Einwilligung der Empfänger, regelmäßiges Bereinigen inaktiver Adressen, einfache Abmeldemöglichkeit.

Content (nicht im Scope): Spam-Score des Inhalts, Link-Reputation, HTML-Qualität.

mailauth.de deckt den technischen Infrastruktur-Teil ab — die notwendige Grundlage ohne die alle anderen Maßnahmen wenig nützen.