You probably haven’t ever heard of DMARC – but it could well be protecting your email inbox from potential spam and online attacks as we speak.
DMARC stands for ‘Domain-based Message Authentication, Reporting & Conformance’ and is an email authentication protocol that ensures the sender of the email is, in all likelihood, from a legitimate source. With the rise in internet scams, phishing tactics and e-commerce, it is more crucial than ever to protect your inbox from possible hacks via fraudulent emails to maintain data protection. A DMARC policy allows a sender's domain to indicate that their emails are protected, and tells a receiver what to do if authentication criteria are not met – such as bounce the email or send it to junk. DMARC removes guesswork from the receiver's handling of these failed messages, limiting or eliminating the user's exposure to potentially harmful messages.
DMARC and peer review systems
The peer review systems widely used at Taylor & Francis - both Editorial Manager and ScholarOne Manuscripts – typically operate by sending emails and alerts from the system as if sent by a named user, where the from address and the @server.com details do not match. This is known as ‘spoofing’. In legitimate use, spoofing acts as a good way to send emails from within an organization’s server (in this case the peer review systems) but appear to the outside world to be from another person. The ‘from’ address may appear as “firstname.lastname@example.org” even though the actual domain of the sending server is something else, such as “email@example.com”. This is the core of DMARC policy, and email providers are now checking to make sure these two domains (the ‘from’ address and the sending server) match so that spammers are not able to ‘spoof’ genuine emails as a means to appear more trustworthy.
In late 2014, both Yahoo and AOL.com signed up to DMARC policy. In June 2016, Google announced that its Gmail server would also follow suit. Due to the large number of registered system accounts within our peer review sites with Gmail, Yahoo or AOL accounts, it is now time for peer review systems to update the formatting of their email addresses to properly support the academic community using the sites to ensure that perfectly valid emails and alerts sent from such systems are not being inadvertently blocked.
What happens next?
The most assured and robust way to not see any adverse effects to the emails your peer review site is sending is to prompt all users away from using Gmail, Yahoo or AOL email addresses in their registered account. Where possible, university and institutional email addresses are always more favorable. It may be useful to use the peer review system to send out a broadcast or system-wide email to all users, suggesting that any person who currently use an email address from Yahoo, AOL or Gmail to interact with the site, should change this as a priority.
The other main change is the way in which the emails from the peer review systems will appear. In the coming weeks, the ‘from’ address will appear as the journal name (or the journal’s common name). The journal name will be what appears in the inbox in the ‘from’ section if you’re looking at a summary view of your inbox. The actual address that the email is connected to would then appear when the email is opened. This should be the case if using Webmail or email clients such as Outlook. You may notice such changes to the emails being sent from your peer review system in the not too distant future, but there is no action for you to take here.
If you have any questions about these changes, don’t hesitate to contact either your Taylor & Francis peer review systems support contact or the managing editor of your journal.
If you think that email notifications from ScholarOne are failing to reach your inbox, please check your SPAM Folder. This is particularly important because if emails are not reaching your SPAM Folder then the ScholarOne email address will need to be whitelisted (approved) by your server, and you will start to receive emails generated by ScholarOne. This tends to be an issue for institutional addresses, e.g. university servers.
If you feel that you have been affected by this issue, you will need to get in touch with your IT department.