search

Pro / dkim-exchange

DKIM Signing Agent for Microsoft Exchange Server
Other
409 stars 143 forks source link

Email sent from Onpremise exchange server to Gmail and O365 not having the Dkim signature on the mail header #356

Open Alagbalive4eva opened 2 years ago

Alagbalive4eva commented 2 years ago

Versions

Description

we have been using Exchange DKIM signer for a while now and recently we were flagged and the root cause mentioned was Malformed public Key, so i proceeded to redo the Dkim configuration.

After reconfiguring the DKIM i noticed that the Existing DNS check box returns No record found for selector._domainkey.Domain

Simple nslookup on the server using the below commands: set q=txt selector._domainkey.mydomain.com

Returns the domain key text without any problems.

Also i used the DKIMvalidator which passed.

Public Key DNS Lookup

Building DNS Query for selector._domainkey.domain Retrieved this publickey from DNS: v=DKIM1; k=rsa; p=MuikytWi3Kf0OAYHidfgreffenf5PyjCzBGlrQnU0G8X4GUZ96AH6mc5d3darONggndBFwsAJkDJZo9wyvvF3m+6/fstreyhrtbdffvvdfsvtr/Y/HlYX5++o5y4n+Bp4PqUKip6FFY6bOrkllEi1InyBW5orQHYCVI2jYSpfCS7/yiVe+zIQEZqf0EvO0X3L2miOIQI+AqoG/WvH0UDlRf0xpDjd9YTQIDAQAB Validating Signature

result = pass Details:

DKIM Signature was also verified

Message contains this DKIM Signature: DKIM-Signature: v=1; a=rsa-sha256; d=domain; s=mail; c=relaxed/relaxed; When i send email to gmail and O365 from the header i can see : dkim=none (message not signed) header.d=none But when i send an email to yahoomail it passed successfully : dkim=pass header.i=@domain header.s=mail;

Steps to Reproduce

Expected behaviour;** Email sent to Gmail and O365 should have the Dkim signature present

Actual behavior: Email sent to Gmail and O365 shown the Dkim signature on the mail header as none (message not signed)

sjackson0109 commented 2 years ago

This is a fault with your Office 365 configuration.

Look at the exchange online console, and then navigate to the defender anti-spam settings. There you can setup DKIM signing. With a different DNS Selector address.

Note you can use NSLOOKUP in one line. nslookup -type=txt _selector._domainkey.senderdomain.com

Note the selector might be a different spelling! Check the signed headers, for the prefix of the selector name.

Example some of mine are _selector-DATE.. or -selector-mimecast-date. Exchange online has a funky setup, where you use a CNAME instead.. so you don’t have to manually update the public key in the txt record ever again..

Why is this happening: In an exchange Hybrid configuration::, if you used your Exchange On Prem front-end servers as the transport servers (with centralised mail processing enabled on your tenant).. then all SMTP mail is processed on exchange online.. Without centralised processing, then your emails are signed and sent out of the SMTP delivery queues I. Prem, sent straight to your recepients MX.

I feel I have the exact setup as you (exchange configured in a hybrid mode, with centralised processing enabled? Which is the default behaviour.

Simon Jackson

On 16 Mar 2022, at 20:05, Alagbalive4eva @.***> wrote:

 Versions

Windows Server Version: Windows Server 2016 standard Exchange Version: Installed DKIM Exchange Version: Version 15.1 (Build 2176.2) Description

we have been using Exchange DKIM signer for a while now and recently we were flagged and the root cause mentioned was Malformed public Key, so i proceeded to redo the Dkim configuration.

After reconfiguring the DKIM i noticed that the Existing DNS check box returns No record found for selector._domainkey.Domain

Simple nslookup on the server using the below commands: set q=txt selector._domainkey.mydomain.com

Returns the domain key text without any problems.

Also i used the DKIMvalidator which passed.

Public Key DNS Lookup

Building DNS Query for selector._domainkey.domain Retrieved this publickey from DNS: v=DKIM1; k=rsa; p=MuikytWi3Kf0OAYHidfgreffenf5PyjCzBGlrQnU0G8X4GUZ96AH6mc5d3darONggndBFwsAJkDJZo9wyvvF3m+6/fstreyhrtbdffvvdfsvtr/Y/HlYX5++o5y4n+Bp4PqUKip6FFY6bOrkllEi1InyBW5orQHYCVI2jYSpfCS7/yiVe+zIQEZqf0EvO0X3L2miOIQI+AqoG/WvH0UDlRf0xpDjd9YTQIDAQAB Validating Signature

result = pass Details:

DKIM Signature was also verified

Message contains this DKIM Signature: DKIM-Signature: v=1; a=rsa-sha256; d=mtn.bj; s=mail; c=relaxed/relaxed; When i send email to gmail and O365 from the header i can see : dkim=none (message not signed) header.d=none But when i send an email to yahoomail it passed successfully : dkim=pass @.*** header.s=mail;

Steps to Reproduce

Expected behaviour;** Email sent to Gmail and O365 should have the Dkim signature present

Actual behavior: Email sent to Gmail and O365 shown the Dkim signature on the mail header as none (message not signed)

— Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you are subscribed to this thread.

Alagbalive4eva commented 2 years ago

Hi sjackson0109

Thanks for your quick response. But i am currently not running an hybrid enviroment. I have an onprem email server and also an O365 email server which are different domain and no trust between them. My problem is that i have configured Dkim on the on prem exchange server and when i send an email to Gmail and another domain email hosted on O365, the Dkim signature is missing and and the dkim part of the header displays "dkim=none (message not signed) header.d=none". byt when i send from my onpre to Ymail the Dkim is present and dislays "dkim=pass header.i=@Domain header.s=mail".

johnjore commented 2 years ago

Hm... Not sure if related, but I might have this problem as well. Single Exchange 2019 on-prem CU10, 15.2.922.7, no O365. DKIM 3.3.4

Every test email I send to googlemail works without issues, passes SPF and DKIM. However, occasionally, with real emails, I get this back:

<record>
    <row>
      <source_ip>x.x.x.x</source_ip>
      <count>2</count>
      <policy_evaluated>
        <disposition>none</disposition>
        **<dkim>fail</dkim>**
        <spf>pass</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>domain.name</header_from>
    </identifiers>
    <auth_results>
      <spf>
        <domain>domain.name</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>

Not sure how to troubleshoot this as the test emails always pass both SPF and DKIM.

stryqx commented 2 years ago

What canonicalization is in use: relaxed or simple? My guess is that simple is configured and you're getting failures due to a mail server in the delivery path modifying the headers used for signing. A good explanation of the difference can be found here - https://stackoverflow.com/a/63706246 If you're using relaxed, then you need to investigate the affected received message + delivery path to see what's dramatically mangling the headers used to perform the DKIM signing.

On Wed, 18 May 2022 at 21:16, John Jore @.***> wrote:

Hm... Not sure if relates, but I might have this problem as well. Single Exchange 2019 on-prem, no O365. DKIM 3.3.4

Every test email I send to googlemail works without issues, passes SPF and DKIM. However, occasionally, with real emails, I get this back:

x.x.x.x 2 none **fail** pass domain.name domain.name pass

Not sure how to troubleshoot this as the test emails always pass both SPF and DKIM.

— Reply to this email directly, view it on GitHub https://github.com/Pro/dkim-exchange/issues/356#issuecomment-1129880828, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEEHYXNWPJ6SGT6SXGZJH4TVKTGPRANCNFSM5Q44PK2Q . You are receiving this because you are subscribed to this thread.Message ID: @.***>

-- Regards, Chris Knight

johnjore commented 2 years ago

My Exchange looks up the MX record, and emails direct to @googlemail mail host. I dont use a smarthost or relay server so there should be no difference in the path.

Should be Relaxed:

<policy_published>
    <domain>domain.name</domain>
    <adkim>r</adkim>
    <aspf>r</aspf>
    <p>none</p>
    <sp>reject</sp>
    <pct>100</pct>
  </policy_published>

Here is another weird one from Google. Both IP addresses are the same. One successful, and four failing DKIM?

  <record>
    <row>
      <source_ip>x.x.x.x</source_ip>
      <count>1</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim>
        <spf>pass</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>domain.name</header_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>domain.name</domain>
        <result>pass</result>
        <selector>selector1</selector>
      </dkim>
      <spf>
        <domain>domain.name</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>
  <record>
    <row>
      <source_ip>x.x.x.x</source_ip>
      <count>4</count>
      <policy_evaluated>
        <disposition>none</disposition>
        **<dkim>fail</dkim>**
        <spf>pass</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>domain.name/header_from>
    </identifiers>
    <auth_results>
      <spf>
        <domain>domain.name</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>

Managed to send an email to google, no DKIM references, at all, in the email on the google side.

Original Message Message ID 559403d17f544425bc46bb81305ea414@domain.name Created at: Wed, May 18, 2022 at 9:29 PM (Delivered after 2 seconds) From: email To: googlemail.com> Subject: test SPF: PASS with IP x.x.x.x Learn more DMARC: 'PASS' Learn more


Delivered-To: <me>
Received: by 2002:ab0:3196:0:0:0:0:0 with SMTP id d22csp435177uan;
        Wed, 18 May 2022 04:29:18 -0700 (PDT)
X-Google-Smtp-Source: ABdhPJwdkkXG+lbnYIOUi2ICA6BP26/Ksox3/QztEev2KOufYwTGOJ5qIDXU5Ho0hnDeTQUX5d16
X-Received: by 2002:a17:902:d544:b0:161:c3fc:5de5 with SMTP id z4-20020a170902d54400b00161c3fc5de5mr2866153plf.112.1652873358005;
        Wed, 18 May 2022 04:29:18 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1652873358; cv=none;
        d=google.com; s=arc-20160816;
        b=Ga4l2Oov9NFVgCYyC8gd9/zX2po1pvKm7CC3cLOgGz2aX3dUi1TEhR/KwPVFriU4Vz
         LiFqzUfCcGfHf70T3AGMHDwJzJ2d/3NCWwO9yV1rhHbzMWIS+8/D5/LjD7tNPxW5agzc
         aRuh3fPkl1JEbTJuVZw6AfdCh8iBzF9ghTXY0jGjFQ5O99hQLsR7GS3bVU0UVh8UHUyL
         3Lc1wmfkSD3Tzu+5yBcV4E9oZmJlTAp4qpc+3rydSEzuVo11jxTWzTX9M28lwkIWXzYD
         gpd2SfctO3N0M6FnPpoj/pbGWYDSpKNaWDpVjvZo0BW4D5JoSFDQ+3crWU9Hy1me+iim
         1UDw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
        h=mime-version:content-language:accept-language:message-id:date
         :thread-index:thread-topic:subject:to:from;
        bh=m19p/XKRxO9HYBOBTRVVbHuN9XddgH33etDcK6YAeSI=;
        b=aC4cZdko3OT+YNFEfPp8q5R6riNY2SStA/xNoB5V8xC9NdpENhwEwe0xhi2Fj4WS4V
         /en7SRVx5ayar5AOsjnCB49XJaGB3BCdY+4SSISbl7JxSAQAfAGfZGjen/wuF4PAOcih
         nJQksDF9UzGNZxI6uuiFsk2B70PQiG30lUC9FmaiYA6GLWzz/6YhcqATj9CvAa1Xrfut
         EpVhxZKLWmUgI6gfuOND3RFrKKZ6x3drR1bDqd+IXKrlkGNW/ZHXIq8aQlXH3JshnMIk
         HLSAJO8Uyhvr9BFW1rsLhvFtCIHPY5nibE0sssUuQWQS7BHGeNj6xnelPZaEIzrlc4xe
         +gfw==
ARC-Authentication-Results: i=1; mx.google.com;
       spf=pass (google.com: domain of email designates x.x.x.x as permitted sender) smtp.mailfrom=email;
       dmarc=pass (p=NONE sp=REJECT dis=NONE) header.from=domain
Return-Path: <email>
Received: from fqdnservername ([x.x.x.x])
        by mx.google.com with ESMTPS id n1-20020a634d41000000b003c640139e9csi2275651pgl.372.2022.05.18.04.29.17
        for <me@gmail.com>
        (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
        Wed, 18 May 2022 04:29:17 -0700 (PDT)
Received-SPF: pass (google.com: domain of email designates x.x.x.x as permitted sender) client-ip=x.x.x.x;
Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of email@domain.name designates x.x.x.x as permitted sender) smtp.mailfrom=email@domain.name;
       dmarc=pass (p=NONE sp=REJECT dis=NONE) header.from=domain.name
Received: from exchangeserverfqdn (t.t.t.t) by exchangeserverfqdn (t.t.t.t) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.922.27; Wed, 18 May 2022 21:29:15 +1000
Received: from exchangeserverfqdn([fe80::0000:000:0000:0000]) by exchangeserverfqdn ([fe80::0000:000:0000:0000]) with mapi id 15.02.0922.027; Wed, 18 May 2022 21:29:15 +1000
Content-Type: multipart/mixed; boundary="_000_559403d17f544425bc46bb81305ea414domain.name_"
From: emailname<email@domain.name>
To: email <@googlemail.com>
Subject: test
Thread-Topic: test
Thread-Index: AQHYaqqBLB+ZHdIvfkKEVmUh5RrAXw==
Date: Wed, 18 May 2022 11:29:15 +0000
Message-ID: <559403d17f544425bc46bb81305ea414@domain.name>
Accept-Language: en-GB, nb-NO, en-US
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: <559403d17f544425bc46bb81305ea414@domain.name>
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [y.y.y.y]
MIME-Version: 1.0

--_000_559403d17f544425bc46bb81305ea414domain.name_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

--_000_559403d17f544425bc46bb81305ea414domain.name_
Content-Disposition: attachment; filename="winmail.dat"
Content-Transfer-Encoding: base64
Content-Type: application/ms-tnef; name="winmail.dat"

--_000_559403d17f544425bc46bb81305ea414domain.name_--

I'm guessing there is a problem in ruleset that decides if DKIM is to be applied to the message or not as it. I.e. "Got new message, checking if I can sign it..."

johnjore commented 2 years ago

I had a (small) brainwave.

And for what its worth, I think emailing a contact results in the message not being signed.

Also, I upgraded to 3.4.0 (Latest pre-release, for this test)

johnjore commented 2 years ago

Bump? Anyone else seeing the same? or just me?

stryqx commented 2 years ago

Howdy,

Just checked my Exchange Server 2019 CU11 install running DKIM 3.4.0. Exchange DkimSigner transport agent has the lowest priority with no other transport agents installed other than the default Microsoft-installed ones. I'm using the following signing settings:

Sending e-mails to Contacts in my Exchange organisation results in those messages being signed correctly. Not seeing any DKIM failures in my DMARC reports.

Double-check your Transport Agent priority settings and signing headers. Also check your external DNS provider - you can get DKIM failures due to DNS lookup failures, which can occur if your domain zone file isn't properly replicated from the primary nameserver to the secondary nameserver(s), or if the delegated nameserver records for your domain published by your DNS registrar are incorrect (e.g. there's more entries here than there are nameservers that have a copy of your current zone file).

On Fri, 27 May 2022 at 21:01, John Jore @.***> wrote:

Bump? Anyone else seeing the same? or just me?

— Reply to this email directly, view it on GitHub https://github.com/Pro/dkim-exchange/issues/356#issuecomment-1139513301, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEEHYXNCVSL2O3QROVGPWL3VMCTRNANCNFSM5Q44PK2Q . You are receiving this because you commented.Message ID: @.***>

-- Regards, Chris Knight

jdixon-86 commented 1 year ago

@stryqx @johnjore @Alagbalive4eva The default debug messages in the transport agent are not very good if you have a lot of messages and a lot of servers. It makes it hard to identify the messages you are sending and what is happening to them.

So I adjusted the code on my end to accurate identify them and I have found that a lot of my messages to Office 365 apparently have a "TnefPart" which this DKIM signer is coded not to sign. The recipient domain is not an accepted domain so I'm a little confused as to why it is doing this.

This code may need to be looked into: https://github.com/Pro/dkim-exchange/blob/59fe5308715b57580095210faca733b82921a5c7/Src/Exchange.DkimSigner/DkimSigningRoutingAgent.cs#L90

because I wonder if updates to Exchange are forcing this format when communicating with Office 365 (even when not in Hybrid mode). I'm still testing in my environment.

stryqx commented 1 year ago

Howdy,

Might be worth checking the TNEF conversion settings on the Exchange Server. https://learn.microsoft.com/en-us/exchange/mail-flow/content-conversion/tnef-conversion?view=exchserver-2019#tnef-conversion-options-for-remote-domains

On Tue, 6 Dec 2022 at 08:54, Jacob Dixon @.***> wrote:

@stryqx https://github.com/stryqx @johnjore https://github.com/johnjore @Alagbalive4eva https://github.com/Alagbalive4eva The default debug messages in the transport agent are not very good if you have a lot of messages and a lot of servers. It makes it hard to identify the messages you are sending and what is happening to them.

So I adjusted the code on my end to accurate identify them and I have found that a lot of my messages to Office 365 are apparently have a "TnefPart" which this DKIM signer is coded not to sign. The recipient domain is not an accepted domain so I'm a little confused as to why it is doing this.

This code may need to be looked into:

https://github.com/Pro/dkim-exchange/blob/59fe5308715b57580095210faca733b82921a5c7/Src/Exchange.DkimSigner/DkimSigningRoutingAgent.cs#L90

because I wonder if updates to Exchange are forcing this format when communicating with Office 365 (even when not in Hybrid mode). I'm still testing in my environment.

— Reply to this email directly, view it on GitHub https://github.com/Pro/dkim-exchange/issues/356#issuecomment-1338226209, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEEHYXN3JXNPRVE7VW67HK3WLZQAVANCNFSM5Q44PK2Q . You are receiving this because you were mentioned.Message ID: @.***>

-- Regards, Chris Knight