DMARC Overview

Domain-based Message Authentication, Reporting & Conformance (DMARC) is an email authentication protocol that helps protect your domain from email spoofing. Spammers often fake the "From" address to make it look like their emails are coming from your domain. By publishing a DMARC record, you inform other email services about how to handle unauthenticated emails, reducing the risk of phishing and email backscatter. This helps safeguard your domain's reputation and ensures better management of suspicious messages.

DMARC not only offers a method for email receivers to notify senders regarding emails that either pass or fail DMARC evaluation but also integrates a reporting function within its policy. NICeMail Admin Console offers a separate DMARC Reports section within the Admin Reports, where you can analyze the DMARC reports received via email. 

Before publishing DMARC

The DMARC policy builds on the widely deployed SPF and DKIM protocols to ensure email authenticity. It allows the sender to indicate that their emails are protected by SPF and/or DKIM, and instructs the receivers about the action, like quarantine or reject the message, if both the SPF and DKIM checks fail. 

An email using your domain's email address, which fails the SPF test and / or the DKIM test, will trigger the DMARC policy. So, you need to configure the SPF records and DKIM keys for your domains before you publish the DMARC policy.

The DMARC policy will be effective only if you send all the emails using your own domains. Emails sent on behalf of your domain via third party services will appear unauthenticated, and may be rejected based on the DMARC policy published. To authorize the emails via third party providers, you need to share the DKIM key to be included in the headers, or the emails should be sent via the SMTP servers, which already have the authorized DKIM Keys and SPF records published. 

DMARC records

DMARC records are DNS records that help prevent email spoofing and phishing attacks by providing a way for email senders to authenticate their emails. These records contain policies that instruct email servers on how to handle emails that claim to originate from a specific domain. DMARC records specify rules for email authentication methods such as SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail). A DMARC record consists of several key components, each playing a crucial role in ensuring the authenticity of email communications and specifying the action to be taken when an email fails authentication. The components are as follows:

Policy Action

The policy component of a DMARC record specifies the action to be taken when an email fails authentication. By defining policies such as Quarantine, Reject or None, domain owners can protect recipients from potentially harmful emails and bolster trust in their domain. We highly recommend rolling out DMARC policy in a phased manner. To roll out in a phased manner, you'll need to set the action to be taken when DMARC validation fails, or the 'p' parameter, from None to Quarantine, and finally to Reject. A detailed explanation of the action is as follows:

Phase 1: Monitor Reports and Traffic 

When you set the DMARC policy to "p=none," all emails will be delivered as usual, regardless of whether they pass or fail DMARC authentication. This phase is purely for monitoring purposes and does not enforce any actions on email delivery. You will receive reports of violations to the email address specified in the policy. Once you find the reports with only valid spoofed emails, you can change the policy to Quarantine. If you set the action to be taken when DMARC fails to none, the record would typically be generated as follows:

"v=DMARC1; p=none; rua=mailto:admin@yourdomain.com"

Phase 2: Quarantine Emails and Analyze

When you set the DMARC policy to "p=quarantine", all the emails that fails DMARC authentication will be sent to quarantine and sends you reports of the violation to the email address specified in the policy. You can monitor the emails in the Quarantine and approve or reject emails from the Quarantine. You can revisit your reports and also monitor the Quarantine emails. Once you are confident that only spoofed emails will be rejected and all valid emails are signed, you can change the policy to 'Reject' to completely roll out DMARC. If you set the action to be taken when DMARC fails to quarantine, the record would typically be generated as follows:

"v=DMARC1; p=quarantine; rua=mailto:admin@yourdomain.com"

Phase 3: Reject Spoofed emails

 When you set the DMARC policy to "p=reject", all the emails that fail DMARC authentication, will be rejected and will not be delivered to the recipient's inbox as usual. You can keep track of the rejected emails, via the reports you receive via email to the email address provided. If you set the action to be taken when DMARC fails to reject, the record would typically be generated as follows:

"v=DMARC1; p=reject; rua=mailto:admin@yourdomain.com"

Percentage Policy

The Policy percentage or 'pct' component in the DMARC record, specifies the percentage of emails to be affected by the policy in phase 2 or phase 3. When setting up DMARC, you can specify a percentage value between 0% and 100% as Policy percentage to determine the percentage of emails that should be subjected to the DMARC policy action (such as quarantine or reject) if they fail DMARC authentication. It is recommended to slowly increase the percentage from 0% to 100% for a gradual transition that minimizes the potential impact on legitimate email traffic. The important aspect is to ensure that you monitor the email reports regularly to ensure that valid emails do not get rejected or quarantined before full deployment of the DMARC policy. This policy percentage is specified within the DMARC record's pct tag. For example,

"v=DMARC1; p=quarantine; pct=20; rua=mailto:admin@yourdomain.com" 

In the above example, only 20% of the emails that appear spoofed will be quarantined, and the rest of the emails will still be delivered as usual, but will be included in the reports.  

DMARC Alignment

Dmarc Alignment ensures that the domains found in the SPF record and DKIM signature align with the domain found in the From header of the email. These alignments in the DMARC policy strengthen the integrity of email communications by verifying that emails originate from legitimate sources and have not been tampered with during transit. However, organizations might have varying email infrastructure setups, including complex email forwarding, subdomains, and third-party services. So, to provide flexibility and accommodate diverse email configurations and authentication practices across different organizations, users can choose between Strict and Relaxed modes of alignments. The choice between strict and relaxed alignment depends on the organization's security requirements and email authentication policies. 

SPF Alignment (aspf)

SPF alignment checks whether the domain indicated in the SPF record corresponds to the domain specified in the From address of the email header. 

• In Strict Alignment mode (s), if there are any mismatches, such as differences in subdomains or variations in the domain name between the From header domain and the SPF record domain, strict alignment mode will result in alignment failure.
• In relaxed alignment mode (r), as long as they share the same organizational domain, even if there are minor variations, such as slight differences in the domain name or subdomains between the From header domain and the SPF record domain, they will pass the SPF alignment.

In the above example, since both the domain found in the header From address and the envelope From address/Return Path address align, it indicates that the email has passed SPF authentication.

DKIM Alignment (adkim)

DKIM alignment checks whether the domain indicated in the DKIM signature matches the domain specified in the From address of the email header.

• In Strict Alignment mode (s), the 'd=' tag (domain) in the DKIM signature must precisely match the domain found in the From header of the email. Any differences, like in subdomains or variations in the domain name, lead to alignment failure.
• In Relaxed Alignment mode (r), as long as the organizational domain ('d=' tag) of the DKIM signature matches the organizational domain of the From header, even if subdomains differ, the email passes DKIM alignment.

In the above example, the successful alignment between the domain in the header From address and the 'd=' tag indicates that the email has passed DKIM authentication.  

Generate DMARC records 

Manually publishing DMARC records can be prone to errors due to the complexity of the syntax and configuration options involved. Even minor mistakes in the DMARC record, such as typos, incorrect policy settings or missing information, can lead to misinterpretation by email servers or email deliverability issues.

To mitigate the risk of errors and ensure the accurate configuration of DMARC records, NICeMail provides automatic generation of DMARC records in Admin Console. Follow the below steps to generate DMARC records:

1. Login to https://mailadmin.mgovcloud.in.
2. Select Domains from the left pane, and choose the domain for which you want to configure DMARC.
3. In the Email Configuration tab, select DMARC.
4. Select the action to be taken when DMARC validation fails for your domain according to your preferences from the options given below:
   • Do nothing to the email (Phase 1)
   • Quarantine the emails (Phase 2)
   • Reject the emails (Phase 3)
5. Provide the Aggregate notification email address to which the detailed Aggregate report should be sent.
6. Provide the Forensic notification email address to which the Forensic report should be sent.
7. Select the action to be taken when DMARC validation fails for your subdomains according to your preferences from the options given below:
   • Do nothing to the email (Phase 1)
   • Quarantine the emails (Phase 2)
   • Reject the emails (Phase 3)

8. If required, enter the Policy percentage to specify the percentage of emails that should be subjected to the configured DMARC policy actions (quarantine or reject).

   Note:

   If you do not specify a Policy percentage, the default percentage of 100% will be set for your DMARC policy action. 

9. Select the SPF Alignment severity to determine how closely the SPF record must match the From address in the email header for it to pass authentication, from the options (Strict / Relaxed).
10. Select the DKIM Alignment severity to determine how closely the DKIM signature must match the "From" address in the email header for it to pass authentication, from the options (Strict / Relaxed).
11. Once done, click Generate.

The TXT records containing the specified DMARC configurations will be generated. 

Publishing DMARC Policy

The generated DMARC record will be in the following format: 

Once you generate the DMARC policy record, you must create a TXT record in your DNS and publish the generated values. To publish your DMARC record, follow the steps:

1. Navigate to your domain provider's DNS configuration page.
2. Create a TXT record in your DNS.
3. Copy and paste the TXT Name / Host values generated in the Admin Console.
4. Copy and paste the TXT Value / Content values generated in the Admin Console.
5. Choose the shortest TTL value for the changes to take effect as soon as possible, then click Add.
6. Once added, navigate back to NICeMail Admin Console and click Verify to verify the records.

Upon successful verification, the DMARC record will be configured for your domain. If you want to update the DMARC records, navigate to the DMARC policy section in Admin Console and click the Re-generate button. Make the required changes, generate the record, and update it on your DNS page. 

Once configured, you will start receiving DMARC reports according to your DMARC configurations. These reports provide you with information about anomalies in emails, the source of unsigned emails, or emails that appear to be spoofed. Additionally, they detail the overall count of emails that either pass or fail DMARC, DKIM, and SPF validations. By using these DMARC reports, you can understand and analyze the activity of IP addresses sending emails on behalf of your domain, review the sources, and potentially include valid IP addresses in your SPF records or configure legitimate sources with DKIM.

Troubleshooting DMARC Record Addition and Verification

SPF and DKIM configuration errors

Double-check the DNS configuration to ensure that both SPF and DKIM records are properly published and accessible to email servers performing authentication checks.

Incorrect Values / Syntax errors

Check the syntax of your DMARC record to ensure it follows the correct format. Common mistakes include missing semicolons, incorrect tags, or invalid values. It is recommended to generate the DMARC record in the Admin Console to avoid inconsistencies in records.

Longer TTL

TTL (Time To Live) is the time specified in your DNS for each change in your DNS to be effective. If you have a huge TTL value (24 hrs/ 48 hrs), then the TXT Record might not be provided during the verification process. It might take up to 12 - 24 hours for DNS changes to take effect, based on the TTL set. Please check the TTL value using the DNS checker tool and try verifying after a while.