The email security audit in 2026: SPF, DKIM and DMARC without apparent conformity

What SPF, DKIM and DMARC actually protect

These mechanisms authenticate domains and their use within a message. They do not confirm a person's identity, the truthfulness of the content or the safety of a link. DMARC principally limits impersonation using the exact domain in the From: header. It does not block visually similar domains, abuse of the display name, a compromised mailbox, or a legitimately authenticated phishing campaign.

RFC 9989 states plainly that a DMARC pass does not mean a message is safe or wanted. The receiver still uses reputation, content analysis, behavioural signals and its own policy. ^[1] Research on SMTP smuggling further shows that inconsistent protocol parsing across successive servers can undermine authentication despite correct DNS records. ^[12]

A complete audit therefore separates four layers:

• domain identity: SPF, DKIM, DMARC, delegation of sending and reporting;
• server-to-server transport: SMTP TLS, MTA-STS, TLS-RPT or DANE;
• mailbox and platform security: MFA, legacy protocols, forwarding rules, OAuth applications, administrative roles and event logging;
• protection of the recipient: content filtering, blocking display-name impersonation, link and attachment analysis, phishing reporting and incident response.

SPF: authorising a server, not the visible sender

Sender Policy Framework (SPF) lets a domain owner state which IP addresses may use that domain in the SMTP identity MAIL FROM or HELO/EHLO. The record is published as TXT. SPF by itself does not check the domain the user sees in the From: header; DMARC fills that identifier-binding gap. ^[3]

An SPF audit involves far more than checking the syntax:

• exactly one SPF record exists for the domain being assessed;
• every include mechanism, ip4/ip6 range and redirect has a business owner;
• the record does not needlessly authorise whole shared ranges belonging to a provider;
• the final qualifier matches the intended policy rather than being a leftover from a pilot;
• recursive evaluation of all include mechanisms stays within the DNS limits;
• the envelope domain aligns with the author domain wherever SPF is meant to produce a DMARC pass;
• a change of provider ranges has not left orphaned authorisations behind.

RFC 7208 caps at ten the total number of terms that cause DNS queries during the whole, including recursive, evaluation. That covers include, a, mx, ptr, exists and redirect. Exceeding it yields permerror; the recommended limit on void DNS responses is two. ^[3]

"Flattening" SPF into a list of IP addresses can reduce the number of queries, but it creates a copy of the provider's data that has to be kept synchronised. An audit should check the update mechanism, difference monitoring and the ability to roll back a bad change quickly. One-off correctness of the record is not enough. A study based on weekly snapshots collected over 17 months for 176 million domains across four top-level domains makes the point: purely syntactic errors affected 0.4 per cent of records, while problems that only surface at evaluation time affected 7.7 per cent - nearly twenty times as often ^[11]. A syntax validator will therefore miss most of the cases in which SPF stops working. Those percentages describe the population of domains measured in that study, not the share of any given organisation's mail traffic.

DKIM: the signature, its scope and the key lifecycle

DomainKeys Identified Mail (DKIM) signs selected headers and a hash of the message body. The receiver fetches the public key from a TXT record under a name made of the selector and _domainkey, and reads the signing domain from the d= tag. The signature can survive forwarding if the intermediary does not alter the signed elements. ^[4]

RFC 8301 forbids RSA-SHA1. For RSA it requires a key of at least 1024 bits and recommends a minimum of 2048. RFC 8463 adds Ed25519-SHA256. ^[4] If an organisation uses Ed25519, the audit should confirm support among its most important receivers; a parallel RSA signature may be needed for interoperability.

A DKIM review should cover:

• whether every sending system signs with its own controlled domain aligned to From:;
• the algorithm, key length, protection of the private key and who is accountable for it;
• which headers are signed, in particular From:, and the canonicalisation used;
• the absence of the unsafe body length tag l=;
• unique selectors per provider and environment, rather than a shared key;
• the procedure for rotation, compromise and retirement of a selector;
• how long the old key stays published, derived from real message transit and queue times.

No general DKIM standard mandates rotation "every six months" or "every year". The schedule should follow from the threat model, what the provider supports, how the key is protected and the incident procedure. More important than an arbitrary calendar is a rotation that can be carried out without interruption, using two selectors and confirming the new signature before removing the old record.

DMARC under RFC 9989

DMARC evaluates the author domain from the RFC5322.From field. A message passes DMARC when at least one mechanism returns a positive result and its domain aligns with the author domain:

• SPF: a pass for the MAIL FROM domain, and alignment of that domain with From:;
• DKIM: a valid signature and alignment of the d= domain with From:.

Alignment may be relaxed, meaning the same organisational domain, or strict, requiring an identical domain. Relaxed is the default. For p=reject, do not rely on SPF alone, because ordinary forwarding changes the IP address and often the envelope domain; the current standard requires a full DMARC participant to produce valid DKIM signatures. ^[1]

What changed in 2026

• RFC 9989 has Proposed Standard status and replaces the informational RFC 7489 and the PSD extension in RFC 9091.
• Policy discovery uses a walk up the DNS tree instead of the previous dependence on the Public Suffix List.
• The np policy can address non-existent subdomains.
• The pct tag has been removed and is historic. The new t=y signals testing mode; it is not percentage sampling.
• rf and ri were likewise removed from the core specification.
• The format of aggregate reports is set by RFC 9990, and of individual failure reports by RFC 9991.

As at August 2026 this is a recent change of standard. The documentation and implementations of large providers may still describe pct from RFC 7489. An audit should therefore record separately conformity with the target standard and operational conformity with specific receivers. Do not assume the new tag is already uniformly supported.

p=none, quarantine and reject

p=none is for observation: it requests no change in the handling of messages that fail DMARC. p=quarantine asks for them to be treated as suspicious, and p=reject for them to be rejected. These are the domain owner's declarations, but the receiver retains its own policy and may decide otherwise.

The move to enforcement should come only after inventorying the systems, fixing SPF or DKIM alignment, testing forwarding and mailing lists, and assigning owners to the exceptions. The safe outcome is not p=reject in itself but p=reject with no loss of legitimate mail and a measurable process for handling new sources.

DMARC reports: operational data and untrusted input

The address in rua asks receivers for aggregate reports. These contain, among other things, source IP addresses, message counts and the results of SPF, DKIM and identifier alignment. A report is not a complete record of sending: receivers are under no obligation to send one, the data is aggregated, and delays and implementation differences are normal. ^[2]

Where reports go to a domain other than the one publishing the policy, the receiving domain must confirm that in DNS. Missing that authorisation is a common cause of an empty dashboard despite a correct address. ruf concerns individual failure reports, which may disclose more about a message; using it calls for a separate assessment of confidentiality, lawful basis, retention and access.

An XML report and its compressed attachment are data arriving from the internet. The parser should have size and time limits, external entity loading disabled, an isolated account and duplicate checking. Research presented at USENIX Security 2023 showed that flawed DMARC reporting implementations can create operational risk and amplification mechanisms. ^[10]

A reporting vendor's dashboard is a supporting tool. An audit should pull a sample of the source XML, compare it with the aggregation, and check time zones, sources marked "unknown" and how a new or suspicious stream is escalated.

MTA-STS, TLS-RPT and DANE protect SMTP transport

STARTTLS in plain SMTP is opportunistic encryption. An active attacker may try to strip the STARTTLS offer or redirect the connection. MTA-STS lets a receiving domain declare, through DNS and an HTTPS policy, that its MX servers support TLS with a valid certificate, and what to do on error. TLS-RPT supplies reports about TLS negotiation problems. DANE for SMTP binds transport to TLSA records protected by DNSSEC. ^[5]

An MTA-STS audit checks the _mta-sts record, the version identifier, the availability of https://mta-sts.domain/.well-known/mta-sts.txt, the certificate, the complete MX list, testing versus enforce mode, the max_age value and a safe procedure for changing or withdrawing the policy. For TLS-RPT it checks the _smtp._tls record, receipt of reports and alerting. DANE only makes sense with properly maintained DNSSEC and TLSA records for every relevant MX host.

These mechanisms protect the leg between servers. They do not provide encryption from sender to recipient and do not protect a message stored in a mailbox. Where end-to-end encryption is required, a separate architecture is needed - S/MIME or OpenPGP - together with key management.

ARC and forwarding: evidence from a chain, not automatic trust

Forwarding often breaks SPF, and a mailing list may alter the body and invalidate DKIM. Authenticated Received Chain (ARC) lets intermediaries record and sign the authentication results they saw at each stage. A receiver may use that chain in its decision. ^[6]

ARC does not turn a DMARC fail into a pass, does not confirm the truth of authorship and does not oblige anyone to trust a seal. The reputation of the intermediary, the correctness and continuity of the chain and the receiver's local policy all have to be assessed. RFC 8617 remains an experimental document.

An audit test should cover the real routes: automatic forwarding between organisations, mailing lists, security gateways, ticketing systems and transport rules. Analysing only a message sent directly from Microsoft 365 or Google Workspace gives an incomplete picture.

BIMI: a brand layer, not a substitute for protection

Brand Indicators for Message Identification (BIMI) lets clients that support it display a logo associated with an authenticated domain. BIMI is not described in RFC 9091. That number covered the DMARC extension for public suffix domains and has been superseded by RFC 9989. BIMI is developed as an industry specification.

In Gmail, deployment requires DMARC plus a VMC or CMC certificate, a file in the required format and a BIMI record; the verification mark is tied to the VMC. ^[9] Other operators may have different requirements, and displaying the logo remains their decision. There is no basis for promising a specific uplift in opens or clicks without a study relating to the particular population, campaign and mail client.

BIMI should be deployed after SPF, DKIM, DMARC and sending reputation are in order. It is an element of brand presentation, not a control that blocks phishing, look-alike domains or compromised accounts.

What Gmail, Yahoo and Outlook.com require

Mailbox operators' requirements are technical conditions of delivery, not legislation. They can change independently of the RFCs, so an audit records the date of verification and the recipient group.

• Gmail: all senders to personal accounts must use SPF or DKIM, TLS, correct DNS and RFC 5322 formatting. Senders exceeding 5,000 messages a day to personal Gmail accounts must have SPF and DKIM, DMARC at least p=none, domain alignment, and - for marketing and subscribed mail - one-click unsubscribe. Google requires the spam rate in Postmaster Tools to stay below 0.3 per cent. ^[7]
• Yahoo: requires at least SPF or DKIM, correct DNS and a low complaint level from all senders. Bulk senders must use SPF and DKIM, publish DMARC at least p=none and achieve alignment; marketing requires a working one-click unsubscribe. Yahoo publishes no fixed numeric threshold for the "bulk" category. ^[8]
• Outlook.com: Microsoft's requirements apply to domains sending more than 5,000 messages a day to consumer addresses at Outlook.com, Hotmail.com and Live.com. They cover valid SPF, DKIM and at least DMARC p=none; non-conforming messages may be rejected with code 550 5.7.515. That threshold should not be carried over automatically to Exchange Online business recipients. ^[13]

DMARC does not guarantee deliverability. The decision is also shaped by recipient consent, complaints, domain and IP reputation, content, sending rate, working unsubscribes and server responses. An audit should separate an authentication failure from a reputation problem.

What an email security audit looks like

1. Domain inventory. Primary domains, subdomains, unused domains, brands, campaign domains, envelope domains, DKIM selectors and DNS zone owners.
2. Sending map. The office platform, CRM, invoicing, helpdesk, monitoring, devices, applications, marketing providers, gateways and forwarding mechanisms.
3. DNS testing. Authoritative answers from several resolvers, DNSSEC, TTLs, delegation errors, duplicate records and authorisations for external reporting addresses.
4. SPF assessment. Syntax, full recursion, DNS limits, breadth of authorisation, orphaned providers, MAIL FROM alignment and how the record is maintained.
5. DKIM assessment. Signatures from every stream, the d= domain, selector, algorithm, key length, headers, l=, rotation and response to compromise.
6. DMARC assessment. Policy discovery under RFC 9989, relaxed or strict alignment, p, sp, np, testing mode, reports and the handling of inactive domains.
7. Message analysis. Samples from every source and at different receivers, complete Authentication-Results headers, direct scenarios, forwarding and lists.
8. Transport. MX records, certificates, STARTTLS, MTA-STS/TLS-RPT or DANE, and evidence from reports rather than the mere presence of records.
9. Inbound protection, platform and mailboxes. DMARC verification of inbound mail, exceptions for trusted relays, detection of domain and display-name impersonation, MFA, legacy protocol access, privileged accounts, applications, forwarding, mailbox rules, log auditing and the account compromise procedure.
10. Maintenance process. Owners, approval of new senders, monitoring of reports and DNS changes, response SLAs, data retention and re-testing.

The report should separate a departure from the standard, a delivery risk, a security gap and an optimisation recommendation. An "SPF pass" from a provider domain that does not align with From: is not a DMARC success. Likewise a correct MTA-STS record with no working HTTPS policy provides no transport protection.

Does the law require DMARC

In Poland there is no general provision requiring every organisation to publish SPF, DKIM or DMARC. The act on the national cybersecurity system provides, for entities within its scope, risk management measures appropriate and proportionate to the risk; article 32 of the GDPR similarly requires measures appropriate to the risk of the processing. Neither names DMARC. ^[14]

Domain authentication may nonetheless be a justified measure where email is used to communicate with customers, transmit data, reset passwords or approve transactions. An audit should tie the control to a specific risk and obligation of the organisation, rather than asserting that "NIS2 requires DMARC". The requirements of Gmail, Yahoo and Microsoft remain separate terms of their services.