https://nalar.dev/tags/email-security/ Recent content in Email Security on Nalar Hugo en-us Wed, 23 Sep 2026 00:00:00 +0000 https://nalar.dev/dmarc-ties-mail-authentication-to-visible-from-domain/ Wed, 23 Sep 2026 00:00:00 +0000 https://nalar.dev/dmarc-ties-mail-authentication-to-visible-from-domain/ <p>Email can carry several domain identities at once. The address displayed in the <code>From</code> header can differ from the envelope sender used by SMTP, while a DKIM signature can name yet another domain in its <code>d=</code> tag. SPF and DKIM authenticate identities from those separate protocol layers; neither mechanism alone requires its authenticated domain to match the domain presented to a recipient in <code>From</code>.</p> <p>Domain-based Message Authentication, Reporting, and Conformance (DMARC), specified in RFC 7489, connects those layers. A receiver evaluates SPF and DKIM, tests domain alignment against the RFC5322.From domain, and obtains a policy published by that domain. A message passes DMARC when at least one qualifying SPF or DKIM path both authenticates successfully and aligns.</p> https://nalar.dev/mta-sts-enforces-authenticated-tls-for-smtp-delivery/ Wed, 23 Sep 2026 00:00:00 +0000 https://nalar.dev/mta-sts-enforces-authenticated-tls-for-smtp-delivery/ <h1 id="mta-sts-enforces-authenticated-tls-for-smtp-delivery">MTA-STS Enforces Authenticated TLS for SMTP Delivery</h1> <p>SMTP STARTTLS can encrypt mail transport, but ordinary opportunistic TLS permits delivery to continue when encryption is unavailable. That compatibility behavior leaves room for an active intermediary to suppress STARTTLS or redirect delivery toward an unintended server.</p> <p>SMTP MTA Strict Transport Security, defined by RFC 8461, gives a recipient domain a policy channel for conforming sending MTAs. The policy states which MX hosts are acceptable and whether delivery must use TLS with a valid PKIX certificate. In <code>enforce</code> mode, a sender does not silently downgrade when those checks fail.</p>