Domain-based Message Authentication, Reporting, and Conformance (DMARC) is an email authentication protocol designed to protect domains from phishing attacks and abuse by spammers. A domain may have multiple senders for different types of email, but each domain may have only one DMARC record.
For example, a domain may have an on-premise Exchange server for email sent by employees and a third-party email provider for sending promotional emails to customers. The email administrators might want different DMARC records, but DMARC does not support this. In this article, we will discuss strategies to merge DMARC records from different email providers with some examples.
DMARC records and subdomains
Another solution to email providers wanting different DMARC records is for one provider to use a subdomain.
A single DMARC record applies to all email sent from any single domain. For example, the DMARC record at _dmarc.example.org dictates DMARC policy for all email sent from example.org. If two email providers are sending email from example.org, they must merge their DMARC records.
There may be scenarios where the administrators cannot agree on how to merge their DMARC records. In this case, one of the email providers could use a subdomain. If the business sends email from example.org and the other email provider uses a subdomain such as promotions.example.org, they can each create their own DMARC records. The DMARC records would be at _dmarc.example.org and _dmarc.promotions.example.org.
Caution should be used in this scenario. Using less stringent policies in the DMARC record for the subdomain may allow phishing and spam. This could potentially tarnish the reputation of the business.
Merging “rua” and “ruf” tags
The “rua” tag specifies email addresses for aggregate reports. The “ruf” tag specifies email addresses for message-specific forensic reports.
DMARC allows multiple email addresses to receive copies of reports. So if there are two email providers for a domain, both administrators can receive reports for the domain. But each administrator may need to filter the reports for the email sent by their system.
To merge the “rua” and “ruf” tags, specify the email addresses from each record separated by commas. Each email address can optionally have its own size limit. Append an exclamation point and a size limit such as “10m” for 10 megabytes. For example:
- v=DMARC1; p=reject; rua=mailto:admin@example.org
- v=DMARC1; p=reject; rua=mailto:reports@example.net!5m
+ v=DMARC1; p=reject; rua=mailto:admin@example.org,mailto:reports@example.net!5mMerging “p”, “sp”, and “np” tags
The “p” tag gives the overall DMARC policy for the domain. The “sp” tag gives the DMARC policy for subdomains. And the “np” tag gives the DMARC policy for subdomains that do not exist in the DNS.
These DMARC tags specify how email that fails one or more DMARC checks should be handled. Each policy tag may specify:
- “None”: No DMARC policy. Mail that fails DMARC checks should be delivered. Useful during initial deployment and testing.
- “Quarantine”: Mail that fails DMARC checks should be placed in quarantine. This usually means delivered to a spam folder or held for administrator review.
- “Reject”: Mail that fails DMARC checks should be rejected.
Since “None” is not often used, merging records will usually mean selecting between “Quarantine” and “Reject”. “Reject” is more secure, but configuration errors may cause email to be rejected. Some domains may use “Quarantine” as a more cautious choice.
Merging the “p” tag
The “p” tag is the most important part of the domain’s DMARC record. If both records specify the same value, that value can be used in the merged record.
If one of the records species “Reject” and the other species “Quarantine”, then one administrator is more mindful of security. There may be good reasons for this, including past attacks, security reviews, or requirements imposed by management or oversight bodies. In most cases, “Reject” will be the correct choice in the merged record. The administrator that previously used “Quarantine” should be prepared to exercise more care to avoid configuration errors.
Here is an example where the two providers have agreed that “Reject” is the best option for the domain:
- v=DMARC1; p=reject; rua=mailto:admin@example.org
- v=DMARC1; p=quarantine; rua=mailto:reports@example.net
+ v=DMARC1; p=reject; rua=mailto:admin@example.org,mailto:reports@example.netMerging the “sp” tag
The “sp” tag should be omitted in the final DMARC record for the domain if neither of the records being merged uses the “sp” tag.
If one record specifies “Reject”, then the domain probably has good reasons for this, and “Reject” will be the best choice for the merged record. The domain strongly desires to allow mail only from the domain itself but never from subdomains. This may be due to a strict security architecture or problems with phishing attacks in the past, or both.
Use “Quarantine” if at least one of the records being merged specifies “Quarantine” but neither record specifies “Reject”.
Merging the “np” tag
Merging the “np” tag is similar to merging the “sp” tag, but these two policies are used to combat slightly different types of phishing and spam.
The “np” tag should be omitted in the final DMARC record for the domain if neither of the records being merged uses the “np” tag.
If one record specifies “Reject”, then “Reject” will be the best choice for the merged record. The domain may have had problems with phishing attacks using important-sounding but non-existent subdomains.
Use “Quarantine” if at least one of the records being merged specifies “Quarantine” but neither record specifies “Reject”.
Merging “aspf” and “adkim” tags
As we discussed in our DMARC article, the “aspf” and “adkim” tags specify the required domain alignment policy for SPF and DKIM, respectively. Each tag must specify “s” for strict alignment or “r” for relaxed alignment.
As with the “p” tag, it is generally best to use the most secure option when merging. So if the two records to be merged each specify “r” then the merged record should use “r” for these tags.
But if one record specifies “s”, then strict alignment will be best in the merged record. This may require discussion amongst the administrators of the two domains to ensure that the change from relaxed to strict alignment doesn’t cause problems.
Here is an example of merging DMARC records with differing domain alignment policies. If the tag is not specified, the default value is “r” for relaxed:
- v=DMARC1; p=reject; aspf=s; rua=mailto:admin@example.org
- v=DMARC1; p=reject; adkim=s; aspf=r; rua=mailto:reports@example.net
+ v=DMARC1; p=reject; aspf=s; adkim=s; rua=mailto:admin@example.org,mailto:reports@example.netMerging the “fo” tag
The “fo” tag specifies failure reporting options in a colon-separated list. The possible values for the “fo” tag are:
- “0”: Generate a failure report if all checks do not result in “pass”.
- “1”: Generate a failure report if at least one check does not result in “pass”.
- “d”: Generate a DKIM failure report if the message signature fails to validate.
- “s”: Generate an SPF failure report if the message fails SPF evaluation.
DMARC allows multiple values in this tag, so a good merge strategy is to append the tag values from the two records. For example:
- v=DMARC1; p=reject; fo=1; rua=mailto:admin@example.org
- v=DMARC1; p=reject; fo=d:s; rua=mailto:reports@example.net
+ v=DMARC1; p=reject; fo=1:d:s; rua=mailto:admin@example.org,mailto:reports@example.netMerging the “rf” tag
The “rf” rag specifies the report format. Currently, there is only one value for this tag: “afrf” which is the Authentication Failure Reporting Format specified in RFC 6591. The value “afrf” is assumed if this tag is omitted.
This tag can be omitted when merging records until more tag values are added to DMARC. For example:
- v=DMARC1; p=reject; rf=afrf; rua=mailto:admin@example.org
- v=DMARC1; p=reject; rua=mailto:reports@example.net
+ v=DMARC1; p=reject; rua=mailto:admin@example.org,mailto:reports@example.netMerging the “ri” tag
The “ri” tag specifies the report interval between aggregate reports in seconds. The default value is one day (86,400 seconds).
Using the larger of the two values from the records being merged is a good strategy. For example, if one record uses the default of one day and the other uses three days (295,200 seconds):
- v=DMARC1; p=reject; rua=mailto:admin@example.org
- v=DMARC1; p=reject; ri=295200; rua=mailto:reports@example.net
+ v=DMARC1; p=reject; ri=295200; rua=mailto:admin@example.org,mailto:reports@example.netMerging the “pct” tag
This tag will usually not be merged, but it is best to employ it after merging or any other potentially risky DMARC change
The “pct” tag is the percentage of emails that the domain’s DMARC policy should be applied to. This is used to gradually test the effects of a change in the domain’s DMARC record. Once the administrator is confident that the record is correct, the “pct” tag can be removed so that the DMARC record will be applied to all email for the domain.
After merging records, it is a good strategy to start at a low “pct” tag value such as 10 for 10% of emails, and increase gradually as we discussed in our DMARC article:
- v=DMARC1; p=reject; rua=mailto:admin@example.org
- v=DMARC1; p=reject; rua=mailto:reports@example.net
+ v=DMARC1; p=reject; pct=10; rua=mailto:admin@example.org,mailto:reports@example.netFinding the DMARC record for a domain
DMARC records are stored as TXT records, so a standard TXT lookup will retrieve DMARC records. DMARC record names always begin with the label “_dmarc”. The dig or nslookup command line tools can be used. To find the DMARC record for Google, use this command:
dig TXT _dmarc.google.com
On operating systems that support nslookup, you can use the following:
nslookup -type=TXT _dmarc.google.com
I was recommended this website by my cousin I am not sure whether this post is written by him as nobody else know such detailed about my difficulty You are wonderful Thanks