I dont know why, when I test my domain via mxtoolbox this week I got result DMARC policy is not enabled.
This is not happened before, everything is ok and I never do any changes in my DNS server.
I checked my DNS record and there is no issue, my DMARC policy set to quarantine.
_dmarc.mydomain.com. IN TXT "v=DMARC1; p=quarantine; pct=100; ruf=mailto:admin#mydomain.com; rua=mailto:admin#mydomain.com; sp=none; adkim=s; aspf=s"
How to solve this problem?
Thanks.
Maybe it refers to your subdomain policy (sp). With your current DMARC record, I could simply send (i.e. spoof) emails from subdomain.mydomain.com instead of mydomain.com. Remove sp=none; so that subdomains inherit the policy of your organizational domain.
Related
Everything has been working good untill today, when we had an issue with our SSL certificate when it expired and we changed it for another.
Since that happened, we can properly send emails but not receive them, unless they are emails from our own domain.
The installed SSL is not a Wildcard SSL.
We have not added the subdomain "mail.domain.com" on the Plesk domains list.
We assigned the non Wildcard SSL to work also on email on the Plesk domain settings.
We have no information regarding the non-receiving emails on the Plesk logs.
If i go to the following SMTP tester: https://www.wormly.com/test-smtp-server and send an email checking that it has to be an SMTP email, then that email is received correctly even if it comes from a different domain.
By the other side, if i do not check the SMTP email checkbox, the email is never received
Our DNS records are the following:
domain.com. TXT v=spf1 +a +mx -all
smtp.domain.com. A SERVER.IP
pop.domain.com. A SERVER.IP
pop3.domain.com. A SERVER.IP
imap.domain.com. A SERVER.IP
domain.com. MX(1) mail.domain.com
What can be going wrong?
It has been apparently been fixed after changing the MX record from "mail.domain.com" to "domain.com".
These DNS records have been working for a year since our last update, and the only thing that has changed is the SSL certificate. Im not really sure how this has been affected, maybe the previous SSL certificate was a Wildcard one, while this wasnt, and that made the email not receive properly.
Not really sure about this theory though, but it seems to work.
I use Mailgun for the outgoing emails of my customers and Cloudflare to manage DNS.
The problem is that my customers want to send emails using GMail as well, but I don't want them to know which service I am using.
Therefore, In case in the future I change the service, I don't want to contact all customers asking to change the parameters again.
Here is what I use:
So I decided to use DNS for this: I created for each domain a new CNAME (smtp.mydomain.com) which points to smtp.eu.mailgun.org:
Everything worked fine for few months by now, but from yesterday emails sent from GMail bounce back with this error: "TLS Negotiation failed, the certificate doesn't match the host".
I tried using other ports also, but still the same result.
If in GMail I use smtp.eu.mailgun.org instead of smtp.mydomain.com everything works fine again, so I guess the problem is in the DNS/Cloudflare configuration...
This is the report of the DNS Check of smtp.mydomain.com that I get from MXToolbox:
Any idea on how to fix this?
Thank you!
SOLUTION:
As of April 2020, Google started enforcing TLS when sending email.
In the Gmail settings under Accounts and Imports, Edit your Send mail as Email settings.
Change your outgoing servername (SMTP Server) to smtp.hostprovider.com (mine was smtp.dreamhost.com). If you are using your website name, (mail.example.com), this will continue to fail.
I also updated the port number from 587 to Port 465
Hope this helps.
I am using mailgun as my mail provider for my domain. My domain is hosted through namecheap. I want to set up an email redirect like admin#mydomain.com to go to my personal email address. I can not do this through namecheap because I have a mail provider set up. Here is what I see in the main domain configuration page on namecheap:
I set up a matching route in mailgun however, this only works for the mailgun subdomain. So I can create a redirect for admin#mg.mydomain.com which works, but not admin#mydomain.com. No errors or bounces for admin#mydomain.com it just doesn't work.
Any ideas how to make this work? I have a ticket pending with mailgun, so I will report the solution here for others once its resolved.
I resolved this with the settings below. The Host Records were:
...and the MX records are:
Then in Mailgun > Receiving, I created a route that looks like this:
We are an E-mail service provider and properly configured SPF, DKIM and DMARC to authenticate all emails. we have dedicated IP addresses too.
We are allowing our clients to send emails through our servers.
The following setup has been done on the client side.
Our SPF record has been included in Client's DNS record (SPF), so that we are authorized to send emails on their behalf.
As far as DKIM is concerned, we are signing the emails and signing domain is our domain.
My question is:
What should I do, In order to sign email on behalf of the client?
How do, I implement the whole process?
I have checked SMTP2GO and found out they are asking the client to add a cname record to their DNS as follows:
Host Name:
selector._domainkey.yourdomain.com
Value:
dkim.smtp2go.net.
We would like to do the same. what should be done on our DNS records in order to achieve this?
Another option is adding a TXT record to client DNS
Host Name:
selector._domainkey.yourdomain.com
value:
k=rsa p= 'public key'
We would like to do the same. what should be done on our DNS records in order to achieve this?
Thanks in Advance!
Cheers,
Sundar.
We have a client with a website hosted on AWS and he is using Google apps to send notification emails. These emails are marked as spam/junk.
We have set an SPF record as per Google's documentation. Clicking on view messege source I found SPF:softfail. From what I understand, setting up reverse DNS/PTR record can also help, but we have 2 production instances behind an ELB and we're not sure how to set that up as it doesn't have a public IP.
This is how our Route53 setup looks:
example.com A ALIAS ***.elb.amazonaws.com.
example.com MX 1 ASPMX.L.GOOGLE.COM.
example.com TXT "v=spf1 include:_spf.google.com ~all"
mail.example.com CNAME ghs.googlehosted.com
Apparently, the client was sending all of his emails through local smtp without using Google Apps. I've added his IP to the SPF record temporarily until he moves the emails over to go through google. We have also set a DKIM record.
PTR records and ELBs had nothing to do with it.