DMARC, SPF and DKIM explained (2026 update)

SPF (Sender Policy Framework, specified in RFC 7208) is a DNS TXT record that lists which IP addresses or hostnames are authorised to send mail on behalf of your domain. A receiving mail server looks up your SPF record and checks whether the sending IP is in the list. If yes, the SPF check passes; if no, it fails.

An example SPF record:

example.com IN TXT "v=spf1 include:_spf.google.com include:sendgrid.net ip4:198.51.100.10 -all"

That record authorises Google Workspace, SendGrid, and one specific IP. The trailing -all is the policy: hard-fail anything not in the list. The softer ~all means soft-fail (treat as suspicious) and ?all means neutral (no opinion, do not use this).

SPF has a hard limit: a single record can resolve to at most 10 DNS lookups. Exceed it and the record becomes invalid — a common failure mode for organisations that have accumulated a long list of third-party senders.

DKIM (DomainKeys Identified Mail, RFC 6376) does what SPF cannot: it cryptographically signs the message itself. Each outgoing message gets a header DKIM-Signature containing the domain, the selector, and the signature. The receiver looks up the public key in DNS (at <selector>._domainkey.<domain>) and verifies the signature.

DKIM solves two problems SPF cannot. First, it survives forwarding — SPF breaks when a message is forwarded because the new sending IP is no longer in the original sender's SPF record, but DKIM signatures travel with the message. Second, it proves integrity — the signed body cannot be modified in transit without invalidating the signature.

The selector mechanism lets you rotate keys without breaking deliverability — publish a new key under selector 2026a, wait for in-flight mail signed with the old selector to finish, then remove the old record. Standard practice is annual rotation; 2048-bit RSA keys are now the de-facto minimum.

DMARC (Domain-based Message Authentication, Reporting and Conformance, RFC 7489) is the glue. It does three things SPF and DKIM cannot do on their own:

• Tells receivers what to do when a message fails authentication — accept, junk it, or reject it outright.
• Enforces alignment between the From: header domain and the domain checked by SPF or DKIM. Without alignment, an attacker can pass SPF on their own domain and still spoof yours.
• Provides reporting — aggregate XML reports sent to a mailbox you specify, listing which sources are sending mail claiming to be your domain and whether they passed authentication.

An example DMARC record:

_dmarc.example.com IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; sp=reject; adkim=s; aspf=s"

Breakdown: p=reject is the policy for the apex domain; sp=reject applies the same policy to subdomains; rua is where aggregate reports go; adkim=s and aspf=s require strict alignment.

When a receiving server gets a message, it does roughly this:

1. Check SPF on the Return-Path domain — does the sending IP match the SPF record? Pass or fail.
2. Check DKIM signature — does at least one signature verify against a public key in DNS? Pass or fail.
3. Look up DMARC on the From: header domain. Check whether SPF or DKIM passed AND aligned with the From: domain.
4. If DMARC alignment fails, apply the published policy: none (deliver and report), quarantine (deliver to spam), or reject (refuse).

DMARC passes if either SPF or DKIM passes with alignment. You do not need both every time; you need at least one, every time. In practice, signing every message with DKIM and listing your sending infrastructure in SPF covers both pathways.

Gmail and Yahoo announced enforcement in October 2023 and started actively rejecting unauthenticated bulk mail in February 2024. Two years on, the rollout has tightened — the 5,000-messages-per-day threshold remains the published bar, but in practice many smaller senders see deliverability degradation without DMARC alignment.

Microsoft began similar enforcement for Outlook.com and Hotmail starting in 2024. The direction of travel is unambiguous: every major mailbox provider now expects valid SPF + DKIM + DMARC, and the consequences for non-compliance have escalated from "your security score looks bad" to "your invoices do not reach customers".

For SMBs, the practical impact is that DMARC has moved from a security concern owned by IT to a deliverability concern owned by marketing and finance. The good news is that the fix is the same in both framings.

Going straight to p=reject on day one will break legitimate mail. The standard rollout is:

1. Week 0 — publish p=none with reporting. You authenticate nothing yet, but you start receiving aggregate reports listing every source claiming to send as your domain.
2. Weeks 1-4 — triage the reports. Categorise each source: legitimate (Mailchimp, Zendesk, your own infra), known third-party (a partner platform), spoofed (an attacker). Fix SPF / DKIM for legitimate sources.
3. Week 4-6 — move to p=quarantine. Failed mail goes to spam, not deleted. You are now mitigating spoofing without losing edge-case legitimate mail.
4. Week 8-12 — move to p=reject. Failed mail is refused. By now your reports should show near-100% authenticated mail from legitimate sources.
5. Steady state — quarterly review. Read the aggregate reports every quarter to catch new third-party senders before they break things or get spoofed.

SPF lookup overflow. Past 10 DNS lookups the record becomes invalid. Common cause: stacking include: directives for every SaaS you have ever used. Fix: flatten where possible, prune unused senders, or use an SPF-flattening service if the count truly cannot be reduced.

DKIM signing with a 1024-bit key. Still works, but increasingly flagged as weak by audit and security scanners. Migrate to 2048-bit on the next rotation.

DMARC record under p=none for years. A static p=none provides reporting but no spoofing protection. The point of monitoring is to graduate.

No subdomain policy (sp=). If you publish p=reject on the apex but no sp=, a forgotten subdomain remains spoofable. Set sp=reject unless you have a specific subdomain that legitimately needs a softer policy.

Aggregate reports going to a mailbox nobody reads. The RUA address has to actually be read. Use a dedicated address, ideally feeding a DMARC-reporting tool that aggregates the XML.

Email authentication is one of the five core pillars in every CyberScore scan. We do a passive DNS lookup against your apex domain and common subdomains, parse the SPF / DKIM / DMARC records, and score them against the criteria above:

• SPF present, syntactically valid, hard-fail policy (-all), under the 10-lookup limit.
• DKIM detection on common selectors (google, selector1, mailo, etc.), key length, signature algorithm.
• DMARC present, policy strength (none / quarantine / reject), subdomain policy, alignment mode, RUA configured.
• Cross-checks for common misconfigurations (DMARC published but no SPF or DKIM, subdomains weaker than apex, etc.).

The result is a per-pillar score that feeds into your overall 0-100 CyberScore. The first scan typically surfaces at least one actionable item — most often a DMARC stuck at p=none from a project that never finished, or an SPF record over the lookup limit.