SPF, DKIM, DMARC, and Friends: The Enterprise Security Capabilities Security+ Expects You to Configure
Chris Rees
25+ years in IT · Pluralsight author, 4.6/5 across 2,000+ ratings
Domain 4 is the largest domain on Security+ and objective 4.5 is its toolbox: the capabilities an enterprise actually deploys to enforce everything the earlier objectives described. The questions are practical. A scenario names a problem, and the answers name four real products, and only one of them sits where it could see the problem. Here is each capability, what it can and cannot see, and the one flow that candidates most often get backwards: how SPF, DKIM and DMARC fit together.
Capabilities are placement decisions
Every capability in this objective has a vantage point, and its vantage point decides what it can do. An endpoint agent sees processes and files but not the wire. A gateway sees traffic but not what a process does after the download completes. A DNS filter sees every name a machine asks for, and nothing about what happened after the answer came back.
That is the lens for the whole objective. When the scenario describes a problem, ask where the evidence of that problem would be visible, and pick the capability that lives there.
Email: three records, one decision
Email authentication is three separate mechanisms that candidates tend to merge into one. Each answers a different question, and DMARC is the only one that makes a decision.
SPF is a list of IP addresses and hosts allowed to send mail for your domain. The receiver looks at the server the message came from and checks the list. It fails when mail is forwarded, because the forwarder is not on the list, which is why SPF alone is not enough.
DKIM signs the message. The sending server signs the headers and body with a private key; the receiver fetches the public key from DNS and verifies. It survives forwarding, and it proves the content was not altered, which SPF cannot.
DMARC is the policy layer. It says: if neither SPF nor DKIM passes in alignment with the visible From address, do this: nothing (p=none, monitoring only), send it to spam (quarantine), or refuse it (reject). It also asks receivers to send aggregate reports, which is the only way a domain owner ever learns their domain is being spoofed.
The exam pattern: a scenario where attackers are sending mail that appears to come from the company's domain wants DMARC set to reject, with SPF and DKIM in place to give DMARC something to evaluate. A scenario about forwarded mail failing authentication is describing SPF's weakness and wants DKIM. And an organization that just published its records should start at p=none, because reject with a misconfigured record blocks its own mail.
A secure email gateway is the box that does all of this checking plus filtering for malware, phishing and spam, and it sits inline in front of the mail server. It is the "email security" product the objective is pointing at.
Web and DNS filtering: two vantage points
Web filtering comes in two shapes and the objective names both. Agent-based filtering runs on the endpoint and follows the device wherever it goes, which is the answer for a remote workforce. Centralized proxy filtering runs at the network edge and sees every device on the network without installing anything, which is the answer for a campus or a guest network, and it fails the moment the laptop leaves the building.
What the filter does with what it sees is the same either way: URL scanning for known-bad destinations, content categorization so policy can say "no gambling, no personal storage," block rules for specific sites, and reputation scoring for the ones nobody has categorized yet.
DNS filtering is the lightweight cousin. Every connection starts with a name lookup, so a resolver that refuses to answer for malicious domains stops the connection before it starts, on every device that uses that resolver, with no agent and no proxy. It sees nothing after the lookup, which means it cannot inspect content, but it is the cheapest broad control in the objective and the one that catches malware calling home.
DLP: what it can see decides what it can do
Data loss prevention exists to stop sensitive data leaving, and its effectiveness is entirely about placement. Endpoint DLP sees files being copied to USB, printed or pasted into a browser. Network DLP sees data crossing the perimeter in mail and web traffic, until the traffic is encrypted, at which point it sees nothing unless the proxy decrypts. Cloud DLP, usually through a CASB, sees what lands in sanctioned SaaS.
The exam's DLP questions hinge on that. A scenario about an employee emailing a spreadsheet of card numbers wants network or email DLP. One about the same spreadsheet on a USB drive wants endpoint DLP. One about it being uploaded to a personal cloud account over HTTPS wants either endpoint DLP or a decrypting proxy, because network DLP alone is blind to the encrypted upload.
Endpoint: EDR, XDR, HIPS and FIM
Four capabilities live on the host, and the differences are about scope.
| Capability | What it watches | What it does | Distinguishing feature |
|---|---|---|---|
| HIPS | activity on one host | blocks known-bad behavior in real time | prevention, host-only |
| EDR | processes, files, network on each endpoint | records, detects, lets analysts investigate and respond | the recording and the response tooling |
| XDR | endpoints plus identity, email, cloud, network | correlates across all of them | the correlation across sources |
| FIM | specific files and configurations | alerts when they change | integrity, not malware |
EDR versus XDR is the pair to have straight. EDR is deep on the endpoint. XDR takes EDR's approach and extends it across other telemetry sources, so it can connect a phishing email, the login that followed, and the process that ran, as one incident. A scenario that complains analysts cannot see the link between the email and the endpoint activity is asking for XDR.
File integrity monitoring is the quiet one. It does not look for malware; it looks for change. A system binary, a web server's document root or a configuration file that changed outside a change window is the signal, and FIM is a detective control that compliance frameworks require for exactly that reason.
NAC: checking the device before it gets a network
Network access control answers the question the perimeter never asked: is the thing plugging in allowed here, and is it healthy? The device authenticates (typically 802.1X), NAC checks its posture (patches current, endpoint protection running, disk encrypted), and the device is placed on the production network, a remediation network, or nowhere. A scenario about contractors' laptops or an unmanaged device appearing on the LAN is a NAC question.
The placement map
Five stems, placed
- Phishing mail spoofing the company's own domain is reaching customers. The company's problem is what other servers do with mail claiming to be from it: publish SPF and DKIM, then set DMARC to reject.
- Remote employees on home networks are reaching sites the office proxy would block. The proxy cannot see them. Agent-based web filtering, or DNS filtering pointed at a managed resolver.
- An analyst can see a malicious process on a laptop but cannot tell which email delivered it or which account it used. The gap is correlation across sources: XDR.
- A web server's configuration file changed at 3 a.m. with no change ticket. Nobody is asking about malware; the question is about unauthorized change. File integrity monitoring.
- A visitor plugged a personal laptop into a conference room port and reached the finance VLAN. The device was never checked before getting a network. NAC with posture assessment, backed by 802.1X.
Everything else in the objective is covered elsewhere on this blog: firewall rule anatomy and screened subnets in secure network architecture, and the identity capabilities in IAM. Objective 4.5 is where those pieces get deployed as products, and the map above is the fastest way to place any of them.
Key takeaways
- SPF lists who may send, DKIM signs the message, DMARC decides. Start at p=none, move to quarantine, finish at reject. Forwarding breaks SPF; DKIM survives it.
- Agent-based filtering follows the device; a centralized proxy covers the network. DNS filtering stops connections before they start, on every device, without inspecting content.
- DLP can only stop what it can see. Endpoint for USB and print, network for mail and web until it is encrypted, cloud for SaaS.
- EDR is deep on the endpoint; XDR correlates across endpoint, email, identity and cloud. FIM watches for change, not malware.
- NAC checks identity and posture before granting a network. Unmanaged or contractor devices on the LAN are a NAC question.
Enterprise security capabilities are objective 4.5 of Security+ Domain 4, Security Operations, the largest domain on the exam at 28%. Work all 39 Domain 4 topics, from hardening and asset management through monitoring, IAM, automation and incident response, with our Security+ Domain 4 study guide.
#SecurityPlus #SY0701 #EmailSecurity #SPF #DKIM #DMARC #EDR #XDR #DLP #NAC #CompTIA #CyberSecurity
This is the biggest domain on your exam
Security Operations is 28% of Security+, more than any other domain. Master all 9 objectives, from hardening to incident response, with our Domain 4 guide.
Get the Domain 4 guideKeep reading
On-Prem to Serverless: Architecture Models, the Line That Moves, and the Twelve Considerations Security+ Scores Them By
Objective 3.1 reads like a glossary, but the exam never asks for a definition. It describes a workload, names a constraint, and asks which model fits or which risk you accepted. Every model as one decision about how much of the stack you control: the responsibility line from on-prem to SaaS, IaC, serverless and microservices, air gap versus VLAN versus SDN, hypervisor versus kernel, the devices you cannot patch, and the twelve considerations that turn a stem into a rubric.
Read Security+ deep divesBuilt to Survive: High Availability, Backups, and Power, the Half of Security+ Domain 3 Nobody Studies
Availability is the third letter of the triad and the objective candidates skim. Security+ 3.4 in full: load balancing and clustering, active-active versus active-passive, platform and geographic diversity, the full, incremental and differential trade-off drawn as a chart, snapshots, replication and journaling, UPS versus generator, and the capacity planning question the exam hides in a story about a hiring freeze.
Read Security+ deep divesRansomware, Rootkits, and Logic Bombs: Malware Types and the Indicators Security+ Expects You to Spot
Objective 2.4 is the longest list in Security+ and the one that turns into the most scenario questions. Malware classified by how it spreads and what it does, the attack families beyond malware, and the nine indicators of malicious activity, from impossible travel to missing logs, that tell you which attack a stem is describing before you read the answers.
ReadEnjoyed this? Get the AI security news that matters.
Join The AI Security Brief for the top AI security news, plus what's important to the C-suite. Free, straight to your inbox.
No spam. Unsubscribe anytime.