When sending email through Azure Communication Services (ACS), proper sender authentication is essential to ensure that your messages are trusted and successfully delivered. DomainKeys Identified Mail (DKIM) is one of the key technologies that provides this assurance by digitally signing each outgoing message. This allows recipient mail systems to verify that the email was not altered and genuinely originates from your domain. In this post, we’ll look at how to configure DKIM for Azure Communication Services, explain the underlying concepts, and highlight why sender authentication is a critical step in protecting your brand reputation, avoiding spoofing improving overall deliverability.
Sender authentication for email refers to a set of technical methods used to verify that messages truly come from the domain they claim to be sent from. It’s designed to help combat spam, phishing and spoofing. Together, these three standards help improve email deliverability, protect recipients from fraudulent messages and safeguard the sender’s domain reputation.
There are three main standards that make up modern email sender authentication:
- SPF
- DKIM
- DMARC
DKIM Background
DomainKeys Identified Mail (DKIM) is a method of email authentication that helps validate mail sent from your Microsoft 365 organization to prevent spoofed senders that are used in business email compromise (BEC), ransomware, and other phishing attacks.
The primary purpose of DKIM is to verify that a message hasn't been altered in transit. Specifically:
-
One or more private keys are generated for a domain and are used by the source email system to digitally sign important parts of outbound messages. These message parts include:
-
From, To, Subject, MIME-Version, Content-Type, Date, and other message header fields (depending on the source email system).
-
The message body.
-
-
The digital signature is stored in the DKIM-Signature header field in the message header and remains valid as long as intermediate email systems don't modify the signed parts of the message. The signing domain is identified by the d= value in the DKIM-Signature header field.
-
The corresponding public keys are stored in DNS records for the signing domain (CNAME records in Microsoft 365; other email systems might use TXT records).
-
Destination email systems use the d= value in the DKIM-Signature header field to:
-
Identify the signing domain.
-
Look up the public key in the DKIM DNS record for the domain.
-
Use the public key in the DKIM DNS record for the domain to verify the message signature.
-
Adding ACS Domain
As part of deploying ACS email resources you will most likely want to add a custom domain that matches your brand and identity. This is easily done in the portal as shown below.
The domain that you add will need to be verified to prove ownership. This should not be a surprise as this is a thing that admins have done for years in Azure and also M365.
That’s a standard task, so let’s look at the more interesting things…
ACS Email Sender Authentication – SPF
Configuring SPF is straightforward. Just add the required SPF record directly at the required level of the DNS hierarchy. In this case since we are adding the sales subdomain to tailspintoys.ca we must add the SPF record at the sales.tailspintoys.ca level. Note that SPF does not have inheritance - unlike DMARC. if there is already a SPF record at the tailspintoys.ca level, it will not be used for the subdomain. Hence we must ensure that it is added directly to the subdomain.
ACS Email Sender Authentication – DKIM
In the ACS wizard it provides the CNAME values that are to be entered for each DKIM selector record. There are two, which is the same as EOP. This allows for rotation of the key material for any required reason without having to make changes to DNS. This is a very useful level of abstraction. However, note what is provided for the CNAME record. It is different than the DKIM selectors that are used in EOP. This is because EOP only uses “Selector1” and “Selector2”.
An example of Selector1 for the sales.tailspintoys.ca domain would be:
selector1._domainkey.sales.tailspintoys.ca
The DKIM selectors for ACS email are longer – see the example below.
selector1-azurecomm-prod-net._domainkey.sales.tailspintoys.ca
After the zone file has propagated we can check if the ACS Selector1 and Selector2 DKIM entries work:
If we want to check the ACS DKIM selectors, then retrieve the below CNAME records:
selector1-azurecomm-prod-net._domainkey.sales.tailspintoys.ca
selector2-azurecomm-prod-net._domainkey.sales.tailspintoys.ca
Let’s also at how these records appear in MXToolbox.com
ACS Selector1
ACS Selector2
Cheers,
Rhoderick
