What is SPF, DKIM, and DMARC?

SPF, DKIM and DMARC are the three email authentication standards that together decide whether a message reaching a recipient is treated as legitimate, quarantined, or rejected outright. They are not interchangeable — each answers a different question about the message — and in 2026 all three are effectively mandatory for any domain that sends mail, not only bulk senders. This guide explains what each one does, how they interact, and the specific failure modes that trip up most domains.

SPF — Sender Policy Framework (RFC 7208)

SPF is a DNS TXT record that lists the IP addresses and hostnames authorised to send mail on behalf of your domain. When a receiving server gets a message, it checks the MAIL FROM (envelope sender) domain, looks up that domain's SPF record, and verifies that the connecting IP is in the allowed list.

A typical SPF record looks like this:

v=spf1 ip4:185.71.60.245 include:_spf.google.com include:spf.mailgun.org ~all

Key components:

• v=spf1 — version tag, always required
• ip4: / ip6: — explicit IPs
• include: — delegates to another domain's SPF
• a, mx — authorise the domain's own A/MX records
• ~all (softfail) or -all (hardfail) — what to do with unlisted senders

The single most common failure is exceeding the 10 DNS lookup limit. Every include, a, mx, ptr, and exists mechanism counts. Stack Google Workspace, Microsoft 365, and two ESPs and you are already past 10. When SPF exceeds 10 lookups the receiver returns permerror and most filters treat that as fail.

DKIM — DomainKeys Identified Mail (RFC 6376)

DKIM solves a different problem: it cryptographically proves that the message content was not modified in transit and that it was signed by someone who controls the stated domain. The sending server computes a hash of selected headers plus the body, signs it with a private key, and adds a DKIM-Signature header. The receiver fetches the public key from DNS at selector._domainkey.domain.tld and verifies.

A DKIM DNS record looks like:

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

The selector (default in this example, but often google, mailfilter, s1, or a date-based name) lets a domain publish multiple active keys for key rotation. Every mail platform uses its own selector convention, which is why DKIM discovery is harder than SPF — you have to know the selectors to check them.

Key rules in 2026:

• Minimum key length is 2048 bits. 1024-bit keys are deprecated and penalised by Gmail.
• Rotate keys every 6-12 months.
• Sign at least From, To, Subject, Date, Message-ID and the body.
• Use relaxed canonicalisation (c=relaxed/relaxed) to survive minor whitespace changes.

DMARC — Domain-based Message Authentication, Reporting and Conformance (RFC 7489)

DMARC is the policy layer that sits on top of SPF and DKIM. It does two things: it tells receivers what to do when authentication fails, and it requests aggregate and forensic reports so the domain owner can see who is sending mail as their domain.

A DMARC record:

_dmarc.example.com. TXT  "v=DMARC1; p=reject; rua=mailto:[email protected]; ruf=mailto:[email protected]; pct=100; adkim=s; aspf=s"

Tags explained:

• p= — policy: none, quarantine, or reject
• rua= — aggregate report destination
• ruf= — forensic (per-failure) report destination
• pct= — percentage of failing mail to apply policy to (useful for gradual rollout)
• adkim= / aspf= — alignment mode, s (strict) or r (relaxed)
• sp= — subdomain policy (defaults to p= if omitted)

The critical concept DMARC introduces is alignment. SPF authenticates the envelope sender (MAIL FROM), DKIM authenticates the d= tag in the signature. DMARC requires that at least one of these matches the domain visible in the From: header that the recipient actually sees. A message can pass SPF and DKIM and still fail DMARC if neither aligns with From:.

How the three fit together

A message arriving at a receiver is evaluated in roughly this order:

1. SPF check against the MAIL FROM domain.
2. DKIM verification of any signatures present.
3. DMARC lookup on the From: header domain.
4. Alignment check between SPF/DKIM results and the From: domain.
5. Policy application: none, quarantine, or reject.
6. Report generation to rua= and optionally ruf=.

DMARC passes if either SPF aligns or DKIM aligns. You do not need both. But in practice most domains configure both because DKIM survives forwarding (SPF breaks) and SPF is cheaper to set up for transactional mail (DKIM signing can be harder to configure on some platforms).

The 2026 bulk sender requirements

Gmail and Yahoo's February 2024 rules, now fully enforced, require any domain sending more than 5,000 messages per day to Gmail or Yahoo users to:

1. Publish SPF and DKIM, both passing and aligning with From:.
2. Publish a valid DMARC record at minimum p=none with rua reporting.
3. Keep spam complaint rate below 0.3% (and preferably below 0.1%).
4. Include a one-click list-unsubscribe header on marketing mail.
5. Not spoof Gmail/Yahoo addresses in From:.

Microsoft introduced similar rules in May 2025. The effective threshold is now much lower than 5,000/day — in practice any domain with commercial volume is treated as bulk.

Common mistakes

• Publishing SPF without DKIM (or vice versa) and expecting DMARC to pass.
• Using p=reject before aggregate reports confirm legitimate mail aligns.
• Multiple SPF records on one domain (invalid — only one allowed).
• DMARC record on the wrong host (must be at _dmarc.domain, not domain).
• Forgetting rua= — without reports you are flying blind.

When to use IntoDNS.ai

IntoDNS.ai checks all three records in a single scan, flags alignment problems, counts SPF lookups, probes 40+ common DKIM selectors, parses the DMARC policy and explains the exact DNS records to publish for any gap. It is the fastest way to go from "my mail is going to spam" to a working authentication setup that meets Gmail and Yahoo's 2026 requirements.

How the three relate to other standards

SPF, DKIM and DMARC are the foundation. Around them have grown several newer standards worth knowing:

• ARC (Authenticated Received Chain, RFC 8617) — preserves SPF and DKIM results across forwarding. When mail is forwarded, SPF breaks because the forwarder's IP is not in the original domain's SPF. DKIM usually survives unless the forwarder modifies the body. ARC adds signatures at each hop that record the original authentication result, so the final recipient can trust a forwarded message.
• BIMI (Brand Indicators for Message Identification) — requires DMARC at p=quarantine or p=reject and displays your verified logo in supporting mail clients.
• MTA-STS (RFC 8461) and TLS-RPT (RFC 8460) — enforce TLS on inbound SMTP and report failures. Orthogonal to SPF/DKIM/DMARC but part of the same security posture.
• DANE/TLSA (RFC 7672) — pins TLS certificates in DNS. Requires DNSSEC on the domain's zone. Not available for .ai domains because Anguilla's TLD does not support DS records at registry level.

In a fully modern setup, a domain has all of these configured. SPF, DKIM and DMARC are the minimum; BIMI and MTA-STS are the realistic add-ons for 2026.

Worked example: a full record set

For a consultancy on example.com using Google Workspace plus Mailgun for transactional mail, a complete email security record set looks like:

example.com                   TXT  "v=spf1 ip4:185.71.60.245 include:_spf.google.com include:mailgun.org ~all"
google._domainkey.example.com TXT  "v=DKIM1; k=rsa; p=MIIBIjANBg..." (2048-bit)
k1._domainkey.example.com     TXT  "v=DKIM1; k=rsa; p=MIIBIjANBg..." (Mailgun selector)
_dmarc.example.com            TXT  "v=DMARC1; p=reject; rua=mailto:[email protected]; adkim=r; aspf=r"
_mta-sts.example.com          TXT  "v=STSv1; id=20260401T000000"
_smtp._tls.example.com        TXT  "v=TLSRPTv1; rua=mailto:[email protected]"
default._bimi.example.com     TXT  "v=BIMI1; l=https://example.com/bimi-logo.svg"

This is a 2026-baseline posture: SPF under 10 lookups, DKIM on two selectors at 2048-bit, DMARC at full enforcement with aggregate reporting, MTA-STS and TLS-RPT for TLS enforcement, and BIMI for logo display. Run an IntoDNS.ai scan to see how close your domain is to this baseline.