This article is intended for the use of IT departments and technical readers who have any understanding of email security. In some cases, you may be reading this page because your organisation has received emails which have failed DKIM, and hence, DMARC validation. This page should explain why that happened and how to resolve the problem.
DMARC, which stands for “Domain-based Message Authentication, Reporting & Conformance”, is an email authentication, policy, and reporting protocol. Building on SPF and DKIM it allows organisations to improve and monitor protection of their domain(s) from fraudulent email. [dmarc.org]
The software provided by GroupBC is a collaborative working system that is likely to be used by many users throughout a potentially complex supply chain. To facilitate this, each user must supply an email address to register with the system. This acts as both a means of communication and an identifier for that user.
The provided software will, at times, send email to users. This can be for a variety of reasons - password resets, notifications, reports etc. Many of these messages are system notifications and as such, they are "from" an administrator email address associated with the particular BC system being used. However, Issue notification messages are sent on behalf of the user of the system who initiated that process, i.e. who sent the issue. For the benefit of other users on the project, the intention is make the email appear as if it is directly from the user while at the same time identifying the email as originating from the BC server (via the Sender header). When an Issue notification email is received, the ability to filter the incoming email by the name of the person who sent the issue is very useful, particularly when a large number of issue notification emails has been received. Also, a user responding to the email can respond directly to the person who issued the information to them. No reply-to field is specified since the RFC5322.From field is the default address to which replies are addressed and the appropriate recipient of the reply is the user in question.
Our intention is to make it clear to recipients that the message has been sent by our system on behalf of the user in question. We attempt to do that by constructing the email with the following header and envelope information:
|The administrator address of the BC server|
|The user's registered address|
Business Collaborator Server <server admin>@groupbc.com
|The administrator address of the BC server (as used for the MailFrom field)|
In order for DMARC verification to succeed either SPF or DKIM must be valid and must match the domain of the address specified in the From field. SPF checks on the RFC5321.MailFrom will pass as this is always a groupbc.com address and there is a valid SPF record configured on the groupbc.com domain that matches the IP of the outgoing SMTP server within our hosted environment. However, in the case of Issue notification emails, the From field will not match the domain used for SPF validation and so we must ensure that the DKIM signature validates for that domain.
DKIM signing requires cooperation between GroupBC and "company.com" in order to sign messages with a key that is
- in place for signing within the hosted BC environment and
- is published within the domain of "company.com"
This key can be generated by "company.com" or GroupBC and then shared between the two parties. We would suggest that GroupBC generate the key as this will not require the private key to be transmitted because it will remain within our environment. GroupBC would then provide the public key for insertion into the "company.com" domain.
Selector and Domain/Sub-domain
In order to delegate email signing to our outgoing SMTP service the key must be designated a specific selector name. We suggest a 2048 bit key with selector name s2048_groupbc.
You may wish to delegate a sub-domain to GroupBC for the purposes of DKIM signing e.g. groupbc.company.com. The advantage of this would be that GroupBC would not be able to sign email with a valid signature for company.com. However, since the users' email addresses registered within our system will almost certainly be on the company.com domain rather than the subdomain, DMARC validation will only be possible in relaxed mode (as opposed to strict mode). For this reason if strict mode is required then a sub-domain cannot be used.
No changes to company.com's published DMARC policy are required. The fact that DKIM validation will pass on a domain (d=company.com) matching the From field value means that DMARC validation will succeed. As mentioned above, if using a sub-domain (d=groupbc.company.com) then DMARC must be configured for relaxed checking (rather than strict) to pass.
In order to put in place a valid DKIM signing mechanism for outgoing email from the GroupBC hosted environment, please raise a support request by emailing firstname.lastname@example.org and this will be passed to the Systems team for implementation. Please ensure that a suitable technical contact is provided for us to contact.