Presented here is a simple technical method the translation community can employ to gum up the works of the spammers' spam machines. Why the translation community specifically? Well the method does of course apply to anyone, but the particular spam pandemic (resisting saying ‘spamdemic’… not very well) ravaging the inboxes of LSPs with stolen CVs actually seems to originate from a particular group. We can’t be sure of its scale, but we’re aware of its approximate whereabouts and some of the key players' true identities. Breaking this spam ring would be a great way to start the new year afresh.
This specific spamming ring I refer to has been operating for a number of years now and has proven hard to stop. This is because of their use of free email providers. None of which are particularly well policed. However, there is a glimmer of hope, in that the free providers do actually provide automated methods of canning spam emails before they leave the house. It’s just that very few people are aware of them, or how they are employed.
I’ll keep this brief, because I could quite easily fill a book with this topic. I’ve basically been working with a colleague recently to stop email being spoofed from their domain. I think we cracked it, and want to share how, as well as explain the wider implications.
Responsible email providers, which Microsoft and Google aspire to be, check their email before sending it. They check that it isn’t being sent out under a false name so as to more easily ensure delivery straight to your inbox. But it’s hard for them to tell if a brand new free account, sending via third-party software, is genuinely affiliated with some translation-related domain or not. So most of the time the email is delivered to you with a plethora of mixed information in the email’s metadata, otherwise known as its ‘headers’. You get a from email address, a reply-to and other false information added to help the email’s deliverability. So your inbox doesn’t filter it out, basically. You might have noticed that flagging one email as spam doesn’t necessarily stop the next one from a new free email account.
The following technical method only works 100% if everyone does it. This is of course not at all a realistic expectation. But the more people who are aware of the fact that they have the power to stop their domain from being used to spoof emails, blocking the spammers before they even leave Microsoft/Google servers, the harder the job of the spammers is. So to be clear, it won’t stop you receiving spam, but it’ll stop your domain from being involved in the sending of spam. As well as other impacts I’ll explain below.
It also beats the other best practice of constantly reporting new spam accounts to abuse@hotmail.com, or abuse@gmail.com, especially with their onerous requirements for full message metadata (headers) and form filling. And what’s more, it will only take 10 minutes to set this up.
##The solution
- SPF and DMARC
- (and DKIM, optional, because it’s more involved)
I suggest we all set up SPF and DMARC records because it’s quick to do and does no harm to our own deliverability (in many cases actually improving it), while blocking out the spammers. If you can follow a DKIM tutorial (I’ll provide some below) and add that too, all the better.
###Example SPF record (my own):
"v=spf1 a mx ip4:myipaddress ~all"
It is added to your domain records (look for DNS records) with your email or domain host. Your host probably has a tutorial or offers support on this. I also had to put an @ in the ‘name’, or record type field.
###Example DMARC record (my own):
"v=DMARC1; p=none; pct=100; rua=mailto:my@emailaddress.co.uk; aspf=r;"
The settings in my case are: v = version, p = policy (alternatives are reject or quarantine, neither of which are desirable at first), pct = % of bad emails to apply the policy to, rua = the report address of the domain owner to send the alert to. aspf refers to subdomains, whether or not mail can be sent from them. I kept mine r, relaxed, but s, strict, is another option.
So that should stop nearly all attempts at spoofing your domain name. By default, I’ve checked, SPF+DMARC is enough to get you started, and you will get reports if your SPF policy fails when someone tries to spoof you. It is probably better to also include DKIM, if you can get it arranged. It’s actually relatively straightforward in Google Apps/Suite. I’ll provide some tutorial links here for after you’ve set up the first two.
###Guides for G Suite and Office 365
- SPF guide on G Suite, formerly Google Apps
- DMARC guide on G Suite, formerly Google Apps
- DKIM guide on G Suite, formerly Google Apps
- MS Office 365 SPF and DMARC guide
- MS Office 365 DKIM guide
##A brief attempt at a simplified explanation
SPF and DKIM came first (ca. 2004-2007) - they are simple one-liner text records added to your domain’s public record.
SPF tells all responsible email providers who make the check what your Sender Policy is, i.e. who can send email using your domain in the headers. DKIM offers Domain Keys to prove Identified Mail. What that means is that the email has a signature appended which matches (mathematically) to the key shown publicly in the domain record. It’s a wax seal on your emails. It’s more complicated to set up than DKIM, but offers this additional protection and credibility.
DMARC was built on top of the others, and has been around for the last 10 years, created in 2007 by Paypal who were having trouble with spoofers pretending to be them. For obvious reasons. DMARC, as far as I understand it, checks whether or not your domain allows sending from their servers and domains. It does this by calling your domain, looking at the text records for SPF and/or DKIM and confirming eligibility. If it fails, based on your DMARC settings, it will either report details to you of the attempt made, reject the message or quarantine it. This is good because spammers, using automated software or not, will give up on domains that fail and move on to open ones.
That’s why it is up to the translation community - every single business and freelancer - to secure their domains against spoofing.
Now, no judgement on anyone who hasn’t, or doesn’t feel confident enough to do it. I consider myself to be quite technically literate and still only realised I was missing a DMARC record this week. I have had SPF and DKIM for a number of years, however.
##A word on your domain’s credibility
A final word of warning for those who think they can put this down to a triviality, or a storm in a teacup: spammers can get your domain blacklisted. In practice, this means that your own genuine emails will start ending up in Spam boxes of clients, colleagues, family, friends and prospects.
Finally, and I have nothing to corroborate this as it’s nigh on impossible to get proof of anything SEO-algorithm related, but it may also affect search ranking results if search engines by MS and Google know your domain is involved in spam operations. It may not, but it’s not beyond the realm of possibility for your domain spam score to weight your pagerank. And, frankly, it’s such a simple job, it’s not worth the risk.
Do the fix. It’s quick, and we all win. If you don’t want to get involved, please forward this post to your technical partners.