SPF, DMARC und DKIM: der vollständige Leitfaden zur E-Mail-Authentifizierung

Ihre Domain besteht jeden Sicherheitsscan. Ihr SSL-Zertifikat ist gültig, Ihre Header sind eng, Ihr CSP ist gesperrt. Dann landet eine Phishing-E-Mail von Ihrer Domain aus im Posteingang eines Kunden. Geben Sie im Feld „Von“ Ihren Firmennamen ein. Die E-Mail ist gefälscht, aber der Schaden ist real.

Dies liegt daran, dass E-Mails 1982 ohne integrierte Absenderüberprüfung entwickelt wurden. Jedermann Sie können eine beliebige „Von“-Adresse in einer E-Mail festlegen, und zwar ohne SPF-, DMARC- und DKIM-Einträge Domäne haben empfangende Server keine Möglichkeit, die Fälschung zu erkennen. Über 90 % der Phishing-Angriffe nutzen Domain-Spoofing und falsch konfigurierte E-Mail-Authentifizierung sind die offene Tür.

In diesem Leitfaden wird erläutert, was die einzelnen Datensätze bewirken, wie sie zusammenarbeiten und wie alle drei Datensätze überprüft werden auf jeder Domäne mit einem einzigen Skript unter Verwendung der botoi DNS-Sicherheits-API.

So funktioniert die E-Mail-Authentifizierung

Drei DNS-Einträge dienen als Verteidigungsebene. Jeder löst ein anderes Problem:

1. Lichtschutzfaktor Antworten: „Darf dieser Server E-Mails für diese Domain senden?“
2. DKIM Antworten: „Wurde diese Nachricht verändert, nachdem sie den Server des Absenders verlassen hat?“
3. DMARC Antworten: „Was soll ich tun, wenn SPF oder DKIM fehlschlägt, und wohin kann ich Berichte senden?“

Wenn jemand eine E-Mail sendet und behauptet, von dort zu stammen you@example.com, das Empfangen Der Server prüft diese Datensätze nacheinander. Wenn SPF und DKIM beide ausfallen, sagt DMARC p=reject, wird die Nachricht gelöscht, bevor sie den Posteingang erreicht. Ohne alles Drittens gibt es Lücken, die Angreifer ausnutzen.

SPF: Wer kann in Ihrem Namen senden?

SPF (Sender Policy Framework) ist ein DNS-TXT-Eintrag im Stammverzeichnis Ihrer Domain. Es listet alle auf IP-Adresse und Mailserver, die zum Senden von E-Mails für Ihre Domain berechtigt sind. Wenn ein empfangender Server bekommt eine E-Mail von example.com, prüft es den SPF-Eintrag, um zu sehen, ob das Senden erfolgt Der Server steht auf der genehmigten Liste.

Überprüfen Sie den SPF-Eintrag einer beliebigen Domain mit einem einzigen API-Aufruf:

curl -s -X POST https://api.botoi.com/v1/dns-security/spf-check \\
  -H "Content-Type: application/json" \\
  -d '{"domain": "example.com"}'

Antwort:

{
  "success": true,
  "data": {
    "domain": "example.com",
    "has_spf": true,
    "record": "v=spf1 include:_spf.google.com ~all",
    "mechanisms": ["include:_spf.google.com", "~all"],
    "all_policy": "~all",
    "includes": ["_spf.google.com"],
    "valid": true
  }
}

Die zu überprüfenden Schlüsselfelder:

• has_spf: Führt einen TXT-Datensatz durch, der mit beginnt v=spf1 existieren? Wenn falsch, Jeder Server kann E-Mails von Ihrer Domain fälschen.
• valid: Wird der Datensatz fehlerfrei analysiert? SPF-Einträge werden stillschweigend unterbrochen, wenn Sie überschreiten das Limit von 10 DNS-Suchen.
• all_policy: Der nachgestellte Mechanismus, der definiert, was mit nicht gelisteten Absendern geschieht. -all (harter Fehler) lehnt sie ab. ~all (Soft Fail) markiert sie als verdächtig. +all erlaubt jedem, was den gesamten Zweck zunichte macht.

Das 10-Lookup-Limit

SPF-Einträge erlauben maximal 10 DNS-Suchen. Jede include:, a:, mx:, Und redirect: Der Mechanismus zählt als eine Suche. Verschachtelte Includes zähle auch. Sobald Sie Google Workspace, Ihr Marketing-Tool, Ihren Transaktions-E-Mail-Dienst, hinzugefügt haben, und einem CRM stoßen Sie schnell an diese Grenze.

Wenn Sie mehr als 10 Suchvorgänge durchführen, wird der gesamte SPF-Eintrag ungültig. Die APIs valid Das Feld fängt dies ab. Beheben Sie das Problem, indem Sie verschachtelte Includes in IP-Bereiche reduzieren oder konsolidieren Anbieter.

DMARC: Was tun, wenn Prüfungen fehlschlagen?

DMARC (Domain-based Message Authentication, Reporting, and Conformance) verbindet SPF und DKIM zusammen. Es lebt bei _dmarc.example.com als TXT-Eintrag und meldet den Empfang Server zwei Dinge: Was mit Nachrichten zu tun ist, bei denen die Authentifizierung fehlschlägt, und wohin sie gesendet werden sollen Berichte über diese Misserfolge.

Überprüfen Sie Ihren DMARC-Eintrag:

curl -s -X POST https://api.botoi.com/v1/dns-security/dmarc-check \\
  -H "Content-Type: application/json" \\
  -d '{"domain": "example.com"}'

Antwort:

{
  "success": true,
  "data": {
    "domain": "example.com",
    "has_dmarc": true,
    "record": "v=DMARC1; p=reject; rua=mailto:dmarc@example.com; pct=100",
    "policy": "reject",
    "subdomain_policy": null,
    "reporting": {
      "rua": ["mailto:dmarc@example.com"],
      "ruf": []
    },
    "pct": 100,
    "alignment": {
      "dkim": "r",
      "spf": "r"
    }
  }
}

DMARC-Richtlinien

Der policy Das Feld bestimmt, was mit fehlerhaften Nachrichten passiert:

• none: Keine Maßnahmen ergreifen. Nur überwachen. Sie erhalten Berichte, aber immer noch gefälschte E-Mails Posteingänge erreichen.
• quarantine: Fehlgeschlagene Nachrichten in den Spam verschieben. Der Empfänger kann sie weiterhin finden wenn sie schauen.
• reject: Fehlgeschlagene Nachrichten vollständig löschen. Der stärkste Schutz, aber Eine Fehlkonfiguration bedeutet den Verlust legitimer E-Mails.

Sichere DMARC-Rollout-Strategie

Gehe direkt zu p=reject ist riskant. Folgen Sie diesem Weg:

1. Beginnen Sie mit p=none; rua=mailto:dmarc@example.com um Berichte für 2-4 Wochen zu sammeln
2. Rezensionsberichte. Identifizieren Sie alle legitimen Absender, denen die Authentifizierung fehlschlägt. Korrigieren Sie ihre SPF-Includes und DKIM-Schlüssel.
3. Bewegen Sie sich nach p=quarantine; pct=10 um 10 % der fehlerhaften Nachrichten unter Quarantäne zu stellen
4. Zunahme pct auf 25, 50 und dann 100 in den nächsten Wochen, da Sie bestätigen, dass keine legitimen E-Mails betroffen sind
5. Wechseln Sie zu p=reject; pct=100 Sobald Sie Vertrauen in Ihr Setup haben

Der pct Das Feld in der API-Antwort zeigt Ihnen, wo Sie sich in diesem Rollout befinden. Eine Domäne bei pct=100 mit policy=reject hat vollen Schutz.

DKIM: kryptografische Signaturen in jeder E-Mail

DKIM (DomainKeys Identified Mail) fügt den Headern jeder E-Mail eine kryptografische Signatur hinzu ausgehende Nachricht. Der sendende Server signiert die Nachricht mit einem privaten Schlüssel; der empfangende Server überprüft es anhand eines öffentlichen Schlüssels, der in Ihrem DNS veröffentlicht ist. Wenn die Nachricht während der Übertragung geändert wurde (Kopfzeilen geändert, Hauptteil geändert, über eine Mailingliste weitergeleitet, die den Inhalt neu schreibt), die Signatur schlägt fehl.

DKIM zeichnet live auf [selector]._domainkey.example.com. Der Selektor ist eine Beschriftung Ihr E-Mail-Anbieter weist z. B. zu google für Google Workspace oder selector1 für Microsoft 365.

Überprüfen Sie einen DKIM-Eintrag:

curl -s -X POST https://api.botoi.com/v1/dns-security/dkim-check \\
  -H "Content-Type: application/json" \\
  -d '{"domain": "example.com", "selector": "google"}'

Antwort:

{
  "success": true,
  "data": {
    "domain": "example.com",
    "selector": "google",
    "has_dkim": true,
    "record": "v=DKIM1; k=rsa; p=MIIBIjANBgkq...",
    "key_type": "rsa",
    "public_key_length": 2048
  }
}

Schlüsselfelder:

• has_dkim: Wird für diesen Selektor ein öffentlicher Schlüssel veröffentlicht? Wenn falsch, DKIM Die Überprüfung schlägt für alle mit diesem Selektor signierten Nachrichten fehl.
• public_key_length: NIST empfiehlt mindestens 2048 Bit. Schlüssel unter 1024 Bits sind schwach genug, um faktorisiert zu werden.
• key_type: RSA ist der Standard. Ed25519 ist schneller und verwendet kürzere Tasten bietet nur begrenzte Unterstützung für E-Mail-Anbieter.

DKIM und E-Mail-Weiterleitung

Aus diesem Grund ist DKIM auch dann wichtig, wenn SPF konfiguriert ist. Wenn jemand Ihre E-Mail weiterleitet, Die IP des Weiterleitungsservers ist nicht in Ihrem SPF-Eintrag enthalten, daher schlägt SPF fehl. Aber die DKIM-Signatur überlebt die Weiterleitung (solange der Inhalt nicht verändert wird). DMARC besteht, wenn entweder SPF oder DKIM stimmt überein, sodass DKIM Ihr Sicherheitsnetz für weitergeleitete Nachrichten ist.

Wie die drei zusammenarbeiten

Gefahr	Lichtschutzfaktor	DKIM	DMARC
Gefälschte E-Mail von einem nicht autorisierten Server	Erkennt	Erkennt (keine gültige Signatur)	Setzt Richtlinien durch
Der Nachrichtentext wurde während der Übertragung manipuliert	Wird nicht erkannt	Erkennt	Setzt Richtlinien durch
E-Mail vom legitimen Absender weitergeleitet	Schlägt fehl (andere Server-IP)	Ausweise (Unterschrift intakt)	Besteht, wenn DKIM übereinstimmt
Subdomain-Spoofing (user@fake.example.com)	Kein Schutz	Kein Schutz	Blöcke über sp=reject
Einblick in Authentifizierungsfehler	Keiner	Keiner	Sendet aggregierte Berichte

Kein einzelner Datensatz bietet eine vollständige Abdeckung. SPF ohne DMARC bedeutet, dass Fehler nicht erzwungen werden. DKIM ohne SPF bedeutet, dass jeder mit einem gültigen Schlüssel von Ihrer Domain aus senden kann. DMARC ohne beides Gegen SPF und DKIM gibt es nichts, wogegen man etwas durchsetzen könnte.

Prüfen Sie Ihre Domain in 30 Sekunden

Dieses Shell-Skript prüft alle drei Datensätze und druckt eine Bestanden/Nicht bestanden-Zusammenfassung. Es nutzt die Botoi DNS-Sicherheits-API; Für bis zu 5 Anfragen pro Minute ist kein API-Schlüssel erforderlich.

#!/bin/bash
# Audit SPF, DMARC, and DKIM for a domain in 30 seconds
DOMAIN=\${1:-"example.com"}
DKIM_SELECTOR=\${2:-"google"}
API="https://api.botoi.com/v1/dns-security"
PASS=0
FAIL=0

echo "Auditing email authentication for \$DOMAIN"
echo "==========================================="

# SPF check
SPF=\$(curl -s -X POST "\$API/spf-check" \\
  -H "Content-Type: application/json" \\
  -d "{\\"domain\\": \\"\$DOMAIN\\"}")

HAS_SPF=\$(echo "\$SPF" | jq -r '.data.has_spf')
SPF_VALID=\$(echo "\$SPF" | jq -r '.data.valid')
SPF_RECORD=\$(echo "\$SPF" | jq -r '.data.record // "not found"')
ALL_POLICY=\$(echo "\$SPF" | jq -r '.data.all_policy // "none"')

if [ "\$HAS_SPF" = "true" ] && [ "\$SPF_VALID" = "true" ]; then
  echo "[PASS] SPF: \$SPF_RECORD"
  PASS=\$((PASS + 1))
else
  echo "[FAIL] SPF: \$SPF_RECORD"
  FAIL=\$((FAIL + 1))
fi

if [ "\$ALL_POLICY" = "+all" ]; then
  echo "  WARNING: +all allows any server to send as your domain"
fi

# DMARC check
DMARC=\$(curl -s -X POST "\$API/dmarc-check" \\
  -H "Content-Type: application/json" \\
  -d "{\\"domain\\": \\"\$DOMAIN\\"}")

HAS_DMARC=\$(echo "\$DMARC" | jq -r '.data.has_dmarc')
POLICY=\$(echo "\$DMARC" | jq -r '.data.policy // "not set"')
PCT=\$(echo "\$DMARC" | jq -r '.data.pct // 0')

if [ "\$HAS_DMARC" = "true" ]; then
  echo "[PASS] DMARC: policy=\$POLICY pct=\$PCT%"
  PASS=\$((PASS + 1))
else
  echo "[FAIL] DMARC: no record found"
  FAIL=\$((FAIL + 1))
fi

if [ "\$POLICY" = "none" ]; then
  echo "  WARNING: policy=none only monitors, does not enforce"
fi

# DKIM check
DKIM=\$(curl -s -X POST "\$API/dkim-check" \\
  -H "Content-Type: application/json" \\
  -d "{\\"domain\\": \\"\$DOMAIN\\", \\"selector\\": \\"\$DKIM_SELECTOR\\"}")

HAS_DKIM=\$(echo "\$DKIM" | jq -r '.data.has_dkim')
KEY_TYPE=\$(echo "\$DKIM" | jq -r '.data.key_type // "unknown"')
KEY_LEN=\$(echo "\$DKIM" | jq -r '.data.public_key_length // 0')

if [ "\$HAS_DKIM" = "true" ]; then
  echo "[PASS] DKIM: selector=\$DKIM_SELECTOR key_type=\$KEY_TYPE key_length=\$KEY_LEN"
  PASS=\$((PASS + 1))
else
  echo "[FAIL] DKIM: no record for selector '\$DKIM_SELECTOR'"
  FAIL=\$((FAIL + 1))
fi

if [ "\$HAS_DKIM" = "true" ] && [ "\$KEY_LEN" -lt 2048 ] 2>/dev/null; then
  echo "  WARNING: DKIM key is \$KEY_LEN bits (2048 recommended)"
fi

# Summary
echo ""
echo "Results: \$PASS passed, \$FAIL failed"
[ "\$FAIL" -eq 0 ] && echo "All checks passed." || exit 1

Führen Sie es aus:

bash audit.sh example.com google

Das erste Argument ist Ihre Domain; Der zweite ist Ihr DKIM-Selektor. Das Skript erstellt 3 APIs Aufrufe (innerhalb des kostenlosen Kontingents), prüft jeden Datensatz, markiert Warnungen für schwache Konfigurationen, und wird mit einem Code ungleich Null beendet, wenn eine Prüfung fehlschlägt. Legen Sie es in einem Cron-Job oder einer CI-Pipeline ab zur laufenden Überwachung.

Wenn Sie JavaScript bevorzugen, finden Sie hier die gleiche Prüfung wie bei einer asynchronen Funktion:

async function auditEmailAuth(domain, dkimSelector = "google") {
  const api = "https://api.botoi.com/v1/dns-security";
  const headers = { "Content-Type": "application/json" };

  const [spf, dmarc, dkim] = await Promise.all([
    fetch(\`\${api}/spf-check\`, {
      method: "POST",
      headers,
      body: JSON.stringify({ domain }),
    }).then((r) => r.json()),

    fetch(\`\${api}/dmarc-check\`, {
      method: "POST",
      headers,
      body: JSON.stringify({ domain }),
    }).then((r) => r.json()),

    fetch(\`\${api}/dkim-check\`, {
      method: "POST",
      headers,
      body: JSON.stringify({ domain, selector: dkimSelector }),
    }).then((r) => r.json()),
  ]);

  return {
    domain,
    spf: {
      exists: spf.data.has_spf,
      valid: spf.data.valid,
      record: spf.data.record,
      allPolicy: spf.data.all_policy,
    },
    dmarc: {
      exists: dmarc.data.has_dmarc,
      policy: dmarc.data.policy,
      pct: dmarc.data.pct,
      reporting: dmarc.data.reporting?.rua || [],
    },
    dkim: {
      exists: dkim.data.has_dkim,
      selector: dkimSelector,
      keyType: dkim.data.key_type,
      keyLength: dkim.data.public_key_length,
    },
  };
}

// Usage
const report = await auditEmailAuth("example.com", "google");
console.log(JSON.stringify(report, null, 2));

Gängige Anbieterkonfigurationen

Jeder E-Mail-Anbieter verfügt über eine eigene SPF-Einbindungsdomäne und einen eigenen DKIM-Selektor. Hier sind die Werte für die gängigsten Anbieter:

Anbieterin	SPF enthalten	DKIM-Selektor(en)
Google Workspace	include:_spf.google.com	google
Microsoft 365	include:spf.protection.outlook.com	selector1, selector2
Amazon SES	include:amazonses.com	UUID-basiert (überprüfen Sie die SES-Konsole)
SendGrid	include:sendgrid.net	s1, s2
Stempel	include:spf.mtasv.net	Pro Domain (überprüfen Sie die Postmark-DNS-Einstellungen)
Mailchimp / Mandrill	include:servers.mcsv.net	k1

Wenn Sie mehrere Anbieter nutzen, enthält Ihr SPF-Eintrag alle in einem einzigen TXT-Eintrag. Zum Beispiel: v=spf1 include:_spf.google.com include:sendgrid.net ~all. Beobachten Sie das 10-Suchen-Limit, wenn Sie Anbieter hinzufügen.

Wichtige Punkte

• Lichtschutzfaktor steuert, welche Server E-Mails für Ihre Domain senden können. Überprüfen Sie es mit die /v1/dns-security/spf-check Endpunkt. Achten Sie auf das 10-Lookup-Limit und vermeiden +all.
• DMARC Definiert, was passiert, wenn SPF oder DKIM fehlschlägt. Nach und nach ausrollen p=none Zu p=reject mit der pct Feld. Immer eingestellt a rua Adresse für den Empfang von Berichten.
• DKIM beweist die Nachrichtenintegrität mit kryptografischen Signaturen. Verwenden Sie 2048-Bit Geben Sie mindestens die erforderlichen Schlüssel ein und vergewissern Sie sich, dass Ihr Selektor mit veröffentlicht ist /v1/dns-security/dkim-check.
• Alle drei Datensätze arbeiten zusammen. SPF allein verhindert nicht das Weiterleiten von E-Mail-Spoofing. DKIM allein sagt den Empfängern nicht, was sie bei einem Fehler tun sollen. DMARC ohne SPF und DKIM hat nichts durchzusetzen.
• Automatisieren Sie Ihre Schecks. Führen Sie das Prüfskript nach einem Zeitplan oder in CI aus, um DNS-Drift und Anbieter abzufangen Migrationen und versehentliche Datensatzlöschungen, bevor sie die Zustellbarkeit beeinträchtigen.