Email sending – Securing your identity

Emails are one of the basics everyone needs and uses today, with many using either a service or hosting their own with their own domain. Emails have come a long way in attempts to reduce spam and verify that the sender is who they say they are. While there are other standards for sending emails they tend to apply to the content rather than protocol.

The 3 important DNS entries to remember to ensure that your email servers can be verified are DKIM, SPF and DMARC. These 3 together set the policy and help verify your server’s identity to aid the receiving server to determine if you are a legit sender or a malicious one. Although there are additional things you can use to filter emails this is out of the scope for this article including the use of an antivirus to scan incoming email and configuration. These 3 are applied on the DNS level.

DKIM
DKIM (DomainKeys Identified Mail) is a protocol that protects email content being sent to stop it from being altered. Its concept is similar to that of SSL whereby you have private and public keys however DKIM does not encrypt content. Similarly to SSH, although encryption is embedded into SSH the key system however is just a more secure way to login as a way to identify the user, while in email it identifies the server and ensures the server is the correct one should someone try to send random packets to the receiving sender pretending to be the sending server. Emails can use SSL to encrypt their content during transmission but that is a different matter. What DKIM does do is sign keys which the receiving server can then use to verify if the email received was really from the server it claims to be from. DKIM requires both DNS configuration and the server sending the email to be configured as well (this is where you gety our public key from).

SPF
SPF (Sender policy framework) defines which hosts are allowed to send email on behalf of a domain. There are many policies that can be applied here such as whether to cover subdomains or specific ones and you can define domains or IP addresses. If you dont have a static IP address you can create an alias and use it here as this accepts both domains and IPs.

DMARC
DMARC (Domain-based Message Authentication, Reporting, and Conformance) defines how to handle emails that do not comply with your domain’s email policies or emails that have run into errors such as the user not existing or anything that requires sending a response back to the sender. In DMARC you should define how to handle bad emails such as to quarantine, allow or reject, a contact’s email address to report this to and how strict should the policy be before an email should be considered bad for instance if failing spf should be considered bad and how many % of emails would this apply to. DMARC can be fined tuned to handle emails differently from subdomains too and has a few different fields that while might seem like they do can do the same thing add to the details in how to define a bad email and how to handle it.

HOWTO configure the options available:
DMARC: https://en.wikipedia.org/wiki/DMARC#DNS_record
SPF: https://dmarcian.com/spf-syntax-table/
DKIM: refer to your email server software on how to set this up, then paste the public key in the TXT of your DNS similar to SPF.
Full guide: https://www.digicert.com/content/dam/digicert/pdfs/guide/how-to-setup-dmarc-guide-en.pdf

Being able to verify your server’s identity is very important to ensure others cannot pretend to be you and to help reduce the likelyhood you are considered spam.