DMARC Reports – Why Email Servers Stop Sending DMARC Reports Due to DKIM

dkimdmarcemail

I have a personal email server I've been running for years; very seldom has there been a problem with sending mail and so I've never really got up to speed with things like SPF, DMARC, and DKIM. Recently, while upgrading the system, I decided to do this.

SPF was very simple, since I use a single, fixed IP address.

DMARC was almost as simple; I set this up initially with a policy of "none" to receive reports and left this for a week or two then switched it to reject.

I've now implemented a DKIM signing filter for the mail server (Courier MTA, and no there is no ready made for this). For the complicated bits I used dkimpy. This also has a simple verification tool which works on whole messages, does it's own look-ups, etc., meaning it is dummy proof in that there is only one way to use it (whereas the signing can be configured various ways and possibly leaves room for me to muck it up). This passes messages that I think should pass
and fails ones that I think shouldn't, so I'm reasonably satisfied that works; I've run it on messages as received from the server. Currently, to minimalize issues, I'm signing just the body and the From header.

However, none of my mail is going through to my test accounts — one is gmail and the other is from my ISP. What's more, although I now have both rua and ruf addresses in the DMARC record, I am not getting any reports for them. Previously, they were both like clockwork.

If all I do is turn off the filter (so no DKIM sig), everything works again. I have checked that the server is actually trying in all cases; the failed DKIM ones seemed to get time-outs and closed connections resulting in an endless deferral — which all alone seems a bit odd since it implies the "rejected" mail is not even being examined, yet removing the signature is all it takes to get it accepted again. I'll put that down to ambiguities in Courier's logging.

I realize no one is bound by any laws here, but is that a normal policy? Assuming the DKIM signature is wrong, shouldn't the receiving server send me a DMARC report of that?

So I'm currently up a creek. Although things like MXToolbox give me flying colours, I have not found a free service that actively tests the DKIM signature by taking mail except for one, which appears to have done what the other servers did — never accepts the mail it is supposed to test (dunno if this is a potential clue).

Here's the relevant DNS records from dig:

  • SPF: cognitivedissonance.ca. 3600 IN TXT "v=spf1 ip4:138.197.150.177 -all"

  • DKIM:

      aporia._domainkey.cognitivedissonance.ca. 3600 IN TXT "v=DKIM1; k=rsa; h=sha256; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAosptGk+J2mdjjc7RWmcnQ3yBqx1JT/lA0bw4GJCzZ+esa0f8rjHhPiW6NnUr64Kf5h0fPEthQhYGTjjw3jAd/3EE28hGA30+jODxEK7A0+5aeI82fWa/ZZk9FvyIhf+UkkX1B0klYhCRW5r91smJ+rwYrr2B6jOrw0DReHTAZ51NACSWI7ov2mA" "UIh2l8blA8hFFBOBwxlzC+smRsYlZCKZfsSMkyS/XIm2m58QNfw/aCHp5VufSrf/hh7f6AGKTgxHfgs+8RBbYdHEM2LAMT+WYsITC3R0OYfgplzWna6PRB9lx+FFzTtT/8XClYfUJ6rwWwM4koeX0yt9gDr/03QIDAQAB"

    Note that the FQDN of the mail server is aporia.cognitivedissonance.ca and so I used aporia as the DKIM selector out of lack of imagination. The email domain is just cognitivedissonance.ca. Should I be using the FQDN instead (ie. aporia._domainkey.aporia.cognitivedissonance.ca)?

  • DMARC:

      _dmarc.cognitivedissonance.ca. 3600 IN  TXT     "v=DMARC1;p=reject;pct=100;rua=mailto:[email protected],mailto:[email protected];ruf=mailto:[email protected],mailto:[email protected]; "

    There are some extra mailto's there for a dmarc validation service I signed up to. Unfortunately, they don't test DKIM signatures directly.

Finally, an example of a signature:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;
 d=cognitivedissonance.ca; [email protected]; q=dns/txt;
 s=aporia; t=1650468130; h=from;
 bh=3N81YR+AxHZqpkdMAh4Jti6JpRmUrlzO5bUjUoWdGeg=;
 b=kNzUid2LG8TfHoegur3JzlcktiJT+5A1E2en+IlV/GgDMZWL0Ft/4kE02LGFzb2kTMkav
 c9jLUqd2+NCrLDzVRBxgwif++vDwoljCI1X0wvbcCqhfA3uElcCuhCAtBkl/ZNqLR0H1Gjq
 XXA801KqyVrvottuv0+PmEOvqQ8skTpBvl4Da8JjQ73Zscm3/5Mfk0dGTLlggNgapszsP9z
 nt/1Oi6gzLasX933wIdLZWVex8QNfKr8+MTx6bmpVodaeklR+281u8k1zhCBu5pWrzlavUh
 CbWjUm4j3YbeztpG98r9MZOVKbJZyHaiHWcRa1vEq3Cz8AEnRyRkQhd5WtvA==

Best Answer

Eventually I did find an online DKIM validator: https://www.appmaildev.com/en/dkim They'll test an upload of an existing mail or give you a test address to send to.

I am not 100% sure what the original problem was, because by the time I found this I had created another one: Using Digital Ocean's "floating IP" feature to set my DNS records from. The OS doesn't actually see this address, and other mail servers were reporting mail as from that "actual" IP, (which is still valid). Worth noting if you are a droplet user.

To be clear, that could not have been the original problem, because I only enabled the floating IP yesterday when, in desperation, I decided to move the node to see if anything fell out of the tree. However...

I have not found a free service that actively tests the DKIM signature by taking mail except for one, which appears to have done what the other servers did -- never accepts the mail it is supposed to test (dunno if this is a potential clue).

Note that service was not the one linked in the first paragraph here. Anyway, that other mail servers in general were refusing connections (as opposed to bouncing mail) does seem to scream "DNS issue". Why exactly this became a problem when the new install of the server had been running for a month I still don't know, so this is really only a partial answer -- although it does explain Why email servers would stop sending DMARC reports. Getting all my ducks in a row with the DNS records (A records for the domain and the aporia node, matching the SPF, etc), finally everything is working as it should be.

Related Topic