If you know, you know. And if you don't know, I'm going to tell you, because not everybody knows this.
The DMARC spec is such that you're really not meant to be able to just randomly send DMARC reports (RUF or RUA) to any random mailbox in the world. Why? So you can't level a denial-of-service attack at an unsuspecting email user (or their email server or mailbox provider). Sneaky bad guys could configure the DMARC record for their domain to point at my mailbox, then send a bunch of email messages that fail authentication checks to various mailbox providers, and then later, those mailbox providers could end up sending DMARC reports via email to my mailbox. Even though it's not my domain. Even though I might not want that.
So, section 7.1 (Verifying External Destinations) of RFC 7489 specifies a reference mechanism that the receiving domain (where the DMARC reports are being delivered to) is supposed to utilize to say that yes, they do want DMARC reports for this given sending domain.
It works like this: If I want to receive DMARC reports for mail sent by (or claiming to be sent by) aliverson.com, but I want those reports to come to dmarcreports@wombatmail.com, I need to create a DNS record, a TXT record of aliverson.com._report._dmarc.wombatmail.com that contains "v=DMARC1;".
This leads to two very important questions:
First, what? Are you sure that this has to be done? I'm a DIY'er, and I've set up a DMARC record for my 30+ domains, and it's all going to one address at one of the domains, and I seem to be getting reports.
If you look closely, you'll see that you're mostly only getting reports from Google, Godaddy (secureserver.net) and a few other (mostly smaller) platforms. You're not getting reports from Microsoft, Yahoo, or a lot of other big mailbox providers or security services. That's because support for this external domain verification is a bit imperfect. As DMARC.org suggests, a few providers may have decided to skip the verification check, perhaps in the name of helping to speed up DMARC adoption.
But, many providers DO respect the verification check, so if you want to receive DMARC reports reliably for your domain, at a mailbox not in your domain, you'll need to set that DNS record up for the receiving domain.
Which leads to the second question. What? Are you sure that has to be done? None of the DMARC providers (Valimail, EasyDMARC, Proofpoint, Red Sift, etc.) told me that this had to be set up when I started using their DMARC monitoring service.
That's because they're the ones that need to set it up; not you. And if you're a DMARC provider, you can simply put a wildcard DNS record so that you tell the world that you'll happily accept DMARC reports via email for any email sending domain in the world. If I wanted to open this up for Wombatmail, I'd publish a wildcard DNS TXT record so that any query for "(anything)._report._dmarc.wombatmail.com" resulted in a "v=DMARC1;" response.
Since the DMARC providers really only need to set this up once, and it's on the RECEIVING end of DMARC reporting (so clients of DMARC providers don't really have to think about it), you don't see them talking about it too much. Which means that a hobbyist or DIYer might not notice this requirement.
If you know, you know. And if you don't know, I'm going to tell you, because not everybody knows this.
The DMARC spec is such that you're really not meant to be able to just randomly send DMARC reports (RUF or RUA) to any random mailbox in the world. Why? So you can't level a denial-of-service attack at an unsuspecting email user (or their email server or mailbox provider). Sneaky bad guys could configure the DMARC record for their domain to point at my mailbox, then send a bunch of email messages that fail authentication checks to various mailbox providers, and then later, those mailbox providers could end up sending DMARC reports via email to my mailbox. Even though it's not my domain. Even though I might not want that.
So, section 7.1 (Verifying External Destinations) of RFC 7489 specifies a reference mechanism that the receiving domain (where the DMARC reports are being delivered to) is supposed to utilize to say that yes, they do want DMARC reports for this given sending domain.
It works like this: If I want to receive DMARC reports for mail sent by (or claiming to be sent by) aliverson.com, but I want those reports to come to dmarcreports@wombatmail.com, I need to create a DNS record, a TXT record of aliverson.com._report._dmarc.wombatmail.com that contains "v=DMARC1;".
This leads to two very important questions:
First, what? Are you sure that this has to be done? I'm a DIY'er, and I've set up a DMARC record for my 30+ domains, and it's all going to one address at one of the domains, and I seem to be getting reports.
If you look closely, you'll see that you're mostly only getting reports from Google, Godaddy (secureserver.net) and a few other (mostly smaller) platforms. You're not getting reports from Microsoft, Yahoo, or a lot of other big mailbox providers or security services. That's because support for this external domain verification is a bit imperfect. As DMARC.org suggests, a few providers may have decided to skip the verification check, perhaps in the name of helping to speed up DMARC adoption.
But, many providers DO respect the verification check, so if you want to receive DMARC reports reliably for your domain, at a mailbox not in your domain, you'll need to set that DNS record up for the receiving domain.
Which leads to the second question. What? Are you sure that has to be done? None of the DMARC providers (Valimail, EasyDMARC, Proofpoint, Red Sift, etc.) told me that this had to be set up when I started using their DMARC monitoring service.
That's because they're the ones that need to set it up; not you. And if you're a DMARC provider, you can simply put a wildcard DNS record so that you tell the world that you'll happily accept DMARC reports via email for any email sending domain in the world. If I wanted to open this up for Wombatmail, I'd publish a wildcard DNS TXT record so that any query for "(anything)._report._dmarc.wombatmail.com" resulted in a "v=DMARC1;" response.
Since the DMARC providers really only need to set this up once, and it's on the RECEIVING end of DMARC reporting (so clients of DMARC providers don't really have to think about it), you don't see them talking about it too much. Which means that a hobbyist or DIYer might not notice this requirement.
And now you know.
Comments
Post a Comment
Comments policy: Al is always right. Kidding, mostly. Be polite, please and thank you.