Email security auditing in 2026: SPF, DKIM, DMARC, and transport security

What SPF, DKIM, and DMARC actually protect

SPF, DKIM, and DMARC protect domain identity, but they do not solve every email-security problem. They do not confirm a person's identity, the truthfulness of a message, the safety of a link, or the good intentions of a sender that legitimately uses an authenticated domain. A correctly authenticated message can still be phishing.

SPF answers whether a particular server is authorised to use a domain in the SMTP MAIL FROM or HELO/EHLO identity. By itself, it does not validate the domain visible to the user in the From: field. The SPF policy is published as a DNS TXT record describing authorised sending sources.^[3]

DKIM allows a domain to cryptographically sign selected headers and a hash of the message body. The receiver retrieves the public key from DNS and verifies the signature, and the signing domain is identified by the d= tag. A DKIM signature can survive forwarding if intermediate systems do not modify signed content in a way that invalidates it.^[4]

DMARC binds the author domain in RFC5322.From to an SPF or DKIM result. A message passes DMARC when at least one of those mechanisms passes and its domain is aligned with the author domain under the selected alignment mode.^[1]

This design limits direct spoofing of an organisation's domain, but it does not block visually similar domains, display-name abuse, compromised accounts, or a phishing campaign sent from a legitimately authenticated domain. An audit should therefore separate domain authentication from mailbox security, transport security, and recipient protection. That distinction also matters for security awareness training: users must not assume that a message which reached the mailbox has passed any verification of its content.

SPF: more than syntax checking

A good SPF audit answers at least six questions:

• Is there exactly one SPF record for the evaluated domain?
• Are all include, a, mx, ip4, ip6, and redirect mechanisms still necessary?
• Does every external sender acting on behalf of the organisation have a business owner?
• Does the record avoid authorising address ranges broader than required?
• Does the MAIL FROM domain align with From: where the organisation relies on SPF for DMARC?
• Does the complete recursive include chain stay within DNS evaluation limits?

RFC 7208 limits the total number of SPF terms that trigger DNS queries to ten. The limit includes include, a, mx, ptr, exists, and redirect, and exceeding it produces permerror. The standard also recommends limiting void DNS lookups to two.^[3]

This matters because SPF problems are often exposed during evaluation rather than simple record parsing. A study presented at USENIX Security 2024 analysed weekly snapshots over 17 months covering 176 million domains in four top-level domains. Pure syntax errors affected 0.4% of records, while evaluation-phase problems affected 7.7%.^[11] These numbers should not be generalised to an individual organisation, but they illustrate the limitations of a simple SPF validator.

SPF flattening into an IP-address list can reduce DNS lookups but creates a local copy of provider data. When the provider changes infrastructure, that copy must be synchronised, otherwise the organisation starts rejecting its own mail. An audit should therefore verify not just today's result but the maintenance process behind the record.

DKIM: a signature is also key management

RFC 8301 prohibits RSA-SHA1. For RSA, it requires at least 1024-bit keys and recommends at least 2048 bits.^[4] RFC 8463 added Ed25519-SHA256.^[5] An organisation should still account for receiver interoperability, particularly when adopting a less common algorithm.

A DKIM audit should cover:

• the d= signing domain and its alignment with the author domain;
• algorithm and key length;
• protection of the private key;
• separate selectors for providers and environments where this usefully limits compromise impact;
• the set of signed headers, including From:;
• absence of unjustified use of the l= body-length tag;
• rotation, revocation, and recovery after compromise;
• confirmation that an old DNS record is not removed before traffic has moved to the new selector.

There is no universal requirement to rotate a DKIM key every six or twelve months. The interval should follow key protection, provider capabilities, the threat model, and the organisation's ability to perform a safe rotation. An auditor who records "no rotation every 6 months" as a non-conformity should be able to name the requirement behind it rather than a habit.

DMARC under RFC 9989

Alignment remains the key concept. SPF may return pass for one domain, but if the MAIL FROM domain is not aligned with From:, that result does not produce a DMARC pass. Likewise, a DKIM signature helps DMARC only if its d= domain aligns with the author domain.^[1]

Relaxed alignment, the default, permits alignment at the organisational-domain level. Strict alignment requires a closer match. The choice should follow the sending architecture rather than the simplistic rule that "strict is always more secure": in an environment with many subdomains and providers, strict alignment can cut off legitimate correspondence.

RFC 9989 also changed policy discovery, moving away from the former dependence on the Public Suffix List. It introduces, among other things, policy for non-existent subdomains through np and the t tag for signalling testing mode. The historical pct mechanism is not part of the new policy model.^[1]

That distinction matters in 2026. The specification is new, while provider documentation and implementations may still describe records in RFC 7489 terms. An audit should record standards conformity separately from operational interoperability with the receivers that matter to the organisation. During a transition period those two things can diverge.

DMARC reports are data, not decoration

DMARC aggregate reports show which sources send mail using the domain, how receivers evaluate SPF and DKIM, and where alignment fails. RFC 9990 defines the current aggregate-report format.^[2]

Adding a rua address without a report-handling process changes little. The organisation needs an owner, retention rules, normalisation, and a process for escalating newly observed sources. In a large domain, reports can reveal a marketing platform, a multifunction printer, a SaaS provider, or an old application that the security team did not know was sending mail. That is usually the single most valuable outcome of an email audit.

Reports should be treated as untrusted external data. A parser should not execute supplied values, fetch arbitrary referenced resources, or pass raw content into high-privilege automation without controls.

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

SPF, DKIM, and DMARC primarily concern domain authentication and message evaluation. They do not provide transport encryption between mail servers.

MTA-STS allows a receiving domain to state expectations for TLS and server identity during message delivery. TLS-RPT enables reporting of failures related to TLS negotiation, routing, and MTA-STS or DANE policy. DANE for SMTP relies on DNSSEC and TLSA records.^[6]

These mechanisms protect specific server-to-server transport paths. They are not end-to-end encryption. Mail-server administrators and destination systems may still have access to message content, which matters when assessing measures under Article 32 of the GDPR.^[15]

ARC and message forwarding

Forwarding, mailing lists, and gateways may modify messages in ways that break SPF or DKIM. ARC records an authenticated chain of earlier authentication evaluations and can provide additional context to the receiver.^[7]

ARC does not fix DMARC and does not automatically authorise delivery. The receiver must decide whether it trusts the systems that created the chain and whether the information is consistent. RFC 8617 has Experimental status, which is also worth recording in architecture documentation instead of presenting ARC as a finished answer to the forwarding problem.^[7]

SMTP smuggling and the limits of the authentication layer

Research published at USENIX Security 2025 showed that inconsistent interpretation of SMTP message boundaries across servers can permit spoofing despite SPF and DMARC. The researchers evaluated public and private mail services, open-source software, and security gateways, demonstrating that the problem cannot be reduced to an incorrect DNS record.^[12]

The audit implication is straightforward: correct SPF, DKIM, and DMARC does not prove that the entire mail path is secure. Intermediate servers, software versions, SMTP parsing behaviour, and patch status also have to be identified. That is territory shared with vulnerability scanning and hardening rather than with DNS configuration.

Mailbox security and recipient protection

Domain authentication does not protect against account takeover, and a compromised account sends mail that passes SPF, DKIM, and DMARC without complaint. An email audit therefore has to cover the platform itself:

• MFA for all accounts, with particular attention to administrative roles;
• legacy protocols that bypass modern authentication;
• outbound forwarding rules created by users;
• OAuth applications with mailbox access and the scope of their permissions;
• event logging, log retention, and alerts on unusual sign-in activity;
• the post-takeover procedure: session revocation, rule review, notifications.

Recipient protection is a separate layer: display-name impersonation detection, link and attachment analysis, marking of mail from outside the organisation, and a simple one-click way to report a suspicious message. That last element costs less than most technical measures and is the one most often missing in organisations that already have a correct DMARC record.

Gmail, Yahoo, and Outlook.com: deliverability requirements, not law

Since 1 February 2024, Gmail has required all senders to meet requirements including SPF or DKIM, TLS, and valid DNS, while senders delivering more than 5,000 messages per day to Gmail accounts must additionally use SPF, DKIM, and DMARC and meet alignment requirements for direct mail.^[8]

Yahoo requires bulk senders to use SPF and DKIM and to maintain a valid DMARC policy of at least p=none, together with alignment of the From: domain with the SPF or DKIM domain.^[9]

In 2025, Outlook.com introduced SPF, DKIM, and DMARC requirements for domains sending more than 5,000 messages per day to Microsoft's consumer services, with enforcement beginning on 5 May 2025.^[10]

These are service-provider anti-abuse and deliverability requirements. They are not general legal obligations. For organisations that need reliable delivery to these recipients, however, they become real operational requirements whose breach is visible immediately in the form of undelivered mail.

Does Polish law require DMARC

There is no general rule requiring every Polish organisation to deploy DMARC.

The KSC, following the amendment effective from 3 April 2026, requires essential and important entities to implement cybersecurity risk-management measures covering, among other matters, secure communications, access control, and protection of systems.^[13] The choice of SPF, DKIM, DMARC, MTA-STS, or DANE depends on architecture and risk rather than on a catalogue of tools.

For certain digital-service providers directly covered by Commission Implementing Regulation (EU) 2024/2690, the requirements are more specific. The regulation requires a plan for adopting modern, interoperable email-communication standards to secure email and reduce email-related threats.^[14] It still does not reduce the whole requirement to one DMARC record.

The GDPR requires security measures appropriate to the risk to personal data.^[15] DMARC can reduce the risk of exact-domain impersonation, but it is not listed as a universal requirement.

The KRI requires covered entities to protect information and systems, manage risk, update software, detect unauthorised activity, and maintain appropriate internal rules.^[16] An email-security audit may provide evidence about some of those controls in a KRI audit, but it does not replace one.

What a sound email audit looks like

The audit should begin with an inventory of domains, subdomains, and sending sources. It should identify not only the main mail system but also marketing platforms, CRM, helpdesk, multifunction devices, business applications, monitoring systems, and providers sending on behalf of the organisation.

It should then examine:

1. DNS and sending sources - SPF, DKIM, DMARC, MX, delegations, and transport-related records.
2. Real messages - Authentication-Results, Received, DKIM-Signature, and Return-Path headers.
3. Alignment - whether legitimate streams pass DMARC by the intended method.
4. Reports - whether the organisation knows all sources and can explain anomalies.
5. Transport - TLS, MTA-STS with TLS-RPT, or DANE where used.
6. The mail platform - MFA, administrative roles, legacy protocols, forwarding rules, OAuth applications, logging, and alerts.
7. User protection - anti-phishing, display-name impersonation detection, link and attachment analysis, and a reporting mechanism.
8. Procedures - provider onboarding, DNS changes, key compromise, account takeover, and retirement of old sources.

Only after legitimate streams have been confirmed should enforcement be strengthened. Moving directly from p=none to reject without visibility into actual sending can block an invoice, a system notification, or the sales team's correspondence, and the cause is often found only days later.

In 4crypto email-audit work, it is useful to combine the DNS layer with analysis of real headers and reports. A validator screenshot showing three green icons is not evidence that all mail streams work correctly.