Wednesday , January 22 2020

Implementing SPF DKIM DMARC BIMI Records

There are several type of standards available online to improve your domain reputation and email deliverability rate. Most of the 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)

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

Lets consider you are having 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

Lets consider you are having 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

Lets consider have have multiple domains hosted, Instead of creating SPF records for each domain . There is a easy of creating one TXT record and you can make all the domains to refer the same TXT record using “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. Lets see how to implement the same . First we should create a TXT record called spf.azure365pro.com with the value (can be a 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 my A record and its 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. Majority of the Office 365 mailboxes are configured with hard fail.The soft fail approach is safer and recommended if your 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"

Lets 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.

image

What is DKIM (Domain Keys Identified Mail) record and let 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 in the domain TXT records.

lets see how to implement the in mimecast for example. Its fairly simple.

Administration Policies _ Sign Outbound _ Create a DKIM Record _ You can create the DNS record and 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.

image

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 a email to gmail and you can click on show original its 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

image

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

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 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 own 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@azure365pro.com;"

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@azure365pro.com;fo=1;ruf=mailto:dmarc@azure365pro.com,mailto:dmarcdashboard@azure365pro.com

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@azure365pro.com also needed to accept reports for
azure365pro.in, the policy record for azure365pro.in would look like this:

_dmarc.azure365pro.in TXT "v=DMARC1; p=reject; rua=mailto:dmarc@azure365pro.com;ruf=mailto:dmarc@azure365pro.com" 

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:

 azure365pro.in._report._dmarc_azure365pro.com TXT "v=DMARC1" 

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@azure365pro.com

Once the record is published you can see.

image

What is (Brand Indicator Message Identification (BIMI)  record and let 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 email logo 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 they will be using BIMI record to insert the image into your app. For Example the sample record look 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.

image

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@azure365pro.com; ruf=mailto:dmarc@azure365pro.com
 _dmarc.careexchange.in    TXT v=DMARC1; p=reject; pct=100; fo=1;rua=mailto:dmarc@careexchange.in; ruf=mailto:dmarc@careexchange.in
 

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

About Satheshwaran Manoharan

Satheshwaran Manoharan is an Microsoft Office Server and Services MVP , Publisher of Azure365pro.com. Specialized in Office365 / Microsoft Exchange / Virtualization , Sathesh is an Messaging Expert supporting/Designing/Deploying many medium size businesses to large enterprises when it comes to Corporate messaging and Virtualization Infrastructure

Check Also

Implementing DKIM in IronPort

Lets see how to Implement DKIM Signing using IronPort. You need to enable signing for …

One comment

  1. Good Explanation Sathesh 🙂

Leave a Reply

Your email address will not be published.