No idea about Upwork, but I had about the same situation about some other company sending me mail I cared about for a reason and their mail was not getting delivered to me because their DMARC check was failing.
They said "thanks, we'll look into it" and kept sending broken mail for years.
My guess is if you're a big enough player Google learns to ignore your broken DMARC config or somebody knows somebody on the inside who can add an exception. And then your mail gets delivered to @gmail.com just fine and that means it's working and wtf is this guy complaining about.
> The SPF policy for upwork.com specifies that mail.clinchtalent.com and all IP addresses that are listed by spf.mandrillapp.com are allowed to send email on behalf of upwork.com
No, it also lists Valimail as being able to make decisions on SPF. That's what the "include:%{i}._ip.%{h}._ehlo.%{d}._spf.vali.email" part is.
> Additionally, the DMARC policy for upwork.com is set to "strict" - which means that if the SPF check fails then all RFC-compliant SMTP servers should reject the message.
There is no “strict” policy. DMARC policy can be one of the following p= {none, quarantine, reject}.
The receiver decides if it wants to apply published DMARC policy for unauthenticated mail. What problem are you seeing exactly?
Remember both SPF and DKIM are used for policy evaluation.
After some investigation, it looks like only mailgun.org is declared in ValiMail but not mailgun.net, e.g. a DNS query for 198.244.56.66._ip.c66.c5341538.usw1.send.mailgun.net._ehlo.upwork.com._spf.vali.email
returns "v=spf1 include:mailgun.org -all"
No idea about Upwork, but I had about the same situation about some other company sending me mail I cared about for a reason and their mail was not getting delivered to me because their DMARC check was failing.
They said "thanks, we'll look into it" and kept sending broken mail for years.
My guess is if you're a big enough player Google learns to ignore your broken DMARC config or somebody knows somebody on the inside who can add an exception. And then your mail gets delivered to @gmail.com just fine and that means it's working and wtf is this guy complaining about.
> The SPF policy for upwork.com specifies that mail.clinchtalent.com and all IP addresses that are listed by spf.mandrillapp.com are allowed to send email on behalf of upwork.com
No, it also lists Valimail as being able to make decisions on SPF. That's what the "include:%{i}._ip.%{h}._ehlo.%{d}._spf.vali.email" part is.
https://support.valimail.com/en/articles/8466461-valimail-sp...
According to https://tools.sendmarc.com/spf-policy-test/upwork.com/198.24... v5142.v530814cf.use4.send.mailgun.net or c66.c5341538.usw1.send.mailgun.net are not allowed to send emails on behalf of upwork.com You can also check through https://spf.access.nu/ or https://dmarcian.com/spf-survey/ that IPs belonging to MailGun are not allowed to send emails for upwork.com
Those tools aren't using the macro which means they are not following the RFC, stop using crappy online tools and wasting people's time.
You can read about it here: https://datatracker.ietf.org/doc/html/rfc7208#section-7
dig +short TXT "159.112.254.142._ip.v5142.v530814cf.use4.send.mailgun.net._ehlo.upwork.com._spf.vali.email"
"v=spf1 include:mailgun.org -all"
--
dig +short TXT mailgun.org
"v=spf1 include:_spf.mailgun.org include:_spf.eu.mailgun.org -all"
--
dig +short TXT _spf.mailgun.org
"v=spf1 include:_spf1.mailgun.org include:_spf2.mailgun.org ~all"
--
dig +short TXT _spf2.mailgun.org
"v=spf1 ip4:104.130.122.0/23 ip4:146.20.112.0/26 ip4:161.38.192.0/20 ip4:143.55.224.0/21 ip4:143.55.232.0/22 ip4:159.112.240.0/20 ip4:198.244.48.0/20 ip4:204.220.168.0/21 ip4:204.220.176.0/20 ~all"
And there's 159.112.240.0/20.
--
The SPF lookup limit is 10 which means that this way of doing it is totally valid.
And here's where you can read about the lookup limit: https://datatracker.ietf.org/doc/html/rfc7208#section-4.6.4
Got it. Thanks and apologies.
> Additionally, the DMARC policy for upwork.com is set to "strict" - which means that if the SPF check fails then all RFC-compliant SMTP servers should reject the message.
There is no “strict” policy. DMARC policy can be one of the following p= {none, quarantine, reject}.
The receiver decides if it wants to apply published DMARC policy for unauthenticated mail. What problem are you seeing exactly?
Remember both SPF and DKIM are used for policy evaluation.
After some investigation, it looks like only mailgun.org is declared in ValiMail but not mailgun.net, e.g. a DNS query for 198.244.56.66._ip.c66.c5341538.usw1.send.mailgun.net._ehlo.upwork.com._spf.vali.email returns "v=spf1 include:mailgun.org -all"