On 30 March 2017 at 16:19, Fazzina, Angelo <angelo.fazz...@uconn.edu> wrote: > Thank you Dominic, > > > > I think I am starting to confuse the 2 sides of the coin and wanted > clarification. > > > > If I setup DKIM, it is to be used by whom ? > > Is it for anyone including my own domain, when an @uconn.edu email is > received, it is to be checked ? > > > > A. Does my DKIM entry in DNS help with sending from x...@example.com > to x...@uconn.edu ? > > B. Does my DKIM entry in DNS help with sending from x...@uconn.edu to > x...@example.com? > > C. Does my DKIM entry in DNS help with sending from x...@uconn.edu > to y...@uconn.edu ? > > > > In “C” I am thinking emails from staff to student and vice versa. Staff on > O365 and students on Google Apps. > > Both cloud solutions. > > *Student to staff* would go google -> to my MX record which is spam > appliance -> postfix box -> O365 servers > > *Staff to Student* would go O365 -> to my MX record which is spam > appliance -> postfix box -> Google servers > As I understand it, DKIM requires a separate DNS record for each subdomain to which it will apply (unlike DMARC). So if you want to send emails with header 'From: alf02013@appmail.uconn.edu' and you want these to have a useful DKIM header, then there must be a DNS TXT entry at mykey._ domainkey.appmail.uconn.edu, and the private key to which this relates must have been used by your mailserver to generate the DKIM header (with s=mykey) that appears in your email. With a separate but similar DNS TXT entry at mykey._domainkey.uconn.edu, the same private key could be used by your mailserver to generate a valid DKIM header for an email from angelo.fazz...@uconn.edu. *Any* MUA can check your DKIM header to see whether the email is unmodified since the DKIM header was created by the private keyholder; but a valid DKIM header means very little unless it matches (is 'aligned with') the domain in the 'From' header, since a malefactor can still create an email faking your 'From' address and insert their own valid DKIM header based on their own domain (which will verify against their DNS TXT record). DMARC takes DKIM and adds in the concept of alignment, but of course it first requires that you are using DKIM. Unfortunately in the real world DKIM is often used badly, including by large organisations that should know better, so an unaligned DKIM header (or one that is faulty in some other way) is only an indication that there *just might* be a problem and nothing more. Similarly the presence of a DKIM TXT entry in DNS does not guarantee that all valid emails from this domain will have a DKIM header. This is another advantage of DMARC with p=reject, because no organisation can afford to have such a policy unless it is confident that its emails will all be correctly signed and aligned. If any of the above is wrong, I hope someone will explain better. Dominic
