DNS, SPF, DKIM, and DMARC

DNS: The Foundation

DNS — Domain Name System — translates human-readable names (rsystems.nyc) into IP addresses that computers use to communicate. When you type a URL into a browser, your computer asks a DNS resolver for the IP address of that domain. The resolver queries a hierarchy of servers and returns the answer.

The Hierarchy

DNS is a hierarchy of authority, separated by periods. The root domain is at the top (empty, not interacted with directly). Below it are Top Level Domains (TLDs): .com, .org, .net, .nyc, .io. Below that are Second Level Domains (SLDs) — the domain you register. google.com is an SLD under .com. mail.google.com is a subdomain of google.com.

Your domain's DNS records are stored on authoritative nameservers controlled by your DNS provider. These records are the source of truth for anyone asking questions about your domain.

Key Record Types

• A: Maps a hostname to an IPv4 address
• AAAA: Maps a hostname to an IPv6 address
• CNAME: An alias pointing one hostname to another
• MX: Specifies which mail servers accept email for your domain
• TXT: Text data — used for verification, SPF, DKIM, and DMARC
• NS: Identifies the authoritative nameservers for your domain

TTL and Propagation

Every DNS record has a TTL — Time to Live — the number of seconds that resolvers should cache the answer before checking again. A TTL of 3600 means cached for one hour. Lower TTLs mean faster propagation of changes but more load on nameservers. Before a planned DNS migration, lower your TTLs 24–48 hours in advance. Restore them after.

SPF: The Authorized Senders List

SPF (Sender Policy Framework) is a TXT record that specifies which mail servers are authorized to send email claiming to be from your domain. The goal is to prevent other servers from sending email as you.

A basic SPF record:

v=spf1 include:_spf.google.com ~all

This says: email from this domain should come from servers in Google's SPF record. The ~all at the end is a soft fail — email from other sources is suspect. -all is a hard fail (reject).

The challenge: you likely have multiple legitimate email sources. Your mail server, your marketing platform, your CRM, your billing system. Each needs to be in your SPF record. SPF also has a hard limit of 10 DNS lookups in the resolution chain — many organizations unknowingly exceed this, silently breaking their SPF checks.

DKIM: The Cryptographic Signature

DKIM (DomainKeys Identified Mail) cryptographically signs outgoing email. Your mail server signs each message with a private key. The corresponding public key is published in DNS. Receiving servers verify the signature — confirming the message came from your domain and wasn't altered in transit.

DKIM survives email forwarding. SPF doesn't (forwarded email looks like it came from the forwarding server, not yours). This makes DKIM the more reliable signal.

Each service sending email on your behalf has its own DKIM key pair. You publish each public key in DNS under a selector:

google._domainkey.yourdomain.com TXT "v=DKIM1; k=rsa; p=[public key]"

DMARC: Enforcement and Reporting

DMARC (Domain-based Message Authentication, Reporting, and Conformance) ties SPF and DKIM together. It tells receiving servers what to do when email fails authentication, and sends you reports about what they observed.

A DMARC record:

v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com; pct=100

Policy levels:

• p=none: Monitor only, take no action — the starting point
• p=quarantine: Failing email goes to spam
• p=reject: Failing email is rejected outright — the goal

Getting to p=reject

Most organizations should not move directly to p=reject. The correct journey:

1. Set p=none and configure report delivery (rua) — collect aggregate reports for 2–4 weeks
2. Parse reports to identify every source sending as your domain
3. Ensure all legitimate sources have SPF records and DKIM configured
4. Test with p=quarantine; pct=10 (quarantine 10% of failing mail) to catch issues
5. Gradually increase pct, verify no legitimate mail is failing
6. Move to p=reject

The reporting data tells you who's sending email that claims to be from you — which is often surprising. Old marketing platforms, billing systems, third-party ticketing tools, forgotten SaaS products — all show up in DMARC reports.

Why It Matters

Without proper DMARC configuration:

• Your emails are more likely to land in spam
• Anyone can send phishing emails appearing to come from your domain
• Your email deliverability degrades over time

With p=reject properly implemented:

• Spoofing your domain is blocked at the receiving server
• Deliverability improves across the board
• Your domain qualifies for BIMI