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:188.8.131.52 ip4:184.108.40.206 ip4:220.127.116.11 ip4:18.104.22.168 -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:22.214.171.124 ip4:126.96.36.199 ip4:188.8.131.52 ip4:184.108.40.206 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:220.127.116.11 -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:18.104.22.168 ip4:22.214.171.124 ip4:126.96.36.199 ip4:188.8.131.52 -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
your-domain.com, TXT, v=spf1 mx:your_mx_server_name include:spf.azure365pro.com -all
your-domain.com, TXT, v=spf1 ip4:your_smtp_server_IP include:spf.azure365pro.com -all
v=spf1 ip4:184.108.40.206/28 include:spf.azure365pro.com include:emailmarketing.com -all
v=spf1 mx ip4:220.127.116.11 ip4:18.104.22.168 ip4:22.214.171.124 ip4:126.96.36.199 -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 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.
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
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 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.
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.
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:
_dmarc.azure365pro.in TXT v=DMARC1; p=reject; rua=mailto:dmarc@localhost;ruf=mailto:dmarc@localhost
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.
Once the record is published you can see.
What is (Brand Indicator Message Identification (BIMI) record and let see how to implement them efficiently.
Please note : BIMI is not matured and most of the providers stopped utilizing it. Lack of documentation and it will become useless soon in my perspective.
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 = 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:188.8.131.52 ip4:184.108.40.206 ip4:220.127.116.11 ip4:18.104.22.168 -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:22.214.171.124 ip4:126.96.36.199 ip4:188.8.131.52 ip4:184.108.40.206 -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:firstname.lastname@example.org; ruf=mailto:email@example.com