In our previous Exchange Security blog, we discussed the importance of not just having an SPF DNS record to verify legitimate email sources, but also having DKIM and DMARC records. We won’t delve into the technical details, as others have covered those aspects. Instead, we’ll focus on safeguarding your organization’s reputation, and how that relates to securing a robust Layered Security Strategy.
So, let’s dig into this a little deeper…
Download Our Layered Security Strategy Whitepaper
Exchange Security – Understanding SPF, DNS, DKIM, & DMARC Records
First of all, what do these records actually do, and where do they get their information from?
SPF Record
The recipient’s server scrutinizes the sender’s address in the email header and consults DNS to identify a match. The DNS record specifies approved IPs that are allowed to send emails on behalf of the domain and provides instructions on how to handle failures. Additionally, SPF can encompass FQDNs, which are then resolved to IPs.
DKIM
The recipient’s server examines the “from” address in the email header. The sender’s server signs the message using the private key of a certificate. Subsequently, the recipient verifies the message’s integrity by checking DNS for the corresponding public key.
DMARC
This assesses the reasons for SPF, DKIM, or both failing in the authentication process. The DMARC DNS record outlines the appropriate actions to take for messages that fail authentication and defines the reporting mechanisms for these failures.
Failure to implement or configure these emails properly can result in your email being marked as spam! If you regularly have issues with your email going straight to your recipients’ spam folders, then your configuration likely needs some review.
Enhancing Email Security With SPF, DKIM, And DMARC
Most hosted email providers offer the option to include DKIM information in your message headers and guide you on creating the necessary DNS record. However, on-premises Exchange lacks this functionality. Fortunately, we’ve worked with an open-source application that easily enables DKIM for Exchange. You can find more about it here, and we can help with configuration and updating your DNS.
When it comes to the DMARC record, it allows you to instruct spam filters on how to handle SPF and/or DKIM failures. For instance, if you haven’t configured DKIM but your email provider adds DKIM to your messages, this discrepancy might lead to undelivered messages. In the DMARC record, you can specify that messages failing SPF are considered spam, and you can choose to ignore cases where DKIM is not in alignment. Additionally, you can request the spam filter to notify you of these failures. This feature proves invaluable in identifying potential attempts to spoof your email domain.
These messages are in XML format, so it’s best to use a third-party tool to organize the data into a more readable format. The beauty of DMARC lies in its ability to alert you when emails attempt to impersonate your domain or are sent from domains closely resembling yours (ex. “compamy.com” with a typo). This alert can help you take corrective actions before any potential harm is caused, especially in cases where scammers may request clients to send sensitive information like bank records.
In a previous post, I suggested that if you own additional domains that don’t typically send emails, you can create SPF and DMARC records clearly stating that these domains do not send emails. Here are some examples for your reference.
Notice the DMARC record is _dmarc.
SPF record: v=spf1 -all
_dmarc record: v=DMARC1;p=reject;sp=reject;adkim=s;aspf=s
You can verify your records by querying DNS:
Resolve-DnsName company.com -Type txt ( the SPF record begins with “v-spf1” )
Resolve-DnsName _dmarc.company.com -Type txt
Setting up SPF, DKIM, and DMARC records is generally manageable, but in some instances, it can become very complex. Since our emphasis is on security rather than the technicalities of DNS, I suggest reaching out to us to ensure proper configuration. If you’re looking to learn more about these authentication methods, a good starting point is this resource: Microsoft Exchange Team Blog – Authenticate Outbound Email. It provides valuable insights into improving email deliverability through authentication.
Optimizing Exchange And Firewall Settings For Modern Connectivity
Now, let’s get into Exchange and firewalls.
In the past, it was typical to allow http (TCP80), https (TCP443), and SMTP (TCP25), and other ports as necessary to enable broad connectivity to Exchange. However, in today’s scenario where nearly everything defaults to https, it’s advisable to no longer allow http. If you’ve migrated your mailboxes to Microsoft 365 and are running Exchange in Hybrid mode, it’s a great opportunity to limit Exchange access to only Microsoft 365 IP addresses. This enhances security and aligns with the current trends in connectivity.
Fortinet, and similar systems, typically have a ready-made setup for Microsoft 365, making this step pretty straightforward. However, if you’re running in Hybrid mode and have SSL inspection turned on, be cautious with SMTP. Microsoft might detect it as a man-in-the-middle setup and terminate the connection, as it’s not a supported configuration for Microsoft 365. For now, it’s safe to keep SSL inspection for https traffic enabled if you prefer.
Conclusion
In closing, understanding and implementing robust email security measures are fundamental to preserving your organization’s credibility and ensuring safe communication channels. The interplay of SPF, DKIM, and DMARC records is pivotal in fortifying against malicious attempts like spoofing and phishing. While the technicalities can be intricate, the emphasis remains on proactive security rather than grappling with the nuances of DNS configurations.
Mirazon’s aim is to guide you in navigating this landscape and securing your email ecosystem effectively. For a deeper understanding or assistance in setting up these essential security protocols, we’re here to help. Let’s collectively fortify your organization against evolving threats, allowing for secure and seamless digital communication.
In our next Exchange Security blog, we’ll delve into both Exchange on-premises and Microsoft 365 Exchange, exploring more areas in detail. Stay tuned!