Is email deliverability impossible with a .name email address?

Also on ServerFault.

I have a dot name domain. .name is an odd TLD: they originally only offered third level domains, eg first.last.name, so that more people could get their own name. They also included the first@last.name email address with each domain registration. They later opened up to normal second level registrations, eg last.name, but only for domains that didn’t have existing third level registrations. I got mine before that, so I’m stuck with it.

I’ve used first@last.name as my primary email address for 18 years or so. However, I don’t own last.name itself, so I have to depend on my domain registrar (and Verisign, the .name Registry Operator) to forward incoming email to me. More importantly, email deliverability for outgoing email has degraded so much that it’s almost unusable. Only Verisign owns last.name’s DNS, and they evidently have no interest in operating SPF, DKIM, DMARC, or SMTP for it. Registrars themselves can’t, since they don’t have control over last.name’s DNS.

Gmail users, for example, see the ugly warning above on my emails.

Am I stuck? Do I need to bite the bullet, give up on this email address I’ve used forever, and switch to a “normal” domain with DNS I can control? Am I missing anything?

5 thoughts on “Is email deliverability impossible with a .name email address?

  1. Sadly, Michael Hampton may be right. All evidence seems to confirm that .name email addresses from third level domain registrations are broken and unusable for outbound email.

    I emailed with ICANN and Verisign, and they basically confirmed this. ICANN said:

    If you would like to use a third level or second level .name domain for email, or upgrade your registration from third level to second level domain, you would need to contact the Registry Operator .NAME domain names.

    Verisign said:

    The .NAME email forwarding service is only for inbound emails, where they are simply passed on the forwarding address. Your outbound emails are not passing through our servers at any time. We do not add SPF/DMARCs to last.name because we do not provide e-mail services to send e-mail, only the e-mail forwarding.

    We don’t provide any other service in regards to email or DNS with .name domain names, 2nd or 3rd level. You will need to contact a DNS hosting provider for assistance on any DNS hosting.

    I replied:

    Thanks for the information, Phil. I understand that you only do .name DNS for forwarding inbound email, not sending outbound. Again, though, you’re the only party that could do that DNS, which makes .name email addresses a pretty incomplete and broken product right now. If that’s the way it is, then I understand. Thanks again.

    Sigh. Disappointing.

  2. Since roughly a couple months ago, Gmail appears to reject messages from domains without SPF records or DKIM keys, which inevitably includes first@last.name addresses from third-level .name domains. Twenty years ago, these addresses were advertised as a way to create a personal “unique online identity,” purportedly “with all the space and none of the spam.” Unfortunately, it hasn’t turned out this way. People like you, me, and many others in the same situation are effectively being forced to abandon them but will probably want to still pay for the registrations to avoid identity thieves snatching them up and getting access to all our mail from sites where we haven’t managed to update our addresses. After all these years, there could be many. Does anyone see a way out of this?

  3. I am beginning to notice that outbound e-mail from spencer@love.name is being rejected by providers like GMail. There is no way I can see to overcome this using help from the dot-name registry, which as far as I can tell is dead at the helm.

    However, I have an idea which I will test as soon as I can configure it, within a week or two. I think I can set up my server to do SPF forwarding, making the envelope sender address of the e-mail look like SRS0=HHH=TT=love.name=spencer@jslove.com, while the from address in the header remains Spencer@Love.Name.

    The advantage of this is that I completely control jslove.com, and have set up SPF records for jslove.com, and can also use jslove.com (or a subdomain) as the submission server for my mail client, which would construct the SRS forwarding address based on the submitting account using a foo@bar.name address, as a special case. The submission agent only accepts mail from clients that use encryption and have a password for their originating address, which so far has 100% blocked hijacking that function of my server.

    So the question is: can I provide DKIM authentication that depends on the sender address rather than the one parsed out of the header, and get providers like AOL, GMail and Yahoo to accept such mail on that basis? I need to go to school on that and perhaps other authentication methods as they are currently specified. I may post here again if I can get it working.

    Less likely that I would offer this as a service, but could provide info on how; perhaps someone might serve that need. I expect there are lots of people in the same boat, although people using dot-name e-mail forwarding seem thin on the ground. If there were more of us, it would surprise fewer people.

  4. Fascinating! Thanks for describing all this. I’ll definitely be curious to see if big email providers support this kind of SPF/SRS forwarding. Please keep me posted!

Leave a Reply

Your email address will not be published. Required fields are marked *