Implementing SPF DKIM DMARC BIMI records to Improve email security

There are several types of standards available online to improve your domain reputation and email deliverability rate. Most enterprise environments implement them all.

• SPF (Sender Policy Framework)
• DKIM (Domain Keys Identified Mail)
• DMARC (Domain-based Message Authentication, Reporting & Conformance)
• Brand Indicator Message Identification (BIMI) (Not Widely used anymore – Needs Verified Mark Certificates to achieve the same)

What is SPF(Sender Policy Framework) record and let see how to implement them efficiently.

It identifies which mail servers are permitted to send email on behalf of your domain. The purpose of an SPF record is to prevent spammers from sending messages with forged from addresses at your domain.

It’s highly recommended to have a SPF record with an hard fail (-all) created for your domain being spoofed elsewhere in the world. Most of the antispam appliances have SPF record check . which is enabled in most of the environment. A proper SPF required a must to improve email deliverability. We will see various scenarios and how SPF records can be created. Configuring a single SPF for single domain it is fairly simple

Lets consider you are having a single domain ,with no Hybrid. Your Sample SPF will look like below if you are using different IP ranges to send out emails.

v=spf1 mx ip4:83.111.59.80 ip4:83.111.59.80 ip4:194.170.218.80 ip4:195.229.45.80 -all

Let’s consider you are having a hybrid with Office 365. where emails sent out from your on-premises and Office 365 and SPF record will look like below.

v=spf1 mx ip4:83.111.59.80 ip4:83.111.59.80 ip4:194.170.218.80 ip4:195.229.45.80 include:spf.protection.outlook.com -all

Let’s consider you are having a hybrid with Office 365, Emails are sent out via on-premises environment and via mimecast from office 365 for example. your SPF record will look like below.

v=spf1 include:eu._netblocks.mimecast.com a:mail.azure365pro.com ip4:149.56.100.101 -all

Let’s consider having multiple domains hosted, Instead of creating SPF records for each domain. There is an easy of creating one TXT record and you can make all the domains to refer the same TXT record using the “include” Option. if you are managing 100 domains and you want to change your Public IP range, for example, you don’t have to update all the domains. you can keep updating the primary TXT record. It will save a lot of time if you manage a lot of domains. Let’s see how to implement the same. First, we should create a TXT record called spf.azure365pro.com with the value (which can be an Ipv4 range or MX), in my case I have specified the public ipv4 range where my Outgoing mails will be. This will be the primary domain and all my additional domains will refer to me to A record and it’s a hybrid environment as well.

spf.azure365pro.com, TXT, v=spf1 mx ip4:83.111.59.80 ip4:83.111.59.80 ip4:194.170.218.80 ip4:195.229.45.80 -all

Now am saying the world as whoever has a TXT record in their public domain as spf.azure365pro.com and if they send out emails from this IP range . Its a trustable source.

The ~all at the end is called a soft fail. It means that recipients may accept mail from another server, but it should be viewed with suspicion. If you change it to -all, you are directing the recipient to reject mail from any server other than these. The majority of the Office 365 mailboxes are configured with hard fail. The soft fail approach is safer and recommended if you are not sure of the environment but if you are aware of the environment then hard fail is a must to improve email reliability.

Lets see how to configure additional Domains sending out outbound email

you can configure the additional domains sending as below referring the other record we already creation. if you have any number of addtional domains you can keep referring to the same record. Even the hosters do the same. Even Microsoft does the same.

your-domain.com, TXT, v=spf1 include:spf.azur365pro.com -all

Let’s see some more Samples.

your-domain.com, TXT, v=spf1 a:your_smtp_server_name include:spf.azure365pro.com -all

OR

your-domain.com, TXT, v=spf1 mx:your_mx_server_name include:spf.azure365pro.com -all

OR

your-domain.com, TXT, v=spf1 ip4:your_smtp_server_IP include:spf.azure365pro.com -all

OR

v=spf1 ip4:12.35.57.75/28 include:spf.azure365pro.com include:emailmarketing.com -all

OR

v=spf1 mx ip4:83.111.59.80 ip4:83.111.59.80 ip4:194.170.218.80 ip4:195.229.45.80 -all

There are multiple SPF generators available online. You can make use of it as well.

What is DKIM (Domain Keys Identified Mail) record, and let’s see how to implement them efficiently.

DomainKeys Identified Mail is an email authentication method designed that allows the receiver to check that an email was indeed sent and authorized by the owner. It works by adding a digital signature to the headers of an email message. That signature can be validated against a public cryptographic key in the domain TXT records.

Let’s see how to implement them in Mimecast, for example. It’s pretty simple.

Administration Policies – Sign Outbound – Create a DKIM Record – You can create the DNS record, wait for the records to replicate, and click on Check DNS. You can do it anytime, as until you assign this to a policy, this signature will not take effect.

Now you can assign to a policy anytime so that it can send out emails with DKIM enabled. always the quickest way of checking it to send an email to Gmail, and you can click on show original it’s almost instant to take effect. So that it will show below. If you have IronPort Check this article also about managing DKIM with multiple domains

What is DMARC (Domain-based Message Authentication, Reporting & Conformance) record and let’s see how to implement them efficiently.

A DMARC policy allows a sender’s domain to indicate that their emails are protected by SPF and/or DKIM and tells a receiver what to do if neither of those authentication methods passes – such as to reject the message or quarantine it. The policy can also specify how an email receiver can report back to the sender’s domain about messages that pass and/or fail

For Example, the Organization controlling the azure365pro.com DNS domain intends to monitor SPF and/or DKIM failure rates and doesn’t expect emails to be sent from subdomains of azure365pro.com. Note that a subdomain can publish its DMARC record; receivers must check it out before falling back to the organizational domain record.

v=DMARC1;p=none;sp=quarantine;pct=100;rua=mailto:dmarcreports@localhost;

v is the version
p is the policy (none/reject/quarantine)
sp the subdomain policy (none/reject/quarantine)
pct is the percent of “bad” emails on which to apply the policy
rua is the URI to send aggregate reports to.

Most of the time, you can see such records, Emails forwarding to DMARC analyzers or to companies who manages your brand protection.

v=DMARC1;p=reject;pct=100;rua=mailto:dmarc@localhost;fo=1;ruf=mailto:dmarc@localhost,mailto:dmarcdashboard@localhost

fo: This is a tag that lets mailbox providers know you want message samples of emails that failed either SPF and/or DKIM. There are four value options available:
0: Generate a DMARC failure report if all underlying authentication mechanisms (SPF and DKIM) fail to produce an aligned “pass” result. (default)
1: Generate a DMARC failure report if any underlying authentication mechanism (SPF or DKIM) produced something other than an aligned “pass” result. (recommended)
d: Generate a DKIM failure report if the message had a signature that failed evaluation, regardless of its alignment.
s: Generate an SPF failure report if the message failed SPF evaluation, regardless of its alignment.
Optional tags

If an email address in rua or ruf has a different root domain than the domain of the policy record, an
authorization record must be added to the root domain of the email address to indicate that it accepts
reports about that domain. For example, if dmarc@localhost also needed to accept reports for
azure365pro.in, the policy record for azure365pro.in would look like this:

Because azure365pro.in is a different base domain than azure365pro.com, the following record needs to be
added to example.com to indicate that it accepts reports about azure365pro.com:

Sample Records – ( if you don’t need any email reports but to implement DMARC . you can use like below as well)

v=DMARC1; p=reject; pct=100

if you just need aggregated URI report you can implement like below.

v=DMARC1;p=reject;pct=100;rua=mailto:dmarc@localhost

Once the record is published you can see.

What is (Brand Indicator Message Identification (BIMI)  record, and let’s see how to implement them efficiently.

You need SPF, DKIM, and DMARC to Implement BIMI, Brand Indicators for Message Identification (BIMI) permits Domain Owners to coordinate with Mail User Agents (MUAs) to display brand-specific Indicators next to properly authenticated messages. Have you ever wondered how the email logos is appearing in your Outlook Apps for Meetup.com, for example, for other reputed domains, you can do a bimi record lookup for the domain and you can check if they will be using BIMI record to insert the image into your app. For Example, the sample record looks like below.

v=BIMI1; l=https://www.azure365pro.com/azure365prologo.svg;

v = Version: the value is always BIMI1. (Required)
l = Location: the URL of your logo using HTTPS only. (Required)
a = Trust authorities: trust certificate to validate domain ownership. (Optional)

Sample record with Trust Cert.

v=BIMI1; l=https://www.azure365pro.com/azure365prologo.svg; a=cert;

Sample Image of BIMI implemented domains.

Lets see how these records will look in a Public DNS zone, for example, in nic. ae

 SPF        
 Hostname    Type    Value
 azure365pro.com    TXT v=spf1 mx ip4:80.111.59.80 ip4:80.111.59.1 ip4:194.170.218.231 ip4:80.111.116.116 -all
 careexchange.in    TXT v=spf1 include:spf.azure365pro.com -all
 a.com    TXT v=spf1 include:spf.azure365pro.com -all
 spf.azure365pro.com    TXT v=spf1 mx ip4:80.111.59.80 ip4:80.111.59.1 ip4:194.170.218.231 ip4:80.111.116.116 -all
 DKIM        
 Hostname    Type    Value
 s1._domainkey.azure365pro.com    TXT v=DKIM1; k=rsa; p=MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM+7SJAxXhD/xNs1Yd/VWm6vgO7GnGjxQ0xFFicj6D8+2CEcONkZm0mWwokSBZ5/b2cFBwIDAQAB
 s1._domainkey.careexchange.in    CNAME   s1._domainkey.azure365pro.com
 s1._domainkey.sys.maqta.ae    TXT v=DKIM1; k=rsa; p=MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM+7SJAxXhD/xNs1Yd/VWm6vgO7GnGjxQ0xFFicj6D8+2CEcONkZm0mWwokSBZ5/b2cFBwIDAQABf2gtjvO1IxYIz5mWEmUUWW4uWeY0Pdj0SEgjznqKo52afQfT8qcAUQ6K3JnY6PwaQIDAQAB
 DMARC        
 Hostname    Type    Value
 _dmarc.azure365pro.com    TXT v=DMARC1; p=reject; pct=100; fo=1;rua=mailto:dmarc@localhost; ruf=mailto:dmarc@localhost
 _dmarc.careexchange.in    TXT v=DMARC1; p=reject; pct=100; fo=1;rua=mailto:dmarc@careexchange.in; ruf=mailto:dmarc@careexchange.in
 

 Uploaded an Implementation Document for Architects So that they can save more time by using the template.

 For Microsoft 365 – SPF / DKIM / DMARC Sample

                          Azure365pro.com
Mail      MX        azure365pro-com.mail.protection.outlook.com
SPF       TXT       v=spf1 include:spf.protection.outlook.com -all
Client   CNAME autodiscover autodiscover.outlook.com
DKIM    CNAME selector1._domainkey selector1-azure365pro-com._domainkey.azure365pro.onmicrosoft.com
DKIM    CNAME selector2._domainkey selector2-azure365pro-com._domainkey.azure365pro.onmicrosoft.com
DMARC TXT       _dmarc v=DMARC1; p=reject; pct=100; fo=1;rua=mailto:dmarc@Azure365pro.com; ruf=mailto:dmarc@Azure365pro.com