mergeable DMARC record

[knoepfchendruecker]

Problem

Imagine a domain with multiple different services, who'd each like to have a word on the contents of the domain's DMARC record (_dmarc TXT):

• a general email service
• a DMARC-reporting service like fraudmarc.com,…
• a email service provider like mailjet,… for sending out one's newsletter.

 The general email service recommends its users to configure DMARC with a policy to quarantine or rejecting any unauthorized mail, setting DMARC's policy to a default of p=quarantine, but also allowing the user to switch to "p=reject" or "p=none".   The DMARC-reporting service doesn't care about the exact policy but would like to have its reporting email address listed in the "rua" or "ruf", as their primary purpose is to analyze any incoming reports. So the service would like to add a "rua=mailto:dmarc@example.com" to the DMARC record. When one address already exists at that tag, the new one should be appended.   DKIM requires alignment of "From"-header and "MailFrom"-envelope. As the newsletter is using a custom subdomain during the SMTP dialogue to receive bounces, the corresponding alignment policy must be "relaxed". While this is the default value for DMARC, the email service provider wants to ensure an "apsf=r" tag.   Suggestion:

• provide an "SPFM"-like "DMARCM" tag, which merges any non-conflicting DMARC tags.

To be decided: recommendation on what to do when two service's DMARC tags do conflict with each other.

• choose the "weaker", more compatible one: prefer "relaxed" over "strict" mode, prefer "quarantine" over "reject", "none" over quarantine or reject.
The user is told whose tags have been overridden during this merge operation.
• choose the "tighter", more secure one: prefer "strict" over "relaxed" mode, prefer "reject" over "quarantine" over "none".
The user is told whose tags have been overridden during this merge operation.
• let the user decide.

Some corner cases to consider:

• an email service provider knows their specific configuration to be incompatible with DMARC (e.g. due to misalignment of Envelope-From and Header-From). They do prefer no DMARC record at all, but could also live with p=none.
• how many email reporting addresses are being honored is up to the reporting server. So an "early" email address in a rua tag may be "more important" than a "late" email address. And after all, users are recommended not to use more than 3 email addresses in each tag, as the later added are unlikely to be honored by most DMARC reporting mail servers.

Why is this needed:

Today, the DMARC-record is a simple TXT record and at best, a Domain Connect template states a conflict if the record starts with "v=DMARC1". We currently don't run into this issue, as barely anyone is deploying DMARC records by default. However, DMARC is a promising technology and so this issue may arise.

Today, any service may decide to use a CNAME instead of a TXT record to bring the entire DMARC record under the full administrative control of the specific service. This does prevent any manual misconfiguration by the user but also prevents any other service from configuring DMARC. A mergeable DMARC record could "fix" this issue, by allowing services to merge their specific DMARC requirements.

[arnoldblinn]

I'm not entirely sure having a design conversation over github is the most efficient approach....but I'll try.

This is indeed interesting. My knee jerk reaction is this:

I haven't seen that many templates trying to define DMARC records. We introduced the SPFM concept because we were seeing some conflicts between email and email marketing services.

Am I missing something in the templates here? If this is a real issue, I'm all in. But if this is theoretical, I'm hesitant to introduce a new concept as driving adoption across all the DNS Providers and Service Providers is a pretty big task. Having a stable spec allows us all to level set.

[knoepfchendruecker]

I don't believe we currently have an issue, but we probably may have an issue in the near future (and it's good to be prepared).

Both technologies (SPF and DMARC) are growing in terms of adoption.

According to builtwith.com, more than 60% of the Top 1M Alexa websites do have SPF records, while less than 2% of the same list of domains do have DMARC records. For the "Top 10k" of domains, the numbers currently are at 80% (SPF) and 7% (DMARC).

According to Valimail's quarterly Email Fraud Landscape report Q4/2018, adoption of DMARC is at 50% for the US Fortune 500 and large US tech companies but (according the same source) on average only 20% of domains with DMARC do have DMARC actually enforced by having a different policy than "none".

So just according to those figures, SPF is currently much more spread than DMARC, and at the low enforcement rate of DMARC, DMARC-related misconfigurations simply don't show up. Both technologies do offer multiple knobs to tune, and so potential collisions or requirements to merge records are more likely for SPF than for DMARC.

Today, most DNS providers do treat both DMARC and SPF as "just another TXT record, the user needs to know the correct syntax of whatever they're doing". Domain Connect's mergeable SPFM does severely improve this situation, and I'd like to see the same for DMARC.

I've also been doing a little bit of research on user-provided (not configured by a template mechanism) SPF records: about 14% is syntactically wrong, usually due to faulty attempts to merge multiple SPF statements, "too many DNS lookups" or including random hostnames who don't have SPF records at all (which according to RFC7208 shall result in a "permanent failure" error, where the SPF record is usually ignored, which in turn "makes sending email work again" after having a misconfigured, too-tight SPF record). An even higher rate of records is semantically wrong: by leaving out obviously required SPF includes, including multiple default policies (anything beyond the leftmost "all"-statement is ignored). As such, having SPFM in place is a great improvement, as it does prevent such edit errors from happening. I do consider DMARCM to provide a similar good basis.

Having some "mergeable DMARC" record gives ESPs the option to influence specific parts of a DMARC policy at no extra risk and without enforcing an actual DMARC policy: if the user did not delegate a subdomain for ESP bounce handling, do request DMARC not to be enforced at all. If the user did delegate a subdomain to the ESP, don't care about the enforcement policy but request DMARC to be checking the alignment in "relaxed" mode. At that stage, the decision of the actual enforcement policy then can be left to the user, as it does become a simple three-button-chooser and not a text string with a dozen different options. So a "mergeable DMARC" record might even increase DMARC awareness and DMARC deployment.

Other than this, you're right as well. As long as nobody is encouraging DMARC records to be deployed universally, DMARC will remain a niche feature for the tech-savy and we won't ever need to deal with random users trying to edit complex statements in a DNS editor or service providers need to deal with DMARC-use cases. As such, Domain Connect should focus on a stable, well-known spec.