Einige Monate, nachdem ich das Thema DMARC für mich abgeschlossen habe, rächt sich mein oberflächliches Verständnis der DMARC-Prinzipien. Als ich zum ersten Mal einen Blick auf einen DMARC-Report von Google für lists.eden.one werfe, bin ich sowohl erschüttert als auch verwirrt:
<record> <row> <source_ip>123.123.123.123</source_ip> <count>1</count> <policy_evaluated> <disposition>none</disposition> <dkim>pass</dkim> <spf>fail</spf> </policy_evaluated> </row> <identifiers> <header_from>lists.eden.one</header_from> </identifiers> <auth_results> <dkim> <domain>lists.eden.one</domain> <result>pass</result> <selector>s42</selector> </dkim> <spf> <domain>eden.one</domain> <result>pass</result> </spf> </auth_results> </record>
Warum ist der SPF-Test gleichzeitig erfolgreich und nicht erfolgreich? Einen ersten Hinweis liefert der etwas detailliertere Report eines anderen Providers:
<record> <row> <source_ip>123.123.123.123</source_ip> <count>1</count> <policy_evaluated> <disposition>none</disposition> <dkim>pass</dkim> <spf>fail</spf> </policy_evaluated> </row> <identifiers> <header_from>lists.eden.one</header_from> <envelope_from>eden.one</envelope_from> </identifiers> <auth_results> <dkim> <domain>janeden.net</domain> <selector>s42</selector> <result>pass</result> </dkim> <spf> <domain>eden.one</domain> <scope>mfrom</scope> <result>pass</result> </spf> </auth_results> </record>
Die Ursache ist offensichtlich die Abweichung zwischen header_from und envelope_from durch die Verwendung des Sender Rewriting Scheme auf meinem Mailserver. Während der SPF-Test selbst lediglich den relevanten DNS-Eintrag für die Briefumschlagsdomain (eden.one) berücksichtigt, prüft der DMARC-Mechanismus in Bezug auf SPF, ob header_from und envelope_from zueinander passen (Under DMARC a message can fail even if it passes SPF or DKIM, but fails alignment.
). Weil meine DMARC-Policy für SPF (und DKIM) eine strikte Übereinstimmung fordert –
<policy_published> <domain>lists.eden.one</domain> <adkim>s</adkim> <aspf>s</aspf> <p>quarantine</p> <sp>quarantine</sp> <pct>75</pct> </policy_published>
– muss dieser alignment check für SPF scheitern. DKIM ist nicht betroffen, weil Listenmails eine eigene DKIM-Signatur für lists.eden.one erhalten. Für Subdomains wie lists.eden.one lässt sich das SPF-Problem lösen, indem ich auf eine entspanntere Policy wechsele:
<policy_published> <domain>lists.eden.one</domain> <adkim>s</adkim> <aspf>r</aspf> <p>quarantine</p> <sp>quarantine</sp> <pct>75</pct> </policy_published> <record> <row> <source_ip>217.160.240.138</source_ip> <count>1</count> <policy_evaluated> <disposition>none</disposition> <dkim>pass</dkim> <spf>pass</spf> </policy_evaluated> </row>
Für andere Domains (z.B. janeden.net) käme nur ein Verzicht auf SRS in Frage, um die Abweichung von header_from und envelope_from zu eliminieren –
<record> <row> <source_ip>123.123.123.123</source_ip> <count>1</count> <policy_evaluated> <disposition>none</disposition> <dkim>pass</dkim> <spf>pass</spf> </policy_evaluated> </row> <identifiers> <header_from>janeden.net</header_from> </identifiers> <auth_results> <dkim> <domain>janeden.net</domain> <result>pass</result> <selector>s42</selector> </dkim> <spf> <domain>janeden.net</domain> <result>pass</result> </spf> </auth_results> </record>
– was aber neue Probleme für die vielen über meinen Mailserver weitergeleiteten E-Mails aufwürfe. Ich tröste mich damit, dass das passende DKIM-Alignment eine hinreichende Bedingung für ein positives DMARC-Ergebnis ist.