TOPIC:

There are 3 email security technologies that will soon be incorporated into the sending and receiving of every FTH email, SPF, DKIM, and DMARC. We have had SPF in place for a long time thanks to Brian, but we are just now implementing the other two technologies.

For your benefit and/or curiosity, here are some good overview YouTube videos on these technologies. They are a bit technical, so if you would rather not view them and just let us handle this, that is fine.

SPF

DKIM

DMARC


We are not really doing anything useful with DMARC at the moment, but it may be something we will look at closer in the future.

At this time, I have implemented DKIM Signatures for emails generated by the server. I am currently testing and perfecting the implementation of DKIM Signatures for emails that you send from your email agent/webmail to our list server (e.g. To distribution lists and officer emails), which are in turn then sent to the end recipients.

I have set up this forum thread to allow you to ask questions and get up to speed with what is being done in this area.

I have now successfully implemented DKIM Signatures for our list server.

Our built-in email security measures have just underwent a step change in improved security.

Steve,

Would you explain briefly how SPF/DKIM is being handled for custom domains? I'm used to setting that up for my own domains but it appears FreeToastHost is reportedly managing a lot of that for the clubs.

I'm used to setting up the DNS TXT records for both SPF and DKIM but don't see any related records associated with our custom domain which points at FreeToastHost..

Is the expectation that those using custom domains will set those records up? If so, the instructions for setting up custom domains should probably be updated.

Finally regarding, DMARC, is it acceptable from a FreeToastHost viewpoint for custom domains to set up the TXT record with 100% rejection of emails that don't pass the checks? That would help with spoofiing would can severely damage an organization's reputation.

Thanks for all your support!

richfulton wrote:

Steve,

Would you explain briefly how SPF/DKIM is being handled for custom domains? I'm used to setting that up for my own domains but it appears FreeToastHost is reportedly managing a lot of that for the clubs.

I'm used to setting up the DNS TXT records for both SPF and DKIM but don't see any related records associated with our custom domain which points at FreeToastHost..

Is the expectation that those using custom domains will set those records up? If so, the instructions for setting up custom domains should probably be updated.

Finally regarding, DMARC, is it acceptable from a FreeToastHost viewpoint for custom domains to set up the TXT record with 100% rejection of emails that don't pass the checks? That would help with spoofiing would can severely damage an organization's reputation.

Thanks for all your support!

Rich, as all of the incoming email is sent through the FTH list server and all of it has the toastmastersclubs.org domain as the From address (to facilitate white listing it), we can handle the DKIM and DMARC stuff ourselves, even if you are using a custom domain. Essentially, a custom domain is just a way to get to the FTH server in this context, and we handle everything from there. As far as reputation goes, it is the server reputation that is at stake, not yours, because it is the final sender of email via the list server or via website emailers.

We are not doing much w/ incoming DKIM and DMARC right now other than sending warning bounces for DKIM failures on incoming **non-member** emails. We are signing outgoing emails as indicated above. Our outgoing DMARC uses a dummy DMARC record. You could say that we are still in the exploratory phase for DMARC and we have not yet figured out exactly what we want to do with it.

Many clubs do not have have the technical know-how to set this stuff up (or it is very limited), so we do and will continue to assert some control where it makes sense in order to make it work in a reasonable way. As a related example, note how you do not have to buy a SSL cert for your custom domain to get https access. (Another thing we are handling.)