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"
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 184.108.40.206 cs1._domainkey.example.com has address 220.127.116.11 cs1._domainkey.example.com has address 18.104.22.168 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.