SPF, DKIM and DMARC: Checks, Policies and Limits

The visible sender address of an email can be forged. SPF, DKIM and DMARC help verify the domains involved. Passing authentication does not prove that the content is safe or identify a particular person.

SPF checks whether an IP address is authorised to send, DKIM checks a digital signature, and DMARC also checks the connection to the visible sender domain. The receiving system decides whether to accept, filter or reject the message. An SPF fail can support rejection even without DMARC.

SPF: Does the sending IP match the envelope domain?

SMTP uses a technical envelope address (MAIL FROM) alongside the visible From header. SPF normally checks the envelope domain; with an empty envelope sender, the HELO domain supplies the identity. An SPF pass therefore does not authenticate the visible From domain by itself.

The DNS record describes authorised sending sources. For otherwise unmatched sources, -all produces fail and ~all produces softfail. Fail means that the SPF policy does not authorise that source, rather than proving forgery: legitimate forwarding can also break SPF. Other results include neutral, none, temporary errors and permanent errors.

The limit counts evaluated SPF terms

At most ten DNS-triggering terms may be evaluated across include, a, mx, ptr, exists and redirect, including nested evaluation. This is not a general limit of ten DNS packets. Additional limits apply to certain lookups.

ip4, ip6 and all do not consume this budget. An early match ends evaluation, so later references are not counted. Exceeding the limit produces permerror for that evaluation. Changes at an included sending service can trigger the error without necessarily invalidating every possible evaluation path.

DKIM protects signed parts, not every byte

The sending system signs with a private key; the receiver verifies with the public DNS key. Protection covers the signed headers and covered body content after defined normalisation: the selected rules can ignore certain formatting differences, such as some whitespace changes. A signature can even cover only part of the body. DKIM pass therefore does not mean that every character of the entire message remained unchanged.

For RSA, RFC 8301 requires at least 1024 bits and recommends at least 2048 bits. A 1024-bit key is not automatically invalid under that standard, but 2048 bits is the better baseline for new RSA configurations. Ed25519 uses different key sizes; comparing the numbers directly with RSA would be misleading.

A long key can occupy one TXT record containing several character strings of at most 255 bytes each. Several strings within one record are different from several separate TXT records. A DNS provider’s interface may handle this splitting automatically.

The correct selector appears as s= in an actual DKIM-Signature; d= supplies the signing domain. The DNS name is selector._domainkey.domain. Guessing common selectors cannot replace this check. No match only means that no key was found at the names tested.

DMARC connects authentication to the visible From domain

DMARC passes when at least one successful SPF or DKIM result aligns with the visible From domain. Strict alignment requires identical domains; relaxed alignment requires the same organisational domain under DMARC’s domain-discovery rules. Similar-looking domain names are not sufficient.

• p=none: no special handling requested through the published DMARC policy.
• p=quarantine: messages failing DMARC should be treated as suspicious.
• p=reject: rejection of such messages is requested.

None of these settings guarantees delivery or rejection. Local filtering remains decisive. Requesting aggregate reports requires a suitable rua destination; p=none alone does not configure report delivery. Reports are not guaranteed from every receiver, even with a destination.

A sensible rollout starts with an inventory of sending services and representative tests and reports, including monthly invoices and infrequent delivery paths. A stricter policy follows once appropriate. No fixed number of weeks or mandatory intermediate quarantine stage follows from the protocol.

What a DNS check can establish

The Email Authentication Checker provides an inventory of DNS records. The current SPF counter traverses references statically instead of simulating a particular message and sending IP. MX records do not prove SMTP reachability. A parent DMARC policy can apply to a subdomain, so an absent direct record does not prove the absence of a policy.

A reliable sending test also needs messages from every legitimate sending system and authentication results at a trusted receiver. A DNS snapshot cannot predict whether every forged message will be rejected.