SPF, DKIM and DMARC explained: authenticating your business email

Why email authentication matters now

Anyone can type your domain into the “From” line of an email. The mail system was built without a way to prove who really sent a message, so three DNS-based standards were added on top: SPF, DKIM and DMARC. Together they let receiving mail servers check whether a message claiming to be from your domain was actually sent by you, and tell them what to do when it was not.

For years these were “good practice”. Since 2024 they have become conditions for reaching the inbox at the largest mailbox providers, especially if you send newsletters, invoices or notifications in volume. This guide explains what each standard does, shows example records, covers the most common configuration mistake, and sets out a safe path to an enforcing DMARC policy.

SPF: which servers may send for your domain

Sender Policy Framework is defined in RFC 7208. You publish a TXT record on your domain listing the servers and services allowed to send mail using that domain in the SMTP envelope (the “MAIL FROM” or return-path address). A receiving server looks up the record and checks the connecting IP address against it.

A typical record looks like this:

example.com.  TXT  "v=spf1 ip4:192.0.2.10 include:_spf.mailprovider.example include:_spf.newsletter.example -all"

ip4: and ip6: authorise specific addresses or ranges.
include: pulls in another domain’s SPF policy, which is how you authorise a hosted email or marketing service.
The final all mechanism catches everything else. Its qualifier sets the result: - means fail, ~ means softfail, ? means neutral and + means pass, according to RFC 7208.

Two rules from the RFC catch people out. A domain must not publish more than one SPF record, so adding a second v=spf1 record for a new service breaks the first. And the ptr mechanism should not be published at all; it is slow and unreliable.

The 10-DNS-lookup limit

SPF evaluation is capped so that a single check cannot trigger an unbounded number of DNS queries. Under section 4.6.4 of RFC 7208, the include, a, mx, ptr and exists mechanisms and the redirect modifier together may not cause more than 10 DNS lookups. The ip4, ip6 and all mechanisms do not count. Going over the limit returns a “permerror” instead of a pass; what the receiver then does with the message is left to its local policy, and a permerror cannot count towards a DMARC pass. The RFC also recommends limiting “void” lookups (queries that return no answer) to two.

The trap is that every include: can itself contain further includes, and those count too. A business that adds a CRM, a helpdesk, a billing tool and a newsletter platform on top of its main email service can cross the limit without noticing. Practical fixes:

Remove includes for services you no longer use.
Send bulk or marketing mail from a subdomain (for example news.example.com) with its own SPF record.
Replace an include with explicit ip4:/ip6: ranges only where the provider publishes stable ranges and you have a process to keep them current.

SPF has a structural weakness: it checks the envelope sender, not the “From” address people see. It also tends to break when mail is forwarded. That is why DKIM and DMARC exist.

DKIM: a signature that travels with the message

DomainKeys Identified Mail is defined in RFC 6376, an Internet Standard. The sending system signs selected headers and the body of each message with a private key and adds a DKIM-Signature header. That header carries a d= tag (the signing domain) and an s= tag (the selector). The receiver combines them to find the public key in DNS at selector._domainkey.domain and verifies the signature.

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

Because the signature is inside the message, DKIM usually survives forwarding, provided nothing along the way changes the signed content. Selectors let you keep more than one key published at once, which makes key rotation straightforward: publish the new key under a new selector, switch signing over, then retire the old one.

On key length, RFC 8301 requires RSA keys of at least 1024 bits and recommends at least 2048 bits. Google’s sender guidelines likewise recommend 2048-bit keys where your provider supports them.

Each service that sends as your domain (your mailbox provider, your newsletter tool, your billing system) should sign with your domain, not only its own. Most providers give you one or more CNAME or TXT records to publish for this.

DMARC: tying it to the visible “From” address

DMARC is what connects SPF and DKIM to the address recipients actually see. A message passes DMARC when SPF or DKIM passes and the domain that passed is aligned with the domain in the “From” header. “Relaxed” alignment allows the same organisational domain (so mail.example.com aligns with example.com); “strict” requires an exact match.

You publish a DMARC record at _dmarc under your domain:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

p= is your policy for failing mail: none (monitor only), quarantine (treat as suspicious, usually the spam folder) or reject.
rua= is where receivers send aggregate reports: daily summaries of which IP addresses sent mail using your domain and whether it passed.
sp= sets a separate policy for subdomains; adkim= and aspf= choose relaxed or strict alignment.

The standard has just been updated

DMARC was first published in 2015 as RFC 7489, an Informational document from the Independent Submission stream rather than an IETF standard. In May 2026 the IETF published the revised specification, often called “DMARCbis”, as three Standards Track documents: RFC 9989 (the core protocol), RFC 9990 (aggregate reporting) and RFC 9991 (failure reporting). Each of the three obsoletes RFC 7489.

The record still starts with v=DMARC1, so existing records keep working. The notable changes, listed in Appendix C of RFC 9989, are:

Removed tags: pct (apply the policy to a percentage of mail), rf and ri.
Added tags: np (policy for non-existent subdomains), psd (marks a public suffix domain) and t (a testing flag that replaces some of what pct did).
Policy discovery now uses a DNS “tree walk” to find the organisational domain, instead of relying on an external public suffix list.

With t=y, you ask receivers to apply a policy one step softer than the one published, so reject is treated as quarantine and quarantine as none. It has no effect on p=none.

A safe rollout: from p=none to reject

Jumping straight to p=reject is the quickest way to block your own invoices. A staged approach avoids that.

Inventory every sender. List each system that sends mail as your domain: mailboxes, website contact forms, CRM, helpdesk, billing, payroll, marketing tools, scanners and printers.
Publish SPF and enable DKIM for each. Keep SPF within the 10-lookup limit and make sure each third-party service signs with your domain.
Publish p=none with rua= reporting. This changes nothing for delivery but starts the flow of aggregate reports. A DMARC report-processing tool makes the XML readable.
Fix what the reports reveal. Expect to find forgotten services and forwarding paths. Each legitimate source should pass with alignment before you move on.
Move to p=quarantine. Under the new specification you can publish p=quarantine; t=y first as a softer trial, then remove t=y. Older guides suggest pct=, which RFC 9989 has removed. Because the new RFCs are recent, some receivers may not act on t=y yet (or may still read pct=), so watch your aggregate reports rather than assuming the softer trial is being applied.
Move to p=reject once reports show legitimate mail passing consistently. Consider sp=reject for subdomains, and np=reject for subdomains that do not exist. Section 7.4 of RFC 9989 adds two cautions: a domain publishing p=reject must sign with DKIM rather than rely on SPF alone, and domains whose users post to mailing lists should not publish p=reject, because it causes problems for those lists and their subscribers. If such a domain still wants reject, the RFC says to run p=none for at least a month, then p=quarantine for as long, and compare the reports first.
Keep watching. New tools get added, keys get rotated and providers change their infrastructure. Reports remain useful long after you reach reject.

Domains that never send email should still be protected: an SPF record of v=spf1 -all and a DMARC record of p=reject tell receivers that any mail claiming to be from them is fake.

What Google, Yahoo and Microsoft require

Gmail

Google’s email sender guidelines took effect on 1 February 2024. All senders to personal Gmail accounts need SPF or DKIM, valid forward and reverse DNS for sending IPs, TLS for transmission, RFC 5322-compliant formatting, and a spam rate reported in Postmaster Tools below 0.3%. Bulk senders, defined as those sending more than 5,000 messages a day to Gmail accounts, additionally need:

both SPF and DKIM;
a DMARC record (a policy of p=none is acceptable);
alignment of the “From” domain with the SPF or DKIM domain;
one-click unsubscribe (the List-Unsubscribe and List-Unsubscribe-Post headers) for marketing and subscribed messages, plus a visible unsubscribe link.

Google’s sender guidelines FAQ adds two points worth knowing. A sender that crosses the bulk threshold once is permanently treated as a bulk sender. And from November 2025 Gmail began ramping up enforcement on non-compliant traffic, including temporary and permanent rejections.

Yahoo

Yahoo’s sender best practices, enforced from February 2024, require all senders to use SPF or DKIM and keep spam complaints below 0.3%. Bulk senders need both SPF and DKIM, a DMARC policy of at least p=none that passes with aligned domains, a one-click List-Unsubscribe header (the RFC 8058 POST method is highly recommended), and must honour unsubscribe requests within two days. Unlike Google and Microsoft, Yahoo’s best-practices page gives no numeric threshold for who counts as a bulk sender.

Outlook.com

Microsoft announced requirements for high-volume senders in April 2025. They apply to domains sending more than 5,000 emails a day to Outlook.com consumer addresses (outlook.com, hotmail.com and live.com). SPF and DKIM must pass, and DMARC must be published at least at p=none and align with SPF or DKIM, preferably both. Enforcement started on 5 May 2025. Microsoft later updated the post: non-compliant messages are rejected with the error 550; 5.7.515 Access denied, replacing the original plan to route them to Junk first.

A short checklist

One SPF record per domain, under 10 lookups, ending in -all or ~all.
DKIM signing with your own domain for every sending service, using 2048-bit keys where supported.
A DMARC record with rua= reporting, reviewed regularly.
A documented path from p=none to p=reject, with dates and an owner.
One-click unsubscribe and low complaint rates for any bulk or marketing mail.
Parked and non-sending domains locked down with v=spf1 -all and p=reject.

Sources

Facts in this article were checked against the linked sources on 9 October 2026. Rules, prices and standards change; check the source before relying on a detail. This article is general information, not legal or financial advice.