DMARC: Wie man seinen E-Mail-Ruf schützt
Vogel
13.04.2016
1 min read
Wichtige Erkenntnisse
DMARC hilft, Ihre Domain vor Phishing, Spoofing und unbefugter E-Mail-Nutzung zu schützen, indem Sie Ihre Authentifizierungsmethoden veröffentlichen und eine spezifische Behandlung für fehlgeschlagene Nachrichten anfordern.
Es funktioniert zusammen mit SPF und DKIM, um die Domain-Ausrichtung sicherzustellen und zu verhindern, dass betrügerische Mails Ihren Absender-Ruf schädigen.
Starke DMARC-Richtlinien unterstützen höheres Vertrauen, höhere Engagement-Raten und zukunftssichern Ihre Domain, da das Ökosystem auf domänenbasierte Reputationsmodelle umstellt.
DMARC-Validierungsprüfungen basieren auf der Domain-Ausrichtung zwischen der From-Domain, Return-Path-Domain (SPF) und der DKIM-Signaturdomain.
Das Einrichten von DMARC erfordert den Empfang von Berichten, das Verständnis von Aggregat- vs. forensischen Daten und das Konfigurieren von Tools zu deren Analyse.
Sie beginnen mit einer sicheren p=none Richtlinie, um den Verkehr zu überwachen, bevor Sie zu quarantine oder reject übergehen.
Das Veröffentlichen eines DMARC-Eintrags erfordert die Erstellung eines DNS TXT-Eintrags unter _dmarc.ihredomain.com mit Richtlinien, Berichtsadressen und optionalen Parametern wie Rollout-Prozentsätzen.
Richtige Berichts-Mailboxen (aggregiert + forensisch) und Analysetools sind entscheidend, um die Compliance zu überwachen, Spoofing zu erkennen und sicherzustellen, dass die Ausrichtung korrekt ist.
DMARC erfordert eine der folgenden Bestätigungen, um zu bestehen: ausgerichtetes SPF oder ausgerichtetes DKIM.
Die Implementierung von DMARC stärkt die E-Mail-Sicherheit und spielt eine Schlüsselrolle in der Markenintegrität, im Vertrauen und in der langfristigen Zustellbarkeit.
Q&A Highlights
Was ist DMARC und warum ist es wichtig?
DMARC (Domain-based Message Authentication, Reporting, and Conformance) ist eine im DNS veröffentlichte Richtlinie, die Ihre Domain vor Spoofing und Phishing schützt, indem sie die Domain-Ausrichtung erzwingt und durch Berichterstattung Transparenz ermöglicht.
Ist DMARC ein Authentifizierungsprotokoll?
Nein. DMARC ist nicht selbst die Authentifizierung—es stützt sich auf SPF und DKIM, um E-Mails zu authentifizieren und verwendet Richtlinien + Berichterstattung, um zu steuern, wie empfangende Server bei Ausfällen damit umgehen.
Worauf prüft DMARC?
Es überprüft:
SPF-Authentifizierung + Ausrichtung
DKIM-Authentifizierung + Ausrichtung
Ein Absender benötigt nur eine dieser Methoden, um DMARC erfolgreich zu bestehen.
Was ist „domain alignment“?
Es ist die Anforderung, dass die sichtbare From-Domäne entweder strikt übereinstimmt oder dieselbe organisatorische Domäne teilt (entspannt) mit entweder der SPF Return-Path-Domäne oder der DKIM-Signaturdomäne.
Warum verbessert DMARC die Zustellbarkeit?
Weil Postfachanbieter authentifizierten, ausgerichteten Domains mehr vertrauen. DMARC verhindert, dass gefälschte Nachrichten Ihren Ruf schädigen, und verbessert die Zustellung in den Posteingang für legitime E-Mails.
Was ist der Unterschied zwischen aggregierten und forensischen DMARC-Berichten?
Aggregierte Berichte (RUA): XML-Zusammenfassungen der Authentifizierungsergebnisse über den gesamten Datenverkehr.
Forensische Berichte (RUF): Einzelne Beispiele für fehlgeschlagene Nachrichten zur tieferen Analyse.
Welche Mailboxen benötige ich, bevor ich DMARC veröffentliche?
Sie sollten zwei Adressen erstellen, wie zum Beispiel:
agg_reports@yourdomain.com (RUA)
afrf_reports@yourdomain.com (RUF)
Dadurch bleiben Berichtsströme getrennt und leichter zu analysieren.
Mit welcher DMARC-Richtlinie sollte ich beginnen?
Beginnen Sie immer mit p=none. Es überwacht die Authentifizierungsaktivität, ohne die Zustellung zu beeinträchtigen, sodass Sie Abstimmungsprobleme und Spoofing-Versuche sicher erkennen können.
Welche DMARC-Richtlinien sind verfügbar?
keine: nur überwachen
Quarantäne: fehlgeschlagene Nachrichten als Spam senden
ablehnen: fehlgeschlagene Nachrichten vollständig blockieren
Wo veröffentliche ich einen DMARC record?
In Ihrem DNS bei:
_dmarc.yourdomain.com
Es muss ein TXT-Eintrag sein, der Ihre Richtlinie, Version und Meldeendpunkte angibt.
Wie sieht ein grundlegender DMARC-Eintrag aus?
Beispiel:
v=DMARC1; p=none; rua=mailto:agg_reports@yourdomain.com; ruf=mailto:afrf_reports@yourdomain.com; pct=100
Was passiert, wenn DMARC fehlschlägt?
Der empfangende Server wendet Ihre angeforderte Richtlinie (none, quarantine, reject) an, obwohl die endgültige Handhabung letztendlich beim Anbieter liegt. Eine strikte Richtlinie kann Phishing-Versuche, die Ihre Domain verwenden, erheblich reduzieren.
In diesem Beitrag erfahren Sie alles, was Sie über die Nutzung von DMARC zum Schutz Ihrer E-Mail-Reputation wissen müssen, und erhalten Hinweise zur Einrichtung für Ihre Domains.
In diesem Beitrag erfahren Sie alles, was Sie über die Nutzung von DMARC zum Schutz Ihrer E-Mail-Reputation wissen müssen, und erhalten Hinweise zur Einrichtung für Ihre Domains.
In diesem Beitrag erfahren Sie alles, was Sie über die Nutzung von DMARC zum Schutz Ihrer E-Mail-Reputation wissen müssen, und erhalten Hinweise zur Einrichtung für Ihre Domains.
Ein effektives Werkzeug, um Betrügerische Mail zu bekämpfen
Oft im selben Atemzug wie die E-Mail-Authentifizierungsprotokolle SPF und DKIM erwähnt, ist DMARC, oder Domain-based Message Authentication, Reporting, and Conformance, kein Authentifizierungsprotokoll an sich. Das Ziel von DMARC ist es vielmehr, uns als Domaininhaber die Möglichkeit zu geben, unseren E-Mail-Ruf zu schützen, indem wir:
E-Mail-Authentifizierungspraktiken ankündigen,
Maßnahmen für E-Mails anfordern, die Authentifizierungsprüfungen nicht bestehen, und
Berichte über E-Mails einholen, die vorgeben, von der eigenen Domain zu stammen.
DMARC kann ein effektives Werkzeug für uns sein, um im Kampf gegen betrügerische Mails, die auf unseren Domainnamen abzielen (z.B. Phishing und Spoofing), einzusetzen und das Vertrauen unserer Empfänger in unsere Mails zu erhöhen. Für Organisationen, die eine Ende-zu-Ende-Verschlüsselung über die Authentifizierung hinaus erfordern, bietet die Implementierung von S/MIME mit effizienten Methoden zur Sammlung öffentlicher Empfängerschlüssel zusätzliche Sicherheitsebenen. Dieses höhere Vertrauen sollte wiederum zu einer höheren Interaktion mit unseren Mails führen, und Mails, die geöffnet und angeklickt werden, steigern den Umsatz und den höheren ROI unserer E-Mail-Kampagnen.
Neben dem Schutz unserer Domain prognostizieren wir, dass die Implementierung von DMARC jetzt eine hervorragende Möglichkeit sein wird, unsere Domain „zukunftssicher“ zu gestalten. Hier bei Bird sind wir der Meinung, dass die Branche mit der Umstellung auf IPv6 fast sicher von einem IP-basierten Rufmodell zu einem Domain-basierten Rufmodell wechseln wird. Ein Domain-basierter Ruf erfordert eine Domain-basierte Authentifizierung, und DMARC wird in Zusammenarbeit mit DKIM und SPF Domains helfen, einen Domain-basierten Ruf aufzubauen, lange bevor er absolut erforderlich ist.
In diesem Beitrag erfahren Sie alles, was Sie wissen müssen, um DMARC zu nutzen und Ihren E-Mail-Ruf zu schützen, sowie Tipps, wie Sie es für Ihre Domains einrichten können.
Oft im selben Atemzug wie die E-Mail-Authentifizierungsprotokolle SPF und DKIM erwähnt, ist DMARC, oder Domain-based Message Authentication, Reporting, and Conformance, kein Authentifizierungsprotokoll an sich. Das Ziel von DMARC ist es vielmehr, uns als Domaininhaber die Möglichkeit zu geben, unseren E-Mail-Ruf zu schützen, indem wir:
E-Mail-Authentifizierungspraktiken ankündigen,
Maßnahmen für E-Mails anfordern, die Authentifizierungsprüfungen nicht bestehen, und
Berichte über E-Mails einholen, die vorgeben, von der eigenen Domain zu stammen.
DMARC kann ein effektives Werkzeug für uns sein, um im Kampf gegen betrügerische Mails, die auf unseren Domainnamen abzielen (z.B. Phishing und Spoofing), einzusetzen und das Vertrauen unserer Empfänger in unsere Mails zu erhöhen. Für Organisationen, die eine Ende-zu-Ende-Verschlüsselung über die Authentifizierung hinaus erfordern, bietet die Implementierung von S/MIME mit effizienten Methoden zur Sammlung öffentlicher Empfängerschlüssel zusätzliche Sicherheitsebenen. Dieses höhere Vertrauen sollte wiederum zu einer höheren Interaktion mit unseren Mails führen, und Mails, die geöffnet und angeklickt werden, steigern den Umsatz und den höheren ROI unserer E-Mail-Kampagnen.
Neben dem Schutz unserer Domain prognostizieren wir, dass die Implementierung von DMARC jetzt eine hervorragende Möglichkeit sein wird, unsere Domain „zukunftssicher“ zu gestalten. Hier bei Bird sind wir der Meinung, dass die Branche mit der Umstellung auf IPv6 fast sicher von einem IP-basierten Rufmodell zu einem Domain-basierten Rufmodell wechseln wird. Ein Domain-basierter Ruf erfordert eine Domain-basierte Authentifizierung, und DMARC wird in Zusammenarbeit mit DKIM und SPF Domains helfen, einen Domain-basierten Ruf aufzubauen, lange bevor er absolut erforderlich ist.
In diesem Beitrag erfahren Sie alles, was Sie wissen müssen, um DMARC zu nutzen und Ihren E-Mail-Ruf zu schützen, sowie Tipps, wie Sie es für Ihre Domains einrichten können.
Oft im selben Atemzug wie die E-Mail-Authentifizierungsprotokolle SPF und DKIM erwähnt, ist DMARC, oder Domain-based Message Authentication, Reporting, and Conformance, kein Authentifizierungsprotokoll an sich. Das Ziel von DMARC ist es vielmehr, uns als Domaininhaber die Möglichkeit zu geben, unseren E-Mail-Ruf zu schützen, indem wir:
E-Mail-Authentifizierungspraktiken ankündigen,
Maßnahmen für E-Mails anfordern, die Authentifizierungsprüfungen nicht bestehen, und
Berichte über E-Mails einholen, die vorgeben, von der eigenen Domain zu stammen.
DMARC kann ein effektives Werkzeug für uns sein, um im Kampf gegen betrügerische Mails, die auf unseren Domainnamen abzielen (z.B. Phishing und Spoofing), einzusetzen und das Vertrauen unserer Empfänger in unsere Mails zu erhöhen. Für Organisationen, die eine Ende-zu-Ende-Verschlüsselung über die Authentifizierung hinaus erfordern, bietet die Implementierung von S/MIME mit effizienten Methoden zur Sammlung öffentlicher Empfängerschlüssel zusätzliche Sicherheitsebenen. Dieses höhere Vertrauen sollte wiederum zu einer höheren Interaktion mit unseren Mails führen, und Mails, die geöffnet und angeklickt werden, steigern den Umsatz und den höheren ROI unserer E-Mail-Kampagnen.
Neben dem Schutz unserer Domain prognostizieren wir, dass die Implementierung von DMARC jetzt eine hervorragende Möglichkeit sein wird, unsere Domain „zukunftssicher“ zu gestalten. Hier bei Bird sind wir der Meinung, dass die Branche mit der Umstellung auf IPv6 fast sicher von einem IP-basierten Rufmodell zu einem Domain-basierten Rufmodell wechseln wird. Ein Domain-basierter Ruf erfordert eine Domain-basierte Authentifizierung, und DMARC wird in Zusammenarbeit mit DKIM und SPF Domains helfen, einen Domain-basierten Ruf aufzubauen, lange bevor er absolut erforderlich ist.
In diesem Beitrag erfahren Sie alles, was Sie wissen müssen, um DMARC zu nutzen und Ihren E-Mail-Ruf zu schützen, sowie Tipps, wie Sie es für Ihre Domains einrichten können.
Begriffe, die Sie kennen sollten
Bevor wir mit der Einrichtung von DMARC für Ihre Domain beginnen, möchten wir sicherstellen, dass wir die gleiche Sprache sprechen. Lassen Sie uns mit der Definition einiger Begriffe beginnen, die wir im weiteren Verlauf dieses Dokuments verwenden werden.
RFC5322.From Domain
Die RFC5322.From Domain ist der Domain-Teil der E-Mail-Adresse, der normalerweise vom Empfänger unserer E-Mail gesehen wird, wenn sie gelesen wird. Im folgenden Beispiel ist die RFC5322.From Domain „joesbaitshop.com“.
From: Joe’s Bait and Tackle <sales@joesbaitshop.com>
DKIM d= Domain
DKIM ist ein Authentifizierungsprotokoll, das es einer Domain ermöglicht, die Verantwortung für eine Nachricht zu übernehmen in einer Weise, die vom Empfänger der Nachricht validiert werden kann; dies geschieht durch die Verwendung von kryptographischen Signaturen, die in die Header der Nachricht eingefügt werden, wenn sie ihren Ursprungsort verlässt. Diese Signaturen sind im Wesentlichen Momentaufnahmen davon, wie die Nachricht zu diesem Zeitpunkt aussah, und der Empfänger kann diese Momentaufnahmen verwenden, um zu sehen, ob die Nachricht unverändert an ihrem Ziel angekommen ist. Der Prozess der Erstellung und Einfügung dieser Momentaufnahmen wird als DKIM-Signierung bezeichnet, und die Domain, die die Verantwortung für die Nachricht übernimmt, indem sie diese signiert, fügt ihren Namen in den Header in einem Schlüssel-Wert-Tag als „d=signingDomain“ ein, und so wird sie als DKIM d= Domain bezeichnet.
Return-Path Domain
Die Return-Path Domain, manchmal auch als RFC5321. From Domain oder Mail From Domain bezeichnet, ist die Domain, an die Rückläufer weitergeleitet werden; sie ist auch die Domain, auf der SPF-Überprüfungen während der E-Mail-Transaktion durchgeführt werden. Diese Domain wird normalerweise nicht vom Empfänger gesehen, es sei denn, der Empfänger ist erfahren genug, um alle Header in einer gegebenen Nachricht zu betrachten.
Standardmäßig wird alle über bird.com gesendete Mail birdmail.com als Return-Path Domain haben, wie im folgenden Beispiel:
Return-Path: <msprvs1=16880EmYZo7L3=bounces-2785@birdmail1.com>
Um jedoch DMARC für Ihre Domain funktionsfähig zu machen, möchten Sie eine benutzerdefinierte Rückläufer-Domain nutzen, eine, die mit der gleichen Domain endet wie Ihre Sende-Domain, z.B. bounces.yourdomain.com, wenn Sie yourdomain.com als Ihre Sende-Domain verwenden.
Organizational Domain
Der Begriff „Organizational Domain“ bezieht sich auf die Domain, die einem Registrar vorgelegt wurde, um die Präsenz der Domain im Internet zu erstellen. Für Bird sind unsere organisatorischen Domains bird.com und birdmail.com.
Domain Alignment
Der letzte Begriff, den man im Zusammenhang mit DMARC verstehen muss, ist „Domain Alignment“, und es gibt ihn in zwei Varianten: „entspannt“ und „streng“.
Relaxed Domain Alignment
Jede zwei Domains haben ein entspanntes Domain Alignment, wenn ihre organisatorischen Domains identisch sind. Zum Beispiel haben a.mail.bird.com und b.foo.bird.com ein entspanntes Domain Alignment aufgrund ihrer gemeinsamen organisatorischen Domain bird.com.
Strict Domain Alignment
Zwei Domains sind in strengem Domain Alignment, wenn und nur wenn sie identisch sind. So sind foo.bird.com und foo.bird.com in striktem Alignment, da die beiden Domains identisch sind. Andererseits sind foo.bird.com und bar.foo.bird.com nur in entspanntem Alignment.
DMARC Domain Alignment Anforderungen
Um die DMARC-Validierungschecks erfolgreich bestehen zu lassen, erfordert DMARC, dass ein Domain Alignment wie folgt besteht:
Für SPF müssen die RFC5322.From Domain und die Return-Path Domain im Alignment sein
Für DKIM müssen die RFC5322.From Domain und die DKIM d= Domain im Alignment sein
Das Alignment kann entspannt oder strikt sein, basierend auf der veröffentlichten Richtlinie der Sende-Domain.
Bevor wir mit der Einrichtung von DMARC für Ihre Domain beginnen, möchten wir sicherstellen, dass wir die gleiche Sprache sprechen. Lassen Sie uns mit der Definition einiger Begriffe beginnen, die wir im weiteren Verlauf dieses Dokuments verwenden werden.
RFC5322.From Domain
Die RFC5322.From Domain ist der Domain-Teil der E-Mail-Adresse, der normalerweise vom Empfänger unserer E-Mail gesehen wird, wenn sie gelesen wird. Im folgenden Beispiel ist die RFC5322.From Domain „joesbaitshop.com“.
From: Joe’s Bait and Tackle <sales@joesbaitshop.com>
DKIM d= Domain
DKIM ist ein Authentifizierungsprotokoll, das es einer Domain ermöglicht, die Verantwortung für eine Nachricht zu übernehmen in einer Weise, die vom Empfänger der Nachricht validiert werden kann; dies geschieht durch die Verwendung von kryptographischen Signaturen, die in die Header der Nachricht eingefügt werden, wenn sie ihren Ursprungsort verlässt. Diese Signaturen sind im Wesentlichen Momentaufnahmen davon, wie die Nachricht zu diesem Zeitpunkt aussah, und der Empfänger kann diese Momentaufnahmen verwenden, um zu sehen, ob die Nachricht unverändert an ihrem Ziel angekommen ist. Der Prozess der Erstellung und Einfügung dieser Momentaufnahmen wird als DKIM-Signierung bezeichnet, und die Domain, die die Verantwortung für die Nachricht übernimmt, indem sie diese signiert, fügt ihren Namen in den Header in einem Schlüssel-Wert-Tag als „d=signingDomain“ ein, und so wird sie als DKIM d= Domain bezeichnet.
Return-Path Domain
Die Return-Path Domain, manchmal auch als RFC5321. From Domain oder Mail From Domain bezeichnet, ist die Domain, an die Rückläufer weitergeleitet werden; sie ist auch die Domain, auf der SPF-Überprüfungen während der E-Mail-Transaktion durchgeführt werden. Diese Domain wird normalerweise nicht vom Empfänger gesehen, es sei denn, der Empfänger ist erfahren genug, um alle Header in einer gegebenen Nachricht zu betrachten.
Standardmäßig wird alle über bird.com gesendete Mail birdmail.com als Return-Path Domain haben, wie im folgenden Beispiel:
Return-Path: <msprvs1=16880EmYZo7L3=bounces-2785@birdmail1.com>
Um jedoch DMARC für Ihre Domain funktionsfähig zu machen, möchten Sie eine benutzerdefinierte Rückläufer-Domain nutzen, eine, die mit der gleichen Domain endet wie Ihre Sende-Domain, z.B. bounces.yourdomain.com, wenn Sie yourdomain.com als Ihre Sende-Domain verwenden.
Organizational Domain
Der Begriff „Organizational Domain“ bezieht sich auf die Domain, die einem Registrar vorgelegt wurde, um die Präsenz der Domain im Internet zu erstellen. Für Bird sind unsere organisatorischen Domains bird.com und birdmail.com.
Domain Alignment
Der letzte Begriff, den man im Zusammenhang mit DMARC verstehen muss, ist „Domain Alignment“, und es gibt ihn in zwei Varianten: „entspannt“ und „streng“.
Relaxed Domain Alignment
Jede zwei Domains haben ein entspanntes Domain Alignment, wenn ihre organisatorischen Domains identisch sind. Zum Beispiel haben a.mail.bird.com und b.foo.bird.com ein entspanntes Domain Alignment aufgrund ihrer gemeinsamen organisatorischen Domain bird.com.
Strict Domain Alignment
Zwei Domains sind in strengem Domain Alignment, wenn und nur wenn sie identisch sind. So sind foo.bird.com und foo.bird.com in striktem Alignment, da die beiden Domains identisch sind. Andererseits sind foo.bird.com und bar.foo.bird.com nur in entspanntem Alignment.
DMARC Domain Alignment Anforderungen
Um die DMARC-Validierungschecks erfolgreich bestehen zu lassen, erfordert DMARC, dass ein Domain Alignment wie folgt besteht:
Für SPF müssen die RFC5322.From Domain und die Return-Path Domain im Alignment sein
Für DKIM müssen die RFC5322.From Domain und die DKIM d= Domain im Alignment sein
Das Alignment kann entspannt oder strikt sein, basierend auf der veröffentlichten Richtlinie der Sende-Domain.
Bevor wir mit der Einrichtung von DMARC für Ihre Domain beginnen, möchten wir sicherstellen, dass wir die gleiche Sprache sprechen. Lassen Sie uns mit der Definition einiger Begriffe beginnen, die wir im weiteren Verlauf dieses Dokuments verwenden werden.
RFC5322.From Domain
Die RFC5322.From Domain ist der Domain-Teil der E-Mail-Adresse, der normalerweise vom Empfänger unserer E-Mail gesehen wird, wenn sie gelesen wird. Im folgenden Beispiel ist die RFC5322.From Domain „joesbaitshop.com“.
From: Joe’s Bait and Tackle <sales@joesbaitshop.com>
DKIM d= Domain
DKIM ist ein Authentifizierungsprotokoll, das es einer Domain ermöglicht, die Verantwortung für eine Nachricht zu übernehmen in einer Weise, die vom Empfänger der Nachricht validiert werden kann; dies geschieht durch die Verwendung von kryptographischen Signaturen, die in die Header der Nachricht eingefügt werden, wenn sie ihren Ursprungsort verlässt. Diese Signaturen sind im Wesentlichen Momentaufnahmen davon, wie die Nachricht zu diesem Zeitpunkt aussah, und der Empfänger kann diese Momentaufnahmen verwenden, um zu sehen, ob die Nachricht unverändert an ihrem Ziel angekommen ist. Der Prozess der Erstellung und Einfügung dieser Momentaufnahmen wird als DKIM-Signierung bezeichnet, und die Domain, die die Verantwortung für die Nachricht übernimmt, indem sie diese signiert, fügt ihren Namen in den Header in einem Schlüssel-Wert-Tag als „d=signingDomain“ ein, und so wird sie als DKIM d= Domain bezeichnet.
Return-Path Domain
Die Return-Path Domain, manchmal auch als RFC5321. From Domain oder Mail From Domain bezeichnet, ist die Domain, an die Rückläufer weitergeleitet werden; sie ist auch die Domain, auf der SPF-Überprüfungen während der E-Mail-Transaktion durchgeführt werden. Diese Domain wird normalerweise nicht vom Empfänger gesehen, es sei denn, der Empfänger ist erfahren genug, um alle Header in einer gegebenen Nachricht zu betrachten.
Standardmäßig wird alle über bird.com gesendete Mail birdmail.com als Return-Path Domain haben, wie im folgenden Beispiel:
Return-Path: <msprvs1=16880EmYZo7L3=bounces-2785@birdmail1.com>
Um jedoch DMARC für Ihre Domain funktionsfähig zu machen, möchten Sie eine benutzerdefinierte Rückläufer-Domain nutzen, eine, die mit der gleichen Domain endet wie Ihre Sende-Domain, z.B. bounces.yourdomain.com, wenn Sie yourdomain.com als Ihre Sende-Domain verwenden.
Organizational Domain
Der Begriff „Organizational Domain“ bezieht sich auf die Domain, die einem Registrar vorgelegt wurde, um die Präsenz der Domain im Internet zu erstellen. Für Bird sind unsere organisatorischen Domains bird.com und birdmail.com.
Domain Alignment
Der letzte Begriff, den man im Zusammenhang mit DMARC verstehen muss, ist „Domain Alignment“, und es gibt ihn in zwei Varianten: „entspannt“ und „streng“.
Relaxed Domain Alignment
Jede zwei Domains haben ein entspanntes Domain Alignment, wenn ihre organisatorischen Domains identisch sind. Zum Beispiel haben a.mail.bird.com und b.foo.bird.com ein entspanntes Domain Alignment aufgrund ihrer gemeinsamen organisatorischen Domain bird.com.
Strict Domain Alignment
Zwei Domains sind in strengem Domain Alignment, wenn und nur wenn sie identisch sind. So sind foo.bird.com und foo.bird.com in striktem Alignment, da die beiden Domains identisch sind. Andererseits sind foo.bird.com und bar.foo.bird.com nur in entspanntem Alignment.
DMARC Domain Alignment Anforderungen
Um die DMARC-Validierungschecks erfolgreich bestehen zu lassen, erfordert DMARC, dass ein Domain Alignment wie folgt besteht:
Für SPF müssen die RFC5322.From Domain und die Return-Path Domain im Alignment sein
Für DKIM müssen die RFC5322.From Domain und die DKIM d= Domain im Alignment sein
Das Alignment kann entspannt oder strikt sein, basierend auf der veröffentlichten Richtlinie der Sende-Domain.
Wie DMARC funktioniert, um Ihre E-Mail-Reputation zu schützen
Wenn wir von einem Mailbox-Anbieter oder einer anderen Domain sprechen, die „DMARC überprüft“, „DMARC validiert“ oder „DMARC-Richtlinie anwendet“, meinen wir damit, dass die Domain, die eine Nachricht empfängt, die folgenden Schritte ausführt:
Ermittelt die RFC5322.From-Domain der Nachricht
Sucht die DMARC-Richtlinie dieser Domain im DNS
Führt die DKIM-Signaturvalidierung durch
Führt die SPF-Validierung durch
Überprüft die Domänen-Ausrichtung
Wendet die DMARC-Richtlinie an
Damit eine Nachricht die DMARC-Validierung besteht, muss die Nachricht nur einen der beiden Authentifizierungs- und Ausrichtungsprüfungen bestehen. Eine Nachricht besteht die DMARC-Validierung, wenn eine der folgenden Bedingungen zutrifft:
Die Nachricht besteht die SPF-Prüfungen und die RFC5322.From-Domain und die Return-Path-Domain sind ausgerichtet, oder
Die Nachricht besteht die DKIM Validierung und die RFC5322.From-Domain und die DKIM d= Domain sind ausgerichtet, oder
Beides davon trifft zu
Übersicht der DMARC-Validierungspfade
Authentifizierungspfad | Verglichene Domains | Erforderliche Ausrichtung | DMARC-Bestandsbedingung |
|---|---|---|---|
SPF | RFC5322.From ↔ Return-Path | Entspannt oder streng | SPF besteht und Domains sind ausgerichtet |
DKIM | RFC5322.From ↔ DKIM d= | Entspannt oder streng | DKIM besteht und Domains sind ausgerichtet |
SPF + DKIM | Beide oben | Entweder ausgerichtet | Einer oder beide ausgerichtete Prüfungen bestehen |
Wenn wir von einem Mailbox-Anbieter oder einer anderen Domain sprechen, die „DMARC überprüft“, „DMARC validiert“ oder „DMARC-Richtlinie anwendet“, meinen wir damit, dass die Domain, die eine Nachricht empfängt, die folgenden Schritte ausführt:
Ermittelt die RFC5322.From-Domain der Nachricht
Sucht die DMARC-Richtlinie dieser Domain im DNS
Führt die DKIM-Signaturvalidierung durch
Führt die SPF-Validierung durch
Überprüft die Domänen-Ausrichtung
Wendet die DMARC-Richtlinie an
Damit eine Nachricht die DMARC-Validierung besteht, muss die Nachricht nur einen der beiden Authentifizierungs- und Ausrichtungsprüfungen bestehen. Eine Nachricht besteht die DMARC-Validierung, wenn eine der folgenden Bedingungen zutrifft:
Die Nachricht besteht die SPF-Prüfungen und die RFC5322.From-Domain und die Return-Path-Domain sind ausgerichtet, oder
Die Nachricht besteht die DKIM Validierung und die RFC5322.From-Domain und die DKIM d= Domain sind ausgerichtet, oder
Beides davon trifft zu
Übersicht der DMARC-Validierungspfade
Authentifizierungspfad | Verglichene Domains | Erforderliche Ausrichtung | DMARC-Bestandsbedingung |
|---|---|---|---|
SPF | RFC5322.From ↔ Return-Path | Entspannt oder streng | SPF besteht und Domains sind ausgerichtet |
DKIM | RFC5322.From ↔ DKIM d= | Entspannt oder streng | DKIM besteht und Domains sind ausgerichtet |
SPF + DKIM | Beide oben | Entweder ausgerichtet | Einer oder beide ausgerichtete Prüfungen bestehen |
Wenn wir von einem Mailbox-Anbieter oder einer anderen Domain sprechen, die „DMARC überprüft“, „DMARC validiert“ oder „DMARC-Richtlinie anwendet“, meinen wir damit, dass die Domain, die eine Nachricht empfängt, die folgenden Schritte ausführt:
Ermittelt die RFC5322.From-Domain der Nachricht
Sucht die DMARC-Richtlinie dieser Domain im DNS
Führt die DKIM-Signaturvalidierung durch
Führt die SPF-Validierung durch
Überprüft die Domänen-Ausrichtung
Wendet die DMARC-Richtlinie an
Damit eine Nachricht die DMARC-Validierung besteht, muss die Nachricht nur einen der beiden Authentifizierungs- und Ausrichtungsprüfungen bestehen. Eine Nachricht besteht die DMARC-Validierung, wenn eine der folgenden Bedingungen zutrifft:
Die Nachricht besteht die SPF-Prüfungen und die RFC5322.From-Domain und die Return-Path-Domain sind ausgerichtet, oder
Die Nachricht besteht die DKIM Validierung und die RFC5322.From-Domain und die DKIM d= Domain sind ausgerichtet, oder
Beides davon trifft zu
Übersicht der DMARC-Validierungspfade
Authentifizierungspfad | Verglichene Domains | Erforderliche Ausrichtung | DMARC-Bestandsbedingung |
|---|---|---|---|
SPF | RFC5322.From ↔ Return-Path | Entspannt oder streng | SPF besteht und Domains sind ausgerichtet |
DKIM | RFC5322.From ↔ DKIM d= | Entspannt oder streng | DKIM besteht und Domains sind ausgerichtet |
SPF + DKIM | Beide oben | Entweder ausgerichtet | Einer oder beide ausgerichtete Prüfungen bestehen |
DMARC für Ihre Domain arbeiten lassen
Da wir nun die Mechanik von DMARC erklärt haben, sprechen wir darüber, wie DMARC für uns arbeiten kann, was die folgenden drei Schritte umfasst:
Vorbereitungen treffen, um DMARC-Berichte zu erhalten
Entscheiden, welche DMARC-Richtlinie für Ihre Domain verwendet werden soll
Ihr DMARC-Eintrag veröffentlichen
Wir werden jeden dieser Schritte unten ausführlich behandeln, aber wir sagen Ihnen direkt, dass Schritt 1 oben etwa 95% Ihrer Vorbereitungszeit in Anspruch nehmen wird.
Da wir nun die Mechanik von DMARC erklärt haben, sprechen wir darüber, wie DMARC für uns arbeiten kann, was die folgenden drei Schritte umfasst:
Vorbereitungen treffen, um DMARC-Berichte zu erhalten
Entscheiden, welche DMARC-Richtlinie für Ihre Domain verwendet werden soll
Ihr DMARC-Eintrag veröffentlichen
Wir werden jeden dieser Schritte unten ausführlich behandeln, aber wir sagen Ihnen direkt, dass Schritt 1 oben etwa 95% Ihrer Vorbereitungszeit in Anspruch nehmen wird.
Da wir nun die Mechanik von DMARC erklärt haben, sprechen wir darüber, wie DMARC für uns arbeiten kann, was die folgenden drei Schritte umfasst:
Vorbereitungen treffen, um DMARC-Berichte zu erhalten
Entscheiden, welche DMARC-Richtlinie für Ihre Domain verwendet werden soll
Ihr DMARC-Eintrag veröffentlichen
Wir werden jeden dieser Schritte unten ausführlich behandeln, aber wir sagen Ihnen direkt, dass Schritt 1 oben etwa 95% Ihrer Vorbereitungszeit in Anspruch nehmen wird.
Vorbereitung zum Erhalt von DMARC-Berichten
Jede Domäne, die eine DMARC-Richtlinie veröffentlicht, sollte zunächst darauf vorbereitet sein, Berichte bezüglich ihrer Domäne zu erhalten. Diese Berichte werden von jeder Domäne generiert, die DMARC-Validierung durchführt und E-Mails sieht, die angeblich von unserer Domäne stammen, und werden uns mindestens täglich zugesandt. Die Berichte werden in zwei Formaten geliefert:
Zusammenfassende Berichte, das sind XML-Dokumente, die statistische Daten darüber zeigen, wie viel E-Mail vom Berichterstatter aus jeder Quelle gesehen wurde, wie die Authentifizierungsergebnisse waren und wie die Nachrichten vom Berichterstatter behandelt wurden. Zusammenfassende Berichte sind so gestaltet, dass sie maschinell ausgewertet werden können, wobei ihre Daten irgendwo gespeichert werden, um eine Gesamtanalyse des Verkehrs, eine Überprüfung der Nachrichtenströme unserer Domäne und möglicherweise die Identifizierung von Trends bei Quellen nicht authentifizierter, potenziell betrügerischer E-Mails zu ermöglichen.
Forensische Berichte, das sind einzelne Kopien von Nachrichten, die die Authentifizierung nicht bestanden haben, jede eingeschlossen in eine vollständige E-Mail-Nachricht im sogenannten AFRF-Format. Die forensischen Berichte sollen vollständige Kopfzeilen und Nachrichteninhalte enthalten, aber viele Berichterstatter entfernen oder anonymisieren einige Informationen aus Datenschutzgründen. Nichtsdestotrotz können die forensischen Berichte sowohl nützlich sein, um die Authentifizierungsprobleme unserer Domäne zu beheben, als auch um anhand von URIs in den Nachrichteninhalten bösartige Domänen und Websites zu identifizieren, die dazu verwendet werden, Kunden des Domäneninhabers zu betrügen.
Die Vorbereitung auf den Empfang dieser Berichte umfasst zunächst die Erstellung von zwei Postfächern in unserer Domäne, um diese Berichte zu verwalten, wie z.B. agg_reports@unseredomain.com und afrf_reports@unseredomain.com. Beachten Sie, dass diese Postfachnamen völlig willkürlich sind und es keine Anforderungen für die Benennung des lokalen Teils des Postfachs gibt; wir können jeden Namen wählen, den wir wünschen, sollten jedoch die beiden für eine einfachere Verarbeitung getrennt halten.
Sobald die Postfachnamen ausgewählt und in unserer Domäne erstellt wurden, ist der nächste Schritt, Werkzeuge bereitzustellen, um diese Postfächer abzulesen und die Daten zu nutzen, insbesondere die zusammenfassenden Datenberichte, die erneut so gestaltet sind, dass sie maschinell ausgewertet und nicht von einem Menschen gelesen werden. Die forensischen Berichte hingegen könnten einfach zu handhaben sein, indem wir sie selbst lesen, aber unsere Fähigkeit dazu hängt sowohl vom Verständnis unseres E-Mail-Clients ab, wie Nachrichten im AFRF-Format angezeigt werden, als auch vom Umfang der Berichte, die wir erhalten.
Während es für uns möglich ist, unsere eigenen Werkzeuge zur Verarbeitung von DMARC-Berichten zu schreiben, empfehlen wir, bis zu dem Zeitpunkt, an dem Bird solche Dienste für bird.com-Kunden bereitstellt (etwas, das wir in Betracht ziehen, aber noch nicht versprechen), dass wir die bereits verfügbaren Werkzeuge für diese Aufgabe nutzen.
Jede Domäne, die eine DMARC-Richtlinie veröffentlicht, sollte zunächst darauf vorbereitet sein, Berichte bezüglich ihrer Domäne zu erhalten. Diese Berichte werden von jeder Domäne generiert, die DMARC-Validierung durchführt und E-Mails sieht, die angeblich von unserer Domäne stammen, und werden uns mindestens täglich zugesandt. Die Berichte werden in zwei Formaten geliefert:
Zusammenfassende Berichte, das sind XML-Dokumente, die statistische Daten darüber zeigen, wie viel E-Mail vom Berichterstatter aus jeder Quelle gesehen wurde, wie die Authentifizierungsergebnisse waren und wie die Nachrichten vom Berichterstatter behandelt wurden. Zusammenfassende Berichte sind so gestaltet, dass sie maschinell ausgewertet werden können, wobei ihre Daten irgendwo gespeichert werden, um eine Gesamtanalyse des Verkehrs, eine Überprüfung der Nachrichtenströme unserer Domäne und möglicherweise die Identifizierung von Trends bei Quellen nicht authentifizierter, potenziell betrügerischer E-Mails zu ermöglichen.
Forensische Berichte, das sind einzelne Kopien von Nachrichten, die die Authentifizierung nicht bestanden haben, jede eingeschlossen in eine vollständige E-Mail-Nachricht im sogenannten AFRF-Format. Die forensischen Berichte sollen vollständige Kopfzeilen und Nachrichteninhalte enthalten, aber viele Berichterstatter entfernen oder anonymisieren einige Informationen aus Datenschutzgründen. Nichtsdestotrotz können die forensischen Berichte sowohl nützlich sein, um die Authentifizierungsprobleme unserer Domäne zu beheben, als auch um anhand von URIs in den Nachrichteninhalten bösartige Domänen und Websites zu identifizieren, die dazu verwendet werden, Kunden des Domäneninhabers zu betrügen.
Die Vorbereitung auf den Empfang dieser Berichte umfasst zunächst die Erstellung von zwei Postfächern in unserer Domäne, um diese Berichte zu verwalten, wie z.B. agg_reports@unseredomain.com und afrf_reports@unseredomain.com. Beachten Sie, dass diese Postfachnamen völlig willkürlich sind und es keine Anforderungen für die Benennung des lokalen Teils des Postfachs gibt; wir können jeden Namen wählen, den wir wünschen, sollten jedoch die beiden für eine einfachere Verarbeitung getrennt halten.
Sobald die Postfachnamen ausgewählt und in unserer Domäne erstellt wurden, ist der nächste Schritt, Werkzeuge bereitzustellen, um diese Postfächer abzulesen und die Daten zu nutzen, insbesondere die zusammenfassenden Datenberichte, die erneut so gestaltet sind, dass sie maschinell ausgewertet und nicht von einem Menschen gelesen werden. Die forensischen Berichte hingegen könnten einfach zu handhaben sein, indem wir sie selbst lesen, aber unsere Fähigkeit dazu hängt sowohl vom Verständnis unseres E-Mail-Clients ab, wie Nachrichten im AFRF-Format angezeigt werden, als auch vom Umfang der Berichte, die wir erhalten.
Während es für uns möglich ist, unsere eigenen Werkzeuge zur Verarbeitung von DMARC-Berichten zu schreiben, empfehlen wir, bis zu dem Zeitpunkt, an dem Bird solche Dienste für bird.com-Kunden bereitstellt (etwas, das wir in Betracht ziehen, aber noch nicht versprechen), dass wir die bereits verfügbaren Werkzeuge für diese Aufgabe nutzen.
Jede Domäne, die eine DMARC-Richtlinie veröffentlicht, sollte zunächst darauf vorbereitet sein, Berichte bezüglich ihrer Domäne zu erhalten. Diese Berichte werden von jeder Domäne generiert, die DMARC-Validierung durchführt und E-Mails sieht, die angeblich von unserer Domäne stammen, und werden uns mindestens täglich zugesandt. Die Berichte werden in zwei Formaten geliefert:
Zusammenfassende Berichte, das sind XML-Dokumente, die statistische Daten darüber zeigen, wie viel E-Mail vom Berichterstatter aus jeder Quelle gesehen wurde, wie die Authentifizierungsergebnisse waren und wie die Nachrichten vom Berichterstatter behandelt wurden. Zusammenfassende Berichte sind so gestaltet, dass sie maschinell ausgewertet werden können, wobei ihre Daten irgendwo gespeichert werden, um eine Gesamtanalyse des Verkehrs, eine Überprüfung der Nachrichtenströme unserer Domäne und möglicherweise die Identifizierung von Trends bei Quellen nicht authentifizierter, potenziell betrügerischer E-Mails zu ermöglichen.
Forensische Berichte, das sind einzelne Kopien von Nachrichten, die die Authentifizierung nicht bestanden haben, jede eingeschlossen in eine vollständige E-Mail-Nachricht im sogenannten AFRF-Format. Die forensischen Berichte sollen vollständige Kopfzeilen und Nachrichteninhalte enthalten, aber viele Berichterstatter entfernen oder anonymisieren einige Informationen aus Datenschutzgründen. Nichtsdestotrotz können die forensischen Berichte sowohl nützlich sein, um die Authentifizierungsprobleme unserer Domäne zu beheben, als auch um anhand von URIs in den Nachrichteninhalten bösartige Domänen und Websites zu identifizieren, die dazu verwendet werden, Kunden des Domäneninhabers zu betrügen.
Die Vorbereitung auf den Empfang dieser Berichte umfasst zunächst die Erstellung von zwei Postfächern in unserer Domäne, um diese Berichte zu verwalten, wie z.B. agg_reports@unseredomain.com und afrf_reports@unseredomain.com. Beachten Sie, dass diese Postfachnamen völlig willkürlich sind und es keine Anforderungen für die Benennung des lokalen Teils des Postfachs gibt; wir können jeden Namen wählen, den wir wünschen, sollten jedoch die beiden für eine einfachere Verarbeitung getrennt halten.
Sobald die Postfachnamen ausgewählt und in unserer Domäne erstellt wurden, ist der nächste Schritt, Werkzeuge bereitzustellen, um diese Postfächer abzulesen und die Daten zu nutzen, insbesondere die zusammenfassenden Datenberichte, die erneut so gestaltet sind, dass sie maschinell ausgewertet und nicht von einem Menschen gelesen werden. Die forensischen Berichte hingegen könnten einfach zu handhaben sein, indem wir sie selbst lesen, aber unsere Fähigkeit dazu hängt sowohl vom Verständnis unseres E-Mail-Clients ab, wie Nachrichten im AFRF-Format angezeigt werden, als auch vom Umfang der Berichte, die wir erhalten.
Während es für uns möglich ist, unsere eigenen Werkzeuge zur Verarbeitung von DMARC-Berichten zu schreiben, empfehlen wir, bis zu dem Zeitpunkt, an dem Bird solche Dienste für bird.com-Kunden bereitstellt (etwas, das wir in Betracht ziehen, aber noch nicht versprechen), dass wir die bereits verfügbaren Werkzeuge für diese Aufgabe nutzen.
Welche DMARC Policy verwenden
Die DMARC-Spezifikation bietet Domaininhabern drei Optionen zur Verfügung, um ihre bevorzugte Behandlung von E-Mails anzugeben, die die DMARC-Validierungsprüfungen nicht bestehen. Diese sind:
none, das bedeutet, die E-Mail wird genauso behandelt, als ob sie unabhängig von den DMARC-Validierungsprüfungen behandelt würde
quarantine, das bedeutet, die E-Mail wird angenommen, aber an einem anderen Ort als im Posteingang des Empfängers abgelegt (typischerweise im Spam-Ordner)
reject, das bedeutet, die Nachricht wird vollständig abgelehnt
Es ist wichtig zu beachten, dass der Domaininhaber eine solche Behandlung nur in seinem DMARC-Datensatz anfordern kann; es liegt beim Empfänger der Nachricht zu entscheiden, ob er die angeforderte Richtlinie beachtet oder nicht. Manche werden dies tun, während andere möglicherweise etwas nachsichtiger bei der Anwendung der Richtlinien sind, z. B. indem sie E-Mails nur in den Spam-Ordner verschieben, wenn die Richtlinie der Domain ablehnen ist.
Wir empfehlen allen unseren Kunden, mit einer Richtlinie von none zu starten, einfach um sicher zu sein. Obwohl wir zuversichtlich in unserer Fähigkeit sind, Ihre E-Mails ordnungsgemäß über DKIM-Signierung zu authentifizieren, ist es dennoch am besten, sich Zeit zu nehmen, um Berichte über Ihre Domain zu prüfen, bevor Sie Ihre DMARC-Richtlinie aggressiver gestalten.
Die DMARC-Spezifikation bietet Domaininhabern drei Optionen zur Verfügung, um ihre bevorzugte Behandlung von E-Mails anzugeben, die die DMARC-Validierungsprüfungen nicht bestehen. Diese sind:
none, das bedeutet, die E-Mail wird genauso behandelt, als ob sie unabhängig von den DMARC-Validierungsprüfungen behandelt würde
quarantine, das bedeutet, die E-Mail wird angenommen, aber an einem anderen Ort als im Posteingang des Empfängers abgelegt (typischerweise im Spam-Ordner)
reject, das bedeutet, die Nachricht wird vollständig abgelehnt
Es ist wichtig zu beachten, dass der Domaininhaber eine solche Behandlung nur in seinem DMARC-Datensatz anfordern kann; es liegt beim Empfänger der Nachricht zu entscheiden, ob er die angeforderte Richtlinie beachtet oder nicht. Manche werden dies tun, während andere möglicherweise etwas nachsichtiger bei der Anwendung der Richtlinien sind, z. B. indem sie E-Mails nur in den Spam-Ordner verschieben, wenn die Richtlinie der Domain ablehnen ist.
Wir empfehlen allen unseren Kunden, mit einer Richtlinie von none zu starten, einfach um sicher zu sein. Obwohl wir zuversichtlich in unserer Fähigkeit sind, Ihre E-Mails ordnungsgemäß über DKIM-Signierung zu authentifizieren, ist es dennoch am besten, sich Zeit zu nehmen, um Berichte über Ihre Domain zu prüfen, bevor Sie Ihre DMARC-Richtlinie aggressiver gestalten.
Die DMARC-Spezifikation bietet Domaininhabern drei Optionen zur Verfügung, um ihre bevorzugte Behandlung von E-Mails anzugeben, die die DMARC-Validierungsprüfungen nicht bestehen. Diese sind:
none, das bedeutet, die E-Mail wird genauso behandelt, als ob sie unabhängig von den DMARC-Validierungsprüfungen behandelt würde
quarantine, das bedeutet, die E-Mail wird angenommen, aber an einem anderen Ort als im Posteingang des Empfängers abgelegt (typischerweise im Spam-Ordner)
reject, das bedeutet, die Nachricht wird vollständig abgelehnt
Es ist wichtig zu beachten, dass der Domaininhaber eine solche Behandlung nur in seinem DMARC-Datensatz anfordern kann; es liegt beim Empfänger der Nachricht zu entscheiden, ob er die angeforderte Richtlinie beachtet oder nicht. Manche werden dies tun, während andere möglicherweise etwas nachsichtiger bei der Anwendung der Richtlinien sind, z. B. indem sie E-Mails nur in den Spam-Ordner verschieben, wenn die Richtlinie der Domain ablehnen ist.
Wir empfehlen allen unseren Kunden, mit einer Richtlinie von none zu starten, einfach um sicher zu sein. Obwohl wir zuversichtlich in unserer Fähigkeit sind, Ihre E-Mails ordnungsgemäß über DKIM-Signierung zu authentifizieren, ist es dennoch am besten, sich Zeit zu nehmen, um Berichte über Ihre Domain zu prüfen, bevor Sie Ihre DMARC-Richtlinie aggressiver gestalten.
Veröffentlichung Ihrer DMARC-Policy
Die DMARC-Richtlinie einer Domain wird bekannt gegeben, indem ein DNS TXT-Eintrag an einem bestimmten Ort im DNS-Namespace veröffentlicht wird, nämlich „_dmarc.domainname.tld“ (beachten Sie den führenden Unterstrich). Ein grundlegender DMARC-Richtlinieneintrag für unsere Beispieldomain von früher, joesbaitshop.com, könnte etwa so aussehen:
_dmarc.joesbaitship.com. IN TXT "v=DMARC1; p=none; rua=mailto:agg_reports@joesbait.com; ruf=mailto:afrf_reports@joesbait.com; pct=100"
Wenn wir diesen Eintrag aufschlüsseln, haben wir:
v=DMARC1 gibt die DMARC-Version an (1 ist derzeit die einzige Wahl)
p=none gibt die bevorzugte Behandlung oder DMARC-Richtlinie an
rua=mailto:agg_reports@joesbait.com ist das Postfach, an das aggregierte Berichte gesendet werden sollen
ruf=mailto:afrf_reports@joesbait.com ist das Postfach, an das forensische Berichte gesendet werden sollen
pct=100 ist der Prozentsatz der E-Mails, auf den der Domaininhaber seine Richtlinie anwenden möchte. Domains, die gerade erst mit DMARC beginnen, insbesondere solche, die wahrscheinlich ein hohes Berichtsaufkommen erzeugen, sollten hier mit einer viel niedrigeren Zahl beginnen, um zu sehen, wie ihre Berichtsbearbeitungsprozesse der Belastung standhalten.
Es stehen weitere Konfigurationsoptionen für einen Domaininhaber zur Verwendung in seinem DMARC-Richtlinieneintrag zur Verfügung, aber die von uns bereitgestellten Tipps sollten ein guter Anfang sein.
Die DMARC-Richtlinie einer Domain wird bekannt gegeben, indem ein DNS TXT-Eintrag an einem bestimmten Ort im DNS-Namespace veröffentlicht wird, nämlich „_dmarc.domainname.tld“ (beachten Sie den führenden Unterstrich). Ein grundlegender DMARC-Richtlinieneintrag für unsere Beispieldomain von früher, joesbaitshop.com, könnte etwa so aussehen:
_dmarc.joesbaitship.com. IN TXT "v=DMARC1; p=none; rua=mailto:agg_reports@joesbait.com; ruf=mailto:afrf_reports@joesbait.com; pct=100"
Wenn wir diesen Eintrag aufschlüsseln, haben wir:
v=DMARC1 gibt die DMARC-Version an (1 ist derzeit die einzige Wahl)
p=none gibt die bevorzugte Behandlung oder DMARC-Richtlinie an
rua=mailto:agg_reports@joesbait.com ist das Postfach, an das aggregierte Berichte gesendet werden sollen
ruf=mailto:afrf_reports@joesbait.com ist das Postfach, an das forensische Berichte gesendet werden sollen
pct=100 ist der Prozentsatz der E-Mails, auf den der Domaininhaber seine Richtlinie anwenden möchte. Domains, die gerade erst mit DMARC beginnen, insbesondere solche, die wahrscheinlich ein hohes Berichtsaufkommen erzeugen, sollten hier mit einer viel niedrigeren Zahl beginnen, um zu sehen, wie ihre Berichtsbearbeitungsprozesse der Belastung standhalten.
Es stehen weitere Konfigurationsoptionen für einen Domaininhaber zur Verwendung in seinem DMARC-Richtlinieneintrag zur Verfügung, aber die von uns bereitgestellten Tipps sollten ein guter Anfang sein.
Die DMARC-Richtlinie einer Domain wird bekannt gegeben, indem ein DNS TXT-Eintrag an einem bestimmten Ort im DNS-Namespace veröffentlicht wird, nämlich „_dmarc.domainname.tld“ (beachten Sie den führenden Unterstrich). Ein grundlegender DMARC-Richtlinieneintrag für unsere Beispieldomain von früher, joesbaitshop.com, könnte etwa so aussehen:
_dmarc.joesbaitship.com. IN TXT "v=DMARC1; p=none; rua=mailto:agg_reports@joesbait.com; ruf=mailto:afrf_reports@joesbait.com; pct=100"
Wenn wir diesen Eintrag aufschlüsseln, haben wir:
v=DMARC1 gibt die DMARC-Version an (1 ist derzeit die einzige Wahl)
p=none gibt die bevorzugte Behandlung oder DMARC-Richtlinie an
rua=mailto:agg_reports@joesbait.com ist das Postfach, an das aggregierte Berichte gesendet werden sollen
ruf=mailto:afrf_reports@joesbait.com ist das Postfach, an das forensische Berichte gesendet werden sollen
pct=100 ist der Prozentsatz der E-Mails, auf den der Domaininhaber seine Richtlinie anwenden möchte. Domains, die gerade erst mit DMARC beginnen, insbesondere solche, die wahrscheinlich ein hohes Berichtsaufkommen erzeugen, sollten hier mit einer viel niedrigeren Zahl beginnen, um zu sehen, wie ihre Berichtsbearbeitungsprozesse der Belastung standhalten.
Es stehen weitere Konfigurationsoptionen für einen Domaininhaber zur Verwendung in seinem DMARC-Richtlinieneintrag zur Verfügung, aber die von uns bereitgestellten Tipps sollten ein guter Anfang sein.
Zusammenfassung
Es gibt viel zu entpacken in den obigen Informationen! Wir hoffen, dass Sie die Anleitung zum Erstellen eines DMARC-Policy-Datensatzes nützlich finden. Wir hoffen auch, dass unsere Erklärung, warum DMARC wichtig ist, klar macht, warum Sie dieses wichtige Tool zum Schutz Ihres E-Mail-Rufs verwenden sollten.
Natürlich ist dies kein vollständiges oder maßgebliches Dokument zu diesem Thema. Wenn Sie tiefer einsteigen möchten oder weitere Hilfe benötigen, ist ein großartiger Ausgangspunkt die offizielle DMARC-FAQ. Und es versteht sich von selbst, dass das MessageBird Support-Team bereit ist, Ihnen zu helfen, Ihr MessageBird-Konto auch für DMARC zu konfigurieren.
Vielen Dank fürs Lesen — und beginnen Sie noch heute damit, Ihre Domains mit DMARC zu schützen!
Es gibt viel zu entpacken in den obigen Informationen! Wir hoffen, dass Sie die Anleitung zum Erstellen eines DMARC-Policy-Datensatzes nützlich finden. Wir hoffen auch, dass unsere Erklärung, warum DMARC wichtig ist, klar macht, warum Sie dieses wichtige Tool zum Schutz Ihres E-Mail-Rufs verwenden sollten.
Natürlich ist dies kein vollständiges oder maßgebliches Dokument zu diesem Thema. Wenn Sie tiefer einsteigen möchten oder weitere Hilfe benötigen, ist ein großartiger Ausgangspunkt die offizielle DMARC-FAQ. Und es versteht sich von selbst, dass das MessageBird Support-Team bereit ist, Ihnen zu helfen, Ihr MessageBird-Konto auch für DMARC zu konfigurieren.
Vielen Dank fürs Lesen — und beginnen Sie noch heute damit, Ihre Domains mit DMARC zu schützen!
Es gibt viel zu entpacken in den obigen Informationen! Wir hoffen, dass Sie die Anleitung zum Erstellen eines DMARC-Policy-Datensatzes nützlich finden. Wir hoffen auch, dass unsere Erklärung, warum DMARC wichtig ist, klar macht, warum Sie dieses wichtige Tool zum Schutz Ihres E-Mail-Rufs verwenden sollten.
Natürlich ist dies kein vollständiges oder maßgebliches Dokument zu diesem Thema. Wenn Sie tiefer einsteigen möchten oder weitere Hilfe benötigen, ist ein großartiger Ausgangspunkt die offizielle DMARC-FAQ. Und es versteht sich von selbst, dass das MessageBird Support-Team bereit ist, Ihnen zu helfen, Ihr MessageBird-Konto auch für DMARC zu konfigurieren.
Vielen Dank fürs Lesen — und beginnen Sie noch heute damit, Ihre Domains mit DMARC zu schützen!
