mergeable DMARC record

[knoepfchendruecker]

mergeable DMARC record

[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.