Skip to main content

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 google.com noreply-dmarc-support@google.com https://support.google.com/a/answer/2466580 6023624817557691617 1634774400 1634860799 mydomain.com r r

none

none 100 208.109.80.58 1 none fail pass mydomain.com mydomain.com pass 208.109.80.53 1 none fail pass mydomain.com mydomain.com pass 208.109.80.52 2 none fail pass mydomain.com mydomain.com pass 209.85.220.41 1 none fail fail local_policy arc=pass mydomain.com hashtagtreinamentos.com pass 208.109.80.1 1 none fail pass mydomain.com mydomain.com pass 208.109.80.47 3 none fail pass mydomain.com mydomain.com pass 208.109.80.60 1 none fail pass mydomain.com mydomain.com pass
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)

Comments

21 comments

Date Votes
  • cPRex Jurassic Moderator
    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:
    0
  • 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:
    0
  • cPRex Jurassic Moderator
    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.
    0
  • mmaciel
    ha, good to know alright then, i'll do that, thanks @cPRex
    0
  • 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 (mail-from=john@ourdomain.com, 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 "john@ourdomain.com" 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
    0
  • cPRex Jurassic Moderator
    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?
    0
  • 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 [quote]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?
    0
  • cPRex Jurassic Moderator
    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:
    0
  • 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
    0
  • cPRex Jurassic Moderator
    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.
    0
  • 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
    0
  • cPRex Jurassic Moderator
    You're very welcome!
    0
  • 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
    0
  • mmaciel
    thanks @mtindor, i'll try that and see how it goes, appreciate
    0
  • 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.
    0
  • cPRex Jurassic Moderator
    @sparek-3 - agree 100%. They just keep tacking things on to old protocols that it wasn't really designed to handle.
    0
  • 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?
    0
  • 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 ?
    0
  • 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.
    0
  • mmaciel
    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.

    thanks for the very detailed answer" indeed this is our current set up, except apparently when server send out mail, they go thru a relay server and this server is messing up the dkim check but like I said in another post, we have been using this server from godaddy for over two years now and never had any problems regarding email deliveryability, it"s just that our dmarc didn"t have any email address configured under the rua setting so we weren"t receiving these reports, but apparently everything works like usual and the only way to actually "fix" this would be setting up my own relay server thanks again
    0
  • cPanelAnthony
    I'm glad to see @sparek-3 was able to offer you such a robust response! Don't hesitate to reach out if you have further issues.
    0

Please sign in to leave a comment.

Didn't find what you were looking for?

New post