Cisco 300-720 SESA common mistakes
Cisco 300-720 SESA · Understand the traps and how to avoid them.
Treating the HAT (Host Access Table) sender groups as if they were content-matching rules, so candidates configure a mail flow policy for a sender group and then expect messages from that group to be filtered by content filters without any filter referencing the group. Candidates also forget that a listener must be selected and that the HAT is per-listener.
The HAT and mail flow policies govern connection-level behaviour (TLS requirement, max recipients, max message size, basic vs. rejected senders), while content filters and message filters run later in the pipeline. Because both are configured under Mail Policies, candidates conflate the two and mispredict which stage will act on a message.
What to do instead
Draw the processing order explicitly on scratch paper: listener → HAT/mail flow policy → sender/receiver verification and reputation → anti-spam/anti-virus/outbreak → content filters and DLP → message filters → routing. For each requirement in a question, ask 'at which stage is this evaluated?' before choosing a feature. Remember each listener has its own HAT, so always confirm which listener the traffic arrives on.
Assuming a configuration change is live as soon as it is committed. Candidates answer questions as if commit were instantaneous and global, ignoring that commit applies to the whole appliance, can take time, may be blocked by pending changes elsewhere, and that some settings (listener ports, interface changes, some certificate operations) require additional steps or a restart.
The web UI presents edits as if they were immediate, and the concept of a staged configuration that must be committed is unfamiliar to candidates coming from platforms that apply changes immediately. Questions about 'why is the change not taking effect' are usually about uncommitted changes or a cluster where the commit has not propagated.
What to do instead
Memorise the rule: nothing takes effect until commit, and commit is appliance-wide, not per-section. Check the pending-changes indicator before troubleshooting. Know that in a cluster the commit must reach every machine, and that some changes need a listener restart or a reboot. When a scenario says 'the administrator saved the change but behaviour is unchanged', the first hypothesis should be an uncommitted or partially propagated configuration.
Confusing SPF, DKIM, and DMARC roles and misreading the DMARC alignment requirement. Candidates state that DMARC passes when either SPF or DKIM passes, without checking that the passing identifier is aligned with the From domain, or they believe SPF alone protects the visible From header.
All three mechanisms are usually taught together and all three 'authenticate email', so candidates collapse them into one concept. The subtlety that SPF authenticates the envelope sender (MAIL FROM / HELO) and DKIM authenticates a signing domain, while DMARC requires alignment with the header From domain, is easy to skip.
What to do instead
Learn each mechanism by the identifier it validates: SPF → envelope sender and connecting IP; DKIM → a d= domain and selector with a cryptographic signature over specified headers; DMARC → alignment of an authenticated identifier with the header From domain, plus a policy (none/quarantine/reject) and reporting addresses. Practise reading a DMARC record field by field (v, p, sp, pct, rua, ruf, adkim, aspf) and work through a case where SPF passes for a different domain and DMARC still fails on alignment.
Mishandling DKIM signing configuration: selecting the wrong signing key or selector, signing the wrong profile, or expecting the appliance to sign messages it does not actually relay or that are routed around the signing configuration.
DKIM signing on the appliance is tied to a signing profile with a domain, selector, and private key, and is applied through the relevant mail flow or content/message filter action. Candidates set up the key but never attach signing to the traffic path, or they attach it to the wrong direction (inbound vs. outbound).
What to do instead
Trace the exact path: which listener receives the mail, which mail flow policy or filter action applies the DKIM signing profile, and whether the message is outbound from a domain covered by the profile. Verify the selector matches the DNS record published for that domain, and confirm the private key loaded correctly. When troubleshooting a DKIM failure, separate 'not signed at all' from 'signed but verification fails' (key/selector/DNS mismatch, body modified in transit).
Misconfiguring TLS on the appliance: setting the outbound TLS support level without understanding the difference between opportunistic and required, or assuming a certificate alone encrypts mail. Candidates also forget that inbound TLS enforcement is a mail flow policy/HAT setting, not a global switch.
TLS on an email gateway has two independent directions (inbound acceptance and outbound sending) and several support levels, plus certificate-based verification. Candidates learn 'enable TLS' as a single action and cannot map a requirement like 'reject plaintext from this partner' to the right control.
What to do instead
Separate the two directions in your notes. Inbound: HAT sender group / mail flow policy controls whether TLS is required, preferred, or optional for connections from that group. Outbound: the destination controls and TLS support level determine whether the appliance requires, prefers, or does not use TLS. For guaranteed encryption to a specific partner, use a TLS-required destination or an encrypted message policy rather than relying on opportunistic TLS.
Treating anti-spam verdicts as binary. Candidates assume a message is either spam or not, and cannot reason about the interplay of the spam threshold, the suspect spam (mark) threshold, positive/negative scores, and per-policy overrides when asked what happens to a message with a given score.
The appliance classifies into negative, suspect, and positive ranges using configurable thresholds, and mail policies can override thresholds per sender or recipient group. Questions often give a score and ask for the outcome, and candidates answer from intuition rather than the threshold logic.
What to do instead
Memorise the three-band model: score below the suspect threshold → likely not spam; between suspect and spam thresholds → suspect spam (subject tagging or quarantine depending on configuration); at or above the spam threshold → spam action (quarantine, drop, or deliver with tag). Then check whether the applicable mail policy overrides the global thresholds. Practise mapping a numeric score against a stated threshold pair to the resulting action.
Confusing content filters with message filters, or building a content filter whose conditions and actions do not match the stated goal (for example, using a content filter to drop a message when the requirement is to modify a header, or expecting a content filter to act on an attachment type without the right condition).
Both are rule engines with conditions and actions, and both can quarantine, drop, or modify. The distinctions (content filters operate on message content with conditions like body text, attachment type, and can be applied per mail policy; message filters are text-based rules with a different syntax and typically act on envelope/header data) are easy to blur under exam pressure.
What to do instead
Build a comparison table: what each rule type can match on, where it sits in the pipeline, and how it is applied (per-policy vs. global). For every practice scenario, write the condition in plain language first ('attachment filename ends with .exe'), then choose the rule type that can express it. Verify the action ordering, since multiple matching filters can all fire and later actions may override earlier ones.
Underestimating DLP configuration dependencies: creating a DLP policy without the classification markers or content matching classifiers it relies on, or expecting DLP to act on outbound mail without the policy being applied to the correct mail flow policy.
DLP on the appliance is layered: classifiers/markers detect sensitive content, DLP policies define what to detect and what action to take, and the policy must be enabled for the relevant mail flow policy (inbound or outbound). Candidates configure one layer and assume the rest is automatic.
What to do instead
Walk the dependency chain every time: sensitive data pattern or classifier exists → DLP policy references it → policy is enabled on the outbound (or inbound) mail flow policy → action (quarantine, drop, encrypt, notify) is configured. Test with a sample message that should trigger and one that should not. Remember that DLP is typically applied to outbound traffic, so an inbound-only scenario should prompt you to question the premise.
Ignoring the message tracking and logging tools when a scenario asks for a diagnosis. Candidates guess at the cause instead of naming the specific place to look: message tracking for delivery and verdict details, mail logs for SMTP conversation detail, and the quarantine for held messages.
Troubleshooting questions reward knowing where evidence lives. Candidates who have not used the tracking and log interfaces fall back on generic answers like 'check the configuration' and cannot distinguish a routing problem from a filtering problem.
What to do instead
Memorise what each tool answers: message tracking answers 'what happened to this message and which filters fired'; mail logs answer 'what did the SMTP conversation look like, including TLS and rejection codes'; quarantine answers 'is it held and why'. For any troubleshooting scenario, state the symptom, name the tool that would confirm or refute each hypothesis, and only then propose the fix.
Mishandling integration scenarios: assuming the appliance can be dropped into an existing mail environment without adjusting listeners, routing, and the upstream/downstream relationship, or forgetting that the appliance's own notifications and alerts need a working delivery path.
Integration questions combine several domains at once (listeners, routing, TLS, authentication, directory integration). Candidates focus on the single feature named in the question and miss the surrounding prerequisites, such as a listener that accepts the traffic, a route to the destination, or directory/LDAP reachability for recipient validation.
What to do instead
For any integration scenario, list the prerequisites in order: interface and listener configured for the expected traffic, HAT accepting the sending hosts, a route or destination for onward delivery, authentication or directory services reachable if used, and alert/notification delivery working. Check each prerequisite against the scenario before selecting an answer, and prefer the answer that addresses the earliest broken link in that chain.