About DMARC
Domain-based Message Authentication, Reporting, and Conformance (DMARC) is a domain security mechanism that allows owners of the domain to inform recipient mail servers what to do with messages if SPF and/or DKIM authentication does not pass for the protected domain. SPF and DKIM are mail authentication methods that combat spoofing by tying key components of an email message back to a reputable source of information.
DMARC directs an email server how to handle an email if it appears to be from your organization and does not pass authorization tests. Tests are based on the DKIM and SPF records that are set up. If an email does not pass these tests there are three options on how to handle the message: take no action, quarantine the message and send to spam, or reject the message and do not deliver to the inbox.
Things to Consider
Adding a DMARC record provides a level of security to your emails, but also requires some additional consideration. If the DMARC policy is set to quarantine or reject, contacts may miss out on receiving important emails from your organization. As a result, you will need to develop a process to continually monitor the reports about DMARC activity. You may need to make updates to your DMARC policy to ensure the largest number of emails possible are reaching the inbox.
Ensuring your SPF and DKIM records are in place is the most critical step to ensure mail deliverability. You can verify your SPF and DKIM records at any time by following these steps.
Configuring a DMARC Record
A DMARC Record is a line of plain text configured as a public DNS txt record, typically on the organization domain or subdomain that is used in the PRA From Address." The record contains a list of tags and values separated by semicolon. Some of these values are required and other values are option. View the table below to learn more about these values.
The line of text outlines what a receiving server will do if an email is not authenticated. The policy (p) defines these actions.
v=DMARC1; p=none; rua=mailto:[email protected],mailto:[email protected]; pct=100; adkim=r; aspf=r
DMARC Tags
Tag | Description and Value | Required or Optional |
v | D: DMARC version tag
V: Must be DMARC1 | Required |
p | D: The policy tag that specifies the action a mail server will take if a message is not authenticated.
Value options: none – policy is not enforced and intended to monitor only
quarantine – policy is enforced and sends the message to a user's spam folder if neither DKIM nor SPF referencing your domain is present
reject – policy is enforced, the message is bounced and not received by the user if neither DKIM nor SPF referencing your domain is present
💡 Particular attention should be paid to this if you’re adding a DMARC policy to your root / corporate domain, or any subdomain that is used by multiple sources. For example, if you have an e-commerce solution that sends customer notifications using your domain in the From address, if neither DKIM, nor SPF domain associated with those emails references your sending domain, it will not be in alignment with DMARC requirements. This will have negative impact on deliverability of those messages, if you were to implement one of the two enforced DMARC policy directives (quarantine or reject) | Required |
pct | D: Specifies the percentage of unauthenticated messages that are subject to the DMARC policy.
V: Formatted as a whole number between 1 and 100. If the value is not provided it will default to 100 | Optional
|
rua | D: The email address that should receive reports about DMARC activity to help you see, whether your domain is being abused or isn’t properly authenticated for any legitimate sources.
V: email address. All email addresses must include mailto: before the address and multiple email addresses can be used but must be separated by a comma.
💡 These reports are sent in XML format, for which a converter or an online utility would be needed to interpret the data provided. | Optional |
sp | D: Sets a policy specifically for a subdomain of the primary domain, if a different DMARC policy should be used.
For example, if you adding DMARC to the root domain of domain.com, this record can specify different enforcement level for traffic that is sent using any sub.domain.com
Value options: none – policy is not enforced and intended to monitor only - this option does not cause any action taken against mail that uses your domain, but can be configured to send reports to an email address you specify in your record, so that you can correct any authentication problems with legitimate sources that send mail on behalf of your domain.
quarantine – policy is enforced and sends the message to a user's spam folder if neither DKIM nor SPF referencing your domain is present
reject – policy is enforced, the message is bounced and not received by the user if neither DKIM nor SPF referencing your domain is present | Optional
If this tag is not used subdomains will use the settings for the primary domain, unless a subdomain has its own DMARC record |
adkim | D: Sets the alignment policy for the DKIM, which measures how strictly information must match the DKIM signature
Value options: s - strict alignment, DKIM domain must be an exact match for the header (from) domain
r - relaxed alignment, exact match between DKIM and header (from) domain isn’t required, but DKIM domain needs to reflect the same parent domain
With relaxed DKIM alignment you may use a subdomain in the From address, even if your DKIM domain is on the root, and vice versa. Strict alignment requires that both the DKIM domain and From address domain match exactly, so if you decide to implement strict alignment, you would have to review all of your mailing sources (including Listrak) that use your domain to ensure that all systems that send on behalf of your domain can satisfy requirements of a strict DKIM alignment. | Optional |
aspf | D: Sets the alignment policy for the SPF domain, which measures how strictly information must match the SPF signature
Value options: s - strict alignment, the SPF domain must be an exact match to the domain that has your DMARC policy
r - relaxed alignment, SPF can be signed on a subdomain of the that has your DMARC policy
💡 Listrak requires relaxed alignment because our SPF record is always signed on a unique subdomain and will not match your sending domain or subdomain (typically bounce.domain.com). | Optional |
Have additional questions? Read more from Google.
Setting Up DMARC
DMARC is added to the domain's DNS settings by updating the TXT record in the DNS settings. Each domain can have individual DMARC records. Subdomains can also have their own records, however, if individual records are not created, subdomains will use the DMAC record of the parent domain.
Adding or Updating DMARC Records
⚠️ Before setting up a DMARC policy, the DKIM and SPF policies must already be in place and authenticating messages for at least 48 hours.
Sign in to the management console for your domain host.
Locate the page where you update DNS records.
Add the new or updated record in the _dmarc section of the record.
Add the TXT record name in the DNS host field.
Add the TXT record value in the next field.
Save Changes.
Verifying DMARC TXT Record Name
Go to the Google Admin Toolbox and select the Dig feature.
In the Name field, enter _dmarc. followed by your complete domain name. E.g., enter _dmarc.yourdomain.com
Below the Name field, click TXT.
Verify your DMARC TXT record name in the results. Look for the line of text that starts with _dmarc.
2024 Google and Yahoo Bulk Sender Requirements Video
Learn about the benefits of using a DMARC policy and how to set it up to stay in compliance with Google and Yahoo's updated email authentication policy.
📑 Articles mentioned in the video: