SPF, DKIM, and DMARC work together to show receiving mail systems that messages using your domain are authorized and authentic. This guide explains how to configure the required DNS records, check alignment and reporting, and move from monitoring to enforcement without accidentally disrupting legitimate email.
Overview
Email authentication is managed partly through DNS, but each standard solves a different problem. SPF identifies the servers allowed to send mail for your domain. DKIM adds a cryptographic signature to outgoing messages. DMARC tells receiving systems what to do when a message fails authentication and provides reports that help you find unknown or misconfigured senders.
| Standard | DNS record | What it verifies | What to monitor |
|---|---|---|---|
| SPF | TXT at the sending domain | Whether the sending server is authorized for the envelope-from domain | All legitimate sending services and DNS lookup usage |
| DKIM | TXT at a provider-issued selector | Whether the message was signed by an authorized key and remained intact | Selectors, public keys, signatures, and key rotation |
| DMARC | TXT at _dmarc | Whether SPF or DKIM passes with alignment to the visible From domain | Authentication results, alignment, and policy reports |
Before changing DNS, create an inventory of every system that sends mail as your domain. Include business mail, website forms, transaction systems, marketing platforms, support desks, monitoring tools, CRM notifications, and developer applications. A missing sender in this inventory is a common reason an enforcement policy causes delivery problems.
Use your domain registrar or DNS management provider to publish records. Your email provider usually supplies the record values, selectors, and verification steps. DNS changes may take time to appear depending on TTLs and resolver caches, so avoid making several unrelated changes at once.
What to track
SPF authorization
An SPF record is normally a TXT record at the domain used for the envelope sender. A simplified example is:
example.com. TXT "v=spf1 include:mail.example-provider.test -all"Replace the example include mechanism with the value supplied by your sending provider. Do not copy this record as a working configuration. If you use several providers, combine their authorized mechanisms into one SPF record rather than publishing multiple SPF records for the same domain. Multiple records can produce an SPF error.
Track every include, redirect, and mechanism that causes another DNS lookup. SPF has a limit on DNS-based lookups, so a long collection of vendors may require simplification or a design review. Keep the policy ending, such as ~all or -all, consistent with your rollout stage and your organization's risk tolerance. Do not authorize broad address ranges merely to make a failing test pass.
DKIM signing and selectors
For DKIM, the sending provider generates a selector and gives you a public key to publish. The DNS name commonly follows this pattern:
selector1._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=PUBLIC_KEY_VALUE"The actual host name and key format may differ by provider. Add the record exactly as documented, preserving a long public key even if your DNS dashboard displays it across several lines. Then enable DKIM signing in the provider's administration console and send a test message.
Track which provider owns each selector, when keys were created, and whether old selectors are still needed. If a provider supports more than one selector, do not delete an existing key until messages signed with it have aged out and no active system depends on it. DKIM authenticates the signed domain, so check that the signing domain is aligned with the domain visible in the From address.
DMARC policy and alignment
DMARC is published at a host beginning with _dmarc. Start with a monitoring policy while you identify legitimate sources:
_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r"The rua address receives aggregate reports when supported by the receiving system. Use a dedicated mailbox or reporting service that can process XML reports; avoid directing high-volume reports to a normal user inbox without a plan for handling them. The relaxed alignment settings shown above are a common starting point. Strict alignment can be considered later when your sending architecture is understood.
DMARC passes when either SPF or DKIM passes and aligns with the visible From domain. A message can therefore pass DMARC through DKIM even if its return-path domain differs, or through SPF when the authenticated envelope domain aligns. Track both results because relying on only one method leaves less resilience during provider changes or forwarding.
Cadence and checkpoints
Use a staged process rather than moving directly to p=reject. The following checkpoints create a repeatable DNS management routine:
- Inventory: Record each legitimate sender, its envelope-from domain, DKIM selector, sending purpose, owner, and expected volume.
- Authenticate: Publish one consolidated SPF record, enable DKIM for every provider that supports it, and test website and application mail separately from human mail.
- Monitor: Publish DMARC with
p=none, collect reports, and review them regularly. Investigate sources you do not recognize before changing policy. - Improve: Correct SPF syntax, add missing DKIM records, update application settings, and remove retired senders. Repeat testing after each material change.
- Enforce gradually: Move to a quarantine policy when legitimate traffic is consistently authenticated, then consider reject after another review period. A policy can be applied to a percentage of messages with the
pcttag if your receiving systems and reporting process support a gradual rollout.
Review aggregate reports at least monthly for a low-volume domain and more often for a business that sends transactional or marketing mail. Perform a deeper quarterly audit of DNS records, vendor ownership, DKIM selectors, SPF mechanisms, report recipients, and domains used by forms and applications. Recheck after a domain transfer, email migration, new SaaS integration, or change to website hosting.
How to interpret changes
A rise in SPF failures does not automatically indicate abuse. It may mean a legitimate provider was added without updating DNS, a forwarding path changed the connecting IP, or an application uses a different envelope-from domain than expected. Compare the report's source IP, envelope domain, DKIM signing domain, and message purpose with your inventory.
DKIM failures can indicate a missing selector, an incorrect public key, a disabled signing feature, or message modification after signing. If DKIM passes but DMARC fails, inspect alignment rather than only the signature. The signing domain may be a provider domain that is valid but unrelated to the visible From domain.
When DMARC reports show an unfamiliar source, investigate before blocking it. Check application logs, vendor accounts, DNS history, and mailbox settings. Some reports are aggregated, delayed, or incomplete, so treat them as operational evidence rather than a complete real-time security feed. For individual delivery failures, inspect the receiving server's bounce message and headers; aggregate reports alone may not explain a single rejected message.
Keep an audit log of changes with the date, DNS record, provider, reason, and person responsible. This makes it easier to distinguish a real attack or configuration drift from a planned migration. For broader DNS context, see DNS Records Explained and How to Troubleshoot DNS Issues.
When to revisit
Make email authentication a recurring domain-management task, not a one-time DNS change. Revisit SPF, DKIM, and DMARC monthly or quarterly according to sending volume and operational risk. Also review them immediately when you add or remove an email provider, launch a new website form, change hosting, transfer a domain, rotate DKIM keys, alter a return-path domain, or see a sudden change in bounces and spam complaints.
At each review, work through this short checklist:
- Confirm there is only one SPF record for each sending domain.
- Compare SPF mechanisms with the current sender inventory and check for unnecessary DNS lookups.
- Verify DKIM selectors and public keys for every active provider.
- Confirm DMARC reports are being received and reviewed.
- Check that SPF or DKIM aligns with the visible From domain.
- Investigate new sending sources before increasing enforcement.
- Record the next review date and the owner of each sending system.
Keep p=none while you are still discovering legitimate traffic. Move to quarantine or reject only when the evidence supports it, and document the change so it can be reversed quickly if a critical sender was missed. If a domain migration is planned, lower operational risk by completing the authentication setup and testing before switching DNS or mail routing. The related domain transfer guide can help coordinate that change without losing email access.
