SPF, DKIM, and DMARC Setup: A Practical DNS Guide

Short answer. SPF authorizes systems to use a domain in the SMTP envelope. DKIM signs a message with a domain-controlled key. DMARC checks whether a passing SPF or DKIM identity aligns with the domain in the visible From header, then applies the domain owner's policy. Inventory every sender first, publish the records supplied by each provider, test real messages, and move DMARC from monitoring to enforcement only after legitimate traffic passes.

SPF, DKIM, and DMARC are related, but they do not do the same job. Treating them as three boxes to tick is how legitimate customer-service mail gets blocked during a rushed DMARC rollout.

This guide uses the standards current on July 16, 2026. In particular, the current DMARC protocol is defined by RFC 9989, published in May 2026. It obsoletes the protocol definition teams previously took from RFC 7489. Aggregate reporting is now specified separately in RFC 9990.

1. What each protocol actually authenticates

The distinction between authentication and alignment is essential. A message can pass SPF for a provider-owned bounce domain and still fail DMARC because that domain does not align with the From domain. A message can also pass DKIM for a provider's domain but fail DMARC for the same reason.

DMARC passes when at least one of these paths succeeds:

1. SPF passes and its authenticated domain aligns with the visible From domain.
2. DKIM passes and the d= signing domain aligns with the visible From domain.

Relaxed alignment generally allows a subdomain and its organizational domain to align. Strict alignment requires an exact domain match. Gmail and Yahoo accept relaxed alignment for their bulk-sender requirements.

2. Inventory every system that sends mail

Do this before editing DNS. List every system that can put your domain in a From address:

• marketing platform;
• ecommerce transaction emails;
• help desk and customer support;
• Google Workspace or Microsoft 365;
• password resets and product notifications;
• invoicing and review platforms;
• recruitment, sales, and event tools;
• legacy systems and forwarding services.

For each system, capture:

Do not infer these values from a vendor's brand name. Send a real message to a test mailbox and inspect its full headers. Provider defaults and custom sending-domain configurations can produce different identities.

3. Configure SPF without breaking existing senders

RFC 7208 defines SPF. The record starts with v=spf1 and ends with an all mechanism. A simple example looks like this:

example.com. 3600 IN TXT "v=spf1 include:provider.example ~all"

This is an illustration, not a record to copy. Use the exact include domain or IP mechanisms documented in your sender's admin panel.

SPF setup checklist

1. Find the domain used in the SMTP envelope or custom Return-Path.
2. Query its existing TXT records.
3. If an SPF record exists, update it instead of publishing a second SPF record.
4. Add only mechanisms required by active senders.
5. Confirm the record remains within SPF's limit of 10 DNS-querying terms during evaluation.
6. Test messages from every sender after the change.

The 10-lookup limit is not the same as 10 visible include: terms. Nested includes and redirect mechanisms can also trigger DNS queries. "SPF flattening" creates operational risk because provider IP ranges can change. First remove unused senders and reduce unnecessary includes. If the record remains too complex, redesign the sending-domain structure with the providers involved.

~all or -all?

~all returns a softfail for non-authorized sources. -all returns fail. Neither setting tells a mailbox provider to reject a message on its own. DMARC alignment and the receiver's policy still matter.

Choose the qualifier based on a complete sender inventory and testing. Do not use ~all as a permanent substitute for understanding unknown traffic, and do not switch to -all simply because it sounds more secure.

4. Configure DKIM with provider-generated selectors

RFC 6376 defines DKIM signatures. A sender signs selected headers and the body with a private key. The receiving system retrieves the public key from DNS using the selector and signing domain.

A DKIM key is queried at:

selector._domainkey.signing-domain.example

Providers commonly ask you to publish either:

• a TXT record containing the public key; or
• a CNAME that lets the provider host and rotate the key.

Publish the exact hostnames and targets shown in your account. Do not reuse Klaviyo, Google, or another customer's sample selectors. If your DNS provider offers HTTP proxying, mail-authentication records must remain normal DNS records, not proxied web records.

DKIM setup checklist

1. Enable a custom sending domain in the sending platform.
2. Copy every DKIM record exactly, including its selector.
3. Wait for DNS according to the record's TTL and provider status.
4. Use the platform's verification step.
5. Send a real message and confirm dkim=pass in Authentication-Results.
6. Confirm the DKIM d= domain aligns with the visible From domain.

More than one DKIM selector is normal. Different senders and key rotations should use different selectors. Retire an old selector only after the related sender has stopped signing with it.

5. Publish DMARC in monitoring mode

DMARC records live at _dmarc under the domain whose policy you control. A minimal monitoring record with aggregate reporting can look like this:

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

Tags used in a basic rollout include:

The reporting mailbox must be able to handle XML reports and potential volume. If reports go to a domain different from the policy domain, additional DNS authorization can be required. A managed DMARC reporting service can make the data easier to read, but the service must not become the only place where sender ownership is documented.

6. Read reports before enforcing policy

Aggregate reports show authentication and disposition data grouped by source. Use them to answer:

• Which IPs send mail using the domain?
• Which sources pass SPF?
• Which sources pass DKIM?
• Which passing identities align with the From domain?
• Is the source legitimate, obsolete, or abusive?
• Who owns the fix?

Classify every material source. For a legitimate source that fails, correct its custom Return-Path, DKIM signing domain, or provider configuration. For an unknown source, investigate before authorizing it. Adding every observed IP to SPF would authorize attackers along with real senders.

RFC 9989 advises domains planning p=reject to use aggregate data first, with at least a month at p=none followed by an equally long period at p=quarantine, then compare results. The exact schedule still depends on mail volume and business risk. A low-volume seasonal sender may need longer to observe all legitimate streams.

7. Move from monitoring to enforcement

Use explicit release gates rather than a calendar alone.

Gate 1: monitoring

Keep p=none while:

• known senders are still missing from the inventory;
• legitimate high-volume streams fail alignment;
• owners have not validated transaction, support, and employee mail;
• aggregate reports are not being reviewed.

Gate 2: quarantine

Move to p=quarantine after material legitimate sources pass and incidents have owners. Monitor changes in support tickets, delivery errors, and DMARC reports. Confirm that forwarded and mailing-list traffic relevant to the organization is understood.

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

Gate 3: reject

Move to p=reject only when the business accepts the operational result: unauthenticated, non-aligned mail using the domain can be rejected by receivers applying the policy.

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

Continue reviewing reports after enforcement. DMARC is an operating process, not a one-time DNS project. New software can create a new mail stream at any time.

8. Verify real traffic, not just DNS syntax

A DNS lookup can prove that a record exists. It cannot prove that a provider uses the intended domain on every message.

For each sender:

1. Send to a mailbox you control at Gmail or another provider.
2. Open the original message or full headers.
3. Find Authentication-Results.
4. Record SPF, DKIM, and DMARC results.
5. Compare the authenticated domains with the visible From domain.
6. Repeat for marketing, transactional, and support messages.

A healthy result often resembles:

spf=pass smtp.mailfrom=bounce.mail.example.com
dkim=pass header.d=mail.example.com
dmarc=pass header.from=example.com

The exact subdomains will differ. What matters is that at least one passing SPF or DKIM identity aligns with header.from.

9. Common failures and fixes

10. Implementation checklist

• [ ] Every mail stream has an owner
• [ ] Existing SPF records have been inventoried
• [ ] SPF stays within protocol lookup limits
• [ ] Each provider's DKIM selectors are published and passing
• [ ] At least one passing identity aligns with the visible From domain
• [ ] DMARC aggregate reports reach a monitored system
• [ ] Marketing, transactional, support, and employee mail have been tested
• [ ] Policy changes have a rollback owner
• [ ] New vendors cannot send from the domain without an authentication review

11. FAQ

Do I need SPF, DKIM, and DMARC if I send fewer than 5,000 emails a day?

Gmail requires all senders to personal Gmail accounts to use SPF or DKIM. Its bulk-sender requirements add both SPF and DKIM, DMARC, alignment, and other controls. In practice, configuring all three protects your domain and avoids rebuilding the foundation when volume grows.

Should DMARC be published on the root domain or the marketing subdomain?

Start with the domain visible in the From header and map how its organizational-domain policy applies. A root-domain policy can cover subdomains, while explicit subdomain records or the sp tag can change that behavior. Review the full domain architecture before publishing enforcement.

Can I have several DKIM records?

Yes. Selectors allow multiple keys and providers to coexist. Each sender should use a selector it owns, and old keys should remain available until no in-flight or retried mail depends on them.

Does p=reject stop all spoofing?

No. It gives participating receivers a strong handling request for messages that use your domain and fail DMARC. Attackers can use lookalike domains, display-name impersonation, or channels outside email. DMARC is important, but it is not a complete anti-phishing program.

Does DKIM encrypt the message?

No. DKIM signs selected message content so a receiver can verify the signature. It does not encrypt the message body. TLS protects transport between cooperating mail servers.

Should I publish forensic reporting tags?

Do not add them by default. Failure reports have limited provider support and can contain sensitive data. Decide with security, privacy, and legal owners whether the operational value justifies collection.

Sources checked on July 16, 2026

• RFC 7208: Sender Policy Framework
• RFC 6376: DomainKeys Identified Mail Signatures
• RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance
• RFC 9990: DMARC Aggregate Reporting
• Gmail email sender guidelines
• Yahoo Sender Hub best practices

Need a second pair of eyes on your DNS?

Deliver can inventory your mail streams, validate alignment, and plan a DMARC rollout without disrupting legitimate mail. Book an email authentication audit.

Related guide:

• Email deliverability guide

Charlotte Rodrigues, Head of CRM at Deliver.