How can you know if the emails you receive are from a real sender, and not from fraudulent attempts? Today, the key to protecting your emails and your domain from spoofing and phishing attacks is to use email verification. As an Office 365 user, you can enable DKIM (DomainKeys Identified Mail) to digitally sign outgoing messages.
Remember the good (?) old days when things were so easy, so insecure and pretty straight forward? The days before https and certificates were really used? The days when you could change the URL in Hotmail and then easily open another user’s emails? Those were also the days when you could easily send an email and let the recipient believe that the email truly came from another email. It was so easy that everyone could do it. With the long gone Outlook Express, anyone without any technical knowledge could write the email of someone and then use Hotmail as the email server. And boom! When the message was received, it would look as if the email came from that person with no warnings or any issues at all!
For programmers, it is well known that you can send an email with PowerShell. It looks like this: PS> Send-MailMessage -From 'Me <firstname.lastname@example.org>' -To 'You <email@example.com>' -Subject 'Going fishing'
However, there is a completely different underlying verification and structure nowadays than back in the days of Outlook Express as described. So protect your emails and domains from spoofing and phishing attacks with email verification!
Let me explain how this works and why this is a clever thing to do.
In all simplicity, when using DKIM you need a private key and a public key.
The private key is embedded in the header of the email when it is sent. This contains information about the domain that sends the email.
The public key decrypts the header information and verifies that the email truly comes from you. The public key is added to the DNS record and is retrieved by the recipient server when the email enters.
This is used to reveal the encrypted header message and therefore it knows that the email truly comes from the domain that it claims to originate from.
It is a very technical process to create and set up a DKIM private key. The intention of this article is not to provide an exhaustive guide on how to do this, but just to provide an overview.
By default, Office 365 uses a default signing configuration for all domains that do not have a policy in place. This means that if DKIM is not manually set up, Office 365 will use its default policy and keys to enable DKIM. DKIM verifies that the sender of the message is, in fact, the party responsible for the message being sent.
When you use Xink server-side signatures in connection with Office 365, we need to make sure that you keep your DKIM and it is not destroyed during that process. So as an Office 365 client who uses server-side signatures with Xink, you need to add the following CNAME record to your domain:
xinkrr._domainkey CNAME xinkrr._domainkey.xink.io.
Changes will not be visible immediately, as it might take up to 72 hours for DNS changes to propagate and take effect.
So with this simple step, you can both use your email signatures in Xink added on server-side level. At the same time, we make sure that your keep your DKIM in place and nothing is broken. This way you can safely send emails and know that they look good and are trustworthy.
This article is part of a series of IT PRO mini articles written by Xink’s tech experts.
If you have any questions or comments, you’re more than welcome to reach out to us at any time, via our online support chat or email.