I85PREP
⌘ K
Cisco 300-720 SESA study materials
Cisco 300-720 SESA study resources

Cisco 300-720 SESA: Email Authentication and Encryption

Cisco 300-720 SESA · Work through your exam, one topic at a time.

All guide sections

Email Authentication and Encryption

This domain covers proving who sent a message and protecting it in transit or at rest: SPF, DKIM, and DMARC verification and signing, plus TLS policy, certificates, and message encryption on the ESA.

Core rules

  • SPF checks the sending IP against the domain's published record. A -all qualifier means hard fail, ~all soft fail; the verification profile decides whether a result is monitored, quarantined, or rejected.
  • DKIM signs selected headers and a body hash with a private key; the public key is published as a TXT record at <selector>._domainkey.<domain>. Verification on inbound mail compares the signature to DNS. Canonicalization (relaxed or simple) must match between signer and verifier.
  • DMARC ties SPF or DKIM to the visible From domain through alignment, and publishes policy p=none, quarantine, or reject plus report addresses. Aggregate reports let a domain owner see who is sending as them.
  • TLS can be opportunistic (try, fall back to cleartext) or required. Requiring TLS on a mail flow policy or per destination domain prevents cleartext fallback; certificate verification prevents interception with a self-signed certificate.
  • Message encryption (envelope/key-server based) and S/MIME are invoked by content filters or message filters using an encryption profile, not automatically.

Worked example

Outbound mail from example.com must be DKIM-signed. Create a signing profile with selector s1 and a 2048-bit key, publish the public key as a TXT record, and enable signing on the outbound mail flow policy. Signing must occur after any content filter that rewrites headers or the body, otherwise the body hash no longer matches. Validate by sending to an external authentication-check address and confirming dkim=pass header.d=example.com, then confirm SPF passes from the same egress IP.

Traps

  • Signing before a filter that adds a disclaimer or header invalidates the signature.
  • Publishing the DKIM key at the wrong selector, or with line breaks inserted by the DNS editor, causes permanent failures.
  • "TLS required" without certificate verification still allows a man-in-the-middle.
  • An encryption profile that no filter references never encrypts anything.
  • Certificates imported without the intermediate chain fail the handshake on many receivers.