Email Security: How SPF, DKIM, and DMARC Work and How to Configure Them

An address in a message’s From field is a claim. SPF, DKIM, and DMARC give receiving systems ways to check domain authorization and detect spoofing.

Mechanism	Pronunciation	What it checks	What you configure
SPF	ess-pee-eff	Whether the connecting server’s IP address is authorized for a domain	A DNS TXT record listing authorized sources
DKIM	dee-kim	A domain’s signature and the integrity of signed content	Signing keys, DNS access to the public key, and outbound signing
DMARC	dee-mark	Whether a successful SPF or DKIM identity aligns with the visible From domain	A DNS TXT record specifying policy and reporting destinations

Domains, addresses, and keys below are examples. Use the values supplied for your actual service and domain.

Three identities to keep separate

Identity	Example	Purpose
Header From	From: sales@example.com	The sender address normally displayed by a mail client
Envelope sender, or MAIL FROM	bounce@mail.example.com	SMTP sender address used for delivery and bounce handling; normally recorded in Return-Path after delivery
DKIM signing domain	d=example.com in DKIM-Signature	The domain taking responsibility for the signature

SPF normally checks the MAIL FROM domain. An SPF pass alone does not validate the visible From address. DMARC connects those identities through domain alignment. When MAIL FROM is empty, as in some delivery notifications, SPF uses the HELO/EHLO domain.

SPF

What it does

Sender Policy Framework publishes which servers may use a domain in an SMTP identity. A receiver compares the connecting IP address with that domain’s SPF policy. It does not check message integrity or identify the person operating the account. RFC 7208

How to configure it

Inventory every sending source: employee mail, website forms, newsletters, and automated alerts. Identify the MAIL FROM domain and required SPF settings for each service.

For a domain sending exclusively through Google Workspace, Google’s example is:

example.com. IN TXT "v=spf1 include:_spf.google.com ~all"

v=spf1 identifies SPF. The include authorizes sources that pass the referenced policy. ~all returns softfail for unmatched sources; -all returns fail. Follow your provider’s instructions and establish a complete sender inventory before choosing the final policy. Neither qualifier alone dictates the receiver’s final delivery decision. Google’s SPF setup guide

For a server you operate, an entry such as ip4:192.0.2.10 can authorize an IPv4 address. This particular address is reserved for documentation.

Publish only one SPF record beginning with v=spf1 at each DNS name. Combine authorized sources into that record. Evaluation permits at most ten DNS lookup-causing terms, including nested include evaluations; exceeding the limit produces permerror. This is a limit on terms such as include, a, and mx, rather than a limit of ten sending services. RFC 7208 §4.6.4

How to verify it

Query TXT records at the actual MAIL FROM domain. These commands are alternatives; run whichever is available. Windows includes nslookup. The dig and host tools are commonly used on macOS and Linux, but may require an additional DNS utilities package.

dig example.com TXT
nslookup -type=TXT example.com
host -t TXT example.com

In Windows PowerShell, you can also use Resolve-DnsName:

Resolve-DnsName -Name example.com -Type TXT

Check the SPF value and make sure it is not duplicated. Then send a message and inspect spf=pass and smtp.mailfrom in the receiver’s results. If MAIL FROM uses mail.example.com, query that name even when the visible From uses example.com.

Forwarding can break SPF because the connecting server changes. DKIM provides another authentication path when signed content survives forwarding.

DKIM

What it does

DomainKeys Identified Mail attaches a digital signature that receivers verify using a public key retrieved through DNS. It associates signed content with a signing domain and detects changes to that content under the signature’s canonicalization rules.

DKIM does not encrypt email. It does not protect unsigned header fields or establish a human sender’s identity. For background on keys and encryption, see Hashing vs. Encryption. RFC 6376

Preparation and configuration

1. Generate a public/private key pair on your sending system, or let your managed email provider generate and manage it. Never publish the private key in DNS.
2. Make the public key available through DNS, either directly in TXT or through a CNAME pointing to provider-managed DNS.
3. After DNS verification, enable signing for the domain. Publishing a record alone does not establish that messages are being signed.

Service	Typical setup
Microsoft 365	Publish the two CNAME records supplied for your domain, then enable signing
Google Workspace	Generate a key in the Admin console, publish the supplied TXT record, then start authentication
Amazon SES Easy DKIM	Normally publish three CNAME records and verify the identity and signing status; Route 53 integration can automate DNS publication

Use your provider’s exact record names and targets. The required records depend on the service and signing method. Microsoft DKIM configuration, Google DKIM configuration, Amazon SES Easy DKIM

A direct TXT record has this structure; PUBLIC_KEY_BASE64 is a placeholder:

selector1._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=PUBLIC_KEY_BASE64"

The selector, here selector1, distinguishes keys within a domain and supports rotation. For RSA, keys of at least 2048 bits are recommended. Follow your provider’s key management and rotation procedure. RFC 8301

What happens during delivery

The sender signs the body and selected headers with its private key. It adds a DKIM-Signature header containing the signature, the signing domain in d=, and the selector in s=.

For d=example.com; s=selector1, the receiver queries selector1._domainkey.example.com, follows any CNAME delegation, and uses the public key to verify the signature. A valid signature establishes integrity for the signed content under the normalization rules. Forwarding can preserve it; a mailing list that changes signed content, such as the subject or body, can invalidate it.

How to verify it

Use the actual selector and signing domain:

dig selector1._domainkey.example.com TXT
nslookup -type=TXT selector1._domainkey.example.com
host -t TXT selector1._domainkey.example.com

For a delegated key, inspect the CNAME target too:

dig selector1._domainkey.example.com CNAME
nslookup -type=CNAME selector1._domainkey.example.com
host -t CNAME selector1._domainkey.example.com

The Windows PowerShell equivalents are:

Resolve-DnsName -Name selector1._domainkey.example.com -Type TXT
# For a delegated key, also inspect the CNAME target
Resolve-DnsName -Name selector1._domainkey.example.com -Type CNAME

For TXT publication, inspect v=DKIM1 and p=. For CNAME publication, check the supplied target and the public key available there. Then inspect a delivered message for DKIM-Signature and a receiver result of dkim=pass. The presence of a signature header alone does not prove successful verification.

DMARC

What it does

Domain-based Message Authentication, Reporting, and Conformance checks alignment with the visible From domain and publishes requested handling for failures.

Either of these paths is sufficient for DMARC to pass:

• SPF passes and its MAIL FROM domain aligns with the header From domain.
• DKIM passes and that signature’s d= domain aligns with the header From domain.

Both are not required, and an unaligned authentication pass is insufficient. Microsoft’s DMARC explanation

Default relaxed alignment accepts domains sharing an organizational domain, such as example.com and mail.example.com. Strict alignment requires an exact match. This is not a simple text suffix check: example.com.attacker.example does not align with example.com. RFC 7489 §3.1

Header From domain	SPF result / MAIL FROM domain	DKIM result / d= domain	DMARC with relaxed alignment
example.com	pass / mail.example.com	fail	pass through SPF
example.com	fail	pass / example.com	pass through DKIM
example.com	pass / vendor.example.net	pass / vendor.example.net	fail: neither identity aligns

How to configure it

Configure SPF and DKIM first, arrange a reporting destination, and publish one DMARC TXT record at _dmarc under the From domain. Begin with monitoring:

_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

Setting	Request to receivers
p=none	No quarantine or rejection requested on the basis of DMARC failure
p=quarantine	Treat failed messages as suspicious, for example by placing them in spam
p=reject	Reject messages that fail DMARC
rua=mailto:...	Send aggregate reports to this destination

p=none does not disable spam filtering. Receivers retain control over final handling, so a published policy does not guarantee a particular delivery result. RFC 7489

Review aggregate reports for legitimate sources and authentication failures, fix missing configurations, then move to quarantine and reject. Reports are generally XML and do not come from every receiver. Reporting to another domain can require DNS authorization by the destination. Check subdomain coverage too: an organizational domain’s policy applies to subdomains without their own DMARC record, and sp= can specify a subdomain policy. Google’s DMARC setup guide

How to verify it

Query the TXT record at _dmarc under the From domain:

dig _dmarc.example.com TXT
nslookup -type=TXT _dmarc.example.com
host -t TXT _dmarc.example.com

In Windows PowerShell:

Resolve-DnsName -Name _dmarc.example.com -Type TXT

Check v=DMARC1, p=, and rua=. Then send a message and inspect dmarc=pass, header.from, and the domains authenticated by SPF and DKIM.

Verify the complete sending path

You can also inspect records with the site’s DNS Lookup tool. DNS publication alone cannot confirm that a provider signs messages or that every application uses the intended sending path.

Send a test from each source to an external mailbox. In Gmail on the web, open the menu next to Reply and select Show original. Other clients provide message headers or source views. Gmail header instructions

Inspect Authentication-Results added by the receiving service. Do not automatically trust a same-named header inserted by a sender. This illustrative result shows all three checks passing:

Authentication-Results: mx.receiver.example;
    spf=pass smtp.mailfrom=mail.example.com;
    dkim=pass header.d=example.com header.s=selector1;
    dmarc=pass header.from=example.com

Both authentication domains align under relaxed rules. After changing DNS, allow for cached answers according to TTL and provider guidance before repeating tests.

Symptom	Check first
SPF fail or softfail	Actual MAIL FROM, connecting IP, missing sending services
SPF permerror	Duplicate SPF records, syntax, lookup limit
No DKIM signature	Signing enabled for the domain, actual sending route
DKIM fail	Key matching d= and s=, key rotation, changes in transit
SPF or DKIM passes but DMARC fails	Alignment with the header From domain

These mechanisms authenticate domains. They do not establish that content is harmless, stop display-name impersonation or lookalike domains, or prevent an attacker from sending through a compromised legitimate account. A pass guarantees neither inbox placement nor safe links and attachments. Gmail’s authentication guidance

References

• BIND 9: dig, nslookup, and host command reference
• RFC 7208: SPF
• RFC 6376: DKIM
• RFC 8301: DKIM cryptographic algorithm and key usage update
• RFC 7489: DMARC
• Google Workspace: Set up SPF
• Google Workspace: Set up DKIM
• Google Workspace: Set up DMARC
• Microsoft 365: Configure DKIM
• Microsoft 365: Configure DMARC
• Amazon SES: Easy DKIM
• Gmail: Trace an email with its full header
• Gmail: Check if a message is authenticated
• Suggested background: SPF, DKIM, and DMARC roles (Zenn, Japanese)