Why DNS Security is Critical
Your domain's DNS records are the foundation of your online presence. They tell the world where your website lives, where to deliver your email, and who is authorized to issue security certificates for your domain. When these records are poorly configured, attackers can exploit them in several devastating ways.
Email spoofing is one of the most common threats. Without proper DNS security, anyone in the world can send emails that appear to come from your domain. Your customers could receive phishing emails that look exactly like they are from you - requesting payment, asking them to click malicious links, or harvesting their credentials. This damages your reputation and exposes your customers to fraud.
DNS hijacking is another serious threat. An attacker who can modify your DNS records can redirect your visitors to a fake version of your website - capturing their logins and payment details before passing them on to the real site. The visitor may never notice anything is wrong.
The four pillars of DNS security - SPF, DKIM, DMARC, and DNSSEC - each address different aspects of these threats. Implementing all four gives you comprehensive protection.
SPF (Sender Policy Framework)
SPF is a DNS record that specifies which mail servers are authorized to send email on behalf of your domain. When a receiving mail server gets an email claiming to be from your domain, it checks your SPF record to see if the sending server is on the approved list. If it is not, the email can be marked as suspicious or rejected outright.
Setting up SPF means adding a TXT record to your domain's DNS. The record starts with "v=spf1" followed by a list of authorized sending sources, and ends with a policy for what to do with unauthorized senders. Using "-all" means reject any email from a server not listed. Using "~all" means treat it as suspicious (soft fail). Never use "+all" which would allow anyone to send as your domain.
If you use Google Workspace for email, your SPF record should include Google's sending servers. If you use Microsoft 365, you include Microsoft's servers. If you use both plus a third-party service like Mailchimp for newsletters, you need to include all three. Keep in mind that SPF has a limit of 10 DNS lookups - if you use many services, this can become a challenge and you may need to optimize your record.
DKIM (DomainKeys Identified Mail)
DKIM takes email authentication a step further by adding a cryptographic digital signature to every outgoing email from your domain. Here is how it works: your email server signs each message using a private key that only you control. A corresponding public key is published in your DNS records. When a receiving mail server gets your email, it retrieves the public key from DNS and uses it to verify the signature. If the signature matches, the email is authentic and has not been tampered with. If it does not match, the email is likely a forgery.
DKIM is typically configured through your email provider's admin console - Google Workspace, Microsoft 365, and most email hosting providers have DKIM setup wizards. Once you enable DKIM in your provider's settings, they give you a DNS record to add. The record looks cryptic (it contains a long public key string) but you just need to add it to your DNS as directed.
The key benefit of DKIM beyond authentication is that it also protects email content integrity. A message signed with DKIM cannot be altered after signing without the signature becoming invalid. This means that even if someone intercepts your email in transit, they cannot modify its contents without detection.
DMARC (Domain-based Message Authentication, Reporting & Conformance)
DMARC is the policy layer that sits on top of SPF and DKIM. It answers the question: "What should receiving mail servers do when an email claims to be from my domain but fails SPF or DKIM checks?" And equally importantly: "Can you please send me reports about what is happening with email sent from my domain?"
There are three DMARC policies. The first, "p=none," is monitoring-only mode. It does not block or flag any emails but instructs receiving servers to send you reports about what they see. This is where you should start - you may discover that legitimate senders (like your CRM, newsletter platform, or e-commerce system) are sending emails on your behalf that are not covered by your SPF or DKIM setup. Starting with monitoring gives you 2-4 weeks to identify and fix these before moving to enforcement.
The second policy, "p=quarantine," tells receiving servers to send emails that fail DMARC checks to the spam folder rather than the inbox. This is a good intermediate step - it reduces the impact of spoofed emails without risking that legitimate emails get rejected.
The third policy, "p=reject," is the gold standard. Emails that fail DMARC checks are rejected outright - they never reach the recipient's inbox. This is the most effective protection against email spoofing from your domain.
DMARC reports are XML files sent to the email address you specify in the record. They can be difficult to read in raw form, but free and paid tools exist to parse and visualize them in a human-readable way. These reports show you every IP address that is sending email claiming to be from your domain, whether those emails pass SPF and DKIM, and how many there are.
DNSSEC (DNS Security Extensions)
DNSSEC addresses a different attack vector: the DNS system itself. When your browser looks up the IP address of a website, it sends queries to DNS servers. Normally there is no way to verify that the answer you receive is legitimate - an attacker positioned between you and the DNS server could return a fake IP address pointing to a malicious site. This is called DNS cache poisoning.
DNSSEC solves this by adding cryptographic signatures to DNS records. When a DNS resolver returns an answer, it includes a signature that can be verified using a chain of trust anchored at the root DNS zone. If the signature does not match, the resolver knows the answer has been tampered with and rejects it.
DNSSEC is enabled at your domain registrar - the company where you registered your domain. Most major registrars support DNSSEC. The process typically involves going to your domain settings, finding the DNSSEC option, and enabling it. The registrar handles the cryptographic key generation. After enabling, allow 24-72 hours for propagation and verify it is working using an online DNSSEC testing tool.
CAA (Certification Authority Authorization)
CAA records are a simple but powerful protection against unauthorized SSL certificate issuance. Without CAA records, any of the hundreds of Certificate Authorities in the world could potentially issue a certificate for your domain - either through an error or as a result of being compromised. A fake certificate issued for your domain could be used in a man-in-the-middle attack against your visitors.
CAA records let you specify exactly which CAs are authorized to issue certificates for your domain. For example, if you use Let's Encrypt for all your certificates, you can add a CAA record that only permits Let's Encrypt to issue certificates. Any other CA that receives a certificate signing request for your domain will see this record and refuse.
You can also include an iodef record that specifies an email address where CAs should send notifications if they receive an unauthorized certificate request for your domain - giving you early warning of potential attacks.
Frequently Asked Questions
Do I need all four: SPF, DKIM, DMARC, and DNSSEC? Yes, because they protect against different threats. SPF and DKIM authenticate your email. DMARC enforces that authentication and provides visibility through reporting. DNSSEC protects the integrity of your DNS records themselves. Each layer adds protection the others do not provide.
My DMARC is set to p=none. Am I protected? No. p=none is monitoring mode only. It does not block or flag any spoofed emails. It just tells receiving servers to send you reports. You need p=quarantine or p=reject to actually prevent spoofed emails from reaching inboxes.
Can I have multiple SPF records? No - only one SPF TXT record is allowed per domain. If you have multiple, most email servers will fail the SPF check entirely. Combine all your sending sources into a single record.
How long does DNS propagation take? DNS changes typically propagate within 1-48 hours globally. The exact time depends on your DNS record's Time To Live (TTL) setting. If you set a low TTL before making changes, propagation can happen within minutes.
What is a dangling DNS record and why is it dangerous? A dangling record is one that points to a resource that no longer exists - for example, a subdomain pointing to a cloud service you have cancelled. Attackers can register or take over that orphaned resource and use it to serve malicious content that appears to come from your legitimate domain.
Originally published at fortifynet.com/blog/dns-security-configuration. I'm the founder of FortifyNet, a website security scanner; this guide comes from our blog, and every DNS check described here can be done by hand with dig or nslookup, no tool required.
Top comments (0)