Email security is the utmost requirement of all organizations to protect confidential data from scammers and cyber criminals. Scammers always seem to find a way to trick end user to get hold of organizational confidential data that is available in the form of emails. Leveraging email systems to improve business productivity and communication puts you in a consistent war against spam, spoofing and phishing.

Being a messaging administrator, you need to plan for security of your messaging systems to secure email data. Apart from antivirus tools being installed on the server, following techniques can be leveraged to secure email messages.

  • Sender Policy Framework (SPF)
  • DomainKey Identified Mail (DKIM)
  • Domain-based Messaging Authentication, Reporting and Conformance (DMARC)

Sender Policy Framework (SPF)

Sender Policy Framework (SPF) allow you to identify which email servers are authorized to send emails for organizational SMTP domain. SPF is added as a TXT record and help prevent spoofing. A spoofed email message is modified to appear as if it originates from a sender other than the actual sender of the message. When a user sends an email, the sending server issues a command in the SMTP message header “From” and include the information of sending server.

Understanding SPF, DKIM and DMARC for Secure Messaging

Recipient messaging system refers to SPF TXT record to determine whether a message from your domain is being received from authorized server that are being advertised in your DNS.

If you do not configure authorized servers for your organization that can send emails then the receiving email server can choose to reject the message as SPAM. The reason why the receiving server can reject your message as SPAM is because they cannot validate that the message comes from an authorized messaging server.

SPF record types were deprecated by the Internet Engineering Task Force (IETF) in 2014. Now weo leverage TXT records in DNS to publish SPF information

Configuring SPF in Office 365

If you are planning to leverage Office 365 emails then you need to add the following public DNS TXT record for sender policy framework.

Record Type = TXT

TTL = 3600

Target = v=spf1 -all

If you are using on premises Exchange server to send emails outside of your organizations then you need the following information for sender policy framework TXT record.

  • IP address
  • Domain Name
  • Enforcement Rule Information

Below is the format of SPF TXT record. SPF TXT record starts with v=SPF1

v=spf1 [<ip4>|<ip6>:<IP addresses>] [Include: <Domain Name>] <enforcement rule>

Let’s assume the public IP address of our exchange 2016 server is and the SMTP domain is then the SPF TXT record will be as below.

v=spf1 ip4: -All

More information on how SPF prevent against spoofing can be found on TechNet.

SPF does not work when you have email forwarding setup on user mailbox. It’s recommended to use SPF in conjunction with other email authentication methods DKIM and DMARC

DomainKey Identified Mail (DKIM)

DomainKeys Identified Mail (DKIM) lets an organization take responsibility of an email message that is in transit and help validate domain identity. DKIM is a more advanced version of Sender Policy Framework (SPF) that helps validate that an email message came from the domain it appears to come from by leveraging cyrptographic authentication. DKIM adds a digital signature to email messages in the message header and authorize your domain to associate or sign its name to an email message. Email systems that receive email from your domain can use digital signature to help determine if incoming email that they receive from your domain is legitimate.

DKIM itself does not directly prevent, filter or identify any spam. It’s recommended to user DKIM in conjunction with SPF to have much better validation of email message

Configuring DKIM in Office 365

Follow the steps mentioned below to configure DKIM in Office 365.

Get-DKIMSigningConfig <Domain Name> | FL *CNAME

Understanding SPF, DKIM and DMARC for Secure Messaging

The output of the cmdlet contains the DKIMsigning configuration for CNAME records.

Add the 2 CNAME records in your DNS registrar. Below is the format of CNAME Records

Record Type = CNAME

Hostname = Selector1._domainkey.<Domain Name>

TTL = 3600

Target = Selector1-<Domain Name>._domainkey.<Tenant Name>

Record Type = CNAME

Hostname = Selector2._DomainKey.<Domain Name>

TTL = 3600

Target = Selector2-<Domain Name>._DomainKey.<Tenant Name>

Once the records have been added to public DNS, run the following cmdlet to enable DKIM in Office 365

New-DkimSigningConfig –DomainName <Domain Name> –Enabled $true

More details on DKIM can be found on TechNet.

Domain-based Message Authentication, Reporting & Conformance (DMARC)

Domain-based Message Authentication, Reporting & Conformance (DMARC) is an email authentication protocol builds on the SPF and DKIM protocols that add reporting capabilities to allow sender and receiver to improve and monitor protection of the domain from fraudulent email. DMARC policies are published in DNS as TXT record and advertise what an email receiver should do with non-aligned email message received from sender organization.

By default, Office 365 tenant is enabled from DMARC and evaluating messages. DMARC look for the following information in email header


Authentication-results:; spf=pass / fail

(sender IP is x.x.x.x)

dkim=none/pass (message not signed OR signature was verified) header.d=SenderDomain;Recipient; dmarc=none / pass