Überprüfung der DMARC-Nichteinhaltung, 4 Beispiele

Überprüfung der DMARC-Nichteinhaltung, 4 Beispiele

Wir haben DMARC eingerichtet und erhalten Berichte (die Richtlinie ist immer noch auf „keine“ eingestellt). Ich habe sie in den DMARC XML-to-Human Converter (dmarcian.com) geladen und die meisten sehen gut aus und sind zu 100 % konform. Aber wir haben einige von Google erhalten, die als Forwarder angezeigt wurden und von denen einige nicht DMARC-konform waren. Ich möchte herausfinden, ob einige davon legitim sind und wir daran arbeiten müssen, oder ob sie korrekt als nicht konform identifiziert wurden und abgelehnt würden, wenn wir die Richtlinie auf „Ablehnen“ setzen.

Ich sehe, dass dmarcian.com sie als Gmail-/App-Weiterleitung anzeigt.

Bildbeschreibung hier eingeben

Im XML sehe ich, dass policy_evaluated ein Bestehen/Nichtbestehen für DKIM und SPF anzeigt. Auch auth_results zeigt ein Ergebnis für beides an. Was bedeuten diese jeweils? Warum sind sie manchmal unterschiedlich? Gibt es keinen allgemeinen DMARC-Compliance-Tag? Welche zeigen DMARC-Compliance an … das policy_evaluated?

In den drei Beispielen unten ist die Quell-IP nicht die IP unseres Mailservers wie bei den anderen. Ich habe festgestellt, dass es hier, außer in Beispiel 4, eigentlich die IP von Google ist.

Beispiel 1 Hier ist ein Beispiel, das nicht gut aussieht, oder? Fehler, Fehler in policy_evaluated. Ich erkenne die andere Domain überhaupt nicht, außer gappssmtp.com muss Google Apps sein, schätze ich.

  <record>
    <row>
      <source_ip>209.85.220.69</source_ip>
      <count>24</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>fail</dkim>
        <spf>fail</spf>
        <reason>
          <type>local_policy</type>
          <comment>arc=pass</comment>
        </reason>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>ourdomain.com</header_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>someotherdomain-com.notourselector.gappssmtp.com</domain>
        <result>pass</result>
        <selector>notourselector</selector>
      </dkim>
      <spf>
        <domain>someotherdomain.com</domain>
        <result>none</result>
      </spf>
    </auth_results>
  </record>

Beispiel 2 Wie wäre es damit? Die andere Domain, die ich tatsächlich erkenne, ist dieselbe Domain wie die von jemandem, mit dem wir derzeit E-Mails senden. Bedeutet das, dass sie versuchen, als unsere Domain zu senden oder was? Oder sie haben eine E-Mail weitergeleitet, die sie ursprünglich von uns erhalten haben (was erklärt, warum DKIM bestanden hat). Aber warum wird sie hier angezeigt? Ich habe eine andere wie diese mit einer anderen Domain gesehen, die mit der von jemandem übereinstimmt, mit dem wir ebenfalls E-Mails senden.

  <record>
    <row>
      <source_ip>209.85.220.41</source_ip>
      <count>7</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>ourdomain.com</header_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>ourdomain.com</domain>
        <result>pass</result>
        <selector>ourselector</selector>
      </dkim>
      <spf>
        <domain>someotherdomain.com</domain>
        <result>none</result>
      </spf>
    </auth_results>
  </record>

Beispiel 3

  <record>
    <row>
      <source_ip>209.85.220.41</source_ip>
      <count>1</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>fail</dkim>
        <spf>fail</spf>
        <reason>
          <type>local_policy</type>
          <comment>arc=pass</comment>
        </reason>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>ourdomain.com</header_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>ourdomain.com</domain>
        <result>fail</result>
        <selector>ourselector</selector>
      </dkim>
      <spf>
        <domain>gmail.com</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>

Beispiel 4 Ich habe festgestellt, dass diese Quell-IP mit der Domäne verknüpft ist, die in der E-Mail-Adresse einer Person erscheint, mit der wir E-Mails senden.

<record>
    <row>
      <source_ip>64.239.243.200</source_ip>
      <count>1</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>ourdomain.com</header_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>ourdomain.com</domain>
        <result>pass</result>
        <selector>ourselector</selector>
      </dkim>
      <spf>
        <domain>ourdomain.com</domain>
        <result>neutral</result>
      </spf>
    </auth_results>
  </record>

Wir sind für jede Hilfe bei der Verarbeitung sehr dankbar!

Antwort1

Herzlichen Glückwunsch zur Implementierung von DMARC. Es sieht so aus, als würden Sie einen maßvollen Ansatz verfolgen.

Es kommt nicht selten vor, dass Benutzer E-Mail-Adressen verwenden, die an echte Postfächer weitergeleitet werden. Google kennt die Server einiger dieser Adressen und kann sie trotzdem an das Postfach des Benutzers senden. Dies ist wahrscheinlich bei den Beispielen 2, 3 und 4 der Fall. Im Laufe der Zeit werden Sie mehrere Datensätze sehen, die bis auf den Berichtszeitpunkt ähnlich sind.

Laut meinen Aufzeichnungen meldet Google für E-Mails, die es als legitim weitergeleitet identifiziert, den Grund „Weitergeleitet“. Andere Domänen melden weitergeleitete E-Mails möglicherweise auch als solche, aber ich habe keine derartigen Berichte.

Wenn E-Mails von einem Weiterleiter fälschlicherweise als Spam gesendet werden, stehen verschiedene Optionen zur Verfügung. Dies ist ein Fall, in dem Sie Ihre Domain möglicherweise auf die Whitelist setzen möchten, wenn Sie sie von Ihrem Weiterleiter erhalten. Der Server sollte erkennen, dass Sie keinen Spam senden, wenn Ihre E-Mails wiederholt im Posteingang abgelegt werden.

Einige Spammer werden versuchen, Ihre Identität trotz DMARC zu fälschen. Da DMARC noch nicht weit verbreitet ist, verarbeiten viele Mailserver E-Mails ohne Bezugnahme auf Ihre Richtlinien. Wenn sie ihre Empfängerlisten nicht bereinigen, um Adressen zu entfernen, die von Anbietern verwaltet werden, die DMARC implementiert haben, erhalten Sie Berichte wie in Beispiel 1. (Wenn Sie zum Senden von E-Mails von Ihrer Domain nicht die Verwendung Ihrer autorisierten Server benötigen, können Sie Berichte wie diesen erhalten.)

In diesem Fall scheint Beispiel 1 jedoch aus dem Google-Netzwerk zu stammen. DNS zeigt an, dass die IP-Adresse zu Google gehört. Eine Whois-Suche nach der Domäne zeigt, dass sich ihre Nameserver in der Domäne „googledomains.com“ befinden. Das Hinzufügen eines Grundes zum Datensatz zeigt an, dass es eine lokale Richtlinie gibt, die diese E-Mail zulässt.

Möglicherweise möchten Sie die gemeldeten IP-Adressen anhand verschiedener DNS-Blacklists überprüfen. Sie können auch in einer DNS-Whitelist aufgeführt sein. Wenn Sie die Daten in einer Datenbank speichern, können Sie die DNS-Suchvorgänge möglicherweise automatisieren.

verwandte Informationen