SPF, DKIM, and DMARC: A Practical Setup Guide

SPF, DKIM, and DMARC at a glance

The three checks work as a chain, but they are not interchangeable. SPF follows the return path, DKIM follows a signed domain, and DMARC connects either result to what the recipient sees. Passing DMARC improves trust in the From domain, but it does not guarantee inbox placement or prove that a message is safe.

How does DMARC alignment decide pass or fail?

DMARC passes when SPF or DKIM passes and its domain aligns with visible From. Default relaxed alignment accepts a shared organisational domain; strict alignment requires an exact match. Aligned DKIM can preserve DMARC when forwarding breaks SPF.

How to configure SPF

Publish one SPF TXT record for each domain used in MAIL FROM. Start with v=spf1, add only the IP addresses and services that send for that domain, then finish with an all qualifier. Do not publish multiple SPF records at the same name. If a provider gives you an include value, treat it as part of that domain's lookup budget rather than copying a guessed record.

v=spf1 ip4:198.51.100.0/24 include:_spf.example.net -all

Keep SPF within the DNS lookup limit

SPF permits at most 10 DNS-querying terms, including nested terms. This covers include, a, mx, ptr, exists and redirect. More than 10 returns permerror. Count them before adding a sender, or move unrelated traffic to a return-path subdomain.

• Use the ip4 and ip6 mechanisms only for address ranges the provider documents and keeps current.

• Remove senders that no longer use the domain.

• Give a separate return-path subdomain its own SPF record when the mail architecture calls for it.

• Avoid static SPF flattening unless you also own a reliable process for tracking provider IP changes.

How to configure DKIM

DKIM signs selected headers and the body with a private key. The selector in DKIM-Signature tells receivers where to find the public key. RSA keys must be at least 1024 bits; 2048 bits is recommended. Providers may use CNAME records for rotation.

1. Generate or request a DKIM key for the sending service.

2. Publish the provider's TXT or CNAME record exactly, using the supplied selector.

3. Enable signing with your domain in the d= tag.

4. Send a real test message and confirm dkim=pass in Authentication-Results.

5. During rotation, publish the new selector before switching the signer, then retire the old key after the transition.

How to configure DMARC

Publish DMARC at _dmarc.example.com. Begin with a monitoring policy and an aggregate-report destination you can actually process. The example below uses relaxed alignment. A receiver can send XML aggregate reports to the rua address, so use a dedicated mailbox or a trusted report processor and check whether external report destinations require additional authorisation.

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; aspf=r; adkim=r

How to roll out DMARC safely in 2026

RFC 9989 removed the old pct tag because receivers applied percentage sampling inconsistently. Do not use pct=10 or pct=50 as a staged rollout. For a domain with human users, mailing lists, or other varied senders, the current standard recommends monitoring at p=none for at least one month before p=reject, then spending an equally long period at p=quarantine. The t=y tag can signal that a policy is in testing, but receivers decide how to use it.

1. Inventory every service that can send with the domain in its visible From address.

2. Publish SPF and DKIM for each legitimate path, then test alignment on received messages.

3. Publish p=none with rua, then review aggregate reports for at least one month.

4. Correct unknown sources, broken selectors, SPF errors, and unaligned third-party signatures.

5. Keep p=quarantine for the same representative period, then use p=reject only after valid mail consistently passes.

Where the DNS records belong

How to test SPF, DKIM, and DMARC

Check DNS first, then inspect a message that travelled through the real sending path. DNS confirms the records are reachable; the received Authentication-Results header confirms whether the receiver evaluated them as expected. Test each provider and each From domain, because one successful path says nothing about a different sender or selector.

dig TXT example.com
dig TXT selector1._domainkey.example.com
dig TXT _dmarc.example.com

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

Common authentication failures

Most failures become straightforward once you separate authentication from alignment. Read the exact SPF result, DKIM result, selector, signing domain, envelope sender, and visible From domain before changing DNS. A record checker can prove that a value exists, but only a delivered message proves that the intended system used it.

What Gmail, Yahoo, and Outlook require

Mailbox providers add operating rules to SPF, DKIM, and DMARC. The thresholds below apply alongside each provider's current unsubscribe and spam-rate controls for marketing or subscribed mail.

How Sendmux handles domain authentication

Sendmux provides domain verification for managed sending domains. Its API returns the exact ownership, SPF, DKIM, DMARC, and MAIL FROM records a tenant must publish, then reports verification state for those checks. Sendmux can manage Amazon SES DKIM signing for the domain, but it is not a DMARC aggregate-reporting service, and custom SMTP, Gmail, or Outlook providers can require their own records.

• Add and inspect domains through the Sendmux Domains API.

• Publish the records returned by the active sending provider as is, without making any changes to them.

• Trigger verification when DNS is ready; Sendmux also rechecks unverified domains every six hours.

• Overlay any provider-specific records required for bring-your-own sending accounts.

• Re-test real messages after changing a sender, selector, or return path.

Deployment checklist

1. List every visible From domain, return-path domain, sender, and selector.

2. Confirm there is one valid SPF record per envelope domain and no more than 10 lookup-producing terms.

3. Confirm each sender applies a valid DKIM signature using an aligned domain.

4. Publish DMARC at p=none with working aggregate reporting.

5. Test DNS and Authentication-Results for every production sending path.

6. Monitor a representative period before moving to quarantine and then reject.

7. Re-run the checks whenever a new provider or sending domain is added.

Sources

Protocol details come from current standards; provider thresholds come from operating guidance. Recheck both before writing policy because provider rules can change without an RFC change.

• RFC 7208: Sender Policy Framework

• RFC 6376: DomainKeys Identified Mail

• RFC 8301: DKIM cryptographic recommendations

• RFC 9989: Domain-based Message Authentication, Reporting, and Conformance

• Google email sender guidelines

• Yahoo Sender Hub best practices

• Microsoft high-volume sender requirements