What is DMARC
DMARC, which stands for Domain-based Message Authentication, Reporting, and Conformance, is a crucial email authentication and anti-phishing technology designed to enhance the security of email communication. It helps organizations combat email fraud, phishing attacks, and unauthorized use of their domain names by allowing domain owners to specify policies for how their email should be authenticated and handled by recipient email servers.
To Jump directly to google requirements click here: updatelink
So how did we go about this in the past ? IS DMARC a replacement ?
No – DMARC doesn’t exactly replace any existing technologies but rather enhances and builds upon them. It works in conjunction with two existing email authentication mechanisms: SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail). Let’s briefly explore how DMARC interacts with these technologies:
- SPF (Sender Policy Framework): SPF is a mechanism that allows domain owners to specify which mail servers are authorized to send emails on behalf of their domain. It helps prevent email spoofing by verifying that the sending server’s IP address is included in the domain’s SPF record. However, SPF alone has limitations when it comes to identifying forged “From” addresses, as it only validates the envelope sender (Return-Path).
- DKIM (DomainKeys Identified Mail): DKIM involves digitally signing outbound emails with cryptographic keys. The receiving server can then verify the signature against the sender’s public key published in the DNS records. This process confirms that the email’s content hasn’t been tampered with during transit and that it originated from the domain it claims to be from.
DMARC builds on these mechanisms and provides a policy framework for domain owners to control how their emails are authenticated and handled. It complements SPF and DKIM by addressing some of their limitations:
- SPF Limitation: SPF is only concerned with the envelope sender’s IP address, which might not match the “From” address that recipients see. DMARC enables the alignment of the visible “From” domain with the domain authorized by SPF, enhancing the alignment and consistency of these domains.
- DKIM Limitation: While DKIM verifies the integrity of email content, it doesn’t necessarily guarantee that the email wasn’t sent from a malicious source. DMARC uses DKIM authentication as one of its components, combining it with other checks to ensure that both the content and sender are legitimate.
In essence, DMARC doesn’t replace SPF or DKIM but provides an overarching policy framework that allows domain owners to dictate how receiving email servers should handle messages that pass or fail SPF and DKIM checks. It consolidates and coordinates the authentication information from both mechanisms and adds an extra layer of control, reporting, and policy enforcement to combat email phishing, spoofing, and abuse.
With DMARC policy handling defaults in place, legitimate email senders can maintain and enhance their domain reputation. This is crucial in ensuring their emails reach the intended recipients’ inboxes, building trust and credibility among users.
For todays organizations its crucial to ensure that its domains are not used to attack and damage other organizations.
Features of DMARC
- Authentication Mechanisms (SPF, DKIM): DMARC builds upon two existing email authentication mechanisms – Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM). These mechanisms enable senders to prove the authenticity of their emails by aligning the sender’s domain with the sending server’s IP address (SPF) or by digitally signing the email content (DKIM).
- Policy Specification: Organizations set up DMARC policies in their DNS (Domain Name System) records. These policies dictate how receiving email servers should handle emails that claim to be from their domain but fail authentication checks. Policies can be set to “none” (reporting only), “quarantine” (place suspicious emails in recipient’s spam folder), or “reject” (block unauthenticated emails).
- Alignment and Identifier Alignment: DMARC introduces two alignment concepts: SPF alignment and DKIM alignment. SPF alignment checks if the domain in the email’s “From” header matches the domain authorized to send emails according to SPF records. DKIM alignment verifies if the email’s DKIM signature matches the sender’s domain.
- Reporting Mechanism: One of the key advantages of DMARC is its reporting mechanism. Organizations receive feedback from recipient email servers about the authentication status of their emails. These reports provide insights into the volume of incoming email traffic, authentication failures, and potential abuse of their domain for phishing attempts.
- Gradual Implementation: Organizations can implement DMARC in a phased manner. The “none” policy helps organizations gather information about the email sources that are sending on their behalf. This information aids in setting up SPF and DKIM records correctly. Once these records are properly configured, organizations can move towards enforcing stricter policies like “quarantine” and eventually “reject.”
- Email Forwarding and Third-Party Senders: DMARC implementation can be complex for organizations that use third-party services or email forwarding. These scenarios might require careful consideration and configuration adjustments to ensure that legitimate emails aren’t blocked. – Here it could be very usefull to utilize one of the many DMARC platforms out there to assist you in this task – more on that later, but some of them are Valimail, RedSift, Dmarcian and Centera security.
- Monitoring and Fine-Tuning: DMARC implementation involves ongoing monitoring of authentication reports. This allows organizations to fine-tune their authentication mechanisms and policies based on the feedback received from recipient servers.
In conclusion, DMARC is an essential tool for bolstering email security by ensuring that only legitimate emails from authorized sources are delivered to recipients. By leveraging authentication mechanisms, specifying policies, and analyzing authentication reports, organizations can significantly reduce the risk of email-based phishing attacks and domain spoofing, ultimately enhancing their email communication’s trustworthiness.
Because subdomains contend with the same abuse potential as parent domains, there are specific conditions for subdomain policies. They are as follows: subdomains inherit the parent domain’s DMARC policy unless you indicate a subdomain policy using the sp= tag in the parent DMARC record or publish a p= tag on a subdomain.
Meaning unless specified all subdomains are covered by policy (p=) in parent
Publishing Different Policies for Parent Domain and Subdomains
To publish a subdomain policy on the parent domain, create a DMARC record that includes an sp= tag to specify a DMARC policy for subdomains of the relative parent domain. Here’s a DMARC record published for example.com that covers the parent domain at p=quarantine and its subdomains at p=reject:
v=DMARC1; p=quarantine; sp=reject; rua=mailto:firstname.lastname@example.org
For many organizations using a DMARC management platform can greatly simplify and enhance the process of implementing and maintaining DMARC for your domains. These platforms offer a range of features that make DMARC management more efficient and effective:
- Centralized Dashboard: Management platforms provide a single interface to manage DMARC records, policies, and authentication mechanisms. This simplifies the process and reduces the complexity of working directly with DNS records.
- Automation: Many platforms offer automated setup and configuration of DMARC records, SPF records, and DKIM keys. This minimizes the risk of manual errors and ensures proper alignment.
- Reporting and Analytics: Management platforms provide comprehensive reports and analytics on email authentication results, allowing you to quickly identify sources of legitimate and suspicious email traffic.
- Alerts and Notifications: Platforms can send alerts and notifications when authentication issues are detected or when changes to email traffic patterns occur.
- Policy Management: You can easily adjust and fine-tune your DMARC policy through the platform’s user-friendly interface, without the need to manually modify DNS records.
- Third-Party Integration: Many platforms integrate with popular email providers and services, allowing you to manage DMARC policies for your domain and third-party services simultaneously.
- Phishing Protection: Some platforms offer advanced features to identify and mitigate phishing attempts based on DMARC data, providing an added layer of security.
- Education and Support: DMARC management platforms often provide educational resources, guides, and support to help you understand and navigate the complexities of DMARC implementation.
- Third-Party Sending: If your organization uses third-party services to send emails, a management platform can help streamline the alignment and authentication process for these services.
- Time and Resource Savings: Implementing and maintaining DMARC manually can be time-consuming and require expertise. A management platform can save you valuable time and reduce the burden on your IT staff.
In summary, using a DMARC management platform can be highly beneficial, especially if you have limited experience with DNS configuration, email authentication, or if you manage multiple domains. It can help ensure a smooth and effective DMARC implementation, enhance your email security, and provide valuable insights into your email traffic.
This screen shot shows an example doamin in the Valimail platform, where we can see alot of data based on the aggregated RUF reports
|Set the percentage of failed emails that the set policy should apply to. The value should be a number between 1 and 100.
|Set a specific policy for emails sent from subdomains. For example, you could choose to ignore failed emails sent from the main domain (p=none) but quarantine those sent from subdomains.
|You can choose here the aforementioned approach for how strict DMARC should be when comparing the sender’s domain against DKIM’s “d” tag. As mentioned earlier, “strict” and “relaxed” are the possible options. By default, the approach is “relaxed”.
|The same choice as the one above, just for SPF alignment. You decide whether SPF should aim for a perfect match of “envelope from” domain and “return-path” address or if subdomains of “envelope from” domain should also be allowed. Also, you can choose to be “strict” or “relaxed”.
|Sets the intervals for how often you want to receive aggregate reports with authentication results (“rua” tag). The value is expressed in seconds and, by default, is 86400 (every 24 hours).
|Settings for the forensics reports (“ruf” tag). You can choose to send the report if: “0” – all underlying checks fail to return a positive DMARC result; “1” – any mechanism fails; “d” – DKIM failed to verify; “s” – SPF failed to verify. By default, it’s “0”.
Update – Office 365
“We’ve already begun rolling out the new policies, starting July 19, 2023, we’re will continue to rollout them out to our government and 21Vianet clouds. As stated in Message Center posts MC640228 (worldwide and government clouds) and MC640225 (21Vianet), you have until mid-August to modify the policies before they’re enforced.”
Meaning – respecting tje reject setting will be enforced by Mid August for all tenants.
So what to do ?
Well – if you wnat best pratice – do nothing Microsoft got you – if you want to stays as is, you will need to adjust the settings in Defender for Office.
Note the default settings are as seen here:
By creating a new policy it will be possible to set specific settings and scope them to single users, groups or everybody – or even specific domains.
A note on “Spoof intelligence”
The relationship between spoof intelligence and whether sender DMARC policies are honored is described in the following table:
|Honor DMARC policy On
|Honor DMARC policy Off
|Spoof intelligence On
|Separate actions for implicit and explicit email authentication failures:Implicit failures use the If the message is detected as spoof by spoof intelligence action the anti-phishing policy.Explicit failures for
p=reject DMARC policies use the If the message is detected as spoof and DMARC policy is set as p=quarantine and If the message is detected as spoof and DMARC policy is set as p=reject actions in the anti-phishing policy.
|The If the message is detected as spoof by spoof intelligence action in the anti-phishing policy is used for both implicit and explicit email authentication failures. In other words, explicit email authentication failures ignore
p=reject in the DMARC policy.
|Spoof intelligence Off
|Implicit email authentication checks aren’t used. Explicit email authentication failures for
p=reject DMARC policies use the If the message is detected as spoof and DMARC policy is set as p=quarantine and If the message is detected as spoof and DMARC policy is set as p=reject actions in anti-phishing policies.
|Implicit email authentication checks aren’t used. Explicit email authentication failures for
p=quarantine DMARC policies are quarantined, and failures for
p=reject DMARC policies are quarantined.
In the consumer version like outlook.com and Live Microsoft will simply respect the policyes without giving the flexibility that it offers to enterprise customers.
Parked Domains + MOERA domain
Parked domains, which are domains registered but not actively used for a website or email, can still benefit from implementing best practices to protect their reputation and minimize potential abuse. While parked domains might not have active content, they can still be exploited by cybercriminals for phishing, spam, or other malicious activities.
And for Office365 customers there is also the MOERA domain to think about (Microsoft Online Email Routing Address) this is your organisations xxx.onmicrosoft.com domain – this domains DNS records is always managed directly in the Admin part of the O365 portal
Activate DMARC for MOERA Domain
- Open the Microsoft 365 admin center at https://admin.microsoft.com.
- On the left-hand navigation, select Show All.
- Expand Settings and press Domains.
- Select your tenant domain (for example, contoso.onmicrosoft.com).
- On the page that loads, select DNS records.
- Select + Add record.
- A flyout will appear on the right. Ensure that the selected Type is TXT (Text).
_dmarcas TXT name.
- Add your specific DMARC value. For more information, see Form the DMARC TXT record for your domain.
- Press Save.
- Basic DMARC Record:
- v=DMARC1; p=none; rua=mailto:email@example.com
- In this example, the DMARC policy is set to “none,” which means that no action is taken based on authentication results. Reports will be sent to the specified email address for analysis.
- Quarantine Policy with SPF and DKIM Alignment:
- v=DMARC1; p=quarantine; sp=quarantine; adkim=s; aspf=s; rua=mailto:firstname.lastname@example.org
- Reject Policy with Reporting:
- v=DMARC1; p=reject; rua=mailto:email@example.com
- This DMARC policy is set to “reject,” which instructs receiving servers to reject emails that fail authentication checks. The specified email address will receive DMARC reports.
- Aggregate and Forensic Reporting:
- v=DMARC1; p=quarantine; rua=mailto:firstname.lastname@example.org; ruf=mailto:email@example.com
- This example includes both aggregate (rua) and forensic (ruf) reporting. Aggregate reports provide summarized information about authentication results, while forensic reports offer detailed data about individual email failures.
- Subdomain DMARC Record:
- v=DMARC1; p=none; rua=mailto:firstname.lastname@example.org; sp=none
- In this case, a DMARC record is set for a subdomain. The policy is set to “none,” and SPF alignment for the subdomain is also disabled (“sp=none”).
- Subdomain with Relaxed Alignment
- v=DMARC1; p=quarantine; adkim=r; aspf=r; rua=mailto:email@example.com
- This example demonstrates a subdomain with relaxed alignment for both SPF and DKIM. “adkim=r” and “aspf=r” indicate that alignment is required, but a relaxed mode is used.
I hope this article gives you some fundamental understanding of DMARC and how it should be used and implemented.
Have a great rest of your day
On Feb 1. 2024 – Google will as the first major player update and tighten the requirements for successful massmailing. This is taken from their info article:
Starting 1 February 2024, senders who send more than 5,000 messages per day to Gmail accounts must meet the requirements in this section.
- Set up SPF or DKIM email authentication for your domain.
- Ensure that sending domains or IPs have valid forward and reverse DNS records, also referred to as PTR records. Learn more
- Keep spam rates reported in Postmaster Tools below 0.3%. Learn more
- Format messages according to the Internet Message Format standard (RFC 5322).
- Don’t impersonate Gmail From: headers. Gmail will begin using a DMARC quarantine enforcement policy, and impersonating Gmail From: headers might impact your email delivery.
- If you regularly forward email, including using mailing lists or inbound gateways, add ARC headers to outgoing email. ARC headers indicate that the message was forwarded and identify you as the forwarder. Mailing list senders should also add a List-id: header, which specifies the mailing list, to outgoing messages.
- Set up DMARC email authentication for your sending domain. Your DMARC enforcement policy can be set to none. Learn more
- For direct mail, the domain in the sender’s From: header must be aligned with either the SPF domain or the DKIM domain. This is required to pass DMARC alignment.
- For subscribed messages, enable one-click unsubscribe with a clearly visible unsubscribe link in the message body. Learn more
If you send more than 5,000 emails per day before 1 February 2024, follow the guidelines in this article as soon as possible. Meeting the sender requirements before the deadline may improve your email delivery. If you don’t meet the requirements described in this article, your email might not be delivered as expected or might be marked as spam. To get help with email delivery issues, go to Troubleshooting.
To learn more about setting up SPF, DKIM and DMARC, visit Prevent