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

Zachary Aab <> Mon, 14 June 2021 17:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 55E803A2C07 for <>; Mon, 14 Jun 2021 10:41:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YXX4K8lAg2hd for <>; Mon, 14 Jun 2021 10:41:23 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::c31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 203E23A2C08 for <>; Mon, 14 Jun 2021 10:41:22 -0700 (PDT)
Received: by with SMTP id j17-20020a0568200231b029024900620310so2845971oob.7 for <>; Mon, 14 Jun 2021 10:41:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eOWDjMkzL+EK1vBKc4sSx42rUgHsIJJ3vzHnHhlcM0I=; b=sDY/f1fB5/tRzCuW9DMH9QGJwhkaKOXC+s6nCffukG43KbQbN19YQstxnXZTQvTTy2 ZVSdBSkr5mNWsIWh/F08vtG5KGV7FV35lkvm9IxG+SjhSgqoWWvEhL9XzPhNAZYKkUFa OQ+Xos7fUh78HMVsDX2GROKX9/5MfVZLgUi9F1pehST6upnSbrV11IeWcQtNJdG7VMqt ZVX68JCF0404GtHwTcO4ZipDz4DMk3paY4VXxe6CldStpMU5ZvT3l7Zs8XXAC0NUVM0f iK8R/ID9dHuNn7zbpiQR+YJXHxnAhvi/nviItQ+E/RXO38hSHaxidNLzabO6/61YxYHF 01dw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=eOWDjMkzL+EK1vBKc4sSx42rUgHsIJJ3vzHnHhlcM0I=; b=k2y28+ZtLD5BGtHgTr/SZf6g2Yogu+cGMlBrTSYp4GucPV5L1Lv3pOFg33LD+2Tx3R +LVq0jyUn1mZDYLfWOxOtQFlOEkEzmn+JYAGohNKTU3qyYlsTtaIbUnqU1AwebFptyzC sNPJ9PALEzMSM7RmPyjBVhvb1uJW/Hf/XZQJnpyqCLG2Q5zRCeHJSV+EnSFXfePVnpV3 BktWLwJR5U35SaejHSovQE0EPOAt3u9Tmbr5ljC+Nt5MmXJCf9pdctxc8nxYL2TtGQRR sPnEw6THK0V6IteyHnVvKCJQvFaMio8dh6TedenIs9BRZTRPK4Ku326nCyQcF7KjFUo+ 6ZbQ==
X-Gm-Message-State: AOAM530AWqtJba0PQmdjhBW7ZvNJQD/hLbMtt+yXs2yPql9m6wgtXF2q DrUFGh/Zg4T/m1y6GMnCtE7cqEm3OIFOMKwti6XxdINoj/nd9A==
X-Google-Smtp-Source: ABdhPJxx4+RXSWGL3nguFfha8ydc4fIsutU0onxj8TVcous1CgRv/VM+WRPm4XSGlf/cMWpugk958nbxHlPmeRHDZNc=
X-Received: by 2002:a4a:dd8d:: with SMTP id h13mr13887036oov.84.1623692480660; Mon, 14 Jun 2021 10:41:20 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Zachary Aab <>
Date: Mon, 14 Jun 2021 13:41:09 -0400
Message-ID: <>
To: "Brotman, Alex" <>
Cc: "" <>
Content-Type: multipart/alternative; boundary="00000000000088c6f305c4bd5dd9"
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:41:28 -0000

This rings to me like something that would look like the simple/relaxed
alignment option currently in DMARC.  "Require aligned DKIM" being
something along the lines of "rdkim=y; rspf=n;" with the
not-included/default value being "n."
If you agree that adding it is simple enough, the real question is what
value does this really add to DMARC and/or will it improve DMARC adoption?
Personally, I think it would be generally welcomed among senders who like
really granular control over their authentication or who don't fully
understand DMARC's "defaults" (for example, senders who use "p=reject;

On Mon, Jun 14, 2021 at 1:10 PM Brotman, Alex <Alex_Brotman=> wrote:

> Hello,
> 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
> Comcast
> _______________________________________________
> dmarc mailing list