Whether you need to send a few hundred emails or a few million, we’re ready to help you deliver your message. Are you ready to get started?
If you have ever configured a domain at Coresender, you have probably come across our message to Cloudflare users, asking them to set the Proxy status to "DNS only" for records they add. The same applies to all DDoS/privacy protection services such as Akamai, Incapsula, Sucuri, etc. If you use any of them, read on.
When configuring Coresender's CNAME records in Cloudflare (or similar proxying services), always disable the "Proxied" mode and go with the simplest "DNS only".
In the old days, when DDoS protection services did not exist, your DNS server would only have one goal: to resolve a domain name to the IP address, so the client could connect to a service (e.g., website) you provide. The principle behind the simplest DDoS attack would be to generate high-enough traffic to deplete all resources of your server, rendering your website unavailable to regular users.
Services such as Cloudflare work as a shield. They take all the impact on themselves and allow only legitimate traffic to reach your server. When you add a host to your domain in Cloudflare, it replaces your IP with its own to protect you. The same happens when you add an alias (or CNAME) so that your host points to some other host by name. Unfortunately, in some cases, this method breaks recursive DNS queries. Let's find out how.
Let's take one of our DKIM records as an example. We instruct you to create the following entry in your DNS server:
When the receiving SMTP server wants to verify your DKIM signature, it first needs to obtain a public key. It does it by querying a DNS TXT record this way:
$ host -t txt cs1._domainkey.example.com
cs1._domainkey.example.com is an alias for cs1.domainkey.coresender.net.
cs1.domainkey.coresender.net descriptive text "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0Mi1ZbalFRcpxsXtoK7zbN76nPr4NFWTXYgnuj8HMRKLiheg8AKegChOttXmHWqOFEiIM7+a6b7Xsq5rAgLQ+eWb3rqq4153WoXq226mpTLLMVb5jjt1xqktlyUaVYq4AvOiOe2Xc1g8MV8UK/2ghSUqDSWXWBuKo03EAkWEFYOp0vCQxg2erusZnL2A6u+v4" "P2Si2dMNVsq6wtwImB80KN/VmTpGldl2f4L3mIM83ItiYDnAlO7+uc4IOsUMl+o4h/+LDsVwdhmiSCscKX8ktjlaKHWy1qeMO7QG+ic/DF5WdrUytARpGKIRt/fYrngOTreQcNu5dYY7NPG5kF+6wIDAQAB"
and since cs1._domainkey.example.com
is a CNAME, the DNS can reach out to cs1.domainkey.coresender.net
and request its TXT record, obtaining a key in return. It's called recursive querying.
If you add your DNS CNAME record using a "Proxied" mode, what Cloudflare really does is it creates an A record instead and hides your original CNAME target. So when you ask a DNS for such record, it replies with something like this:
$ host cs1._domainkey.example.com
cs1._domainkey.example.com has address 104.24.111.210
cs1._domainkey.example.com has address 104.24.110.210
cs1._domainkey.example.com has address 172.67.170.80
cs1._domainkey.example.com has IPv6 address 2606:4700:3034::6818:6fd2
cs1._domainkey.example.com has IPv6 address 2606:4700:3036::ac43:aa50
cs1._domainkey.example.com has IPv6 address 2606:4700:3031::6818:6ed2
As you can see, there's no indication that cs1._domainkey.example.com
is actually a CNAME. And unfortunately, it means that DNS can't recursively query a CNAME target for the TXT record. So in this example, when the receiving SMTP server tries to look for a public DKIM key, this will happen:
$ host -t txt cs1._domainkey.example.com
cs1._domainkey.example.com has no TXT record
DKIM key will not be found, and the check will fail. The good news is that Coresender will protect you from making this mistake by declining to verify your domain settings if the "Proxied" mode was used.
Yes, it is. Since you are just pointing some of your hostnames to the external service provider (like Coresender), you're not exposing any part of your infrastructure. You're not putting any privacy at risk. The world will know you're using Coresender anyway, so this should not be any concern either.