DMARC handling option for SMTP

[EKjellquist]

Support,

I'm wondering if we can potentially have some tweaks for allowing through senders with, let's say 'incomplete' DKIM / DMARC setups. We've been getting a fair number of legit mail that does have good SPF records, but either questionable or improperly-done DKIM/DMARC and getting failures.

a basic DMARC record is usually something like:

v=DMARC1; p=quarantine; rua=mailto:dmarc@domain.com

Receiving mail servers should essentially quarantine any incoming email that fails DMARC alignment from this domain. In strict modes, you can force both SPF and DKIM to pass, or in relaxed modes, at least one or the other needs to pass. We have a number of contacts who don't have a tech person or are otherwise using generated records via Microsoft 365, GMail ,etc. and don't necessarily have the facilities to troubleshoot it.

For AMS, I guess what I'm asking is for some DMARC handling options for incoming mail via SMTP; a number of these sending domains either have no DMARC record or it doesn't have a rule to quarantine or reject. I'd like to have, say, a control or two in the DKIM area in Spam Filtering to handle stuff like this, rather than needing to whitelist as much.

One option could be a checkbox for incoming mail that doesn't have a DMARC policy specified (either nonexistent or no policy value of 'q' or 'r') to have AMS either PASS or Quarantine if at least one of the two checks is a Pass between SPF and DKIM.

Also, I get a good number of incoming DKIM failures for [Invalid Signature] but these mails are blocked, so i can't tell what key / signature was used at email time (could be issues due to DNS propagation, email checksum changing post-send, etc). Not sure of the best way to provide more detail here, but could there potentially be an additional log we could turn in in logging, say, for DKIM specifically to have the debug-level detail? Just a thought.

Somewhat frequently I run into these errors from known good senders (who likely have some technical issue on their end, their DNS records were in flux temporarily or our server couldn't reach them to verify in that moment), it would be good to have more technical info to be able to help them troubleshoot it.

[Code Crafters]

Please note that we have implemented both DKIM and SPF. However, we have not implemented DMARC at all yet. Instead of using DMARC policies to decide if both SPF / DKIM must pass or one of them along with what action to take, we instead have multiple options in DKIM and SPF to allow you to specify the actions for each failure type. For example, DKIM FAIL could reject the email in SMTP or add a SPAM flag / custom even to filter it later with content filtering, but DKIM PERMERROR (invalid DNS record) could allow the email through without being filtered. This means that you can use SPAM flag or even custom events with content filtering to decide your own rules (e.g. SPF + DKIM fail custom events moves to Junk folder but only one of these doesn't.)

We recommend not rejecting emails based on DKIM to start with and instead move the emails to a Junk folder where they can be monitored and adjustments to filtering made. Note that we improved SMTP logs to include the DKIM result (FAIL, PERMERROR etc.) along with a more specific description of why this result was made. These filter tags (DKIMRESULT, DKIMRESULTDETAIL, DKIMSELECTOR, DKIMDOMAIN) can also be used with a content filter rule to create a log of your own just for DKIM if you prefer. See https://www.codecrafters.com/AbilityMai ... torialTags for details of these DKIM tags along with any others that might be useful to you.

We may consider implementing DMARC in a future update to use the DMARC record policies rather than ours to determine strictness (SPF / DKIM or both) actions (Quarantine, Reject) as well as the reporting side as well (rua). However, this is a major feature and we wanted more feedback on how useful this would be before putting in a lot of work for this. As I said, AMS won't use DMARC record policies, but you can filter for SPF / DKIM or both as a combo using SPAM filtering and content filtering for the actions already. As for the reporting side, this is useful for others receiving your emails but also is a vulnerability for triggering heavy workloads from AMS with email SPAM attacks potentially resulting in a DDOS scenario. Note that you can, however, set up DMARC records for your domains (as we have done) to receive DMARC reports from other email servers, detailing why your emails were rejected or quarantined. We have a content filter rule to move these reports to a DMARC folder so they can be looked at periodically without clogging up the Inbox.

If we missed any of your points or you want to detail further specific features (including DMARC itself) that we could add that would help you, please let us know what you would like to see in future updates for AMS.