How to Secure Your Email Delivery: A Step-by-Step Guide

Written by Brian O'Neill | Dec 19, 2023 4:00:00 PM

Various email providers have begun to clamp down on incoming emails that are deemed "untrusted". If you haven't properly set up your email environment, you could find your emails being rejected by the major providers, or more frequently ending up in "Junk" folders where users won't see them. To get your email trusted today really requires that you set up a “Domain-based Message Authentication, Reporting & Conformance" (DMARC) record for your domains - and that requires setting up a couple of other things as well.

Maximizing Email Deliverability: Key Strategies for Success

One thing to keep in mind - you cannot make a recipient provider trust your emails. Emails may be rejected or go to a Junk folder for a variety of reasons, including how the recipient decides to handle the emails. But what you can do is give more reasons for them to trust your emails. Avoid sending emails that "look" spammy, such as having long recipient lists (including Bcc lists), generic attributions, lots of external links to images, etc. If your business requires sending bulk emails, consider setting up a subdomain (something like, "lists.mydomain.com") instead of using your primary domain so that if your bulk domain runs afoul of a recipient provider, your own business emails aren't affected. If you use bulk email tools/third-party providers like SendGrid, also make sure you include their info in your records as shown below.

From an infrastructure standpoint, however, there are several things that you absolutely should be doing these days to increase the trust of your emails. It involves a lot of letters, that we will explain in a moment - SPF, DKIM and DMARC. And you will need access to change your domain's DNS records.

If you are a simple office, with just email provided by a major provider like Microsoft 365 or Google, it is actually very easy to set all of this up. If you have more complicated needs - such as using other service providers that send email on your behalf, like HubSpot or Salesforce for example, you will need to check with each provider to get the information you need.

SPF and DKIM: Pillars of Email Authentication

First, there are two methods we can use to help get your messages to be better trusted - Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM). They both provide trust information, but for two different things - SPF tells a recipient to trust based on the source IP address of the sending email server, while DKIM increases the trust of the message itself. You can use one or the other, but you really should do both.

Let's talk about SPF first. In a way it is much simpler - if you know the information. SPF is a DNS record that lists all the IP addresses that are considered trusted sources for your email, and what to do if email comes from a source not listed. If you only use a single service provider, they will often give the values of this record to you. For instance, if you only use Microsoft 365, your record may look something like this:

"v=spf1 include:spf.protection.outlook.com -all"

This record tells a recipient system to do another DNS lookup for "spf.protection.outlook.com" for an SPF record and include the results as if they were in your own record - that way you don't need to know all the IP addresses of Microsoft's servers (I'll explain the "-all" at the end in a bit). If you have multiple providers, or you maintain servers that send email, etc. you will need to construct a record that includes EVERYTHING that you know of. There are a variety of ways to add things to this record - rather than list them all here, you can refer to this document from Google, but here is an example…let's say, we use Microsoft 365 for our main email, but we have a server that has a public address of "W.X.Y.Z" that also sends email directly to recipients (for example, our monitoring system.) Our record might instead look like:

"v=spf1 ip4:W.X.Y.Z include:spf.protection.outlook.com -all"

Be aware that the maximum length of an SPF (or any DNS TXT) record is 255 characters - if for some reason your record would exceed this length, you can simply create another record, say "spf1.mydomain.com", in the same format with some of the addresses, and then include that in your main record:

"v=spf1 include:spf1.mydomain.com include:spf.protection.outlook.com -all"

You can also use network ranges in an "ip4" specification, like "ip4:W.X.Y.0/24". Note also for IP addresses these are the PUBLIC IP addresses the system would be seen as. If they go through a NAT firewall, be sure to use the external address.

This record goes in your DNS for the domain(s) you are sending email from - typically in the "apex" record, as of type "TXT". How you enter this depends on your DNS provider. You may have other TXT records already - it is fine having several.

The "-all" shown in all the examples basically says to a recipient, "These are ALL the trusted sources, and if you get email from ANY other source, don't trust it." What the recipient will do depends on their own settings. Another option is "~all", which is referred to as "SoftFail", which tells the recipient "You should accept it, but treat it as suspicious…" This might result in it more likely ending up in Junk, however.

DKIM works a bit differently. Instead of us having to define our sending systems, we instead have the sending system cryptographically sign each email that goes through it. Then, when the recipient's system receives it, it looks up the public key via DNS and decrypts the signature. If the signature matches, the message is considered trusted because we know it came from the domain. If the signature does not match, the message is considered untrusted. If no signature is included, the default response is neutral, at least in the absence of a DMARC record that says otherwise – more on that in a bit.

Most major providers support automatically generating the keys, providing the DNS record details, and signing the emails automatically for you, once you follow their instructions on setting it up. When you first enable DKIM at your email provider, you will be given the DNS records to add to your DNS provider. Often these are references to other DNS entries that you add as a CNAME in your DNS. If you are doing this yourself, you will add a specially formatted TXT record. Once the email provider detects that the DNS records are in place, it will begin signing the emails.

Step-by-Step Guide to Enhancing Email Security with DKIM and DMARC in Microsoft 365

Let's look at an example of setting this up in Microsoft 365.

1. Access DKIM Settings in Microsoft 365:

Microsoft loves to move things around, but the DKIM settings are currently found by navigating to the Security control panel in Microsoft 365.
Go to "Email & collaboration", then "Policies & rules", followed by "Threat Policies".
Select "Email authentication settings".
Click on the "DKIM" section.

2. Enable DKIM for Your Domain:

Find and click on the domain you want to enable DKIM for.
A sidebar will appear with a slider marked "Disabled".
Click on the slider. A popup will instruct you to add two CNAME records: "selector1._domainkey" and "selector2._domainkey", along with their values.
The slider will stay in the "Disabled" position for now.

3. Configure CNAME Records:

If your domain is "example.com", the CNAME values will be:
- selector1-example-com._domainkey.examplecom.onmicrosoft.com
- selector2-example-com._domainkey.examplecom.onmicrosoft.com
Add these CNAME records to your DNS with the full DNS names "selector1._domainkey.example.com" and "selector2._domainkey.example.com".
Microsoft will publish the domain key record in their own DNS, so the CNAME you will add simply refers to it. The real record is a TXT record that will look something like this:
- "v=DKIM1; k=rsa; p=ABC123DEF456…"

4. Understand Selector Names and Key Rotation:

Note that you will usually be given two records to add with unique selector names to allow for rotating the keys without interrupting service. The selector names – the part before “._domainkey” - must be 100% unique, but there is no definitive guide for providers to choose unique name.
If you already have a provider like Microsoft 365 that uses “selector1._domainkey” and then a second provider also wants to use “selector1._domainkey”, you need to speak to your providers to support more unique names. While we haven't seen an issue yet, it is conceivable that two providers might use the same selector name.

5. Verify and Enable DKIM Records:

After adding the CNAME records and ensuring they're visible externally (depending on your DNS provider, it could be instantaneous or take some time), return to the DKIM settings.
Click on the slider again. If the DNS records are correctly in place, the slider will switch to "Enabled", and the signing of messages will begin.
When a message is DKIM-signed, the signature header in the message will include the selector of the key used. This allows the receiver to look up the key via DNS as "SELECTOR._domainkey.example.com" and decrypt the signature.

6. Implement Email Routing for DKIM:

If you maintain a number of independent systems that may send email to the outside world and want to make use of DKIM (and potentially reduce the SPF record entries), we recommend relaying your emails through just a couple of systems, then have those systems either do the signing, or in turn route through a provider who can (like Microsoft, Amazon Simple Email Service, or SendGrid).
We recommend still routing through a couple of monitored systems because you will want logs you can reference in case there are any issues with the quantity or nature of the emails sent. You don't want your provider to get angry about the volume or unintentional spammy-ness of the emails and affect your corporate emails as well. We maintain many Linux systems that can all potentially generate email, and we have them all relay through a couple of trusted systems for logging and maintenance purposes, which in turn relay through Amazon SE.

7. Set Up DMARC Record:

OK...now that we've got our SPF and/or DKIM records in place, what about this DMARC thing?

DMARC is simply a third DNS record we add, that tells a recipient how much to trust the other records. This record is a lot more important now as some providers are becoming more suspicious of emails from domains that do not include a DMARC record, and even more if they don't have DKIM signing or SPF records. Bad actors can find domains without these protections and use their domains to send false emails to others. So, while in the past not having these things in place was OK and considered "neutral", things have shifted, and this stance now looks "suspicious" and can even lead to outright refusal of your email. In general, DMARC says that you should trust an email if at least one of SPF or DKIM passes their tests.
DMARC is another TXT record, which goes into our DNS example.com domain as "_dmarc.example.com". Here is a simple example:

"v=DMARC1; p=none; rua=mailto:mailadmin@example.com"

It has several "tags", separated by semi-colons. The first two shown are required:

v=DMARC1

This specifies the type and version of the record this is. "DMARC1" is the only possible value currently. It also must be first in the line. For all others the order does not matter.

p=none
This specifies the "policy" to apply to messages that do not pass DMARC. Here "none" means that you are not directing action - that leaves the recipient to do whatever they would do by default. This does NOT mean "accept it regardless", but it's the value you should use initially until you are confident that your other records are complete.

Other options are "quarantine", which tells the recipient that they should inspect the message further and likely put it aside (i.e., in a Junk folder), and "reject", which tells the recipient "do not accept this email". Note that the policy is advisory…the recipient’s system is still free to accept or reject the message based on other factors.

Hint: if you have several domains that you never send email from, you can help prevent someone from spoofing those domains by adding a "v=DMARC1; p=reject" DMARC record with no other information needed.

All other tags are optional, but here are a few common ones:

rua=mailto:emailaddress…

This tells a recipient system where to send an Aggregate Report to. Typically, once a day in which any email is received from the sending domain, a recipient system set up for sending these reports (the

major providers do this at least) will send a XML-formatted report to the email address listed. More than one address can be specified with comma separation. Each address must have "mailto:" prepended.

ruf=mailto:emailaddress…

Similar to "rua", "ruf" sends Forensic Reports to the listed email addresses. A forensic report is usually sent immediately upon a failure and contains more information. However, they are not necessarily sent for each failure, and they are less implemented than Aggregate Reports. They can be extremely helpful in solving problems if they are sent.

pct=N

In conjunction with "p=quarantine" or "p=reject", "pct" tells a recipient what percentage of email from a sender should be subject to the policy, with "N" being a number from 0-100. This is used to slowly transition from a policy of "p=none" and give time to analyze the reports and avoid legitimate email from being affected. If not specified, the default is 100.

aspf=r; adkim=r

"aspf" and "adkim" can be important and refer to how a recipient will interpret an "alignment" failure vs a direct SPF or DKIM failure respectively. That requires a bit of explanation and a bit of understanding of the SMTP protocol.

If the MailFrom (aka Envelope From) of a message has a domain of example.com, and the From: header has an email address with the matching domain "example.com", then the message is considered "aligned", and all is good.

If for some reason these differ - say, the MailFrom had a subdomain of "lists.example.com" while the From: header simply had example.com, the alignment would be "failed" as they don't match, but it might be desirable to allow for subdomains to pass this particular test. As such, we can tell recipients to use a "relaxed" alignment, which allows subdomains to pass the alignment check. This is the default, but we can specify by setting the particular tag to "r". If we want a "strict" alignment check, we can set the value to "s". An alternative to a relaxed alignment is to have SPF and DKIM set up independently for all your subdomains.

If you use some services that send email on your behalf, you most like need to have your alignments set to "relaxed" anyway as they may be using their own domain in parts of the message which can cause an SPF Alignment failure, but as long as the DKIM alignment passes, your messages should be good.

8. Document Your DNS Records:

One last thing – document your records as to why they are there/what their content means. Some DNS systems do not allow you to annotate the records to provide a reason. This will make auditing the records and removing those that are no longer necessary much easier down the road.

So now, after all that, you should be better protected from others spoofing your email addresses and have more confidence that your legitimate emails will be handled properly. This still does not guarantee anything…recipients can still report your emails as Junk (even accidentally!) - you can only control your end of the equation.

At iuvo, our team of experts are dedicated to helping you optimize your systems for maximum security and efficiency. Whether you're a small business or a large enterprise, our tailored solutions ensure that your infrastructure is robust, and your communications are secure.