SPF, DKIM & DMARC records
Email Security
SPF Email Security
Verify your SPF records
To check your SPF verification:
- Go to http://www.webtoolhub.com.
- In the Enter URL field, enter the full domain name and click Show.
- Compare the key to your SPF records in Moosend.
DKIM Email Security
What is DKIM?#
DKIM (DomainKeys Identified Mail) is an email security standard that helps detect whether messages are altered in transit between sending and receiving mailservers.
DKIM authentication uses public-key cryptography to sign email with a responsible party’s private key as it leaves a sending server; recipient servers then use a public key published to the DKIM’s domain to verify the source of the message, and that the parts of the message included in the DKIM signature haven’t changed since the message was signed. Once the signature is verified with the public key by the recipient server, the message passes DKIM and is considered authentic.
What is a DKIM record?
#
A DKIM record is a specially formatted DNS TXT record; it stores the public key the receiving mail server will use to verify a message’s signature.
A DKIM record is formed by a name, version, key type, and the public key itself, and is often made available by the provider that is sending your email (for example, Postmark. That’s us 👋).
Two key reasons why DKIM is important
1. It confirms your legitimacy as a sender#
Spoofing email from trusted domains is a popular technique for malicious spam and phishing campaigns, and DKIM makes it harder to spoof email from domains that use it. While DKIM isn’t required, having emails that are signed with DKIM appear more legitimate to your recipients and are less likely to end up in the junk or spam folders.
DKIM is compatible with existing email infrastructure and works with SPF and DMARC to create multiple layers of security for domains sending emails. Mail servers that don’t support DKIM signatures are still able to receive signed messages without any problems. It’s an optional security protocol, and DKIM is not a universally adopted standard.
Even though it’s not required, we recommend you add a DKIM record to your DNS whenever possible to authenticate mail from your domain. We use it to sign messages at Postmark, and ISPs like Yahoo, AOL, and Gmail use it to check incoming messages. We’ve done testing that proved messages are more likely to be delivered when they use these security protocols.
2. It helps build your long-term reputation
An additional benefit of DKIM is that ISPs use it to build a domain reputation over time. As you send email and improve your delivery practices (low spam and bounces, high engagement), you help your domain build a good sending reputation with ISPs, which improves email deliverability.
While it’s important to understand what DKIM does, it’s also important to be clear about what it doesn’t solve. Using DKIM will make sure your message hasn’t been altered, but it doesn’t encrypt the contents of your message.
Many ESPs use opportunistic TLS to encrypt messages as they move between sender and recipients, but it’s still possible to send unencrypted messages if an email server refuses a TLS connection. Once a message has been delivered, the DKIM signature will remain in the email headers but won’t encrypt the content of the message in any way.
How To Check DKIM via “nslookup” From the Command Line?
You can check the DKIM record for a domain using the nslookup command in the console or command line. Here’s how:
- Open the console or command line on your computer.
- Type nslookup -q=txt
._domainkey. where is the DKIM selector and is the domain name. - Press Enter to execute the command.
- The output will display the DKIM record for the domain, including the public key and other information.
Below is an example of checking the DKIM record for the domain easydmarc.us with the selector google:
nslookup -q=txt google._domainkey.easydmarc.us
Non-authoritative answer:
google._domainkey.easydmarc.us text = “v=DKIM1; k=rsa;
p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtlOQQmjs3Y5diVg6cKpeJNfiWy0V9DXUERY3xvDyOC2DF8X2P+oNsNfuqpF/dffsSMLxyQOe2aj2msqHaX6MoG8ATUfk1pnNhUu8gqphhyMeBOpGRBsDPCPmaLj+SxO42Tbo9jz8yV//zoTVIJlHe3VKe8DrE22kGT2GcdVQdTR2YLtEV8e4UEgT2pPVmRdpZ””PXYq/nESCaMi8JTCTaARjTpi2Nxs/G4eV8dSv7RIw0qXz6XDfNyDacJ6uIs1hC84R+tFX0GCMJ+z6heD6PPCZtDhBj/hy1MGwg3z+5izDBEBsgCRsNaVa0XHKb54I1L9f/x502WUN9dmOv41jPlswIDAQAB”
The command will return the DKIM record for google._domainkey.easydmarc.us, which includes the DKIM public key and other information.
Setting up DKIM in Office 365
For each domain for which you want to add a DKIM signature in DNS, you need to publish two CNAME records.
For Office 365, the selectors will always be to selector CNAMES “selector1” and “selector2”.
- domainGUID is the same as the domainGUID in the customized MX record for your custom domain that appears before mail.protection.outlook.com. For example, in the following MX record for the domain contoso.com, the domainGUID is contoso-com:
contoso.com. 3600 IN MX 5 contoso-com.mail.protection.outlook.com - initialDomain is the domain that you used when you signed up for Office 365. Initial domains always end in onmicrosoft.com. For information about determining your initial domain, see Domains FAQ.
For example, if you have an initial domain of cohovineyardandwinery.onmicrosoft.com, and two custom domains cohovineyard.com and cohowinery.com, you would need to set up two CNAME records for each additional domain, for a total of four CNAME records.
Host name: selector1._domainkey
Points to address or value: **selector1-cohovineyard-com**._domainkey.cohovineyardandwinery.onmicrosoft.com
TTL: 3600
Host name: selector2._domainkey
Points to address or value: **selector2-cohovineyard-com**._domainkey.cohovineyardandwinery.onmicrosoft.com
TTL: 3600
Host name: selector1._domainkey
Points to address or value: **selector1-cohowinery-com**._domainkey.cohovineyardandwinery.onmicrosoft.com
TTL: 3600
Host name: selector2._domainkey
Points to address or value: **selector2-cohowinery-com**._domainkey.cohovineyardandwinery.onmicrosoft.com
TTL: 3600To enable DKIM signing for your custom domain through the Office 365 admin center
- Sign in to Office 365 with your work or school account.
- Select the app launcher icon in the upper-left and choose Admin.
- In the lower-left navigation, expand Admin and choose Exchange.
- Go to Protection > dkim.
- Select the domain for which you want to enable DKIM and then, for Sign messages for this domain with DKIM signatures, choose Enable. Repeat this step for each custom domain.
For more information view Microsofts article Use DKIM to validate outbound email sent from your custom domain in Office 365 at https://docs.microsoft.com/en-us/office365/SecurityCompliance/use-dkim-to-validate-outbound-email
Verify your DKIM records
To check your DKIM verification:
- Go to http://dkimcore.org/tools/keycheck.html.
- In the Selector field, enter s1.
- In the Domain name field, enter your domain name (without www).
- Click Check.
- If your DKIM Key is valid, the following message displays: This is a valid DKIM key.
- Compare the key to your DKIM records in Moosend: in Moosend , on the menu bar, click
. - On the menu on the left, click Senders and click the sender’s email address that you want to check. Now compare DKIM key in the TXT record value area to the one you have in DKIM core.
DMARC Email Security
How to Configure Office 365 DMARC
DMARC is the last step in securing your Office 365 mail. Where SPF only checks against the 5321.MailFrom address does DMARC also check the 5322.From address. It also tells the receiving mail systems what to do with mail send from your domain that didn’t pass the SPF and DKIM check.
Before we can start with configuring DMARC, you first need to configure SPF and DKIM for Office 365. These protocols are used to determine who is allowed to send mail on behalf of your domain.
In this article, we are going to take a look at how to set up DMARC and I will explain the different options you have when it comes to configuring DMARC.
How does DMARC work?
Before we configure DMARC, it’s good to understand how it exactly works. Because DMARC does not only tell the receiving mail server what to do with unauthorized (spoofed) emails, it also adds an extra security check.
The problem is that email can have multiple From headers. We have the Mail From address (5321.MailFrom), which identifies the sender of the mail. And we have the From address (5322.From), which is displayed in the mail client.
SPF only checks the Mail From address, which can be a problem. Take the following SMTP transcript example:
SPF only checks the Mail From the address. So in this case is the sending IP address allowed to send mail for the domain phishingdomain.com. If the attackers created an SPF record for the domain phishingdomain.com and listed the sending IP address, then the SPF check will pass.
The problem is that SPF doesn’t check the From address, it will completely ignore the fact the From address doesn’t match the Mail From address.
When you have enabled DMARC for your domain (stonegrovebank.com in this example), then the receiving server will also check the From address. This check will fail because the sending IP Address isn’t listed in your SPF record.
Monitoring, Quarantine and Rejecting Email
Another important function of DMARC is that it tells the receiving mail server what it should do with unauthorized emails. Before we can start with moving unauthorized mail to the spam folder, or rejecting mail completely, we first need to know for sure that all legitimate systems are authorized.
| Option | Policy | Description |
|---|---|---|
| Monitoring | p=none |
Just deliver the mail (used for testing) |
| Quarantine | p=quarantine |
Move the mail to the spam folder |
| Reject | p=reject |
Drop the email |
The last thing that you want is that your legitimate emails are dropped by the receiving server because you forget to add an IP Address to the SPF record. So what we can do is first monitor the DMARC results, using the monitoring policy setting.
Only when we are certain that everything is working as expected, can we move to quarantine or rejecting mails.
DMARC Reporting
The monitoring policy is always used in combination with an email address to send the report to. These reports are generated in XML format and give you insight into the DMARC results. Now I have to say, they are a bit hard to read:
You can specify the email address to send the reports to with the following tag in the TXTrecord:
After you have monitored the DMARC reports for a couple of weeks you can start with moving the mail to the spam folder. This way emails won’t be lost when you forgot to add that new mail system (or web application) to the SPF record.
In the end, you might want to reject emails completely, but keep in mind that if you are not using a DMARC analyzer you won’t know when emails are dropped after a failed SPF and DMARC check. So be careful with the reject policy.
Setup DMARC for Office 365
So now you have an idea of how DMARC works, let’s take a look at how to set up DMARC for Office 365. The steps below are not specific to Office 365 but will work for any domain. To set up DMARC we need to create a DNS record, just like with SPF. So make sure you have access to the DNS records.
The first step is to log in to your DNS provider. I am using Cloudflare, if you don’t know how to create DNS records then contact your hosting provider.
We are going to create a new TXT DNS record:
- Add a new record
- Select TXT as type
- Set the name to _dmarc
- Set the content to:
What this record does is monitor p=none all DMARC events, and send a report when SPF or DKIM fails fo=1. It also monitors all subdomains sp=none. The reports are sent to the mail address [email protected].
DMARC Tags
Besides the policies and reporting mail address, you have also a couple of other options that you can use in your DMARC record.
| Tag | Options | Description |
|---|---|---|
| sp | none, quarantine, reject | Used to apply the DMARC record to all subdomains. You can set a custom policy for the subdomains. |
| fo | 0, 1, d or s | Determine when to generate a forensic report: 0 – When both SPF and DKIM fail 1 – When SPF or DKIM fails d – Only when DKIM fails s – Only when SPF fails |
| pct | 1 – 99 | Percentage of failed emails that should be quarantined or rejected. Allows you to slowly test the quarantine or reject policy. Does not work with p=none |
