Avanan: DMARC Module Setup Guide

Description

Enable and configure the Check Point Harmony Email and Collaboration DMARC module. This tool ensures your SPF and DKIM records are up-to-date and helps set up your DMARC TXT records for optimal email security. By using Check Point DMARC Management, you can enhance domain protection and improve message deliverability. (Follow setup please see the Check Point Harmony Email and Collaboration DMARC Management Admin Guide for detailed feature instructions.)

Enabling DMARC

Step 1: Enable the Check Point DMARC Management module

1. Enable the Check Point DMARC Management Module

Step 2: Define an RUA Mailbox Designation

The RUA mailbox (Reporting URI for Aggregate reports) email collects DMARC aggregate reports, aiding in monitoring and verifying email authentication practices.  There are two deployment options:

1. Option A:
   1. Set up a self-hosted mailbox within your Microsoft or Google Workspace environment.
   2. NOTE: This may throttle and lose important data
2. Option B:
   1. Use the assigned RUA mailbox provided by Check Point.

Option A Configuration:

1. Create a shared mailbox via the O365 admin portal/Google Workspace admin center.
   1. You can call the mailbox whatever you would like.  Keep in mind your RUA mailbox is publicly available.
   2. Guides below:
      1. Create a shared mailbox - Microsoft 365 admin | Microsoft Learn
      2. Make a group a Collaborative Inbox - Google Workspace Learning Center
   3. Note: If a self-hosted RUA mailbox already exists, you do not need to create a new or unique mailbox for Check Point

Option B Configuration:

1. Use the assigned RUA mailbox provided by Check Point.
   1. Check Point will provide one via your Harmony Email and Collaboration portal.
      1. Example: {yourportalname}@us.cp-dmarc.com
   2. A DMARC popup will appear on first use with a DMARC  record TXT suggestion based on your existing DNS records.
   3. NOTE: This does not stop you using the Option A configuration instead

Step 3: Update DMARC TXT Record

1. Update your DMARC TXT record on your DNS Host server in your Zone manager settings to include your designated RUA mailbox for Check Point.
   1. This is done in your DNS Host provider environment (http://godaddy.com , namecheap,com, http://easydns.com , etc.)
   2. If you have an existing DMARC record, it may look like these examples:
      1. Scenario 1
         1. v=DMARC1; p=reject; fo=1; ri=3600; rua=mailto:rua@external.dmarcvendor.com; ruf=mailto:ruf@external.dmarcvendor.com
      2. Scenario 2
         1. v=DMARC1; p=reject; fo=1; ri=3600; rua=mailto:rua-dmarc@yourdomain.com; ruf=mailto:rufdmarc@yourdomain.com
   3. Scenario 3
      1. v=DMARC1; p=none; fo=1; ri=3600;
   4. Scenario 4
      1. No DNS TXT entry setup for _dmarc

Scenario 1

Starting configuration

v=DMARC1; p=reject; fo=1; ri=3600; rua=mailto:rua@external.dmarcvendor.com; ruf=mailto:ruf@external.dmarcvendor.com

Updated Configuration

v=DMARC1; p=reject; fo=1; ri=3600;

rua=mailto:rua@external.dmarcvendor.com,mailto:yourportalname@us.cp-dmarc.com;

ruf=mailto:ruf@external.dmarcvendor.com

Scenario 2

Starting configuration

v=DMARC1; p=reject; fo=1; ri=3600; rua=mailto:rua@external.dmarcvendor.com; ruf=mailto:ruf@external.dmarcvendor.com

NO UPDATE REQUIRED!

Scenarios 3 & 4

Scenario 3

v=DMARC1; p=none; fo=1; ri=3600;

Scenario 4

No DNS TXT entry setup for _dmarc

In the DNS Host server, add a new record:

Type: TXT

Name: _dmarc

Value: v=DMARC1; p=none; rua=mailto:yourportalname@us.cp-dmarc.com

Step 4: Review the Check Point Email Security DMARC Management Overview

Upon completing Sections 1 – 3 the DMARC Management addon will begin aggregating DMARC report data immediately after your RUA mailbox has been properly defined in the domain’s DMARC TXT record.

1. Log into your tenant and go to DMARC > Overview

DMARC Overview Dashboard:

1. Select your domains individually to view SPF, DKIM, DMARC authentication and failure rates, identify sending/source IP addresses, geographic locations, track DMARC Reporter trends, and more.

DMARC Recommendations Dashboard:

1. The DMARC > Recommendations feature will provide you with insights and suggestions to help you best optimize your domains for anti-impersonation security, brand safety, and wanted outbound deliverability success.

DNS Knowledge and DMARC Tags

DNS, or Domain Name System, is the backbone of internet communication, acting as a directory that translates human-readable domain names into machine-readable IP addresses, crucial for networking and accessing online resources. When you type a website address into your browser, DNS servers translate that domain name into an IP address that computers use to identify each other on the network.

Beyond website navigation, DNS plays a pivotal role in email delivery. Here’s how different DNS records are instrumental in managing and securing email communication:

MX (Mail Exchange) Records: Specify the mail servers responsible for receiving emails on behalf of a domain and their priority relative to each other. This ensures that emails are correctly routed to the intended recipient's mail server.

SPF (Sender Policy Framework) Records: Define which mail servers are authorized to send emails on behalf of your domain. This helps to prevent email spoofing by verifying sender IP addresses against the expected mail servers listed in the SPF record.

DKIM (DomainKeys Identified Mail) Records: Provide a way to validate that the content of the emails has not been tampered with during transit. It uses a cryptographic signature linked to the domain, enhancing the security and trustworthiness of the email.

DMARC (Domain-based Message Authentication, Reporting, and Conformance) Records:

Build on SPF and DKIM records to define a policy for handling emails that do not authenticate. It also provides mechanisms for reporting and feedback, helping domain owners monitor and protect their domain from unauthorized use.

DMARC Tags and Protocols

Using data from the Check Point DMARC Management dashboard, you will have reporting on what senders or passing and failing SPF and DKIM with use of your domain. Once you are completely sure that your domains are authenticating SPF and DKIM from all of your wanted sending sources, that is when you would modify your DMARC record to a strict p=reject policy.

Reject Strict Policy

v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s; pct=100; fo=1; rf=afrf; ri=86400; rua=mailto:yourportalname@us.cp-dmarc.com; ruf=mailto:dmarc-forensic@exampledomain.com

When you have a p=reject policy in your DMARC (Domain-based Message Authentication, Reporting, and Conformance) record, it specifies the strictest form of DMARC enforcement. This is what you should be aiming for. Anticipating that all of your wanted sending servers and methods have been tested and verified to pass both SPF and DKIM completely, this DMARC policy will encourage receiving email servers to reject fraudulent and unauthorized traffic claiming to come from your domain. The reason this is easier said than done, is that if you have many businesses and organization units that do not have SPF and DKIM correctly configured from their sending methods, this same DMARC p=reject policy will also deter any outbound emails from your organization that have not been correctly configured.

Quarantine Relaxed Policy

v=DMARC1; p=quarantine; sp=quarantine; adkim=r; aspf=r; pct=100; fo=1; rf=afrf; ri=86400; rua=mailto:yourportalname@us.cp-dmarc.com; ruf=mailto:dmarc-forensic@exampledomain.com

Here, p=quarantine indicates that the main domain's policy is to quarantine failing emails. The relaxed settings for adkim and aspf (r for relaxed) are more forgiving about how closely the DKIM and SPF alignments need to match. The ‘relaxed’ status can sometimes create a false sense of victory during deliverability testing. Within the Check Point DMARC Management module reports will indicated all of the pass, fail, soft-fail, etc statuses from originating sending sources to help elevate the use of the strict setting.

None Policy

v=DMARC1; p=none; sp=none; pct=100; fo=1; rf=afrf; ri=86400; rua=mailto:yourportalname@us.cp-dmarc.com ; ruf=mailto:dmarc-forensic@exampledomain.com

With p=none, no specific action is taken on emails failing DMARC. This policy ensures that there is no mail loss due to DMARC failures, which aligns with a beginning goal for a very permissive setup. Meanwhile, the RUA mailbox will still gather DMARC reporter data regarding SPF, DKIM, DMARC pass fail information regarding your domain’s usage as seen by receiving email servers. Unfortunately, p=none leaves your domains more vulnerable to Spoofing and Domain Impersonation attacks putting your employees and your customers at risk.

Starting with SPF

An SPF record is a TXT record that begins with v=spf1 which conveys from your Name Server to receiving email servers that receive emails from you domain which servers are allowed to send email on behalf of your domain.

SPF v=spf1 ip4:55.123.321.12 include:spf.protection.outlook.com include:_spf.google.com include:spf.somehost.com include:marketingplatform.com -all

Understanding DKIM

DKIM (DomainKeys Identified Mail) Records are intended to sign each message with an encrypted key acting as a validation of the email’s origin. If you use Microsoft 365 and/or Google Workspace that is first place to create a DKIM signature for your domain. Depending upon your business and organization needs you will likely also have CRM platforms such as Salesforce and Hubspot which team members use to send emails on behalf of your domain. You may have services such as AmazonSES, Mailgun, Sendgrid, etc that send emails integrated with websites and automated systems pertaining to sales process, shipping, tracking, and automated emails. You may have a self-hosted home grown SMTP relay service or other services that send emails on behalf of your domain. Define and identify any and all portions of your organizations use of such services and ask the question, “Are all email sending services defined in my SPF record and does that service provide and/or need a DKIM signing option?”

DKIM Records are defined by different platforms as both CNAME and TXT records. Both methods work similarly creating a key assigned and aligned from the sending server that authenticates your domains usage of that service with a DKIM signing action taking place from the sending server, and the receiving server will then check your Name Server for the presence of the associated DKIM Key that should match the signature of the email send by the authorized sending server.

In you DNS Zone manager your DKIM Keys will look something similar to:

selector._domainkey.yourdomain.com :

v=DKIM1;k=rsa;

p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAw5R6cnyaO5uutRbG8pErMBsGMyOzZzV0GwiOx7P83cYzo9oyvdrfLEVXMMmMo8iDJxAUCYQeo9OWAmMOVA5og7mc5YoSSK2BqmZ8raZaY6Q/WeD1JZvN2r8VftBT6klut/t9nAw5YWEsxQsFtPEx429eWZFzRV+Vb/lc2j5KxMs/SoAwGm5LxKw8z5e+LWFj6R;

Most DNS Host providers will automatically define / conjoin long TXT record strings. There is a 255-character limit for TXT Records, meanwhile many sending servers may suggestion DKIM keys that exceed 255 characters. This is current best practice for use of 2048 bit DKIM signing keys. Take note that if you DKIM records are not validating or passing during your tests, the problem may be that your DNSTXT Record is cutting off a portion of your DKIM TXT entry. Be aware that this can occur, if you run into this, depending on your DNS Name Server you will usually have an option to add a second TXT string field to the same record.

Just because a message is signed by a DKIM signature, does not mean with was signed by an authorized sending server. Also, be aware that with various routing rules, forwarding options, and complex sending infrastructure sometimes your DKIM signatures may be required to be configured directly on the Email Sending Server, and other times the Sending Server may be sending emails from their own third-party domain, and attributing your domain to the Email Message Envelope, but is signing using their own domain. Because this method is common amongst legitimate use cases, that is why DMARC is necessary, so your domain is not Spoofed or Impersonated by an illegitimate server.

Frequently Asked Questions (FAQs)

How do I lookup my DNS Records? Who else can lookup my DNS records?

DNS Records are public and can be looked up by any internet enabled device. There are multiple tools, platforms, and services that provide DNS query and lookup information. The following are popular free DNS query tools, but there are numerous options available: mxtoolbox.com , nslookup.io , hackertarget.com

Without any special software, from any Command or Terminal prompt you can lookup domain DNS information this way on Windows, macOS, or Linux.

• nslookup -type=ns domain.com
• nslookup -type=mx domain.com
• nslookup -type=txt domain.com
• nslookup -type=txt <selector>._domainkey.domain.com
• nslookup -type=txt _domain.com

For Linux and macOS you can also open a terminal prompt and use dig commands to fetch DNS information:

• dig domain.com NS
• dig domain.com MX
• dig domain.com TXT
• dig _domain.com TXT
• dig <selector>._domainkey.domain.com TXT

How do I find out my portal name?

1. Login to your Harmony Email and Collaboration dashboard via https://portal.checkpoint.com/
2. Right Click on Overview and Open link in new tab
3. In the new tab look at the URL bar for: https://yourportalname.checkpointcloudsec.com/

What is SPF Hosting / Flattening, and do I need it?

Your organization may benefit from an SPF Hosting Service, or it may not be necessary dependent upon the size and complexity of your organization as well as the number of sending servers you need to authorize to send mail on behalf of your organization domain’s.

SPF flattening is a technique used to manage SPF records that are at risk of exceeding the DNS lookup limit imposed by the SPF specification. SPF records define which mail servers are allowed to send email on behalf of your domain. However, the SPF specification limits the number of DNS lookups to 10. When your SPF record includes many different mechanisms that require DNS lookups, such as include, a, mx, or ptr, you might exceed this limit, which can lead to legitimate emails being marked as spam or not delivered at all.

Some SPF Host providers and Flattening solution use SPF macros, which act as placeholders in SPF records that expand to specific values based on the context of the email being sent, such as sender's IP, domain name, or local-part of the sender's address. They're used to create more dynamic SPF records that adapt to changing sending sources without manual updates.

v=spf1 +ip4:%{i} +ip6:%{i} +a:%{d4} +mx:%{d3} +ptr:%{d2} %{ir}.%{v}._spf.%{d} ~all

In this SPF record:

• %{i}: Insert the sender’s IP address.
• %{i} for IPv6 is implied if used without an explicit prefix.
• %{d4}: Insert the fourth level of the domain name (subdomains).
• %{d3}: Insert the third level of the domain name.
• %{d2}: Insert the second level of the domain name.
• %{ir}: Insert the reversed IP address of the sender.
• %{v}: Insert the literal string in-addr for IPv4 or ip6 for IPv6.
• %{d}: Insert the current domain.

SPF macros should be used judiciously and only as necessary to meet the specific needs of your email sending infrastructure.

Alternatives to SPF Flattening

Instead of SPF flattening, you could:

Consolidate Senders: Reduce the number of include statements by limiting the number of services allowed to send emails on behalf of your domain.

Dynamic SPF Services: Some services will dynamically update your SPF record to include the correct IP addresses without exceeding the lookup limit.

SPF Domain Trees: Let’s assume you have three different email domains that you want to use to send emails.

In this example we will use domainA.com , domainB.com , and domainC.com

domainA.com SPF record: "v=spf1 include:domainB.com -all"

This DNS record statement authorizes emails from domainB.com to be sent as if they are from domainA.com. However, including domainA.com in the SPF record of domainB.com isn't similarly straightforward. If done without careful management, it can result in a circular reference where each domain points to the other for authorization, potentially causing resolution issues and errors during SPF checks. Instead, each domain should manage its SPF record independently to clearly define its authorized sending sources without causing dependency or loop issues.

SPF inclusion is best configured with one directional authorization, so domainB.com should not include domainA.com in its SPF record.

Thus, the SPF Record of Domain B is:

domainB.com SPF record: "v=spf1 include:domainC.com -all"

This record indicates that domainC.com is authorized to send emails on behalf of domainB.com.

Email Sending Process:

When an email is sent from domainC.com claiming to be from domainA.com, the email verification process involves checking the SPF record of domainA.com. The verifier sees that domainA.com defers to domainB.com for authorization.

SPF Check at Domain B:

The verifier then checks domainB.com 's SPF record, which includes domainC.com . Since domainC.com is authorized by domainB.com , and domainB.com is authorized by domainA.com, the email will successfully passes the SPF check.

domainA.com trusts domainB.com

domainB.com trusts domainC.com

Therefore, indirectly, domainA.com trusts domainC.com through domainB.com . The use of domainC.com can be used to send emails on behalf of domainA.com, meanwhile domainA.com cannot send email on behalf of domainC.com

This method relies on each domain correctly and explicitly listing its authorized senders in its SPF records. If any link in this chain fails to properly authorize the next link, emails could be rejected or marked as spam. It's important to carefully manage these SPF records to avoid unintentional permission grants and to ensure email authenticity.

If and when such configurations are implemented it is important to maintain that the envelope information of the message corresponds to with the SPF settings.