Re: [dmarc-ietf] 3.2.6 The meaning of non-existence (Sample Data)
Using an NXDOMAIN test, I have these occurrences in the last 24 hours: - 1 nxdomain that is from a legitimate sender, - 1 that is NXDOMAIN because the ESP misspelled the client organization name, and - 1 that is a bogus NDR. So the NXDOMAIN test will identify fewer problems, but will create fewer problems also. Caveat: Consider that my email stream is modest. Internet scale multiplies everything by many orders of magnitude. Does anyone have data from a bigger message stream? Doug On Sun, Dec 19, 2021 at 6:42 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > Here are some results based on 3025 messages, involving 1253 unique > RFC5322.From domains, collected over less than 24 hours. These results > are collected AFTER excluding messages from blacklisted sources and sources > with SPF=NXDOMAIN, so a high percentage is not spam. > > I detected 52 messages, from 10 unique domains, which failed the MX/A > test. I do not test on because I do not accept mail using IPv6. > > All 10 could produce DMARC PASS based on relaxed alignment, although I > have not evaluated whether they publish a DMARC policy. I simply evaluate > SPF and DKIM based on relaxed alignment for all incoming messages. > > All 10 domains had RFC5321.MailFrom and RFC5322.From domains that were > different. > > 7 of 10 had DMARC PASS based on both SPF and DKIM: > bc.qvcemail.com > doctors-digest.com > email.nutricia-na.com > mail.foodnetwork.com > mail.medscape.org > mktg.daily-harvest.com > email3.reachmd.com > > 1 of 10 had DMARC PASS based on SPF alignment only: > mg.homedepot.com > > 2 of 10 had DMARC PASS based on DKIM only: > info.extraspace.com > update.strava.com > > 1 of 10 had an SPF record on the RFC5322.From address. > email.nutricia-na.com > > Overall, this suggests to me that ESP messages will have trouble complying > with any NP criteria, and this may force us to use a weaker one, such as > NXDOMAIN only, even though my preference is a strong one. > > Doug Foster > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] 3.2.6 The meaning of non-existence (Sample Data)
It is not infrequent. Here is some more detailed statistics: msgs domains description Msg Fail Domain Fail 3,025 1,253 All messages1.72% 0.80% 1,098 296 Allowed msgs4.74% 3.38% 581 175 ESP messages8.95% 5.71% 52 10 MX/A Failures The percentages are relative to the failure counts. "ESP messages" counts any message where the From addresses are different. So 5.7% of third-party mailings use a From address that is not found or not easily found in DNS. This is not insignificant. John, I don't know what algorithm you are proposing. Please clarify. Doug On Mon, Dec 20, 2021 at 12:10 PM Alessandro Vesely wrote: > On Mon 20/Dec/2021 12:53:12 +0100 Douglas Foster wrote: > > I am not doing any root domain lookups. If that is part of the > proposed > > algorithm, somebody needs to document it. I am simply looking for a > resource > > record matching the FROM domain name. > > > Oops, yes, you're right. Dunno why I looked up their org domain, probably > lack > of caffeine... > > Those 10 domains are non-existing under 3.2.6. Only 4 of them return > NXDOMAIN. > > One of them, mail.foodnetwork.com, has its own DMARC record with a policy > different from that of its parent domain, which can be a reason to use a > subdomain. (Curiously, it is one of those returning NXDOMAIN.) > > For the other 9, all what I can think of is some kind of > misconfiguration. I > asked a few times why would one want to use a non-existing domain for the > From: > address, but got no answers. Anyway, your numbers show that it's not a > very > frequent setup. > > > Best > Ale > -- > > > > > > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] IETF Process/Culture was Re: 3.2.6 The meaning of non-existence
It appears that Alessandro Vesely said: >On Sun 19/Dec/2021 21:42:16 +0100 Scott Kitterman wrote: >> If the domain owner has suggested that you reject mail from a sub-domain >> that has none of A, , or MX records, why would you not do that? >Then it turns out that one can also define DMARC record at some non-existing >sub domains, possibly as an alternative to using np=... Now this begins to >look puzzling. Only if you misunderstand the way the DNS works. If there is a txt record for _dmarc.foo.bar, that means the name foo.bar exists. It may not have any records, but it exists. That's the difference between a DNS NXDOMAIN response for a non-existent domain and NOERROR for one with no records. The difference is not an accident, not a mistake, and is not going to change. See for example RFC 8020. >The reason to introduce np= was to select domains that really don't exist. >Why >don't we stick to that definition? Yes indeed, why don't we, and end this pointless argument? R's John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] 3.2.6 The meaning of non-existence (Sample Data)
It appears that Alessandro Vesely said: >On Mon 20/Dec/2021 12:53:12 +0100 Douglas Foster wrote: >> I am not doing any root domain lookups. If that is part of the proposed >> algorithm, somebody needs to document it. I am simply looking for a >> resource >> record matching the FROM domain name. > > >Oops, yes, you're right. Dunno why I looked up their org domain, probably >lack >of caffeine... > >Those 10 domains are non-existing under 3.2.6. Only 4 of them return NXDOMAIN. If you prefix _domainkey to those names and do a lookup, several of them return NOERROR which suggests they have DKIM keys. For the umpteenth time, there is a DNS definition of non-existent which is the only one you get to use in the IETF. Can we stop wasting time with this fruitless argument, please? R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] 3.2.6 Rethinking the NP algorithm
Goal: block all unregistered subdomains of a parentdomain, particularly to solve the PSD problem, but ideally to solve it with a generalized design: SETUP: The domain owner or PSD creates these DNS entries at any desired DNS node: · DMARC record at _dmarc.parentdomain · type=CNAME, name="*.parentdomain", DATA=”reserved.parentdomain” · type=txt, name="reserved.parentdomain", DATA=”FromFlags v=1 scope=none” Evaluator uses this process: Receives a message with domain: mail.sub2.sub1.parentdomain Tree walk until a DMARC policy is found at _dmarc.parentdoma Navigate down one level and query: type=TXT, name=sub1.parentdomain Query result of DATA=”FromFlags v=1 scope=none” means that the domain is non-existent and should not be allowed for RFC5322.FROM addressing Effect: Any name which triggers the wildcard will be evaluated as non-existent. Because of the tree walk, the rule will affect the entire subtree. The same "FromFlags" txt record can be used without wildcards to explicitly protect any single name. Less DNS overhead than any alternative, and more precise. I wish we could but the flag on the SPF record, instead of creating a new one. Doug Foster ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] IETF Process/Culture was Re: 3.2.6 The meaning of non-existence
On Monday, December 20, 2021 12:39:15 PM EST Alessandro Vesely wrote: > On Sun 19/Dec/2021 21:42:16 +0100 Scott Kitterman wrote: > > If the domain owner has suggested that you reject mail from a sub-domain > > that has none of A, , or MX records, why would you not do that? > Are we sure that's what the domain owner meant to suggest? > > An organization can use sp= on its root domain record, or it can define a > DMARC record at some subdomains. So far so good. > > Then it turns out that one can also define DMARC record at some non-existing > sub domains, possibly as an alternative to using np=... Now this begins to > look puzzling. > > The reason to introduce np= was to select domains that really don't exist. > Why don't we stick to that definition? What definition are you wondering why we didn't stick to? Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] IETF Process/Culture was Re: 3.2.6 The meaning of non-existence
On Sun 19/Dec/2021 21:42:16 +0100 Scott Kitterman wrote: If the domain owner has suggested that you reject mail from a sub-domain that has none of A, , or MX records, why would you not do that? Are we sure that's what the domain owner meant to suggest? An organization can use sp= on its root domain record, or it can define a DMARC record at some subdomains. So far so good. Then it turns out that one can also define DMARC record at some non-existing sub domains, possibly as an alternative to using np=... Now this begins to look puzzling. The reason to introduce np= was to select domains that really don't exist. Why don't we stick to that definition? Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] 3.2.6 The meaning of non-existence (Sample Data)
On Monday, December 20, 2021 12:10:31 PM EST Alessandro Vesely wrote: > On Mon 20/Dec/2021 12:53:12 +0100 Douglas Foster wrote: > > I am not doing any root domain lookups. If that is part of the proposed > > algorithm, somebody needs to document it. I am simply looking for a > > resource record matching the FROM domain name. > > Oops, yes, you're right. Dunno why I looked up their org domain, probably > lack of caffeine... > > Those 10 domains are non-existing under 3.2.6. Only 4 of them return > NXDOMAIN. > > One of them, mail.foodnetwork.com, has its own DMARC record with a policy > different from that of its parent domain, which can be a reason to use a > subdomain. (Curiously, it is one of those returning NXDOMAIN.) > > For the other 9, all what I can think of is some kind of misconfiguration. > I asked a few times why would one want to use a non-existing domain for the > From: address, but got no answers. Anyway, your numbers show that it's not > a very frequent setup. ... for legitimate mail. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] 3.2.6 The meaning of non-existence (Sample Data)
On Mon 20/Dec/2021 12:53:12 +0100 Douglas Foster wrote: I am not doing any root domain lookups. If that is part of the proposed algorithm, somebody needs to document it. I am simply looking for a resource record matching the FROM domain name. Oops, yes, you're right. Dunno why I looked up their org domain, probably lack of caffeine... Those 10 domains are non-existing under 3.2.6. Only 4 of them return NXDOMAIN. One of them, mail.foodnetwork.com, has its own DMARC record with a policy different from that of its parent domain, which can be a reason to use a subdomain. (Curiously, it is one of those returning NXDOMAIN.) For the other 9, all what I can think of is some kind of misconfiguration. I asked a few times why would one want to use a non-existing domain for the From: address, but got no answers. Anyway, your numbers show that it's not a very frequent setup. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] IETF Process/Culture was Re: 3.2.6 The meaning of non-existence
In an organization of non-trivial size the chance that the person making the decision about what to put in DNS can reliably answer the question "used for RC5322.From addressing" is vanishingly small. They can, however, be very confident about if they have set up A//MX records. At best you are trading one kind of uncertainty for another. Scott K On Monday, December 20, 2021 7:12:34 AM EST Douglas Foster wrote: > Scott asked some questions along the lines of "since no test is perfect, > why don't we just run with the easily-understood MX/A/AAA test. I had not > responded to that part of the question previously. > > I have two major problems with the MX/A/ test: > > - If we are only testing for "Does this domain send out SMTP mail?", then > SPF must be included in the criteria. SPF speaks to what the domain sends, > while MX speaks to what the domain receives, and A/ speaks to what the > domain might receive. If we are testing for send behavior, we need to > examine the send authentication attribute. Any test which is based on > SMTP and other things should include SPF for the same reason. > > - Since we are not testing exclusively for SMTP behavior, we need to think > about how to avoid false positives, and how a domain owner changes a test > result from Fail to Pass. I have been calling this action "compliance > measures", hoping that the term was clear.For the MX/A/ test, with > or without SPF, the only way to indicate compliance is to publish false > information about SMTP configurations that do not apply to this domain. > Such false information has the potential for changing the behavior of SMTP > participants, and cannot be acceptable in a standards-track document. > > I have suggested feature-specific DNS flags, to indicate that a particular > domain does or does not participate in FROM addressing, or does not > participate in SMTP addressing. These have the advantage of being very > specific, but they depend on domain owners publishing new information. > A test which minimizes publishing new data has a better chance of being > usable, with confidence, by evaluators. So I suggested an exact-match > DMARC policy as an indicator to mean "used for RC5322.From addressing." > I am not entirely happy with that workaround, as it may have unwanted side > effects about how reporting occurs back to the domain owner. > > DF > > > > On Sun, Dec 19, 2021 at 3:42 PM Scott Kitterman > > wrote: > > If the domain owner has suggested that you reject mail from a sub-domain > > that has none of A, , or MX records, why would you not do that? Just > > as with any DMARC policy it's on the sender to ensure authorized email > > conforms to the policy. My impression is that you think that rejecting > > mail from such sub-domains is inherently risky somehow? > > > > My view is that it's substantially less risky than for more usual > > sub-domains. Note that I don't claim it's risk free. No filtering > > decision is risk free, so I don't find suggestions that it's not totally > > free of uncertainty particularly useful. > > > > My sense is that you are still searching for something that the np= tag > > was never meant to be. It might be more fruitful to try and specify what > > problem you are trying to solve and how we might go about it independent > > of > > the non-existent domain definition. Maybe you can propose a totally new > > tag that addresses the issues you are concerned about. If this new tag > > gets support from the group then we could look at if np= is still needed > > or > > if it's redundant. > > > > Scott K > > > > On December 19, 2021 7:35:30 PM UTC, Douglas Foster < > > > > dougfoster.emailstanda...@gmail.com> wrote: > > >What I said was that reception of NDRmessages is only a requirement for > > > > the > > > > >SMTP From address, so they are only required for the RFC5322.From address > > >when the two From addresses match. For msiling list messages, tbe two > > >do > > >not match. > > > > > >My topic was about the ability or inability to detect a never-valid > > > > RFC5322 > > > > >>From address. I am not engaged in any effort to change mailing lists. > > >> > > > NP=reject MUST never reject mailing list traffic. If we cannot do that, > > > > > >NP is useless. > > > > > >But we can meet that requirement, if we construct the right test. I can > > >support several different variations of the test, which differences in > > >strictness and complexity. I just cannot support the MX-A- test. > > > > > >Doug > > > > > >Doug > > > > > >On Sat, Dec 18, 2021, 12:15 PM John Levine wrote: > > >> It appears that Jeremy Harris said: > > >> >On 18/12/2021 03:47, Douglas Foster wrote: > > >> >> MX checks are a valid tool for assessing SMTP MailFrom addresses, > > > > since > > > > >> the > > >> > > >> >> sender is supposed to be ready to accept non-delivery reports and > > > > other > > > > >> >> automated messages. Of course,
Re: [dmarc-ietf] IETF Process/Culture was Re: 3.2.6 The meaning of non-existence
Scott asked some questions along the lines of "since no test is perfect, why don't we just run with the easily-understood MX/A/AAA test. I had not responded to that part of the question previously. I have two major problems with the MX/A/ test: - If we are only testing for "Does this domain send out SMTP mail?", then SPF must be included in the criteria. SPF speaks to what the domain sends, while MX speaks to what the domain receives, and A/ speaks to what the domain might receive. If we are testing for send behavior, we need to examine the send authentication attribute. Any test which is based on SMTP and other things should include SPF for the same reason. - Since we are not testing exclusively for SMTP behavior, we need to think about how to avoid false positives, and how a domain owner changes a test result from Fail to Pass. I have been calling this action "compliance measures", hoping that the term was clear.For the MX/A/ test, with or without SPF, the only way to indicate compliance is to publish false information about SMTP configurations that do not apply to this domain. Such false information has the potential for changing the behavior of SMTP participants, and cannot be acceptable in a standards-track document. I have suggested feature-specific DNS flags, to indicate that a particular domain does or does not participate in FROM addressing, or does not participate in SMTP addressing. These have the advantage of being very specific, but they depend on domain owners publishing new information. A test which minimizes publishing new data has a better chance of being usable, with confidence, by evaluators. So I suggested an exact-match DMARC policy as an indicator to mean "used for RC5322.From addressing." I am not entirely happy with that workaround, as it may have unwanted side effects about how reporting occurs back to the domain owner. DF On Sun, Dec 19, 2021 at 3:42 PM Scott Kitterman wrote: > If the domain owner has suggested that you reject mail from a sub-domain > that has none of A, , or MX records, why would you not do that? Just > as with any DMARC policy it's on the sender to ensure authorized email > conforms to the policy. My impression is that you think that rejecting > mail from such sub-domains is inherently risky somehow? > > My view is that it's substantially less risky than for more usual > sub-domains. Note that I don't claim it's risk free. No filtering > decision is risk free, so I don't find suggestions that it's not totally > free of uncertainty particularly useful. > > My sense is that you are still searching for something that the np= tag > was never meant to be. It might be more fruitful to try and specify what > problem you are trying to solve and how we might go about it independent of > the non-existent domain definition. Maybe you can propose a totally new > tag that addresses the issues you are concerned about. If this new tag > gets support from the group then we could look at if np= is still needed or > if it's redundant. > > Scott K > > On December 19, 2021 7:35:30 PM UTC, Douglas Foster < > dougfoster.emailstanda...@gmail.com> wrote: > >What I said was that reception of NDRmessages is only a requirement for > the > >SMTP From address, so they are only required for the RFC5322.From address > >when the two From addresses match. For msiling list messages, tbe two do > >not match. > > > >My topic was about the ability or inability to detect a never-valid > RFC5322 > >>From address. I am not engaged in any effort to change mailing lists. > > NP=reject MUST never reject mailing list traffic. If we cannot do that, > >NP is useless. > > > >But we can meet that requirement, if we construct the right test. I can > >support several different variations of the test, which differences in > >strictness and complexity. I just cannot support the MX-A- test. > > > >Doug > > > >Doug > > > >On Sat, Dec 18, 2021, 12:15 PM John Levine wrote: > > > >> It appears that Jeremy Harris said: > >> >On 18/12/2021 03:47, Douglas Foster wrote: > >> >> MX checks are a valid tool for assessing SMTP MailFrom addresses, > since > >> the > >> >> sender is supposed to be ready to accept non-delivery reports and > other > >> >> automated messages. Of course, this has applicability if (but only > if) > >> >> the RFC5322.From domain is the same as the RFC5321.MailFrom domain. > >> > > >> >I disagree. It is well-established practice for a mailing list manager > >> >to accept and process NDRs accepted on the 5321.mailfrom (which differs > >> >from the 5322.from). > >> > >> Jeremy is right. Mailing lists always, and I mean always, put their > >> own 5321 bounce address on the messages so they can do bounce > >> management. If you look at the mail from this list, the bounce address > >> is dmarc-boun...@ietf.org. > >> > >> I have to say I am dismayed that we are spending time dealing with such > >> utterly basic misconceptions here. > >>
Re: [dmarc-ietf] 3.2.6 The meaning of non-existence (Sample Data)
I am not doing any root domain lookups. If that is part of the proposed algorithm, somebody needs to document it. I am simply looking for a resource record matching the FROM domain name. Because I am a Windows guy, I use the deprecated NSLOOKUP. I have done minimal work in DIG. I retested one of the names and confirmed the same results: > set type=MX > info.extraspace.com Server: G3100.myfiosgateway.com Address: 192.168.1.1 *** G3100.myfiosgateway.com can't find info.extraspace.com: Non-existent domain > set type=A > info.extraspace.com Server: G3100.myfiosgateway.com Address: 192.168.1.1 *** G3100.myfiosgateway.com can't find info.extraspace.com: Non-existent domain > Doug Foster On Mon, Dec 20, 2021 at 4:44 AM Alessandro Vesely wrote: > On Mon 20/Dec/2021 00:42:27 +0100 Douglas Foster wrote: > > > > I detected 52 messages, from 10 unique domains, which failed the MX/A > test. > > [...] > > > > 7 of 10 had DMARC PASS based on both SPF and DKIM: > > bc.qvcemail.com > > doctors-digest.com > > email.nutricia-na.com > > mail.foodnetwork.com > > mail.medscape.org > > mktg.daily-harvest.com > > email3.reachmd.com > > > > 1 of 10 had DMARC PASS based on SPF alignment only: > > mg.homedepot.com > > > > 2 of 10 had DMARC PASS based on DKIM only: > > info.extraspace.com > > update.strava.com > > > What do you mean by "failed the MX/A test"? Only doctors-digest.com > seems to be non-existent under 3.2.6. > > > ale@pcale:~/tmp$ for d in $doms mg.homedepot.com info.extraspace.com > update.strava.com; do r=$(get_root_domain $d|sed -rn 's/^ Root Domain: > *(.*)$/\1/p'); echo "$d -> $r"; dig +short $r; dig +short $r mx; echo; done > bc.qvcemail.com -> qvcemail.com > 167.140.19.203 > 100 smtp2.qvc.com. > 100 smtp3.qvc.com. > > doctors-digest.com -> doctors-digest.com > > email.nutricia-na.com -> nutricia-na.com > 52.36.54.191 > 20 mail3792.nutricianorthamerica.mkt4389.com. > 5 bounce.email.nutricia-na.com. > 10 reply.email.nutricia-na.com. > > mail.foodnetwork.com -> foodnetwork.com > 204.78.50.45 > 100 foodnetwork-com.mail.protection.outlook.com. > 1 aspmx.l.google.com. > 10 alt3.aspmx.l.google.com. > 5 alt1.aspmx.l.google.com. > 5 alt2.aspmx.l.google.com. > 10 alt4.aspmx.l.google.com. > > mail.medscape.org -> medscape.org > 104.18.27.226 > 104.18.26.226 > 10 alt3.aspmx.l.google.com. > 10 reply-mx.s6.exacttarget.com. > 1 aspmx.l.google.com. > 5 alt2.aspmx.l.google.com. > 5 alt1.aspmx.l.google.com. > 10 alt4.aspmx.l.google.com. > > mktg.daily-harvest.com -> daily-harvest.com > 104.18.1.9 > 104.18.0.9 > 10 alt4.aspmx.l.google.com. > 1 aspmx.l.google.com. > 10 alt3.aspmx.l.google.com. > 5 alt1.aspmx.l.google.com. > 5 alt2.aspmx.l.google.com. > > email3.reachmd.com -> reachmd.com > 34.195.222.240 > 34.233.81.108 > 10 mx1-us1.ppe-hosted.com. > 10 mx2-us1.ppe-hosted.com. > > mg.homedepot.com -> homedepot.com > 35.201.95.83 > 20 mx0a-000e6601.pphosted.com. > 10 mxb-000e6601.gslb.pphosted.com. > 10 mxa-000e6601.gslb.pphosted.com. > 20 mx0b-000e6601.pphosted.com. > > info.extraspace.com -> extraspace.com > 13.107.246.13 > 10 mxa-00257001.gslb.pphosted.com. > 10 mxb-00257001.gslb.pphosted.com. > > update.strava.com -> strava.com > 3.227.103.50 > 44.195.56.39 > 52.0.47.160 > 3.217.33.77 > 3.237.58.53 > 34.197.5.198 > 54.209.232.157 > 52.72.119.210 > 30 alt2.aspmx.l.google.com. > 50 aspmx3.googlemail.com. > 20 alt1.aspmx.l.google.com. > 10 aspmx.l.google.com. > 40 aspmx2.googlemail.com. > > > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] 3.2.6 The meaning of non-existence (Sample Data)
On Mon 20/Dec/2021 00:42:27 +0100 Douglas Foster wrote: I detected 52 messages, from 10 unique domains, which failed the MX/A test. [...] 7 of 10 had DMARC PASS based on both SPF and DKIM: bc.qvcemail.com doctors-digest.com email.nutricia-na.com mail.foodnetwork.com mail.medscape.org mktg.daily-harvest.com email3.reachmd.com 1 of 10 had DMARC PASS based on SPF alignment only: mg.homedepot.com 2 of 10 had DMARC PASS based on DKIM only: info.extraspace.com update.strava.com What do you mean by "failed the MX/A test"? Only doctors-digest.com seems to be non-existent under 3.2.6. ale@pcale:~/tmp$ for d in $doms mg.homedepot.com info.extraspace.com update.strava.com; do r=$(get_root_domain $d|sed -rn 's/^ Root Domain: *(.*)$/\1/p'); echo "$d -> $r"; dig +short $r; dig +short $r mx; echo; done bc.qvcemail.com -> qvcemail.com 167.140.19.203 100 smtp2.qvc.com. 100 smtp3.qvc.com. doctors-digest.com -> doctors-digest.com email.nutricia-na.com -> nutricia-na.com 52.36.54.191 20 mail3792.nutricianorthamerica.mkt4389.com. 5 bounce.email.nutricia-na.com. 10 reply.email.nutricia-na.com. mail.foodnetwork.com -> foodnetwork.com 204.78.50.45 100 foodnetwork-com.mail.protection.outlook.com. 1 aspmx.l.google.com. 10 alt3.aspmx.l.google.com. 5 alt1.aspmx.l.google.com. 5 alt2.aspmx.l.google.com. 10 alt4.aspmx.l.google.com. mail.medscape.org -> medscape.org 104.18.27.226 104.18.26.226 10 alt3.aspmx.l.google.com. 10 reply-mx.s6.exacttarget.com. 1 aspmx.l.google.com. 5 alt2.aspmx.l.google.com. 5 alt1.aspmx.l.google.com. 10 alt4.aspmx.l.google.com. mktg.daily-harvest.com -> daily-harvest.com 104.18.1.9 104.18.0.9 10 alt4.aspmx.l.google.com. 1 aspmx.l.google.com. 10 alt3.aspmx.l.google.com. 5 alt1.aspmx.l.google.com. 5 alt2.aspmx.l.google.com. email3.reachmd.com -> reachmd.com 34.195.222.240 34.233.81.108 10 mx1-us1.ppe-hosted.com. 10 mx2-us1.ppe-hosted.com. mg.homedepot.com -> homedepot.com 35.201.95.83 20 mx0a-000e6601.pphosted.com. 10 mxb-000e6601.gslb.pphosted.com. 10 mxa-000e6601.gslb.pphosted.com. 20 mx0b-000e6601.pphosted.com. info.extraspace.com -> extraspace.com 13.107.246.13 10 mxa-00257001.gslb.pphosted.com. 10 mxb-00257001.gslb.pphosted.com. update.strava.com -> strava.com 3.227.103.50 44.195.56.39 52.0.47.160 3.217.33.77 3.237.58.53 34.197.5.198 54.209.232.157 52.72.119.210 30 alt2.aspmx.l.google.com. 50 aspmx3.googlemail.com. 20 alt1.aspmx.l.google.com. 10 aspmx.l.google.com. 40 aspmx2.googlemail.com. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
