Email Security Starts in DNS

Updated 2026-09-12. An educational guide for email administrators and security teams.

Why email security begins with DNS

Email has no built-in proof of origin. The From address on a message is text that any sender can type, which is why phishing and domain spoofing work. The fix the industry settled on lives in DNS: the owner of a domain publishes public records that describe which servers may send for it and how its messages are signed, and every receiving server checks those records for every message. A content filter can only guess whether a message is malicious. DNS authentication answers a simpler question with certainty: did this come from somewhere the domain owner authorised?

This is also why these records are public. SPF, DKIM and DMARC only function because any server on the internet can read them. Publishing them exposes nothing sensitive, but it does mean anyone can see when they are missing or misconfigured, and attackers look for exactly that.

The DNS records that matter for email

Every record below is a normal DNS record on your domain. Most are TXT records at specific names.

SPF: who may send for your domain

An SPF record is a single TXT record that lists sending sources: IP ranges, your own MX or A records, and include: references to vendors such as Google Workspace, Microsoft 365 or a marketing platform. It ends with a qualifier for everything else: -all (fail) or ~all (soft fail). Receivers check the connecting server against the list.

Three rules keep SPF working:

1. One record only. Two SPF TXT records on the same name make the result a PermError, which receivers treat as no SPF at all.
2. Ten lookups, total. Every include, a, mx, redirect and exists counts, and so does everything nested inside your vendors' includes. Exceeding ten is a PermError. This is the most common SPF failure on real domains, and it usually arrives quietly when a vendor changes its own record.
3. Finish with -all. ~all was meant for testing. +all authorises the whole internet and is worse than no record.

SPF checks the envelope sender (the return path), not the From header a person sees, and it breaks on forwarding because the forwarding server is not in your list. Both gaps are why DKIM and DMARC exist.

DKIM: proof the message is yours and unchanged

DKIM signs each outgoing message with a private key held by your sending system. The matching public key is published in DNS under a selector name, so a receiver can fetch it and verify the signature. A valid signature proves the message was sent by a system holding your key and that the signed headers and body were not modified afterwards. Unlike SPF, DKIM survives forwarding.

1. One selector per sending service. Your mail platform, your marketing tool, your ticketing system and your invoicing platform each need their own key and DNS record. Missing one means that service's mail fails DKIM.
2. Use 2048-bit keys and rotate them on a schedule. Vendors that use a CNAME to their own key rotate for you; keys you host yourself do not rotate themselves.
3. Sign with your own domain (the d= tag), not the vendor's, or the signature cannot align for DMARC.

DMARC: policy, alignment and reporting

DMARC connects SPF and DKIM to the From address that people actually see. A message passes DMARC when SPF or DKIM passes and the domain that passed aligns with the From domain. The record then states what receivers should do with failures and where to send reports.

1. p=none monitors. Mail is delivered as usual and you receive aggregate reports (rua=) listing every source that sends as your domain, passing or failing. Start here, and read the reports.
2. p=quarantine asks receivers to treat failures as suspicious, typically the spam folder. Use pct= to phase it in.
3. p=reject asks receivers to refuse failures outright. This is the policy that stops spoofing, and the one BIMI and most compliance frameworks expect.

Alignment can be relaxed (organisational domain matches) or strict (exact match) for SPF and DKIM separately. The sp= tag sets the policy for subdomains, which otherwise inherit the parent policy, and ruf= requests forensic reports, which few receivers still send. Moving from none to reject without reading the reports is how legitimate mail gets blocked; moving from none to nothing is how spoofing continues.

TLS in transit: STARTTLS, MTA-STS, TLS-RPT and DANE

Authentication proves who sent a message. Transport security protects it between servers. Mail servers negotiate TLS with STARTTLS, but the default is opportunistic: if the offer is stripped or the certificate is wrong, the mail still goes through in plain text. Two mechanisms remove that fallback.

1. MTA-STS publishes a small TXT record and a policy file over HTTPS declaring that your inbound servers require TLS with valid certificates. Senders that support it refuse to deliver over an insecure connection once the policy is in enforce mode. Start in testing mode.
2. TLS-RPT gives senders an address for daily reports on connections that could not meet your policy. Publish it alongside MTA-STS or you will never learn about failures.
3. DANE achieves the same guarantee with a TLSA record validated by DNSSEC instead of a certificate authority. It requires DNSSEC on your zone and is widely used by receivers in some regions; many domains run MTA-STS and DANE together.

End-to-end encryption of message content (S/MIME, PGP) is a separate layer applied by senders and recipients, not by DNS, and is out of scope for this guide.

BIMI, MX and PTR: the supporting records

BIMI displays your logo next to authenticated mail in supporting inboxes. It is a reward for finishing the work above: receivers only show the logo when DMARC is at quarantine or reject, the logo is a compliant SVG, and, for most inboxes, a Verified Mark Certificate proves you own the mark.

MX records must point at the servers that actually accept your mail, with sensible priorities, and nothing else. A stale MX to a decommissioned host, or one pointing at a CNAME, causes bounces and gives attackers a hostname to claim. Subdomains that should never receive mail can publish a null MX (0 .).

PTR records live on the sending IP's reverse zone, usually controlled by the hosting provider. Receivers expect every sending IP to have a PTR that resolves back to the same address and matches the name the server announces in HELO. Missing or mismatched reverse DNS is one of the first reasons mail from a new server lands in spam.

Non-sending and parked domains

Every domain you own can be spoofed, including the ones that never send mail: brand variants, old campaign domains, acquisitions and typo defensives. Lock each one with three records: an SPF record of v=spf1 -all, a DMARC record of v=DMARC1; p=reject; with a reporting address, and a null MX. Receivers can then reject anything claiming to be from those domains. This is the cheapest, most overlooked step in domain security, and it scales with how many domains you hold, which is why it is worth checking in bulk rather than one domain at a time.

DNS configuration and optimisation for mail

1. Inventory every sender first. Marketing, support desk, billing, HR, CRM, monitoring, and the printers. Each one needs SPF coverage and its own DKIM selector. DMARC aggregate reports will show you the ones you forgot.
2. Keep SPF under the lookup limit by design. Remove vendors you no longer use, prefer ip4/ip6 entries for servers you control, avoid mx and ptr mechanisms, and move high-volume vendors to their own subdomains with their own SPF. Automated "flattening" replaces includes with IP lists that go stale the moment a vendor changes; if you use it, monitor it.
3. Use a subdomain per sending purpose (for example mail., news., alerts.). Each gets its own SPF, DKIM and DMARC, a reputation of its own, and a smaller blast radius when a vendor is compromised.
4. Set TTLs deliberately. Short TTLs (300 to 3600 seconds) on records you are changing let you roll back fast; longer TTLs on stable records reduce lookups. Lower a TTL a day before a planned change, not during it.
5. No CNAME at the zone apex and no CNAME as an MX target. Both violate DNS rules and break mail in ways that look intermittent.
6. Consistency across subdomains. A strict parent policy with an open subdomain is an open door. Publish sp= in the parent DMARC record or explicit records on each subdomain.
7. Watch for change. Vendors update their include records and rotate keys; registrars and DNS hosts migrate zones; colleagues add records for a new tool. A record that was correct in January can fail in March without anyone editing it. Track DNS changes across all your domains and review reports on a schedule.

A rollout order that does not break delivery

1. List every service that sends as your domain, including subdomains.
2. Publish or repair SPF with every source covered and fewer than ten lookups, ending in -all.
3. Enable DKIM on every source, each with its own selector, signing with your domain.
4. Publish DMARC at p=none with an aggregate reporting address. Read the reports for two to four weeks and fix every legitimate source that fails.
5. Move to p=quarantine, phased with pct=, then to p=reject once reports are clean.
6. Add MTA-STS in testing mode with TLS-RPT, review the reports, then enforce. Add DANE if your zone has DNSSEC.
7. Lock down every non-sending domain with -all, p=reject and a null MX.
8. Add BIMI once DMARC enforcement is in place.
9. Confirm PTR records for every sending IP and MX records for every receiving host.
10. Put the whole set under change monitoring and a quarterly review.

Common mistakes we see in real DNS

1. Two SPF records on the same domain, usually after adding a vendor by hand.
2. SPF over ten lookups because of nested vendor includes.
3. DMARC left at p=none for years with no one reading the reports.
4. DKIM keys that were never rotated, or 1024-bit keys still in service.
5. A vendor signing with its own domain, so DKIM passes but never aligns.
6. Subdomains with no policy under a parent that says reject.
7. Parked and brand domains with no records at all.
8. MX pointing at hosts that no longer exist, or at a CNAME.
9. Sending servers with no reverse DNS.
10. MTA-STS policy files that expired or moved, silently disabling the policy.

Verifying your records with DNSai tools

DNSai is a DNS utility, not an email gateway or filtering service; the tools below read public DNS and show you what receivers will see. Use them to check the records in this guide, compare a domain against its vendors, and investigate a delivery problem. Every result is drawn from the same public DNS a receiving server queries.

Frequently asked questions

What is email authentication?

Email authentication is a set of DNS-published policies and signatures (SPF, DKIM and DMARC) that let a receiving mail server check whether a message really came from a server your domain authorises, and whether its content was altered in transit. Without it, anyone can put your domain in the From address.

Do I need all three of SPF, DKIM and DMARC?

Yes. SPF authorises sending servers, DKIM signs the message, and DMARC ties both to the visible From domain and tells receivers what to do when checks fail. Each covers a gap the others leave open, and DMARC only works once SPF or DKIM is in place.

What does a DMARC policy of p=none actually do?

Nothing to the mail. p=none is monitoring mode: receivers deliver as usual but send you aggregate reports showing which sources pass and fail. It is the right starting point, but it stops no spoofing until you move to p=quarantine or p=reject.

Why does my SPF record fail with too many DNS lookups?

SPF allows at most ten DNS lookups per evaluation, counting every include, a, mx, redirect and exists mechanism, including the ones nested inside your vendors' records. Exceeding ten returns a PermError and receivers treat the record as invalid. Remove unused includes, avoid mx and ptr where you can, and split sending across subdomains.

What is the difference between TLS, MTA-STS and DANE?

TLS encrypts a mail connection between servers, but by default it is opportunistic and can be downgraded. MTA-STS is a DNS record plus an HTTPS policy that tells sending servers your domain requires TLS and valid certificates. DANE does the same job with a TLSA record protected by DNSSEC. TLS-RPT adds reports about failed connections.

Should non-sending and parked domains have email records?

Yes. A domain that never sends mail should publish v=spf1 -all, a DMARC record with p=reject, and a null MX record (0 .). Otherwise it is an easy target for spoofing because receivers have nothing to check against.

Is DNSai an email security provider?

No. DNSai is not an email gateway and does not offer an email filtration service. DNSai is a Cyber Security DNS Utility: DNS lookup and analysis tools that show how a domain's mail-related records are configured, so you can verify and troubleshoot the settings in this guide.

How often should I review these records?

Whenever you add or remove a mail vendor, at least quarterly for SPF include sprawl and DKIM key age, and continuously if you can. Records change silently when vendors update their includes, and a DNS change tracker will tell you before deliverability does.

Related Resources

1. SPF, DKIM & DMARC Guide — the protocol details and record syntax
2. SPF too many DNS lookups (PermError) — diagnosing and fixing the ten-lookup limit
3. Moving DMARC from p=none to p=reject — a phased rollout walkthrough
4. How to find a DKIM selector
5. Identify an email gateway from MX records
6. Reverse DNS and PTR records
7. What your SPF record reveals about your vendors
8. DMARCbis and DKIM2 — where the standards are heading
9. Domain Name System — DNS fundamentals
10. All DNS Tools