Unresolvable RFC.5321 domain at Yahoo

Seen this recently?

451 Message temporarily deferred due to unresolvable RFC.5321 from domain; see https://postmaster.yahooinc.com/error-codes

This is Yahoo doing some extra work to identify that the 5321.From domain¹The return-path, aka the 821.From, 5321.From, or bounce address is the email address you send from at the protocol level, not the email address in the From: header, and it’s the address any bounces will be sent to. of the mail is acceptable to them.

Yahoo are going (slightly) beyond what’s required for the return path to be valid in SMTP terms. SMTP just requires that the return path be syntactically valid – i.e., looks like an email address – and that it be deliverable. The basic DNS check you might do would be to check if the right-hand-side of the email address has an MX record²or an A record – but that’s only there for legacy deployments from decades ago, so don’t rely on that. Have an MX record.. So for a bounce address of bounces@email.example.com you’d check to see if email.example.com had an MX record.

Yahoo want to also check that it looks like a legitimate address in another way, that the organizational domain of the right-hand-side looks legitimate. The organizational domain is what you might think of as a “domain” as opposed to a “hostname”, here it’s example.com. They’re checking this by looking up the SOA (start of authority) record for example.com. The SOA record generally isn’t very interesting unless you’re a DNS resolver, it mostly contains metadata about DNS caching and similar. But DNS requires every organizational domain to have one³ technically DNS requires every DNS zone to have one, and an organizational domain will almost always be it’s own DNS zone. Those very rare cases where it isn’t are things like SaaS companies allow users to have their own username.companyname.com virtual machines, and you didn’t want mail from there anyway., so it’s a good way to check that it’s legitimate and correctly set up.

If looking up an SOA for the organizational domain of your bounce address fails then Yahoo won’t accept your mail – and your DNS setup is broken, which could cause all sorts of other subtle DNS related issues.

How could it be that example.com has no SOA record and so isn’t a valid domain in DNS, but email.example.com has a valid MX record and according to your DNS testing looks fine? There are lots of ways to break DNS, but one of the ways ESPs handle custom bounce addresses using domains owned by their customer – a good practice, and needed for DMARC alignment – makes them particularly vulnerable to it.

If your customer is “corporate.com” and they want to use a custom bounce address in their domain, such as bounces@email.corporate.com, you as an ESP need them to setup DNS for email.corporate.com so that it points at your bounce handler. There are a lot of ways to do that, but the most flexible is for your customer to delegate the whole email.corporate.com subdomain to your nameservers.

Delegation means that when the nameservers for corporate.com receive a query for email.corporate.com, or any subdomain under it, they respond with a redirection, saying “go ask the ESPs nameservers instead”. This is great, everything works fine. The ESP can modify the MX records for the bounce handler if they need to operationally, and similarly for any other records under the email.corporate.com subdomain. Any queries for corporate.com itself, such as an SOA record, are answered directly by the customer DNS server. Yahoo is happy.

But … what if the customer decides to register a new domain, campaignbrand.com, just for email? What they should do is add that domain to their corporate nameserver, or their registrars nameserver, and delegate the email.campaignbrand.com subdomain to the ESP nameserver, exactly the same as the previous example.

But sometimes things don’t go according to plan. The customer might think “I’m not using the base campaignbrand.com for a website or anything, just click tracking links and the bounce address – I don’t need to bother with setting up DNS for it”. Instead, when they register the domain, they tell the registrar to use the ESPs namservers for it. The ESP configures their nameservers to respond to email.campaignbrand.com. Any queries for email.campaignbrand.com will be sent directly to the ESP nameservers, and they’ll answer them correctly. So click tracking and MX lookups and everything work. But any query for campaignbrand.com, like Yahoo looking for an SOA record, will be sent to the ESP nameservers too. Depending on how they’re configured they might respond with an error, or not respond at all, but the one thing they’re not going to do is respond with the SOA record Yahoo wants.

So, if you see this error check to see whether you can query DNS for the SOA record of campaignbrand.com⁴dig campaignbrand.com soa or I have a web form.. If you can’t, that may be your problem.

• 1
  The return-path, aka the 821.From, 5321.From, or bounce address is the email address you send from at the protocol level, not the email address in the From: header, and it’s the address any bounces will be sent to.
• 2
  or an A record – but that’s only there for legacy deployments from decades ago, so don’t rely on that. Have an MX record.
• 3
  technically DNS requires every DNS zone to have one, and an organizational domain will almost always be it’s own DNS zone. Those very rare cases where it isn’t are things like SaaS companies allow users to have their own username.companyname.com virtual machines, and you didn’t want mail from there anyway.
• 4
  dig campaignbrand.com soa or I have a web form.