Filter by the layer you are operating. Every article is scoped to one question and links back to primary technical sources.
SPF is evaluated from a single policy record for a domain; multiple independent SPF TXT records can create a permanent error instead of broader authorization.
Read field note →
A DKIM selector tells receivers which public key record to retrieve; rotating selectors lets a sender change keys without changing the From domain.
Read field note →
A monitoring policy lets a domain observe alignment before moving to stricter disposition; the current protocol reference is RFC 9989, with reporting split into RFC 9990 and RFC 9991.
Read field note →
DMARC evaluates whether an authenticated SPF or DKIM domain aligns with the visible From domain, so a raw PASS can still fail the alignment requirement.
Read field note →
Start with the exact rejection code and Authentication-Results evidence before changing unrelated copy or sending volume.
Read field note →
A provider migration can leave obsolete SPF includes, old DKIM selectors or alignment paths that no longer match the message actually sent.
Read field note →Adding one legitimate sender can push an existing SPF policy over protocol limits because nested include mechanisms also consume DNS lookups. Diagnose the evaluation path before deleting or flattening records.
Read field note →A migration can leave the old provider’s SPF policy beside the new one. Receivers do not merge two v=spf1 records at the same hostname; the result can be SPF PermError.
Read field note →When DKIM reports a body-hash mismatch, the public key can be perfectly correct. The more useful question is whether something changed the message body after the DKIM signer calculated bh=.
Read field note →DKIM rotation is safer when the new key is published and verified before signers switch, while the old selector remains resolvable long enough for queued or delayed messages to finish verification.
Read field note →A DKIM selector is one DNS name. If a migration leaves both provider-hosted CNAME data and a self-hosted TXT key at that exact name, DNS semantics and DKIM lookup behavior become unreliable.
Read field note →The old pct tag from RFC 7489 is no longer part of the current DMARC base specification. Small senders should stage enforcement through testing, reporting, scoped subdomains, and controlled policy changes instead of assuming percentage rollout.
Read field note →RFC 9989 distinguishes policy for existing subdomains with sp from policy for nonexistent subdomains with np. Understanding the distinction prevents a root DMARC record from being interpreted too broadly.
Read field note →When aggregate reports are sent to a mailbox on a different domain, DMARC reporting has an authorization step intended to prevent report amplification. A syntactically valid rua value alone may not be enough.
Read field note →SPF authenticates the SMTP envelope identity, commonly exposed as Return-Path. DMARC then asks whether that authenticated domain aligns with the RFC5322 From domain the recipient sees.
Read field note →A short SPF TXT record can exceed the protocol lookup budget after nested includes are expanded. Trace the evaluated tree instead of counting only the mechanisms you can see at the root.
Read field note →SPF has a second processing guard that many dashboards omit: implementations should limit void lookups such as NXDOMAIN or empty answers, with two recommended by RFC 7208.
Read field note →Replacing provider includes with literal IP ranges reduces DNS work but removes automatic inheritance of the provider’s future infrastructure changes. That maintenance trade-off is easy to miss.
Read field note →Current DKIM crypto guidance requires RSA keys of at least 1024 bits and recommends at least 2048. A selector rotation is the safest time to check both algorithm and key length.
Read field note →DKIM canonicalization is often misunderstood as permission for gateways to rewrite messages. Relaxed mode tolerates defined formatting changes; it does not make arbitrary footer or link modification safe.
Read field note →RFC 9989 changes how DMARC policy discovery and the organizational domain are determined. The new DNS Tree Walk can differ from older PSL-based explanations and tooling.
Read field note →The old ri tag for requested aggregate-report intervals is marked historic in the current DMARC registry. RFC 9990 describes reports as typically daily or more frequent without restoring ri.
Read field note →RFC 9989 explicitly removes the ability to specify a maximum report size in the DMARC reporting URI. Old rua examples with a !size suffix should not be copied into current templates.
Read field note →