Implementing DMARC for Your Organization

DMARC (Domain-based Message Authentication, Reporting, and Conformance) is an email authentication protocol that builds on DKIM and SPF, and is designed to protect email domain owners from unauthorized use, such as email spoofing. It works by allowing domain owners to publish policies in their DNS records that specify how to handle emails that fail those SPF and DKIM authentication checks.

Key Components of DMARC:

1. Authentication: DMARC builds on two existing email authentication mechanisms, SPF and DKIM. It ensures that emails are properly authenticated using these methods.
2. Alignment: DMARC checks that the domain in the "From" header field (RFC5322.From) aligns with the domains used in SPF and DKIM authentication.
3. Policy: Domain owners can specify policies for handling emails that fail authentication, such as rejecting, quarantining, or delivering them.
4. Reporting: DMARC provides a mechanism for receiving feedback about emails that pass or fail authentication checks, helping domain owners monitor and improve their email security.

Benefits of DMARC:

• Improves Email Deliverability: Helps legitimate emails reach recipients by reducing the chances of them being marked as spam.
• Provides Visibility: Offers detailed reports on email authentication results, allowing domain owners to track and address issues.
• Prevents Email Spoofing: Protects against phishing attacks and business email compromise by ensuring only authenticated emails are delivered.

NOTE: If you currently have DMARC set up or plan to in the future, you must ensure that you have already completed the process for Email Sending Domains to have your Click account Email Sending Domains configured in order to align with the DMARC you will set up. If the domains that you want to use do not validate as Waiting for Approval or Approved Status in that part of Click please open a ticket for guidance on next steps.

Why use DMARC?

DMARC has moved from being a Best Practice, a "nice-to-have" to really being a requirement for sending any significant quality of email messages to your subscribers.

Starting in February 2024, Google and Yahoo mandated that bulk email senders must have a DMARC policy in place. Emails that do not pass DMARC alignment are delayed or not delivered, ensuring stricter email authentication.

MailBox Providers (MBPs) have increased their focus on email validation to prevent spam and phishing attacks. This includes stricter enforcement of SPF and DKIM alignment with the "From" domain, making DMARC compliance essential for maintaining email deliverability.

Such changes have driven wider adoption of DMARC across the industry, making it a standard practice for email authentication.

Your Mailstreams, and your Stakeholders

It is very important to realise that DMARC affects all the mailstreams that use that domain, or its subdomains. This can include:

• Transactional Emails: These emails are triggered by user actions and include order confirmations, shipping notifications, password resets, and account updates
• Internal Communication: Emails sent within the organization, including company updates, policy changes, and team announcements.
• Customer Support and Service: Responses to customer inquiries, support tickets, and feedback.
• Legal and Compliance Emails: Communications related to legal notices, compliance updates, and regulatory information.
• Operational Emails: Notifications about non-IT system updates, maintenance schedules, and operational changes
• Event-Related Emails: Invitations, reminders, and follow-ups for webinars, conferences, and other events.
• Partner and Vendor Communications: Emails exchanged with business partners, suppliers, and vendors.
• Security and IT Notifications: Alerts and updates related to security incidents, IT maintenance, and system performance.

A mailstream refers to the flow of email messages sent and received by an organization. It encompasses all the different types of emails that are part of the organization's communication strategy. They are often split by the platform they are sent from, for example if you are a business all your 1:1 email sent to and from individuals might well be hosted by Microsoft Office365, or possibly Google Workspaces.

You are probably using Microsoft Dynamics CRM, and so Click for some of these, but certainly not all of them. So any use, or change to DMARC will involve probably your entire organisation, and may very well be a bigger project than just for example, the Marketing team.

At a minimum you'll need to identify all of your sending domains that you send your email messages from in all of your systems, and platforms, e.g. Office365, Google Workspaces, Ticketing systems, Event and Web Conference platforms, etc.

Check if you have DMARC set up on those sending domains that you listed. Ask yourself and your various people and teams (IT team, Change Management, CIO/CTO etc.) some questions.

1. What are the DMARC policies you’ve already enacted, if any?
2. What mailstreams do you know about and are they all authenticated correctly with SPF and DKIM?
3. Do you already monitor DMARC using a third-party tool like Dmarcian, EasyDMARC, Valimail, or others?
4. Do you specifically monitor the DMARC Aggregate Reports, and do they identify any mailstreams that you or your CIO/CTO don't know about?
5. Are the volumes you send on your domains across all mailstreams enough to be considered a bulk sender? You already use Click and Microsoft Dynamics CRM, so the answer is going to be, "Yes".

Setting up DMARC is a big task, but the rewards and payoffs are clear and tangible, and Click strongly recommends using DMARC for all your domains you use to send email. Much of the work will need to be shared throughout your entire technology and information services. You and your organizations' stakeholders will implement and monitor DMARC.

Click's Email Deliverability team can always offer some general information and best practices, and you can open a Support ticket with Click Support if you have questions.

Does Click support DMARC strict adkim or strict aspf?

Click implements the SPF and DKIM that DMARC relies on using a subdomain for virtually all the DNS records. The subdomain is used for MX, SPF TXT-type, and DKIM TXT-type DNS records and is completely essential. This means we do not support strict adkim or strict aspf.

The author or organizational domain will need the applicable DMARC default adkim value of relaxed either by using the adkim=r; tag or removing the adkim tag altogether. It will also need the DMARC default aspf value of relaxed either by using the aspf=r; tag or removing the aspf tag altogether. This is absolutely required to support authentication on a subdomain as described previously.

How does DMARC work?

A DMARC record is created for an email sending domain. It’s a TXT DNS record which can be configured in many ways to determine how relaxed/strict it should be, how subdomains should behave, where reporting should go, and most importantly what type of policy you want to want your subscriber's MailBox Provider (MBP) to follow when email is not authenticated.

There are 3 policies that a DMARC record can have for any one domain.

1. None: Instructs the receiver not to do anything in particular with the email if it fails DMARC but allows them to view reporting for all emails sent with their domain.
2. Quarantine: Instructs the receiver to deliver the email to the spam/junk folder if DMARC fails.
3. Reject: Instructs the receiver to reject or bounce the email back if it fails DMARC.

Using a policy of Quarantine or Reject is considered enforcement of your DMARC, and is a step you should eventually take, but only after thorough vetting and verification with your stakeholders including your CIO/CTO.

An email server/ISP/spam filter will not base their decision solely on DMARC. Emails will still be put through the normal anti-spam checks and algorithms, even if DMARC passes. MBPs/email servers/filters are not required to honor the DMARC policy, but most will.

What is required for DMARC to pass?

For an email message to pass a DMARC test, it must meet the following requirements:

SPF:

• SPF: The email must pass SPF authentication, meaning the IP address sending the email is authorized to send on behalf of the domain in the "From" header.
• Alignment: The domain in the SPF record for the return path (or Return-Path) domain must match (or be a subdomain of) the domain in the "From" header that is visible to the subscriber.

DKIM:

• DKIM: The email must pass DKIM authentication, meaning the email's DKIM signature is valid and has not been tampered with.
• Alignment: The domain in the domain in the DKIM signature must match (or be a subdomain of) the "From" header.

DMARC Policy:

• The email must align with the DMARC policy published in the DNS records of the domain in the "From" header. This policy specifies how to handle emails that fail SPF or DKIM checks (e.g., reject, quarantine, or none).