A new email industry group was announced this morning. DMARC is a group of industry participants, including large senders, large receivers and relevant intermediaries working on a framework to reduce the harm from phishing.
DMARC is working on a standard to allow senders to publish sending policies and receivers to act on those policies. Currently, senders who want receivers to not deliver unauthenticated email have to negotiate private agreements with the ISPs to make that happen. This is a way to expand the existing programs. Without a published standard, the overhead in managing individual agreements would quickly become prohibitive.
It is an anti-phishing technique built on top of current authentication processes. This is the “next step” in the process and one that most people involved in the authentication process were anticipating and planning for. I’m glad to see so many big players participating.
DMARC: an authentication framework
D
RSS - Posts
Thanks for the post Laura!
This is an exciting new addition to the deliverability box of tricks and it not only offers a good platform for authentication but as far as I understand it also offers a level of reporting.
This is however something that ESPs will have to consider carefully as to ensure whatever implementation they have is extendible and updatable.
At our ESP most clients have a custom sending domain and the emails are signed with a shared DKIM domain identity as some are on a shared IP address. Also, all the custom sending domains that clients have include an SPF (TXT) record. This has been easy to manage as we just use the “include:” switch in the SPF record which points to our primary domain, allowing us to update the SPF record on our side as required instead of asking each client to update their SPF records.
My questions are:
1) Does DMARC allow for dkim-identity sharing?
2) Does the _dmarc txt record have a switch to include a record from another source? Just like the SPF “include” rule)?