Securing your Email Infrastructure and your Brand

With the advent of Cloud-based email solutions (Google Suite, O365 etc.) and stringent mail filtering and Protection, this note describes DKIM, SPF, and DMARC DNS records that help administrators in guaranteeing that the emails that are relayed from Mail servers or Relay servers are delivered to the recipients.

There are also scenarios where Organization Signs-up for marketing mailers like Mail Chimp and other Cloud-based solutions to send Marketing and other forms of communication to customer email addresses.

Certain Good Practices

• If using an On-Premise email solution, always ensure that the IP used for Relaying emails if dedicated only to the email servers. For example, we had a customer report a problem wherein their Domain/ Public IP was always blacklisted. It was later found that they shared this with the other server for Internet access which was causing the Risk to the IP reputation.
• If using a third Party marketing email solutions ensure that you either use a different domain or a subdomain than your corporate email domain. This will protect your IP/ domain reputation.
• If you are a Bulk email sender use Multiple IP addresses to relay your emails.
• Always ensure that you use an antivirus solution to scan all your outgoing emails.
• Use SPF, DKIM, DMARC to ensure that recipient email servers / Gateways or other filtering solutions are guaranteed senders authenticity.
• Use Transport level security between your email servers and the recipient's email servers.

Reverse DNS records

AntiSpam solutions sometimes depend upon Reverse DNS to compare the FQDN of the originating server against the IP address used to relay the emails.

Though generating NDR (nondelivery receipts ) for reverse DNS is not a part of the RFC, certain mail filtering appliances may block emails based upon reverse DNS. This method of mail filtering is being replaced by other technologies with the advent of Cloud email solutions where Mail from < recipient@domain.com > might be different from the SMTP relay Host FQDN names.

Sender Policy Framework (SPF)

SPF allows the DNS administrator to publish a DNS TXT record on their Public DNS zones specifying the IP address, IP address Block or Host/ FQDN of servers that are authorized to send emails on behalf of the domain. The recipient Antispam agent will validate the SPF record against the server that relayed the email. In case SPF hard fail is configured the recipient Antispam Solution could drop the email or give it a High Score for Spam confidence level thereby delivering it to the recipients' Junk folder List. 

The -all at the end of the example SPF defines it as a Hard fail, which means that the SPAM filter should discard the email. If it is replaced with a ~all it means a soft fail, which causes the mail filtering appliance to accept the email but tag it as a SPAM or suspicious before delivering it to the recipients' mailbox.

Example SPF for Microsoft.com

v=spf1 include:_spf-a.microsoft.com include:_spf-b.microsoft.com include:_spf-c.microsoft.com include:_spf-ssg-a.microsoft.com include:spf-a.hotmail.com ip4:147.243.128.24 ip4:147.243.128.26 ip4:147.243.1.153 ip4:147.243.1.47 ip4:147.243.1.48 -all

Domain Key Identified email (DKIM)

DKIM is used to prevent spoofing, SPAM’s by affixing the email message with a digital signature. The SPAM filter infrastructure compares this against the Public Key (DKIM record) published on the Sender domains DNS to validate the authenticity of the email.

Example DKIM Record on the Public DNS and the domain Key information in Message Headers

v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCkHq3ztGIm1R8alD+7oZiaG5mTUttFdFOlpKHRBZCPFG4sugV1EfF5F6JpwbJDzZmyIlqYfTgUkmYOvbHsoYvW7rddLKVTh+vE1SZ5P9coIHrw759hXbpPDSQ9JNP8aN+Bfrg6YMEWnOGA+PL+ZpyvswcB0jz9M6yMvowOxCHv5QIDAQAB; n=1024,1435867504,1
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com,
s=selector1;
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
bh=9AI7to4IxPPpelCbo/ZYz3x7EorWs4gaG91e09iQQYA=;
b=ijvlm+1+YDVBwufOuqZIixmdyDax01oUNwNnS1BXd5lNviGclzpbycKJnGxFetdj1b4Y6ma8cjUf6nIoWfNmvCNQELGiEPJL9Rr+gVkYxiJajJYhf0OKhE9zdQP/HgT4tL33rfWUc0OSi9uzlik/Ey+SloC8uebog7+e+Og2QPw=

DMARC

Domain message authentication, reporting, and conformance rely on DKIM and or SPF records. The DMARC policy is published by the domain owner. DMARC Alignment could be classified into Strict and Relaxed. For Strict Alignment, the domain in FROM: must be identical with the Published record. For relaxed it should match the Organizations TLD.

 Example – For strict alignment FROM: testdomain.com should match and should pass the DKIM/SPF for the domain. For Relaxed it could be FROM: subdomain.testdomain.com

Example DMARC for Microsoft.com

v=DMARC1; p=reject; pct=100; rua=mailto:d@rua.agari.com; ruf=mailto:d@ruf.agari.com; fo=1

The rua and ruf are URLs for sending the aggregate reports / forensic reports. “p” is the policy that defines that the emails should be rejected and “pct” is the percentage of times the policy should be applied in case of DMARC check failures.

I hope this is useful for Mail server administrators and security assessors/ auditors.