Beginning February 2024, Gmail and Yahoo will mandate that all emails utilize DKIM and DMARC authentication. It is strongly advised for all email senders to implement DKIM and DMARC to ensure compliance.
For further information, please visit our blog post regarding the upcoming authentication requirements by Google and Yahoo in 2024.What is DMARC?
DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. It is a free, technical solution that authenticates emails by integrating SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail) techniques. Launched in 2012, DMARC aids in combating email fraud, such as phishing, by allowing domain owners to define how their email domains' unauthorized use should be handled via a policy in the DMARC record (identified with "p=").
P = NONE This policy mode is for monitoring your email traffic without taking any additional actions.
P = QUARANTINE Under this policy, emails not authorized are directed to the spam folder.
P = REJECT Representing the final policy stance and the ultimate objective of DMARC implementation, this setting guarantees that unauthorized emails are completely blocked from delivery.What is DMARC Record?
A DMARC record is a type of TXT DNS record located at the _dmarc subdomain. It specifies the policies and preferences for how email servers should handle emails, using a structure of tags and their associated values, which are divided by semicolons.
Here is a simple illustration of a DMARC record:
v=DMARC1; p=none;Below are essential tags for configuring a DMARC record:
v (Version of DMARC):
Default: DMARC1
Explained: Indicates the version of the DMARC protocol being used. Always set to "DMARC1". Incorrect or missing values will lead to the DMARC record being disregarded.
p (Policy):
Default: none
Explained: Defines the course of action for emails that fail DMARC authentication.
none: Gathers feedback without altering the existing email process.
quarantine: Moves dubious emails likely to the spam folder.
reject: Blocks all emails that fail authentication.
adkim (DKIM Alignment Mode):
Default: r
Explained: Sets the alignment criteria for DKIM signatures.
"r" (Relaxed Mode): Accepts emails if there's a match in the organizational domain between DKIM and the From domain.
"s" (Strict Mode): Requires an exact match between the DKIM and the From domain.
aspf (SPF Alignment Mode):
Default: r
Explained: Mirrors the adkim tag, but applies to SPF verification.
"r" (Relaxed Mode): Passes emails with matching organizational domains between SPF verified and the From domain.
"s" (Strict Mode): Demands a perfect match between the SPF domain and the From domain.
sp (Sub-domain Policy):
Default: Inherits parent domain’s p=value
Explained: Sets a specific policy for subdomains separate from the main domain’s DMARC policy.
fo (Forensic Reporting Options):
Default: 0
Explained: Dictates the criteria for sending forensic reports.
"0": Sends reports only if all authentication checks fail.
"1": Sends a report if any single check fails.
"d": Specifically for DKIM failures.
"s": Specifically for SPF failures.
ruf (URI for Forensic Reports):
Default: none
Explained: Identifies where forensic reports should be sent, using the format "mailto:address@example.org".
rua (URI for Aggregate Reports):
Default: none
Explained: Designates where aggregate XML feedback reports are sent, in "mailto:address@example.org" format.
rf (Report Format):
Default: afrf
Explained: Specifies the format of forensic reports.
pct (Percentage of Messages to Filter):
Default: 100
Explained: Determines what percentage of failing emails should be subjected to the DMARC policy, useful specifically with "quarantine" or "reject" policies.
ri (Reporting Interval):
Default: 86400 (seconds)
Explained: Sets how often aggregate reports should be sent.
Each tag plays a crucial role in setting DMARC policies and establishing mechanisms for authentication and feedback, crucial for securing emails and managing failure reports accurately.
For creating a DMARC record easily, using a DMARC generator tool is advisable.
Understanding DMARC Functionality:
Authentication Process:
SPF/DKIM Verification:
Email receiving servers carry out confirmation checks using SPF (Sender Policy Framework) or DKIM (DomainKeys Identified Mail) authentication protocols.
Domain Alignment Verification:
Ensures the domain indicated in the SPF (Return-Path) or the domain specified in the DKIM signature (d= parameter) matches the domain mentioned in the email's "From" header.
DMARC Policy Implementation:
Identifies and applies the specific DMARC policy set within the DNS record for the domain found in the email's "From" header.
Sample Configuration Scenarios:
When the SPF check is successful and matches the "From" domain, DMARC authentication is considered successful. v=DMARC1; p=none; aspf=r;
When DKIM verification is successful and coordinates with the "From" domain, DMARC authentication is regarded as successful. v=DMARC1; p=none; adkim=s;
If both SPF and DKIM validations fail, DMARC authentication is deemed unsuccessful. v=DMARC1; p=reject;Alignment Options:
Relaxed Mode (r): Permits SPF/DKIM verifications to include subdomains when comparing with the "From" domain.
Strict Mode (s): Demands a precise match between SPF/DKIM domains and the "From" domain.
Report Mechanisms:
Aggregate Reporting: Gathers pass/fail outcomes in comprehensive reports, dispatched periodically to designated emails as per the rua tag.
Forensic Reporting: Provides in-depth reports on authentication failures to specific contacts (ruf), although, due to privacy issues, many providers refrain from distributing these reports.
Reporting Frequency (ri): Specifies how often aggregate XML reports are sent to the stakeholders.
Configuration Examples:
For dispatching aggregate reports daily: v=DMARC1; p=none; rua=mailto:postmaster@mydomain.com; ri=86400;
For sending forensic reports weekly: v=DMARC1; p=none; ruf=mailto:postmaster@mydomain.com; ri=604800;Policy and Compliance:
DMARC Policy (p): Determines the action taken on emails that fail DMARC verification.
Percentage of Checked Messages (pct): Indicates the portion of emails to undergo DMARC assessment.
Sample Setups:
Initiating with a quarantine approach and testing at 50% coverage: v=DMARC1; p=quarantine; pct=50;
Transitioning to a reject strategy with complete implementation by omitting the pct tag: v=DMARC1; p=reject;These configurations are designed to validate email authenticity and establish guidelines for managing authentication failures. This offers senders the capacity to adjust reporting and enforcement intensities according to their specific needs and phases of verification process.
Resolving DMARC Email Failures for Users on LC Email Shared Domains
DMARC is not required to send emails from the shared domains on LeadConnector email system.When you switched to LC email system or not configured your own mailgun / SMTP all your email will be sent through LC shared domain.
To address the issue, temporarily modify your DMARC record within your DNS settings to adopt a p=none policy.
The error indicated by DMARC arises from a p=reject or p=quarantine policy, blocking emails failing DMARC authentication from reaching the Inbox. To ensure email delivery despite DMARC failures, you should update your DMARC policy to p=none through your DNS provider. It's worth noting that shifting to a less stringent policy is generally not advised, so this alteration should be considered a short-term solution.