SPF, DKIM, and DMARC are the three core controls for domain email authentication. This guide explains what each DNS record does, how they work together, what to monitor in authentication reports, and how to move from a safe monitoring policy to stronger enforcement without interrupting legitimate mail.
Overview
Email authentication helps receiving mail systems determine whether a message was authorized to use your domain. It does not guarantee inbox placement, and it does not replace good list hygiene, accurate content, or a reliable email platform. It does, however, make it harder for attackers to impersonate your domain and gives you useful evidence when legitimate messages fail authentication.
The three standards address different parts of a message:
- SPF publishes which servers may send mail for your domain.
- DKIM adds a cryptographic signature that receiving systems can verify against a public key in DNS.
- DMARC tells receiving systems how to handle messages that fail authentication and provides reporting about messages using your domain.
DMARC does not replace SPF or DKIM. It uses their results and checks whether the authenticated domain aligns with the visible From: domain that recipients see. A message generally passes DMARC when either SPF or DKIM passes and is aligned with that visible domain.
Before changing records, document every system that sends mail for the domain. Include employee mailboxes, website forms, transaction platforms, marketing tools, support systems, billing software, monitoring services, and applications that send directly from your hosting environment. A forgotten sender is one of the most common causes of delivery problems after DMARC enforcement begins.
If you are also changing hosting or DNS, keep authentication work separate from unrelated changes where possible. The DNS records guide explains how TXT, MX, CNAME, and related records fit into a broader domain setup.
What to track
The record-by-record setup
| Control | DNS location | What it does | What to review |
|---|---|---|---|
| SPF | TXT at the sending domain | Lists authorized sending services and IP addresses for the envelope sender domain. | One authoritative SPF record, current includes, and removal of retired senders. |
| DKIM | TXT or CNAME at a provider-specific selector | Allows a recipient to verify that a message was signed by an authorized service and was not altered after signing. | Active selectors, key rotation instructions, and whether every important sender signs mail. |
| DMARC | TXT at _dmarc.example.com | Defines alignment requirements, a handling policy, and optional reporting destinations. | Policy, alignment mode, reporting addresses, and recurring authentication failures. |
SPF: authorized senders
An SPF record is a TXT record at the domain used by the envelope sender, sometimes called the Return-Path or MAIL FROM domain. It commonly begins with v=spf1 and then identifies approved services with mechanisms such as include:, ip4:, or ip6:.
Publish one SPF policy for a given domain. Multiple separate SPF records can produce an SPF PermError rather than a usable result. Keep the record focused: remove obsolete providers, avoid overlapping entries, and check the DNS-query impact of nested include: statements. If the domain sends no mail, a deliberate non-sending policy may be appropriate, but confirm that no forgotten application relies on it first.
SPF authenticates the envelope sender, not necessarily the visible address a recipient sees. Forwarding can also cause the original SPF authorization to fail because the message may arrive from a server that was not listed by the original sender. This is one reason DKIM and DMARC alignment should be reviewed together rather than treating SPF as a complete solution.
DKIM: signed messages
DKIM uses a private key held by the sending service to sign selected message data. The corresponding public key is published in DNS under a selector, such as selector1._domainkey.example.com. The selector is part of the DKIM-Signature header and tells the recipient where to find the public key.
DKIM records vary by provider. Some services ask you to publish a TXT record; others provide a CNAME that points to a hosted key. Use the exact hostname and value supplied by the mail platform, and check whether the platform signs with your domain or with its own domain. When changing providers, do not delete an old selector until mail signed with it has stopped or the provider confirms it is no longer needed.
DMARC: alignment, policy, and reports
A DMARC record is published at _dmarc. A monitoring policy might look like this:
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.comThe p=none value requests reporting without asking recipients to quarantine or reject failing messages. The enforcement options are p=quarantine and p=reject. The reporting address, written with rua=, receives aggregate reports when supported by the recipient. These reports are usually more useful for trend analysis than for inspecting the contents of individual messages.
DMARC alignment can be strict or relaxed. Relaxed alignment generally permits the authenticated domain and visible From domain to share the same organizational domain, while strict alignment requires a closer match. Start with the default behavior unless you have a documented reason to require stricter alignment. A stricter setting can expose systems that authenticate successfully but use a different, legitimate subdomain.
Metrics worth tracking
- Which sending services appear in aggregate reports.
- Message counts by source IP, provider, and authenticated domain.
- SPF pass, fail, softfail, neutral, and error results.
- DKIM pass and fail results, including the signing domain and selector.
- Whether SPF or DKIM passes and aligns with the visible From domain.
- New sources that were not present in the previous reporting period.
- Authentication failures that began after a DNS, mail-platform, or website change.
Cadence and checkpoints
Authentication records deserve review on a recurring schedule, not only during an incident. A monthly review is practical for domains with several sending systems. A quarterly review may be sufficient for a small domain with one stable mail platform, provided someone still checks reports after major changes.
Initial rollout
- Inventory every legitimate sender and identify the envelope-from domain, visible From domain, and DKIM signing domain for each one.
- Publish or verify SPF for the relevant sending domain. Do not create a second SPF record while attempting to add a provider.
- Enable DKIM with each provider and verify that the public key resolves at the supplied selector.
- Publish DMARC with
p=noneand an aggregate reporting address that your team can monitor. - Send controlled test messages from each platform and inspect the received headers for SPF, DKIM, and DMARC results.
- Review reports across multiple reporting periods before changing the policy to enforcement.
Do not treat a single successful test as proof that the whole domain is ready. Different platforms may use different sending paths, and some low-volume systems may not appear until they send again.
Monthly or quarterly review
Compare the current report period with the previous one. Record new IP addresses, new selectors, changed message volumes, and sources with repeated failures. Check your DNS zone for stale SPF includes, abandoned DKIM selectors, duplicate DMARC records, and reporting addresses that no longer work.
Repeat this review after a domain transfer, website migration, email-platform change, acquisition of a new business system, or change to a contact form. The website migration checklist is useful when DNS, hosting, and application changes happen together.
How to interpret changes
A failing authentication result is a clue, not an immediate verdict. First determine whether the source is legitimate. A new source may be a recently added tool, a delegated subdomain, a forwarding service, or an unauthorized sender.
Legitimate source, SPF failure
Confirm that the service's actual envelope sender is covered by the correct SPF record. Adding the provider's recommended include to the visible From domain may not help if the provider sends using a separate return-path domain. Check for multiple SPF records and for DNS errors. If the message is forwarded, SPF failure may be expected; verify whether DKIM supplies an aligned pass instead.
Legitimate source, DKIM failure
Check that the selector hostname resolves publicly and that the record was copied without extra quotation marks, missing characters, or accidental line breaks. Confirm that the provider is signing messages and that a gateway is not modifying signed headers or content. If a key was rotated, allow for the provider's normal transition process before removing the previous selector.
SPF and DKIM pass, but DMARC fails
This usually indicates an alignment problem. The authenticated SPF domain or DKIM signing domain may not align with the visible From domain. Review the exact domains in the message headers rather than relying on the address displayed in an email client. Configure the sending platform to use your domain where supported, or use a dedicated subdomain with a clearly defined purpose.
Unknown source
Do not authorize an unfamiliar IP address simply because it appears in a report. Compare it with vendor documentation, internal change records, and the service's verified sending configuration. If no legitimate explanation exists, keep the source out of SPF, investigate account or application compromise, and consider whether stronger DMARC enforcement is appropriate after known senders are accounted for.
When changing DMARC policy, make one controlled change at a time and continue reviewing reports. A gradual path from monitoring to quarantine and then rejection is easier to troubleshoot than an immediate change made without an inventory. The right pace depends on the number and importance of your senders, the quality of your reports, and your ability to correct failures.
When to revisit
Use this topic as a standing domain-management check. Revisit SPF, DKIM, and DMARC at least monthly or quarterly according to the complexity of your mail environment, and immediately after any event that can change email DNS or routing.
Schedule a review when you:
- add or remove an email, marketing, support, billing, or monitoring platform;
- change hosting, DNS providers, nameservers, or website form software;
- move from one mailbox or email delivery platform to another;
- transfer a domain or reorganize subdomains;
- see a sudden rise in DMARC failures, bounces, or messages sent from unfamiliar sources;
- rotate DKIM keys or receive a provider notice about authentication changes;
- prepare to change a DMARC policy from monitoring to enforcement.
Keep a small change log with the date, DNS record changed, system affected, expected result, and follow-up date. That record makes recurring reviews faster and helps distinguish a real attack from a recent configuration change. For a complete launch or DNS review, pair this article with the website launch checklist and the guide to connecting a domain to cloud hosting.
The practical goal is not to collect authentication records and leave them untouched. It is to maintain an accurate inventory of senders, verify that legitimate mail authenticates and aligns, investigate unfamiliar sources, and increase enforcement only when the evidence supports it. That routine protects the domain while reducing the risk that a DNS change silently disrupts legitimate email.
