[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)
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
