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==