Axigen Community Forum

  • If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

Announcement

Collapse
No announcement yet.

DKIM signing not working on fourth domain

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

    DKIM signing not working on fourth domain

    Hi,

    I have a strange issue regarding DKIM signing. I just set up a fourth domain and for some strange reason when email is relayed though Axigen (10.1.5) towards a Gmail recipient, it does NOT appear to be DKIM signed. However, if I send the email though webmail or the android K-9 mail client the Gmail recipient shows it as signed by my domain.

    Everything regarding the configuration of this fourth domain is identical to the other three, other than the domain name itself and obviously the private and public DKIM keys.

    Any thoughts?

    Thanks in advance,

    Kris

    #2
    Hello,

    Under normal conditions DKIM signing is made only for authenticated messages (like those sent via WebMail). Could you check how the messages that are not signed are received into your server?

    If you allow relaying from trusted IP addresses the messages received from that IP addresses are not authenticated thus, most probably, will not be signed.

    If you still could not trace the problem please share the smtpFilters.script file so we could (re)evaluate the conditions used for signing messages.

    HTH,
    Ioan

    Comment


      #3
      Hi Ioan,

      I sent a personal message to your account with the contents of smtpFilters.script.

      Comment


        #4
        Hello,

        The smtpFilters script confirmed that the signing is conditioned by the mailFromDomain and by the isAuth connection status.

        The next step should be to check your logs to understand how the messages that are not signed (before relaying to the final destination) are received by the server. My bets are that them are sent via a non-authenticated session (like accepting based on an acceptance rule or being generated locally, via the sendmail wrapper).

        My suggestion is to increase the log level for SMTP Receiving and Processing services to Protocol Communication level and review the logs for such messages.

        HTH,
        Ioan

        Comment

        Working...
        X