[dmarc-ietf] Usage Guide interview (ESP) with Alwin de Bruin @ Measure Mail

[Tim Draegen <[e-mail]>]

[This email is the first of a series described here: https://www.ietf.org/mail-archive/web/dmarc/current/msg03671.html Thanks much to Alwin for being the first to volunteer and to help smooth out the rough spots.]

Background: Measure Mail is a Netherlands-based Email Service Provider operating since 2001. Within Measure Mail Alwin is responsible for operations. The company strives to remain up to date with changes in the email ecosystem. Outside of Measure Mail Alwin is heavily involved in Netherlands standardization communities to establish technology guidelines for ESPs and government email requirements. Alwin has advocated for DMARC within Netherlands circles since its public release.

Experience:
From company perspective, making customers recognizable to the recipients of email is primary. Two points:
	• Cannot interfere with existing email infrastructure.
	• Cannot settle for “sent on behalf of” in a UI, which lead to the required use of sub-domains. Customers are provided with DNS settings to allow Measure Mail to send email using a customer’s sub-domain.

Use of sub-domains allows us to make email appear to come from customer, including addresses, embedded links, and other branding. Ensuring that all domain identifiers in an email are aligned helps make email obvious and easy to deliver. Customers accept this explanation as it is easy to understand.

Sending DNS settings to customers can be quite complex. However, the requirement to implement DNS-changes leads to better customers in terms of us servicing slightly more technically savvy customers, but also tends to exclude very small businesses that do not have resources to deal with DNS configuration.

Making DNS changes easier for customers is something we’ve focused on over the past few years. In this way, we’ve arrived at requiring DNS changes only once during onboarding. This appears to be a trend among the market.

Customer use of DMARC policies has had little impact on our service. For the sub-domains that customers provide to us, we originally placed DMARC records to help monitor email delivery. By design we see little impact to our service due to customers publishing DMARC policies.

When customers publish their own DMARC records, we ask our customers to provide us with their reporting address so that we can forward sub-domain specific reports to the customer. In this way the customer gets a complete picture. Otherwise the customer might not see the complete picture.

Strict vs Relaxed mode: haven’t run into any issues, but mainly because we work with customers early. Plus, we have DMARC records in place at sub-domain which we operate in.

SPF considerations: we maintain an include that customers use. By doing this, we can maintain the real SPF record without requiring customer changes. Also, we use dedicated sub-domains and so configuration avoids top-level SPF record issues.

DKIM considerations: key rotation appears to be relatively new in the market. Our own infrastructure is ready for key rotation. Customers are being upgraded to use newer functionality that allows for no-touch key rotation. But, this is a process where older customers need to perform DNS changes to get to the “no more touch” world.

Key sizes: we’ve always used 1024 bit keys, with our newer infrastructure using 2048 keys. Once customers are on newer infrastructure, the upgrade to 2048 bit keys is transparent.

DKIM options: we use default DKIM settings when possible. Default headers that are signed mirror what is published in DKIM spec. Simple body canonicalization. DKIM timestamp included.

Policy implications: we discuss DMARC with customers if the subject comes up, and when customers are onboarded. People are guided to the Wikipedia articles on DMARC to learn about the basic stuff. DKIM sometimes requires additional explanation.

Other thoughts on Domain Owner & ESP interaction? We’re thinking of implementing DMARC reporting for the bounce messages that we receive to help communicate status to bounce-originating organization.

Overall, we don’t have issues with DMARC. This is likely due to our pre-DMARC understanding that domain alignment is common sense approach to sending customer email.
(end)