SPF, DKIM and DMARC all set but dmarc-reports keep saying the opposite

[mmaciel]

hello

recently i started receiving these reports once a day from google and in some cases it says the check for dkim and spf fail, even tho dmarcian, dkimvalidator and any other such tools says everything is set up correctly

<?xml version="1.0" encoding="UTF-8" ?>
<feedback>
  <report_metadata>
    <org_name>google.com</org_name>
    <email>[email protected]</email>
    <extra_contact_info>https://support.google.com/a/answer/2466580</extra_contact_info>
    <report_id>6023624817557691617</report_id>
    <date_range>
      <begin>1634774400</begin>
      <end>1634860799</end>
    </date_range>
  </report_metadata>
  <policy_published>
    <domain>mydomain.com</domain>
    <adkim>r</adkim>
    <aspf>r</aspf>
    <p>none</p>
    <sp>none</sp>
    <pct>100</pct>
  </policy_published>
  <record>
    <row>
      <source_ip>208.109.80.58</source_ip>
      <count>1</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>fail</dkim>
        <spf>pass</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>mydomain.com</header_from>
    </identifiers>
    <auth_results>
      <spf>
        <domain>mydomain.com</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>
  <record>
    <row>
      <source_ip>208.109.80.53</source_ip>
      <count>1</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>fail</dkim>
        <spf>pass</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>mydomain.com</header_from>
    </identifiers>
    <auth_results>
      <spf>
        <domain>mydomain.com</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>
  <record>
    <row>
      <source_ip>208.109.80.52</source_ip>
      <count>2</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>fail</dkim>
        <spf>pass</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>mydomain.com</header_from>
    </identifiers>
    <auth_results>
      <spf>
        <domain>mydomain.com</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>
  <record>
    <row>
      <source_ip>209.85.220.41</source_ip>
      <count>1</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>fail</dkim>
        <spf>fail</spf>
        <reason>
          <type>local_policy</type>
          <comment>arc=pass</comment>
        </reason>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>mydomain.com</header_from>
    </identifiers>
    <auth_results>
      <spf>
        <domain>hashtagtreinamentos.com</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>
  <record>
    <row>
      <source_ip>208.109.80.1</source_ip>
      <count>1</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>fail</dkim>
        <spf>pass</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>mydomain.com</header_from>
    </identifiers>
    <auth_results>
      <spf>
        <domain>mydomain.com</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>
  <record>
    <row>
      <source_ip>208.109.80.47</source_ip>
      <count>3</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>fail</dkim>
        <spf>pass</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>mydomain.com</header_from>
    </identifiers>
    <auth_results>
      <spf>
        <domain>mydomain.com</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>
  <record>
    <row>
      <source_ip>208.109.80.60</source_ip>
      <count>1</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>fail</dkim>
        <spf>pass</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>mydomain.com</header_from>
    </identifiers>
    <auth_results>
      <spf>
        <domain>mydomain.com</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>
</feedback>

also i don't know any of these ips, they are definitely not from my server, and the same thing happen with another domain we have

is someone sending emails using our domain name? how can we fix this? oh and even tho this is happening, we are NOT having any problems with email deliverability, at least not as far as i know (no one complained so far)

 

[cPRex]

Hey there! It's interesting that the IPs are not from your server, as that is likely the most important clue. Typically this is a service you have to sign up for, according to what I've found on Google:

How to disable Google DMARC emails? - Gmail Community

If you don't have those records in place in your DNS, you may want to reach out to Google directly as it seems someone is trying to send fake messages with your address, based on the details I have available at this time.

 

[mmaciel]

Hey there! It's interesting that the IPs are not from your server, as that is likely the most important clue. Typically this is a service you have to sign up for, according to what I've found on Google:

How to disable Google DMARC emails? - Gmail Community

If you don't have those records in place in your DNS, you may want to reach out to Google directly as it seems someone is trying to send fake messages with your address, based on the details I have available at this time.

Hello Rex, thanks for the reply

yes, indeed we only started receiving these reports after i added an email address to the rua configuration inside the dmarc, but my confusion is not on how to stop them (indeed i could simply remove the email address and that would be it) but why i'm receiving these reports with these weird ips as the source and failed dkim and spf

sorry, my english is not very good, i wasn't very clear in the first post

 

[cPRex]

Your English is great, and I understood the first post well!

I think it's just someone else trying to use your address to send spam, so you may want to reach out to Google directly to let them know.

 

[mmaciel]

ha, good to know

alright then, i'll do that, thanks @cPRex

 

[mmaciel]

hey @cPRex , sorry to double post, but i have another doubt now

it turns out it's not only google who's issuing these reports, as i just received one from a different domain, saying this:

DMARC Failure Report for ourdomain.com ([email protected], ip=208.109.80.47)

This is an email abuse report for an email message received from IP 208.109.80.47 on Fri, 22 Oct 2021 13:00:16 -0300.

The message below did not meet the sending domain's DMARC policy.

For more information about this format please see http://tools.ietf.org/html/rfc6591 .

weird thing is, i checked under whm's Mail Delivery Reports and i can see that indeed we had an email from "[email protected]" sent to the reporting domain 2 minutes before we received this failure report, except i still don't know that IP... if you look that IP up you can see it's from godaddy, and indeed our server a vps from godaddy, but like a said, that's not our server ip and neither is the sender ip from the Delivery Event Details

sorry, i guess it's even more confusing now, but hopefully you'll be able to understand

edit: i found these two threads from stackoverflow which are very similar to my problem, but still can't seem to solve it

DMARC Failure only for linkedin

I just setup our domain a couple weeks ago to use SPF and DMARC, but no DKIM atm. But every now an then I receive an DMARC Failure report from linkedin: This is an email abuse report for an email

stackoverflow.com

Email did not match DMARC policy, while SPF seems to match

I have a DMARC policy set for a domain like so, to combat email spoofing: v=DMARC1;p=quarantine;rua=mailto:[email protected];pct=100;ruf=mailto:[email protected];fo=0:d:s;aspf=r;adkim=r; Today I receiv...

stackoverflow.com

 

[cPRex]

I believe at this point it would be best to create a ticket with our team so we can check this directly on the affected server. Can you do that and then post the ticket number here so I can follow along?

 

[mmaciel]

Alright... in fact, shortly before reviving this thread i decided to open a ticket with godaddy, seeing how we pay for managed support for our server, and these weird ips appear to be from them, so im waiting for their reply... actually they just replied while i was writing this

this is the answer i got from them

it is a normal system thing anyway because the mail goes out from our server to a relay server that has a different IP than the server IP, the only way to change this is for you to define your own relay server but this would be done by your programmer and is out of our scope of support

as usual, they weren't very helpful, specially considering some of these IPs are not from godaddy, like this one 209.85.220.41, which appears to be from google? unless they use some servers from google as well

do you think i still should open a ticket with you guys or its more or less solved?

 

[cPRex]

That is completely up to you - if it's solved to your satisfaction, then there's no reason to poke us. If you are using the GoDaddy relay server, that answer would be correct.

If you did want to explore other email options besides their relay system, we have more details on that here, although this would be a paid service from a third-party provider:

https://support.cpanel.net/hc/en-us/articles/360052412573-How-to-configure-a-third-party-smarthost

 

[mmaciel]

i see... tbh i didn't even know there was a relay server in use, but my main concern is if these reports mean our mails are not being delivered, because if that's the case, and the problem lies within the relay server, it seems it would be up to godaddy to solve this, as i don't have access to this relay server? but they say its normal and there's no problem

 

[cPRex]

It's correct that you would not have access to their relay server. You are likely sending through that since they block direct access to the outside world through port 25.

If you want more control you'd either need to setup an alternative mail relay or find a different hosting provider that does not have this restriction in place.

 

[mmaciel]

i see, then i will keep talking with them to see if we can come up with a solution

thank you very much for clarifying everything @cPRex

 

[cPRex]

You're very welcome!

 

[mtindor]

i see, then i will keep talking with them to see if we can come up with a solution

thank you very much for clarifying everything @cPRex

Because GoDaddy forces customer email out through other servers, you have to have more in your SPF record to account for the additional IPs that might be relaying your email (legitimately) out of the GoDaddy network. Here are just some:

secureserver.net. 57 IN TXT "v=spf1 ip4:97.74.135.0/24 ip4:72.167.238.0/24 ip4:72.167.234.0/24 ip4:72.167.218.0/24 ip4:68.178.252.0/24 ip4:68.178.213.0/24 ip4:216.69.139.0/24 ip4:208.109.80.0/24 ip4:188.121.52.0/23 ip4:188.121.43.0/24 include:spf1.secureserver.net -all"

That's just an example of some of the IP space _your_ outbound emails may be relayed through, legitimately. Notice the bold one, which includes the IPs you showed as being in the DMARC reports.

So if you crosscheck the IPs in your DMARC reports with the ones above (forget about the Outlook stuff), and you add those ipv4 subnets to _your_ txt record, you will no longer get those failures. Yep, it's a pain in the neck - -AND GoDaddy _should_ have a customer "include:" for their customers to use that already includes all of the possible Ips. But they likely dont.

It would be tedious to keep up with this method, but like I said -- if you the majority of your DMARC failure reports are referencing IPs in the 208.109.80.0/24 IP block (which are some of GoDaddy's outbound relays), then add that to your SPF record.

Mike

 

[mmaciel]

thanks @mtindor , i'll try that and see how it goes, appreciate

 

[sparek-3]

This is part of the problem with SPF. In order for SPF to really work, everybody has to know exactly what IP addresses are sending legitimate messages from their domain name.

(In this particular instance is this the fault of the domain owner or GoDaddy? If GoDaddy is going to force you to use their outbound servers to send out mail, then GoDaddy should publish an SPF record or statement outlining what domain owners on GoDaddy should set their SPF record to. Perhaps that statement exists but GoDaddy doesn't advertise it well.)

That's a tall, tall task to ask for non-technical people and even some technical people.

So because too few people actually know and understand what IP addresses are sending messages from their domain name, then receiving servers can't treat SPF fails as strictly as they should.

Instead of:

"This message came from an IP not recognized in the domain's SPF record, let's discard it or flag it as spam"

You get:

"This message came from an IP not recognized in the domain's SPF record... but the owner the domain name might not know what they are actually doing in their SPF setup, so we'll treat this message as a normal message"

(regardless of what the all operator is set to, because again you can't trust domain owners to really know and understand what they are doing)

This begs the question of what's the real point of SPF? You have to have it set, but it's usefulness is mostly meaningless.

Instead of actually launching an education campaign (or domain owners listening to/heeding an education campaign) about SPF and DKIM. The minds that be thought it was a great idea to add something new - DMARC - so a domain owner can define how well they know and trust their SPF and DKIM settings. BRILLIANT!

Pretty soon there will be a new something so users can define how well they understand and know what they set their DMARC record to.

 

[cPRex]

@sparek-3 - agree 100%. They just keep tacking things on to old protocols that it wasn't really designed to handle.

 

[mmaciel]

@sparek-3 very thoughtful post and i agree, kinda messed up, and i'd like to believe there's a statement or article from godaddy out there explaining all this, but i couldn't find it

also, let me ask a silly question: regarding what @mtindor said, would that also fix the failed dkim check?

 

[psytanium]

I'm having the same delivery problem with Godaddy, every few months. I want to ask if we can we setup 2 relays ? Like primary and alternative.
Can someone recommend a third-party smarthost ?

 

[sparek-3]

DKIM is a public/private key combination. Just like TLS certificates. Private keys are used to encrypt data, public keys are used to decrypt that data.

Now, I'm not going to pretend to know exactly how DKIM works, but the general gist of it is:

On the server you are sending out mail through - it will have a private key. The mail MTA handling mail will use this key along with certain headers in the message and encrypt this information. And then include that encrypted part in the headers of the message.

When the recipient server gets the message, it find this encrypted message and then using the public key that is stored in your domain's DNS record, decrypt the data and make sure the information aligns.

So for DKIM to work - the server you are sending your outgoing messages through has to have the private key that corresponds with the public key that is in your domain's DNS record. The outgoing server also has to know to encrypt the particular header information and include that in the message.

When you setup DKIM in cPanel's control panel it generates a public/private key pair. It adds the public key to the DNS record for your domain name. It stores the private key in a directory such that when Exim sees an outgoing message from your domain name it encrypts the necessary headers with that private key and sends the message on. Now when recipient servers get your message (if they are configured to handle DKIM lookups ... for the most part this is done in SpamAssassin or other spam entities because again, nobody can be trusted to have their DKIM keys setup correctly) it will take that encrypted part, use the public key stored in your domain's DNS, decrypt that part and compare it to the defined headers in the message. This way the receiving server knows that the message came from a server that has the associated private key for the domain's DKIM.

This means that in order for DKIM to work:

1) All servers you are sending messages out from will have to have the corresponding private key associated with the public key in your DNS. Now, I don't know how something like GoDaddy works with distributed mail servers. If all mail is initially sent out from their users to a single server and then relayed out from there, then that one single server would be the server that is signing (encrypting) the message. Otherwise, all servers that GoDaddy (or whatever entity) is sending out mail from would need to have that private key to sign outgoing messages.

If you are sending out message through a third party mail server that doesn't have your DKIM private key, then your outgoing messages won't be DKIM signed. Your DKIM will effectively fail.

2) Your DNS will have to reflect the correct public key that is associated with the private key used to encrypt (or sign) these messages. For cPanel that means, if you set up DKIM in your control panel, but use your domain registrar's nameservers, then the rest of the world is not going to see the public key that cPanel created in the public/private key creation. You would have to manually enter that public key into the DNS record that your domain registrar's nameservers are using.

For most people, if they are using the nameservers that their web hosting provider gave them (assuming the web hosting company knows what they are doing) then DNS changes made in your cPanel will be reflected correctly to the outside world. But if you don't use those nameservers or if the outside world otherwise is unaware of your DKIM public key, then your messages may be signed by a DKIM private key, but the outside world is not going to have any way of decrypting that information and your DKIM will effectively fail.


I would fancy a guess that most cPanel based hosting providers have a server and maybe a DNS cluster or maybe they host DNS on the same server. If you are using such a provider and you set up DKIM in your cPanel and if you use that same server to send out mail - then your messages will get signed by the appropriate DKIM private key. And when recipients receive your message they'll be able to look up the appropriate DKIM public key to decrypt the necessary information to yield a DKIM success.

But there's also a lot of web hosting companies out there that don't know what they're doing. There's a lot of individuals out there that want to do things their way and not follow the instructions as laid out by their hosting company. And there's a lot of people that just don't know any better and that's how these things like DKIM and SPF can fail.