This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Feature Request - DKIM and DMARC Support

As many spam filtering providers are continually upping their defenses against spam, DKIM and DMARC support is going to be an increasing need-to-have for authenticating client's email servers as non-spammers.

Rackspace is even updating their systems to support DKIM signing on outgoing email and will be implementing DMARC as well which is going to make spam filtering even more troublesome with them when our client's systems don't support either.

And Office 365 supports DKIM as seems rather odd that Reflexion is lagging behind so much in bringing these features to the table.

This thread was automatically locked due to age.
  • For those that stumble on this request ... please read answer here:


    Reflexion and you: DKIM
    Posted by Max McElroy on 23 October 2019 01:26 PM
    This article applies to any Enterprises that are sending mail outbound through our Smarthost

    This article will: Briefly define DKIM and describe how it interacts with Reflexion

    This article will NOT: describe how to configure DKIM

    DomainKeys Identified Mail (DKIM) is a method to ensure that mail is A) coming from where it is supposed to, and B) not manipulated or altered while in transport.  This is achieved by adding a txt record with a "public key" to the domain registry, adding a "private key" to the mail service, and encoding a hashed copy of the keys to all mail sent by the mail service.  If the message is altered in transit, the hash of the keys is changed, and if the recipient server is enforcing DKIM checks, the message will be handled according to the recipient's checks.  This can be used to prevent "man in the middle" and hijacking style attacks from being delivered through email.  When used in conjunction with SPF or DMARC, DKIM can further helps prevent spoofed or false messages from being delivered.

    However, Reflexion does not currently provide our own DKIM signing for outbound messages.  In addition, because of how DKIM is designed to work, we also cannot recommend using the Control Panel Footer if you both have DKIM, and use our smarthost for outbound mail.

    As previously described, altering a message while in transit will change the key-hash for a DKIM protected message.  When Reflexion added the Control Panel Footer to an inbound message, this will break the hash for an inbound message.  Furthermore, when a message is sent back outbound through our smarthost we will strip the footer out of a message if we detect it; which would also cause any outbound messages to then fail a DKIM check.  Our official statement for our own clients is that we do not support the use of DKIM for this reason.

    If your domain is utilizing DKIM to secure your messages, you can disable the Control Panel Footer for inbound messages.  This will allow you to send outbound through Reflexion without the key-hash being disturbed.  Alternatively, you can remove the Reflexion smarhost from your environment, but if the Control Panel Footer is active, external recipients will be able to see it.

    Currently, we do not have any plans to initiate DKIM support.  If this changes, we will notify our partners and clients, and provide in depth configuration instructions.
  • This article does not address DMARC alignment.  I am working with a client who has a DMARC policy of reject.  And I am troubleshooting with Sophos support on why messages are still being received inbound that spoof my client's domain AND do not achieve DMARC alignment.  So let me break this down

    Message is from and originates from an overseas IP address.  DKIM signing was not present so DMARC alignment was not achieved this way.  In addition, the original sender IP from overseas is not authorized on our SPF record.  So DKIM alignment failed, and SPF alignment failed… so our DMARC reject policy should have indicated to the Reflexion SMTP server to drop the connection as it was not aligned with our policy. 

    The sender is spoofing an internal email address  which DMARC should require the SPF to corroborate that claim by looking at the sender’s IP address.  In my understanding, DMARC alignment should have failed and the Reflexion mail server should have rejected this message in the SMTP session. 

    I’m trying to get to an understanding of why this happened.  Is our SPF or DMARC settings not correct, or is DMARC checking not performed by Reflexion’s mail servers?  This is a significant part of our mail domain integrity and it doesn’t appear to be working properly.  Can you help me understand this?