Anyone who has managed a mailbox knows the problem: a message arrives claiming to be from your bank, your boss, or a vendor, but something feels off. Attackers forge the "From" address because plain email was never designed to prove who actually sent a message. SPF, DKIM, and DMARC are the three DNS-based records that close that gap.
These three appear in CompTIA A+ Core 1 (220-1201) under the networking domain, in the objective covering DNS, DHCP, VLANs, and VPNs. The exam expects you to recognize each record type, know that all three live in DNS as text records, and understand what each one verifies. In this article you'll learn what each record does, how they work together, and the practical checks a technician performs when email won't authenticate.
Why email needs authentication in the first place
The core weakness is simple. The Simple Mail Transfer Protocol (SMTP) lets a sending server put almost any address in the "From" field. Nothing in the original protocol checks whether that server has permission to send for that domain. This is why phishing and spoofing work so well: a spammer can type billing@yourcompany.com into the From line and the receiving server has no built-in way to tell it's fake.
SPF, DKIM, and DMARC add that missing verification, and they do it through DNS. Each one is published as a DNS record on the domain that owns the email address. When a receiving mail server gets a message, it queries the sending domain's DNS, reads these records, and decides whether the message is trustworthy. In exam terms, remember that all three are DNS text (TXT) records, which is exactly why this topic sits inside a DNS objective rather than a security objective on the A+.
SPF tells receivers which servers are allowed to send
SPF stands for Sender Policy Framework. It answers one question: which mail servers are authorized to send email for this domain? The domain owner publishes a list of approved sending sources, and the receiving server checks incoming mail against that list.
SPF is published as a single TXT record in DNS. A typical record looks like this:
v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.10 -all
Reading it left to right: v=spf1 identifies it as an SPF version 1 record. The include statements pull in the sending IP ranges of services you use, such as a hosted email provider or a marketing platform. The ip4 entry authorizes a specific address directly. The final -all is the enforcement rule, and it matters a lot.
The mechanism at the end tells the receiver what to do with mail from a server that isn't on the list:
-all(hard fail) says reject anything not listed.~all(soft fail) says accept but mark it as suspicious.+allsays allow anything, which defeats the purpose and should never be used.
When a receiving server gets a message, it looks at the connecting server's IP address, queries the sending domain's SPF record, and checks whether that IP is authorized. If it isn't, the receiver applies the policy in the record.
SPF has one important limitation you should understand. It checks the envelope sender (the address used during the SMTP handshake), not necessarily the "From" address the user sees. It also breaks when mail is forwarded, because the forwarding server's IP won't be on the original domain's list. That gap is one reason the other two records exist.
DKIM proves the message wasn't altered and really came from the domain
DKIM stands for DomainKeys Identified Mail. Where SPF checks the sending server's address, DKIM verifies the message itself using a digital signature. This lets a receiver confirm two things: the message genuinely came from the claimed domain, and it wasn't changed in transit.
DKIM uses public-key cryptography. The sending mail server holds a private key and uses it to sign outgoing messages, adding a signature to the email header. The matching public key is published in DNS as a TXT record.