DNS - DKIM TXT result in error? - dns

I have been experiencing some trouble when using cPanel and DKIM keys at my DNS provider.
The problem (From their opinion) was that my DKIM key inside the TXT file made all other DNS records stop working when the DKIM key expired (after 7 days)
My question is:
Is this true-> Will an expired TXT DKIM record make my A, Cname and MX records stop working ?

No. That makes absolutely no sense at all. The content in a TXT record cannot possibly affect any other resource record. At least not in DNS, I cannot say anything about whatever strangeness the provider may have implemented in their own system.

Related

How can I point my domain from Godaddy to another web server without using # and losing email services?

I have access to a Godaddy account where the company has all their domains. One of those I need to point to another web server running Apache. The person that used to work here before me solved this pointing to the new server IP using the record:
A # the.ip.addr.ess 1 hour
and in the webserver end I get it with Apache and as far as the webserver goes, it runs flawlessly. I even have some subdomains using the same A record structure.
But...now I have two issues. First, I lost email reception. I can send via smtp and webmail but anything sent to my domain gets bounced back after 24 hours, even if sent to an alias or forwarder.
The second issue is that I need to verify the domain with Firebase and even thou I created the TXT record, it cannot be found by Google. I'm sure it's because of the same reason.
What can I do? I understand a little about DNS and records, but not enough for this. I just want all html traffic to reach my webserver as it is now and keep the emails and other domain services working as they were.
As contacting Godaddy support, they said it is not their purview as it is external. I think they just don't know. Go figure.
Are you using GoDaddys NameServers? If not and these are pointing elsewhere no matter what DNS records you set in GoDaddy won't be picked up during DNS lookips. This may explain why the TXT record verification is failing. However if this was true changing the A record wouldn'd disrupt DNS.
# just means the root domain so no subdomain/prefix, mydomain.com.
www is a common subdomain used so you could have an A record which like:
A www the.ip.addr.ess 1 hour
so www.mydomain.com would resolve to the.ip.addr.ess
MX records are used to direct emails to your mail server. Make sure this is pointing to the mail server. If it's pointing at your A record then updating the A record will disrupt this.
Set the MX record to point to the.ip.addr.ess rather then mydomain.com, or an A/CNAME record other then your root domain (which you are updating)
Other considerations may need to be taken, if you have an SPF record (TXT record) this may also need updating, depending on it's current value.
I finally found what I had to do. I needed an A record named 'mail' pointing to the original Godaddy server IP address.
A mail my.ip.add.ress. 1 hour
Thank´s for all the help.

Doubts about SPF record missing

I'm trying to add SPF records on my DNS zone. The SPF records are from mailjet (spf.mailjet.com), the domain is brazilian (.com.br hosted on uolhost) and my server is on DigitalOcean. When i try to add the TXT record, mailjet says "Your SPF record is missing".
I added this TXT (suggested by mailjet) on my DNS zone (at uolhost):
v=spf1 include:spf.mailjet.com ?all
But i have some questions about it (i'm really a beginner on this subjects).
The TXT should be on digital ocean, uolhost or both?
I really have to wait 48h?
The TXT above is correct?
Sorry for my bad english. I really appreciate any help.
First you should make it -all instead of ~all, the whole reason to set up authentication is to prevent people from spoofing your domain.
v=spf1 include:spf.mailjet.com -all
Where you're SPF record goes, depends on where the SPF record is being sent from, or the 5321.From Which is the "Return-Path", etc. Not the "FROM" line.
So view the headers of your email and look for the return path email address.
Whichever domain that is, is the place in DNS you will add the TXT record above, if you don't know how to see the headers of your email just send an email to mailtest#unlocktheinbox.com it will send you your header information on top of the report, just look for "Return-path". There is also an SPF Section, when you have it set up right it will show "PASSED".
BTW, if you have multiple SPF records (one of an email service provider and the other of mailjet); then instead of adding 2 TXT records, please use a single TXT record with a combination like below:
v=spf1 include:spf.mailjet.com include:spf.protection.outlook.com ~all
(since we use outlook email service, hence outlook in our case).

Google Cloud DNS & ProtonMail DKIM records

ProtonMail has rolled out support for receiving mail from custom domains, and I'm adding the necessary records to my project's Cloud DNS settings from within Google Cloud Platform. I added the MX and SPF records, and they checked out, but when I try to add the DKIM records I get a "Not Properly Set" error from ProtonMail's end. I followed the same format, putting protonmail._domainkey in the hostname, adding it as a TXT record, and including v=DKIM1; k=rsa; p=... in the record value.
ProtonMail technical support wasn't very helpful, replying with a "we don't see your TXT DKIM records, please ensure they are being properly propagated" response.
I can provide the other records I've set if anyone thinks it would be helpful.
Your DKIM record may need to be wrapped in quotes.
Try:
"v=DKIM1; k=rsa; p=..."
I had the exact same issue with DKIM on protonmail. Protonmail support suggested verifying the records via mxtoolbox.com. Since I could see that my TXT record wasn't showing up as I had written it, I emailed my domain provider for help. They added quotes to the TXT record, and then I could see the record properly on mxtoolbox.com.
Are you able to retrieve your DKIM record with this tool:
http://mxtoolbox.com/dkim.aspx
Enclosing your DKIM TXT entry in quotes may solve the issue. Many DKIM libraries have issues with spaces after the semicolons.
Did you attempt to use a key larger than 1024 bits?
If you provide the domain name that your are having an issue with, I will look at the DKIM information in the zone.

Gmail SPF records from server don't apply correctly

I'm running my domain on two servers (primary server and blog server) and I manage my mails with Google Apps for business (MX records correctly set).
However, I want to send emails from both servers (primary is a send-only EXIM4 server) and they should not be marked as spam. Therefore I want to set a correct SPF record, but Google keeps telling me that spf=neutral instead of spf=positive.
My current SPF records looks as follows:
v=spf1 ip4:<blog IP> ip4:<primary IP> include:_spf.google.com ~all
What do I have to change in order to get my mails through spam detection?
Thanks
Figured it out.
The record was okay, but I had to create a TXT record with the content above. Not a SPF record, which is weird. But so is technology.

How to use SRV (or any other) record do redirect a domain?

So:
i have a domain example.com
i have a microsoft azure project at example.cloudapp.net
i used a CNAME record to make www.example.com work with example.cloudapp.net.
now the problem:
the domain without the www. part does not work!
i don't have any options to redirect it in my domain provider account. I can only set: A, MX, CNAME, TXT, AAAA or SRV records.
The CNAME and A don't work. I've try CNAME but it dosen't work for example.com. For the A record you have to provide a IP, which is also not very smart for a azure account.
The only record i can imagine to accomplish this is the SRV, but i don't know how to use it properly. Any help or suggestions?
with best regards,
cris
This is more DNS managing question then Azure question.
You can certainly use A record with your Azure deployment. It was at least 6 months back in time (if not longer) when MSFT announced the persistence feature of a VIP (Virtual IP Address). Which means that your deployment (once deployed!) will have 1, non-changing public IP address as long as you do not delete the deployment! That VIP will be persisted across upgrades.
You can find out more about managing deployments here. And here there is a full section "Persitence of VIP", where it is explained how your VIP address is persisted.
So, just A record to your VIP address, and it will work as long as you do not delete the deployment. Who needs to access a deleted deployment anyway. Just try to not forget to update the A record when you create new deployment in case you deleted old one.
UPDATE **
I just made couple of checks and I think it's worth trying following SVR record:
_http._tcp 21600 IN SRV 10 10 80 yourservice.cloudapp.net.
Note the dot at the end, it is essential and important!
(I will try it myself as soon as I can - it is definitelly worth exploring this)
UPDATE 2 **
Interesting observation. I made one such record for one of mine domains. However the result is plain redirect to http://yourservice.cloudapp.net/ and not staing on http://mydomain.com/. So the result is - SRV cannot be used. Just use A record to point to your VIP.

Resources