DMARC Alignment Issue

[possumdelight]

I'm trying to solve a DMARC alignment issue.

A custom application generates and sends sends mail (to the Pickup directory) from info@mydomain.com behalof of user@clientdomain.com and collects bounces in the info@mydomain.com mailbox for central processing.

This has worked well for decades, adding SPF and then DKIM-exchange in recent years; however, I noticed deliverability issues recently due to DMARC alignment fails. After googling for a solution, the only way that I can imagine solving the issue, while maintaining different Header From/Envelope From address domains, is to maybe sign the e-mails going out with a DKIM signature provided to me by clientdomain.com.

Is this possible with dkim-exchange? If I set up clientdomain.com in dkim-exchange with a key provided by the client, will it sign e-mails based on the Header From address, or the Envelope From address? I'm assuming it will sign based on the Envelope From address which wouldn't really solve my problem would it?

Is there a way to DKIM-sign based on the Header From address instead of the Envelope From address?

Any thoughts/input are appreciated.

Kind Regards,

Charlie

[possumdelight]

By the way, thank you guys so much for creating and maintaining this tool. I cannot believe DKIM isn't natively built in to On-prem Exchange. dkim-Exchange has been a life-saver for me.

After looking into my issue further and downloading the repo:

Since DMARC alignment is based on the message header FROM address, I propose that dkim-exchange should prioritize the message header FROM domain when signing messages instead of the Envelope/Return-Path domain. In most cases these domains will be the same; however, in cases like mine, when Return-Path and Message Header From domains are intentionally different, relying on Return-Path will break DMARC alignment - and I don't see any downsides to using the message header FROM address as the first option.

Something like this:

    private void SignMailItem(MailItem mailItem)
    {
        // If the mail item is a "system message" then it will be read-only here,
        // and we can't sign it. Additionally, if the message has a "TnefPart",
        // then it is in a proprietary format used by Outlook and Exchange Server,
        // which means we shouldn't bother signing it.
        if (!mailItem.Message.IsSystemMessage && mailItem.Message.TnefPart == null)
        {

            string smtpAddress = null;
            string domainPart = null;

            // Choose the best smtpAddress for domainPart selection
            if (mailItem.Message.From != null)
            {
                // Prioritize Message.From address for DMARC DKIM alignment
                smtpAddress = mailItem.Message.From.SmtpAddress;
            }
            else if (mailItem.Message.Sender != null)
            {
                // Fall back to Message.Sender address
                smtpAddress = mailItem.Message.Sender.SmtpAddress;
            }
            else if(mailItem.FromAddress.IsValid){
                // Fall back to mailItem.FromAddress
                smtpAddress = mailItem.FromAddress.ToString();
            }
            else {
                Logger.LogWarning("Unable to determine valid From address. Not signing email.");
                return;
            }

            // Assign domainPart based on smtpAddress
            if (smtpAddress != null && smtpAddress.Length > 0)
            {
                try
                {
                    domainPart = new MailAddress(smtpAddress).Host;
                }
                catch (FormatException)
                {
                    // Ignore
                }
            }

            // Do not sign if domainPart is null
            if (domainPart == null)
            {
                Logger.LogWarning("Unable to determine valid domainPart from address '" + smtpAddress +  "'. Not signing email.");
                return;
            }

            /* If domain was found in define domain configuration */
            if (dkimSigner.GetDomains().ContainsKey(domainPart))

...

[Deckard99]

As the development seems not to be existent at the moment I would nope hope to much for a solution in the near future. If you look back in the existing issues, there are at least 2 other issues that describe similar problems with empty sender mails like OOF or NDR. https://github.com/Pro/dkim-exchange/issues/378 https://github.com/Pro/dkim-exchange/issues/181

We are on a Exchange hybrid infrastructure and if users in ExO are sending with their alias addresses (SendFromAliasEnabled) the mails will be signed with the wrong domain (sender domain instead from domain), as you described.

[kavejo]

I guess the cause for this behaviour is that Exchange (2013 and onwards, including online) always resolve the P1 header to the user Primary SMTP Address, and this is by design. DKIM is only applied to P1 (envelope) headers, such as MAIL FROM, and not to P2 (message) headers, like FROM.

If you see, even in Exchange Online, there has been work to ensure P1 match either the sender or recipient domain, and there is no more tenant attribution based on P2.

I'd say it's best to correct the P1/P2 mismatch, ensuring they are on the same domain, rather than signing the P2 FROM.