What Are DNS Security and Email Authentication? DNSSEC, DoH, DoT, SPF, DKIM, DMARC and CAA Explained

What Are DNS Security and Email Authentication? A Practical Guide to DNSSEC, DoH, DoT, SPF, DKIM, DMARC and CAA

Raster preview image checked before being inserted into this Markdown file, used to illustrate DNS authoritative/recursive server software. Not SVG.¹

Raster preview image checked before being inserted into this Markdown file, used to illustrate DMARC and email authentication. Not SVG.²

Raster preview image checked before being inserted into this Markdown file, used to illustrate Internet standards testing such as DNSSEC, HTTPS and email security. Not SVG.³

Quick summary

DNS Security protects domain resolution against spoofing, hijacking, misconfiguration, information leakage and unsafe changes. Important parts include DNSSEC, secure DNS providers, registrar locks, CAA records, zone-change controls, audit logs, DNS monitoring, DoH/DoT for resolvers and safe DNS change workflows.

Email Authentication validates mail sent from your domain. The core mechanisms are SPF, DKIM and DMARC. SPF publishes which servers may send mail for a domain; DKIM signs mail with cryptographic keys; DMARC combines SPF/DKIM with alignment and policy so receivers know how to handle unauthenticated mail.

Cloudflare explains DNSSEC as adding cryptographic signatures to DNS records so resolvers can verify that records came from the authoritative name server and were not modified in transit.⁴ RFC 7208 defines SPF as a mechanism for domain owners to authorize hosts that may use their domain in email.⁵ RFC 6376 defines DKIM signatures.⁶ RFC 7489 defines DMARC.⁷

Simple version: DNS Security protects how users find your domain; Email Authentication protects whether others can impersonate email from your domain.

Why DNS and email are major attack surfaces

A domain is a foundational asset. If attackers control DNS or impersonate mail from your domain, they can:

• redirect your website to malicious IPs;
• create phishing subdomains;
• change MX records to intercept mail;
• request unwanted certificates if CAA is weak;
• impersonate CEO, support or billing mail;
• trick customers into wrong payments;
• abuse email-based verification;
• damage domain reputation;
• cause downtime through bad DNS changes;
• attack SaaS or APIs that rely on domain ownership.

A strong security posture protects both the DNS control plane and email identity.

What DNS Security is not

What Email Authentication is not

Email authentication does not guarantee inbox placement. It helps receivers verify whether mail is legitimately sent on behalf of your domain.

What is DNSSEC?

DNSSEC is a security extension to DNS. DNSSEC does not encrypt DNS queries or responses. It signs DNS data so resolvers can detect forged or modified records.

Cloudflare explains that DNSSEC adds digital signatures to DNS records; by checking signatures, resolvers can verify that a DNS record came from the authoritative name server and was not altered in transit.⁴

Important records:

How DNSSEC works

Simplified model:

Root zone
  ↓ trusted delegation
TLD zone (.com, .vn, ...)
  ↓ DS record
Domain zone (example.com)
  ↓ DNSKEY + RRSIG
Real DNS record

A validating resolver checks the chain of trust from the root down to the domain. If signatures are valid, the response is trusted. If the chain is broken, the resolver can reject the response.

DNSSEC helps against:

• DNS spoofing;
• cache poisoning;
• man-in-the-middle DNS modification;
• forged DNS responses.

DNSSEC does not stop:

• registrar account takeover;
• DNS provider compromise;
• admin misconfiguration;
• domain expiry;
• local malware changing resolvers;
• phishing with lookalike domains.

What are DoH and DoT?

DoH means DNS over HTTPS, defined in RFC 8484.⁸ DoT means DNS over TLS, defined in RFC 7858.⁹

Key point:

• DNSSEC protects data integrity and authenticity.
• DoH/DoT protect the connection between client and resolver.
• DNSSEC and DoH/DoT complement each other.

What is a CAA record?

CAA lets a domain owner specify which Certificate Authorities may issue certificates for the domain. RFC 8659 defines the DNS CAA Resource Record.¹⁰

Example:

example.com. 3600 IN CAA 0 issue "letsencrypt.org"
example.com. 3600 IN CAA 0 issuewild ";"
example.com. 3600 IN CAA 0 iodef "mailto:[email protected]"

Meaning:

• issue: CA allowed to issue normal certificates.
• issuewild: CA allowed to issue wildcard certificates.
• iodef: report address for violations.

CAA does not replace TLS certificate management, but it reduces the risk of unwanted certificate issuance.

What is SPF?

SPF allows a domain owner to publish which servers may send email for the domain. RFC 7208 describes SPF as a protocol by which Administrative Management Domains can explicitly authorize hosts allowed to use their domain names and receivers can check that authorization.⁵

Example:

example.com. TXT "v=spf1 include:_spf.google.com include:sendgrid.net -all"

Meaning:

Common mistakes:

• too many DNS lookups;
• +all;
• forgetting SaaS senders such as CRM, billing or helpdesk;
• SPF pass but DMARC fail because of alignment;
• duplicate SPF TXT records;
• leaving ~all forever.

What is DKIM?

DKIM signs email using a private key. Receivers fetch the public key from DNS and verify the signature. RFC 6376 defines DKIM signatures.⁶

DKIM record location:

selector1._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=..."

Email header:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=selector1; ...

Meaning:

Recommendations:

• enable DKIM for every legitimate sender;
• use strong keys;
• rotate keys;
• use separate selectors per provider;
• check DKIM alignment with From domain.

What is DMARC?

DMARC uses SPF/DKIM plus alignment to decide whether email is valid for the domain in the visible From header. RFC 7489 defines DMARC as a mechanism for domain owners to publish policy in DNS and request receiver reports.⁷

DMARC record:

_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:[email protected]"

Policies:

DMARC passes when:

SPF passes and SPF domain aligns with Header From
or
DKIM passes and DKIM d= domain aligns with Header From

Alignment is the part many teams miss. SPF can pass while DMARC fails if the domains do not align.

How SPF, DKIM and DMARC work together

Email arrives
  ↓
SPF: is the sending server authorized?
  ↓
DKIM: is the message signature valid?
  ↓
DMARC: does SPF/DKIM align with Header From?
  ↓
Apply policy: none / quarantine / reject
  ↓
Send aggregate reports to domain owner

A good setup usually uses both SPF and DKIM. DMARC needs at least one aligned pass.

MTA-STS and TLS-RPT

MTA-STS lets a domain publish a policy requiring receiving mail servers to use TLS, reducing downgrade and MITM risk during SMTP delivery. RFC 8461 defines SMTP MTA Strict Transport Security.¹¹

TLS-RPT lets domains receive reports about TLS failures in mail delivery. RFC 8460 defines SMTP TLS Reporting.¹²

MTA-STS DNS record:

_mta-sts.example.com. TXT "v=STSv1; id=20260605"

Policy file:

https://mta-sts.example.com/.well-known/mta-sts.txt

TLS-RPT:

_smtp._tls.example.com. TXT "v=TLSRPTv1; rua=mailto:[email protected]"

What if a domain sends no email?

Domains and subdomains that do not send mail should still publish anti-spoofing records.

Example:

example.com. TXT "v=spf1 -all"
_dmarc.example.com. TXT "v=DMARC1; p=reject; rua=mailto:[email protected]"
*._domainkey.example.com. TXT "v=DKIM1; p="

For subdomains:

_dmarc.example.com. TXT "v=DMARC1; p=reject; sp=reject"

sp=reject applies to subdomains that do not publish their own DMARC record.

DNS protection checklist

Registrar

• MFA/passkeys;
• registry lock/domain lock where available;
• auto-renewal;
• secure admin mailbox;
• limited transfer permissions;
• domain change alerts;
• expiry monitoring;
• safe recovery code storage.

DNS provider

• MFA/SSO;
• RBAC;
• audit logs;
• change review;
• zone export/backup;
• alerts for NS/MX/TXT/CAA changes;
• scoped API tokens;
• no shared API tokens.

DNS records

• DNSSEC where supported and operationally understood;
• CAA records;
• valid MX records;
• remove old records;
• reduce risky wildcards;
• check subdomain takeover;
• monitor critical records;
• document record owners.

Email authentication checklist

SPF

• one SPF TXT record per domain;
• no +all;
• stay within the 10-DNS-lookup limit;
• include all legitimate senders;
• use -all when confident;
• check DMARC alignment.

DKIM

• enable DKIM per provider;
• separate selectors per provider;
• strong keys;
• key rotation;
• verify DKIM pass;
• verify DKIM alignment.

DMARC

• start with p=none;
• collect reports for several weeks;
• identify legitimate senders;
• fix SPF/DKIM/alignment;
• move gradually through pct, quarantine and reject;
• use sp= for subdomains;
• monitor reports continuously.

MTA-STS/TLS-RPT

• verify TLS on MX;
• publish MTA-STS policy;
• enable TLS-RPT;
• monitor delivery failures;
• avoid enforce mode until tested.

30/60/90-day rollout roadmap

Days 1–30: inventory and monitoring

• Inventory domains and subdomains.
• Check registrar lock and MFA.
• Inventory DNS provider/API tokens.
• Export zone files.
• Review MX, SPF, DKIM and DMARC.
• Create DMARC p=none.
• Create DMARC report mailbox.
• Add basic CAA.
• Protect no-mail domains.
• Add alerts for critical DNS changes.

Days 31–60: fix senders and increase policy

• Identify all senders: Google Workspace, Microsoft 365, SendGrid, Mailgun, CRM, billing, helpdesk.
• Enable DKIM for every sender.
• Fix SPF includes.
• Remove old senders.
• Check DMARC alignment.
• Move to p=quarantine with low pct.
• Enable DNSSEC first on lower-risk domains.
• Test resolver validation.
• Create DNSSEC/DMARC rollback runbooks.

Days 61–90: enforce and operate

• Move primary domain to p=reject when reports are clean.
• Apply sp=reject where appropriate.
• Enable MTA-STS/TLS-RPT.
• Rotate DKIM keys on a schedule.
• Improve CAA.
• Audit DNS API tokens.
• Build DMARC dashboard.
• Check subdomain takeover regularly.
• Drill incidents: domain hijack, MX change, spoofing campaign.
• Document domain ownership.

Common mistakes

• Setting DMARC p=reject without reviewing reports.
• Forgetting SaaS senders.
• SPF records with too many DNS lookups.
• Broad include usage.
• DKIM pass but no DMARC alignment.
• No DKIM on marketing/helpdesk systems.
• Protecting only the root domain.
• No records for no-mail domains.
• No MFA on registrar.
• No auto-renewal.
• No CAA.
• DNSSEC enabled with wrong DS record.
• No monitoring for MX/TXT/NS changes.
• Collecting reports but never reading them.

Example DNS records

SPF for Google Workspace and SendGrid

example.com. TXT "v=spf1 include:_spf.google.com include:sendgrid.net -all"

DKIM selector

google._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIIBIjANBg..."

DMARC monitor

_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:[email protected]; fo=1"

DMARC reject

_dmarc.example.com. TXT "v=DMARC1; p=reject; sp=reject; rua=mailto:[email protected]"

CAA

example.com. CAA 0 issue "letsencrypt.org"
example.com. CAA 0 issuewild ";"
example.com. CAA 0 iodef "mailto:[email protected]"

MTA-STS and TLS-RPT

_mta-sts.example.com. TXT "v=STSv1; id=20260605"
_smtp._tls.example.com. TXT "v=TLSRPTv1; rua=mailto:[email protected]"

Reference tooling

FAQ

What is DNS Security?

DNS Security protects domains, DNS zones, DNS records, registrars, resolvers and DNS change workflows from spoofing, hijacking and misconfiguration.

Does DNSSEC encrypt DNS?

No. DNSSEC signs DNS data to verify integrity and origin. It does not encrypt DNS queries or responses. DoH and DoT focus on encrypted transport between client and resolver.⁴⁸⁹

How are SPF, DKIM and DMARC different?

SPF verifies whether a sending server is authorized; DKIM verifies a cryptographic message signature; DMARC checks alignment with the visible From domain and applies policy.⁵⁶⁷

Do I need all SPF, DKIM and DMARC?

Yes. Use all three. SPF or DKIM can pass DMARC if aligned, but having both SPF and DKIM improves coverage across sending flows.

Which DMARC policy should I start with?

Usually start with p=none, collect reports, fix senders and alignment, then move gradually to quarantine and reject.

Should no-mail domains publish DMARC?

Yes. Domains that send no email should publish SPF -all and DMARC p=reject to reduce spoofing.

Conclusion

DNS Security and Email Authentication are essential domain-protection layers. DNS determines where users and systems go; email authentication helps receivers decide whether mail from your domain is legitimate. A bad NS, MX, TXT, CAA, SPF, DKIM or DMARC configuration can cause downtime, phishing, spoofing or reputation damage.

A practical rollout starts with domain inventory, registrar MFA/lock, DNS monitoring, CAA records, controlled DNSSEC enablement and gradual SPF/DKIM/DMARC deployment. For email, do not jump to p=reject until legitimate senders are known and aligned. For DNS, do not enable DNSSEC without a DS/key rollover runbook. Done carefully, these controls reduce domain spoofing, DNS tampering and email phishing risk.

References

Footnotes

1. GitHub Open Graph preview image for PowerDNS/pdns. https://opengraph.githubassets.com/dns-security-guide/PowerDNS/pdns ↩

2. GitHub Open Graph preview image for trusted-domain-project/OpenDMARC. https://opengraph.githubassets.com/dns-security-guide/trusted-domain-project/OpenDMARC ↩

3. GitHub Open Graph preview image for internetstandards/Internet.nl. https://opengraph.githubassets.com/dns-security-guide/internetstandards/Internet.nl ↩

4. Cloudflare Learning Center. “How does DNSSEC work?” https://www.cloudflare.com/learning/dns/dnssec/how-dnssec-works/ ↩ ↩² ↩³

5. RFC 7208. “Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1.” https://datatracker.ietf.org/doc/html/rfc7208 ↩ ↩² ↩³

6. RFC 6376. “DomainKeys Identified Mail (DKIM) Signatures.” https://datatracker.ietf.org/doc/html/rfc6376 ↩ ↩² ↩³

7. RFC 7489. “Domain-based Message Authentication, Reporting, and Conformance (DMARC).” https://datatracker.ietf.org/doc/html/rfc7489 ↩ ↩² ↩³

8. RFC 8484. “DNS Queries over HTTPS.” https://datatracker.ietf.org/doc/html/rfc8484 ↩ ↩²

9. RFC 7858. “Specification for DNS over Transport Layer Security.” https://datatracker.ietf.org/doc/html/rfc7858 ↩ ↩²

10. RFC 8659. “DNS Certification Authority Authorization (CAA) Resource Record.” https://datatracker.ietf.org/doc/html/rfc8659 ↩

11. RFC 8461. “SMTP MTA Strict Transport Security (MTA-STS).” https://datatracker.ietf.org/doc/html/rfc8461 ↩

12. RFC 8460. “SMTP TLS Reporting.” https://datatracker.ietf.org/doc/html/rfc8460 ↩