Re: [dmarc-ietf] Sender-supplied decision matrix for passing DMARC

Tobias Herkula <> Mon, 14 June 2021 17:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E98733A2C8B; Mon, 14 Jun 2021 10:53:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.796
X-Spam-Status: No, score=-2.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.698, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 59y4K4MrNp5g; Mon, 14 Jun 2021 10:53:12 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 605323A2C7D; Mon, 14 Jun 2021 10:53:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=corp1; h=MIME-Version:Message-ID:Date:Subject:To:From:cc:sender:reply-to; bh=NjbcBCMAenW5JJEZ+JsOZOCHWPxyhMHWF1V7zS2sEVk=; b=CUoQ/Q4EnuUKf1c1muttn9Lm7 f6qBfZ1cVKK7tbfqOHbjScVc2XcvpVB2wqQ4xDNH2+jBEyQ+9kYiikxwQQHg1xKT3UTk4ZPO/5grM 0ZirhLhsJrzNzXToui9U8LbHXqkn1l35+2tsRtIjQtrQoU8Zo6971aZNkMQqRtVStjwUvlqCdJN1b 4ewaQeu+RJoQmnQOxOOAp6udmfAhpTiiJaSmDSi7DSByq9IHGR/UTN28ZuNY8sllkCGOjIlm6Yj/O xOKfPVmmZE8u3mmOKfeWspi6Gw5SReKJScDMbqRuTM+wt5JcjgCMlkhGoNLZfCQNNQKkTuhzUGMRa uCjYRPzFg==;
Received: from [] (helo=KAPPEX002.united.domain) by with esmtps (TLS1.2:ECDHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.92) (envelope-from <>) id 1lsqlq-00052o-HS; Mon, 14 Jun 2021 19:53:10 +0200
Received: from KAPPEX008.united.domain ( by KAPPEX002.united.domain ( with Microsoft SMTP Server (TLS) id 15.0.1497.18; Mon, 14 Jun 2021 19:53:09 +0200
Received: from KAPPEX008.united.domain ([fe80::8d8b:cacd:98e8:ec69]) by KAPPEX008.united.domain ([fe80::8d8b:cacd:98e8:ec69%13]) with mapi id 15.00.1497.018; Mon, 14 Jun 2021 19:53:09 +0200
From: Tobias Herkula <>
To: Seth Blank <>, "Brotman, Alex" <>, "" <>
Thread-Topic: [dmarc-ietf] Sender-supplied decision matrix for passing DMARC
Thread-Index: AddhPDwbCzQ9bLtKT5O2BtOM1Kt/J///8BiA///dPFA=
Date: Mon, 14 Jun 2021 17:53:08 +0000
Message-ID: <caa45e567fb844dd8c46a8ccbf4077d6@KAPPEX008.united.domain>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US, de-DE
Content-Language: de-DE
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_caa45e567fb844dd8c46a8ccbf4077d6KAPPEX008uniteddomain_"
MIME-Version: 1.0
X-Virus-Scanned: ClamAV@mvs-ha-bs
Archived-At: <>
Subject: Re: [dmarc-ietf] Sender-supplied decision matrix for passing DMARC
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 14 Jun 2021 17:55:03 -0000

This risks sendability with the fact that there are a lof of receivers that require SPF-RRs. So not providing SPF-RRs also fails with such an requirement. Besides that does SPF not help with any kind of 5322.From spoofing, but this ist he most important identifier for an enduser.

/ Tobias Herkula

Senior Product Owner Mail Security
Mail Application Security

1&1 Mail & Media GmbH | Mitte | 10115 Berlin | Deutschland
E-Mail:<> | Web:<>

Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 7666

Geschäftsführer: Alexander Charles, Thomas Ludwig, Jan Oetjen, Sandra Vollmer

Member of United Internet

Diese E-Mail kann vertrauliche und/oder gesetzlich geschützte Informationen enthalten. Wenn Sie nicht der bestimmungsgemäße Adressat sind oder diese E-Mail irrtümlich erhalten haben, unterrichten Sie bitte den Absender und vernichten Sie diese E-Mail. Anderen als dem bestimmungsgemäßen Adressaten ist untersagt, diese E-Mail zu speichern, weiterzuleiten oder ihren Inhalt auf welche Weise auch immer zu verwenden.

This e-mail may contain confidential and/or privileged information. If you are not the intended recipient of this e-mail, you are hereby notified that saving, distribution or use of the content of this e-mail in any way is prohibited. If you have received this e-mail in error, please notify the sender and delete the e-mail.

Von: dmarc <> Im Auftrag von Seth Blank
Gesendet: Montag, 14. Juni 2021 19:45
An: Brotman, Alex <>rg>;
Betreff: Re: [dmarc-ietf] Sender-supplied decision matrix for passing DMARC

HUGE cringe ;-) DMARC has an explicit policy that either SPF or DKIM must pass aligned. This proposal breaks that foundationally.

This is suggested quite frequently, but fails to understand just how few senders of email actually send with DKIM. Most email is sent from services that have a core business that's not in email, and when we're lucky, they manage to publish an SPF record for their customers to use. Only large volume sophisticated services tend to do DKIM.

A domain owner that requires everything that sends on its behalf to use DKIM basically shoots itself in the foot, and makes most of the services they'd need to use unavailable to themselves.

The correct answer is what you said: domain owners who want this should only authenticate services using DKIM.


On Mon, Jun 14, 2021 at 10:10 AM Brotman, Alex <<>> wrote:

I was talking to some folks about DMARC, and a question came as to suggest as the domain holder that your messages should always pass DKIM.  Effectively, the asker wants to say "I intend to deploy SPF and DKIM, but I will *always* sign my messages with DKIM."  So the obvious answer may be "Just only use DKIM", but I'm not sure that completely answers the question.  While discussing with someone else, "Tell me when DKIM fails, but SPF is fully aligned".  There was recently an incident at a provider where they were allowing any sender to send as any domain (and I'm aware that's not specifically a DMARC issue).  We all know brands that have just dumped in a pile of "include" statements without fully understanding the implications.  In this case, other users could send as other domains, but perhaps they would not have been DKIM signed.  Should there be a method by which a domain holder can say "We want all message to have both, or be treated as a failure", or "We'll provide both, but DKI
 M is a must"?

>From a receiver side, it makes evaluation more complex.  From a sender side, it gives them more control over what is considered pass/fail.

How does this look in practice?  Maybe "v=DMARC1;p=quarantine;rua=...;pm=dkim:must,spf:should;"
(pm=Policy Matrix)

Does this make everyone cringe, or perhaps worth a larger discussion?

Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy

dmarc mailing list<>

Seth Blank | VP, Product
p: 415.273.8818

This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system.