SPF, DKIM and DMARC as DNS records: what each one is doing
Email authentication via DNS records has become critical infrastructure for any organization managing a domain. Three standards work together to verify that mail claiming to come from your domain actually originates from authorized servers, and to define what happens when it does not. SPF, DKIM, and DMARC are not redundant; each solves a different part of the authentication problem, and all three are typically deployed together. Understanding what each record does, and how they interact, is essential for network engineers responsible for mail infrastructure, DNS management, or domain security.
SPF: Sender Policy Framework
SPF is a DNS TXT record that tells receiving mail servers which IP addresses or hostnames are authorized to send mail on behalf of your domain. When an inbound mail server receives a message claiming to be from user@yourdomain.com, it queries DNS for your SPF record and checks whether the sending server's IP is in the authorized list.
SPF records use a simple syntax with mechanisms that specify allowed senders. The most common mechanisms are:
- →a: Authorizes the A record IP of your domain
- →mx: Authorizes IPs listed in your MX records
- →ip4 / ip6: Explicitly authorizes a specific IPv4 or IPv6 address
- →include: References another domain's SPF policy
- →all: A catch-all that applies a default action (usually -all to reject, or ~all to soft-fail)
v=spf1 ip4:192.0.2.1 include:sendgrid.net include:mailchimp.com ~all
SPF alone does not cryptographically prove that a message is authentic; it only confirms the sending IP is authorized. A determined attacker can still forge the From header. That is where DKIM enters.
DKIM: DomainKeys Identified Mail
DKIM adds cryptographic signing to email. The sending mail server signs the message body and headers using a private key, and publishes the corresponding public key in DNS. Receiving servers retrieve that public key and verify the signature. If the message was altered in transit, or if the signature was forged, verification fails.
DKIM records are published as DNS TXT records under a subdomain selector. The standard format is selector._domainkey.yourdomain.com. A domain can have multiple selectors to support key rotation or multiple sending systems.
default._domainkey.yourdomain.com TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC..."
DKIM is stronger than SPF because it is cryptographic and survives forwarding. However, it does not tell receiving servers what to do if verification fails, and it does not provide reporting. That is the role of DMARC.
DMARC: Domain-based Message Authentication, Reporting and Conformance
DMARC is a DNS TXT record published at _dmarc.yourdomain.com that defines a policy for how mail servers should handle messages that fail SPF or DKIM checks. It also requests that receiving servers send reports back to you about authentication results.
A DMARC policy specifies:
- →p=none: Monitor only; do not take action on failures
- →p=quarantine: Move failed messages to spam or junk folder
- →p=reject: Refuse to deliver failed messages
- →rua: Email address for aggregate reports (summary of results)
- →ruf: Email address for forensic reports (details of failed messages)
- →aspf / adkim: Whether alignment is required (relaxed or strict)
v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com; ruf=mailto:dmarc-forensics@yourdomain.com; fo=1
DMARC also enforces alignment: SPF alignment means the domain in the SPF check matches the From header domain; DKIM alignment means the domain in the DKIM signature matches the From header. Only aligned results count toward policy enforcement.
How They Work Together
Deploy SPF first to authorize your mail servers. Add DKIM to cryptographically sign messages. Then deploy DMARC to define what receiving servers should do and to receive feedback on your authentication posture. Start with p=none to gather data, then move to p=quarantine and finally p=reject once you are confident all legitimate mail passes authentication. This layered approach protects your domain reputation and reduces the risk of spoofing.