LiveChat 
Are spammers/scammers forging your email and ruining your reputation?
Yesterday, I learned that spammers and scammers were forging my email address to send fraudulent emails. Fortunately, their efforts were unsuccessful. All their fraudulent emails bounced.
How did I do that?
To understand how, you need to understand a few technical concepts. In the bad old days, when the Internet was a much more trusting place, anyone could forge anyone’s email address. That resulted in spam inundating everyone’s inboxes, to the point of making emails useless as a communication medium. Over the years, many technical measures and email security standards were developed to keep the problem under control. Today, these standards allow you to configure your domains correctly so that anyone trying to forge your domain’s email will fail. Their emails will either be rejected by email servers (in my case) or sent to the spam folder. This will help protect the reputation of your domain’s emails, which help reduce the likelihood of your emails being sent to spam folders.
There are three email security standards to secure your domain’s email service.
Sender Policy Framework (SPF)
SPF allows web domains to specify which email servers can send emails on behalf of that domain.
Example
For the nab.com web domain, its SPF records (which is publicly known information that can be looked up) specify that only email servers from mail1.nab.com.au and mail2.nab.com are allowed to send emails that come from nab.com.
Therefore, if an email purportedly from the CEO of NAB is sent from a foreign ISP’s email server, then the receiving email server will know that this email is not genuine.
Domain Keys Identified Emails (DKIM)
In DKIM, the web domain contains public cryptographic keys for email servers to verify the authenticity of emails sent from that domain. This is how the authentication works:
- The user’s email application (e.g. Outlook, Google Gmail) authenticates the user to the sending email server (e.g. a Microsoft Exchange server, Gmail).
- When the user sends an email, the sending email server will cryptographically sign the email with a secret private key that only it knows.
- When the email arrives at the receiving email server, it will obtain the public cryptographic key stored publicly in the domain of the sender’s email address. The public key is mathematically related to the secret private key, but it cannot be used to derive the private key.
The receiving email server will use the public key to verify that the email is authentic and has not been tampered with after it was sent.
Example
NAB sends an email from nab@updates.nab.com.au to their customers. In the email, it is specified that the email’s cryptographic signature can be verified with a public key found in the “updates.nab.com.au” domain.
The public key can be publicly obtained with standard system administration tools:
The receiving email server will download the public key from the “updates.nab.com.au” domain and verify the email to ensure that it is authentic and has not been tampered with.
If an email purportedly from nab@updates.nab.com.au cannot be verified, then it is not authentic and possibly tampered with through an interception.
Domain-based Message Authentication, Reporting & Conformance (DMARC)
DMARC is a record publicly published in your domain. It tells receiving email servers what to do with messages that do not conform to SPF and DKIM to the required standard (technically called “not aligned”). This record specifies where the receiving email servers can send reports to the domain’s owner. This report is called the “DMARC report”.
What happened in my case?
Each day, receiving email servers will send DMARC reports to me to inform me of how well my emails to them are doing. Yesterday, I received a DMARC report from Google even though I have not sent any emails from that particular domain to any of Google’s email addresses.
This is the first suspicious sign.
When I opened my DMARC report, I found out that there were dozens of attempts to send emails to Gmail addresses from unauthorised email servers. Because my domain’s DMARC record is set to the strictest level, I have instructed Google to reject every suspicious email.
What if you do not set up your domain correctly with SPF, DKIM and DMARC?
This means you are giving spammers and scammers a free pass to forge your domain’s emails. This in turn will hurt your brand eventually because spam filters will learn that your domain is the source of fraudulent emails. When that happens, you will find that more and more of your emails are either sent to the spam folders or even rejected completely by receiving email servers.
Then there is another problem. Google had sent notice that they are cracking down on improperly configured domains. If your domain is one of them, Google will bounce your emails that are sent to Gmail addresses.
Configuring SPF, DKIM and DMARC
SPF, DKIM and DMARC are highly technical configurations that should be left to the professionals to do. Even among IT professionals, they can be confusing if they do not have experience dealing with them.
It is a one-off setting that needs to be done once. In addition, each time you use services that send emails on behalf of your domain (e.g. email marketing platforms, invoicing services), you need to add records to the SPF and DKIM. This is to ensure that receiving email servers will know that these services are authorised by your domains.
If you need assistance with these configurations, we are here to help. Talk to us if you need help.
|
|
