Email providers are always looking to limit the amount of spam and phishing emails their users receive. Taking advantage of DMARC technology is the next step. Like other security features, there can be collateral damage and inconveniences involved in the implementation, but the benefits outweigh the draw backs.
OpenSRS is a white label domain registrar service provider. Many of our resellers have chosen OpenSRS because of our white label approach. In an effort to maintain anonymity we send notifications to your users as if the message came from the technical contact email address on your account.
Due to an increase in free mail providers (aol.com, hotmail.com, gmail.com, yahoo.com and so on) taking advantage of DMARC, we are seeing an increase in bounced notifications. For example: At this time aol.com has implemented a DMARC policy which rejects 100% of the message sent for @aol.com addresses that do not pass DMARC authentication. If you are using an @aol.com address as your technical contact address OpenSRS won’t be able to send notifications because we aren’t white listed in SPF records for aol.com.
How does this affect me?
If you are using a free mail provider as your technical contact email address some or all of the notifications we send out will be undeliverable. This affects important notifications such as:
- Registrant Verification
- Domain renewal reminders
- Transfer Authorization
- ICANN Trade approvals
- And more
Not all free mail providers have adopted a DMARC policy but we are seeing an increase in these providers enabling policies. As an example, at this time, gmail.com doesn’t have a reject policy but yahoo.com does. There has been speculation that google plans to change their DMARC policy for gmail.com to reject messages sometime in 2017.
What should I do?
We recommend establishing your own domain for use with your reseller account. OpenSRS offers white label email service at just 50 cents USD/month per mailbox. Once you have service established set your reseller account technical contact address to this email address to prevent any delivery issues.
How do I set the technical contact on my account?
- Login at manage.opensrs.com
- Click on “Domains” at the top
- Click on the “Settings” tab
The email address listed in the “Default Settings For New Domains” section is your technical contact address.
If you already have a white label domain setup for your technical contact address you should consider adding our registrar mail system to your SPF records. More details available here.
This doesn't appear to help. The messages from OpenSRS have a
Return-Path: email@example.com ( RFC5321.MailFrom )
And the from address ( RFC5322.From ) is our technical support but
SPF authenticates the RFC5321.MailFrom
DKIM authenticates the RFC5322.From
and DMARC checks that the domain in the RFC5322.From matches an authenticated domain - a domain that has
either been authenticated with SPF or DKIM. The only authentication that can be applied is SPF because
you don't support DKIM on these messages (although you do now have it in the OpenSRS mail system itself
these keys are not used by the notification system)
So DMARC checks that the from address is a opensrs.org email address - which it never is so it always fails.
It is ridiculous that you have not provided a real solution for this problem yet. A simple user-selectable setting to have email addresses spoofed as the are today or sent from opensrs would be easy and would solve the issue. Whats the holdup?
As previously pointed out, the current system is incapable of passing DMARC. You don't provide DKIM, and SPF is not aligned.
As a result I need to choose between not using DMARC to protect my domain or putting up with people sending spam "from" my domain.
There are two obvious solutions:
1) Set the return path the same as the "from" header so SPF is aligned and DMARC can pass.
2) GIve us the option of sending "from" an OpenSRS address. My customers really don't care -- it's not like it's a secret that storefront is OpenSRS.