Corporate DNS security: SPF, DKIM and DMARC

Why does DNS decide who can send as you?

Email was built without a check on the sender. Anyone can type your domain into the From line of a message. What stops that message from being trusted is a small set of records you publish in DNS, which receiving mail servers look up before they decide where the message goes.

Four records do the work: SPF, DKIM, DMARC and, underneath them, DNSSEC. None of them is new, but together they decide whether a fake invoice from your domain lands in a customer's inbox or is refused.

What does SPF do?

Sender Policy Framework lets a domain owner "explicitly authorize the hosts that are allowed to use their domain names".^[1] In practice it is one TXT record listing the mail servers and services that send on your behalf: your email platform, your marketing tool, your CRM, your billing system.

SPF has two common failure points. The first is the lookup limit: evaluators "MUST limit the total number" of DNS-querying terms to 10, and exceeding it returns a permanent error.^[1] Each "include" for a new tool adds to that count, so long SPF records break quietly. The second is that SPF checks the envelope sender, not the address people see, and forwarding or mailing lists can change that envelope. That is why SPF alone is not enough.

What does DKIM add?

DomainKeys Identified Mail adds a cryptographic signature to each message. The receiver validates it by "querying the Signer's domain directly to retrieve the appropriate public key".^[2] If the signed headers or body change in transit, the check fails.

Keys live under "selectors", which allow several public keys per domain at once.^[2] That makes it possible to give each sending service its own key and to replace keys without downtime. Our guide to DKIM key rotation covers how to schedule and automate that.

How does DMARC tie it together?

DMARC links SPF and DKIM to the domain in the visible From address and lets you publish a policy for mail that fails. Since May 2026 it is defined in RFC 9989, which "obsoletes RFCs 7489 and 9091".^[3] Aggregate and failure reporting now sit in separate companion documents, RFC 9990 and RFC 9991.^[3]

Three ideas matter most:

• Alignment. A message passes only if SPF or DKIM passes for a domain that matches the From domain. Relaxed alignment accepts the same organizational domain; strict alignment requires the domains to be identical.^[3]
• Policy. The p tag takes three values. With none, the owner "offers no expression of preference"; quarantine marks failing mail as suspicious; reject says failures are "a clear indication that the use of the domain name is not valid".^[3]
• Testing. RFC 9989 removes the old pct tag and uses a t tag for testing, which applies a policy one level below the one you publish.^[3]

Do mailbox providers require these records?

For bulk mail, yes. Google asks every sender to personal Gmail accounts to set up SPF or DKIM, and senders of more than 5,000 messages a day must also set up DMARC, align the From domain with SPF or DKIM, and support one-click unsubscribe for marketing mail.^[5] Google adds that the DMARC policy "can be set to none".^[5] Yahoo asks bulk senders to implement both SPF and DKIM and to publish a valid DMARC policy "with at least p=none".^[6]

So the provider rules set a floor, not a finish line. A domain at p=none passes them and can still be spoofed. For comparison, CISA's Binding Operational Directive 18-01 directed US federal agencies to set a DMARC policy of reject for all second-level domains within one year of its issue.^[7]

How do you move DMARC to reject safely?

Treat it as a project with a sender inventory at its center:

1. Publish p=none with a reporting address. Read the aggregate reports for a few weeks to see every service sending as your domain.
2. Fix each legitimate sender. Give each one aligned DKIM, add it to SPF where needed, and retire tools nobody owns.
3. Cover the domains that send nothing. Parked and unused domains can be spoofed too; give them a reject policy and an SPF record that authorizes no senders.
4. Move to quarantine, then reject. Watch reports at each step and keep a named owner for any new tool that wants to send mail.

The timing depends on how many services send as you, so we do not put a fixed number of weeks on it.

What does DNSSEC protect?

DNSSEC signs DNS data so resolvers can check it. RFC 4033 says the extensions provide "origin authentication and integrity protection for DNS data", and that by design DNSSEC "does not provide confidentiality".^[4] It protects the answers, including your SPF and DMARC records, from being forged in transit to a validating resolver.

It does not protect the account where those records are managed. If someone takes over your registrar or DNS host login, they can change records and sign them. That is the gap registrar and registry locks close; see DNS and registry locking.

What else belongs in a DNS review?

Email records are one part of a wider check of the domain:

• Dangling records. Subdomains that point to cloud resources you no longer hold can be claimed by others. Our guide to subdomain takeover covers this.
• Lookalike domains. DMARC protects domains you own, not the misspellings someone else registers. See typosquatting protection.
• Account access. Multi-factor authentication and a short list of people who can change DNS at the registrar and DNS host.

If a spoofing campaign is already under way, incident response and takedowns are work for a specialist firm or counsel you contract with. Our domain security service covers the records, inventory and renewal hygiene as part of our digital asset security work.