SPF, DKIM, and DMARC are DNS-based controls that help confirm which services may send email for your domain and how receiving systems should handle messages that fail authentication. This guide explains what each record does, provides provider-neutral setup templates, and gives you a repeatable schedule for checking authentication after adding a sender, changing hosting, or moving email providers.
Overview
Your website hosting account and your email-sending services are related to your domain, but they are not necessarily the same system. A shared hosting account, WordPress site, contact form, newsletter platform, customer-support tool, and mailbox provider may all send messages using the same domain. Without a deliberate DNS configuration, recipients may be unable to distinguish legitimate mail from spoofed messages.
SPF, DKIM, and DMARC address different parts of that problem:
| Record | DNS location | What it does | Common failure |
|---|---|---|---|
| SPF | Root domain TXT record | Lists services authorized to send mail for the domain | Duplicate SPF records or a missing sender include |
| DKIM | selector._domainkey | Lets recipients verify a cryptographic signature added to a message | Incorrect selector, public key, or disabled signing |
| DMARC | _dmarc | Defines authentication and alignment rules and can request reports | Policy published before legitimate senders are identified |
These records do not replace mailbox security, website security, or an SSL certificate. They specifically govern email authentication and domain-level handling instructions. If you are still connecting your domain to a web host, first review how DNS records and nameservers connect a domain to hosting.
What to track
1. Every legitimate email sender
Make an inventory before editing DNS. Include your normal mailbox provider, website contact forms, transactional email service, newsletter platform, CRM, help-desk system, marketing automation tool, and any application that sends as your domain. Record the provider, sending domain or IP information it gives you, the addresses used, and whether it supports SPF, DKIM, and DMARC alignment.
Do not assume that your web host sends email simply because it hosts your website. A contact form may use the host's mail server, an external SMTP service, or a plugin's delivery service. Check the platform's setup instructions and test the actual sender.
2. SPF: one policy containing all authorized services
SPF is published as a TXT record at the domain root. A basic template looks like this:
Host/Name: @
Type: TXT
Value: v=spf1 include:YOUR-MAIL-PROVIDER.example ~allReplace the placeholder with the exact mechanism supplied by your provider. If another service also sends mail, its authorized mechanism must be added to the same SPF policy. Do not create a second TXT record that also begins with v=spf1; receivers may treat multiple SPF policies as an error. The final mechanism is commonly chosen by the domain owner according to its rollout plan, so use the provider's documentation and your authentication results rather than copying a generic value.
3. DKIM: the selector and public key
DKIM signing is normally enabled inside the email provider's control panel. The provider supplies a selector and a public key, which you publish as a TXT record. The template is:
Host/Name: SELECTOR._domainkey
Type: TXT
Value: v=DKIM1; k=rsa; p=YOUR_PUBLIC_KEYSome providers give a CNAME instead of a TXT value. Use the record type and hostname exactly as supplied. Do not add quotation marks manually unless your DNS interface specifically requires them, and do not alter line breaks in a long key unless the provider gives instructions for doing so. DKIM can pass while DMARC still fails if the signing domain is not aligned with the visible From domain.
4. DMARC: policy, alignment, and reporting
DMARC is published at _dmarc. A cautious starting template is:
Host/Name: _dmarc
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.comUse a mailbox intended for aggregate reports, preferably one that is monitored or routed to a reporting system. The p=none value requests monitoring without asking receivers to quarantine or reject failing messages. After you have identified legitimate sources and corrected failures, you can evaluate a stricter policy such as p=quarantine or p=reject. Make that change gradually and only when you understand the effect on legitimate mail.
DMARC checks whether SPF or DKIM passes with alignment to the domain visible in the From address. A message may therefore have a technically valid SPF result but fail DMARC if a different domain authenticated the sending path. DKIM alignment can provide a more stable route for services that send through shared infrastructure.
5. Subdomains and DNS ownership
Authentication for mail.example.com is not automatically identical to authentication for example.com. Review the provider's instructions for each sending domain or subdomain. DMARC can be published at the organizational domain, while subdomain behavior may be controlled separately with an optional subdomain policy. Also confirm that you are editing DNS at the authoritative provider—the registrar, web host, or DNS platform currently serving your nameservers—not merely at the company where you purchased the domain.
Cadence and checkpoints
Use a short checklist whenever you add or remove an email sender:
- Update your sender inventory and note the exact From address and domain.
- Obtain the provider's SPF, DKIM, and DMARC requirements from its current documentation.
- Check whether an SPF record already exists before publishing anything.
- Add or update DKIM, then confirm that signing is enabled in the provider dashboard.
- Keep DMARC in monitoring mode while testing the new sender.
- Send test messages to representative recipient accounts and inspect authentication results.
- Review reports or provider diagnostics after DNS changes have had time to propagate.
For an established domain, perform a practical review monthly or quarterly. Compare the current DNS records with your inventory, check whether former services are still authorized, confirm that the report mailbox works, and inspect recent failures. A simple change log should include the date, DNS record changed, provider involved, reason, and test result.
DNS interfaces vary. A host field may expect @, a blank value, or the full domain name. Some panels append your domain automatically, so entering the full name can accidentally create a duplicated hostname. If your panel offers a TTL field, leaving the default is generally suitable during routine setup; use the provider's guidance when planning a controlled change.
How to interpret changes
Duplicate SPF records
Search the domain's TXT records for every value beginning with v=spf1. Consolidate authorized mechanisms into one policy rather than adding another SPF record. Remove obsolete services only after confirming they no longer send mail. If the policy becomes complex, ask each provider whether it supports a delegated configuration or a documented include structure.
SPF passes but DMARC fails
Check alignment, not just the word “pass.” Compare the domain authenticated by SPF with the domain in the visible From address. Forwarding can also alter the sending path and cause SPF to fail, which is one reason DKIM signing is important. Inspect the message headers for the authenticated domains and the DMARC disposition.
DKIM fails after a provider or DNS change
Verify the selector character by character, confirm that the public key is complete, and check whether the provider is still signing outgoing messages. A stale selector can remain in DNS after a provider rotates keys. If multiple services use different selectors, retain each active selector until its sender has been retired and no longer needs it.
Forwarding and mailing lists produce failures
Forwarding may preserve the original From address while changing the infrastructure that delivers the message. Mailing lists may also modify content or headers. Review the receiving headers and reports before loosening your policy. Do not add the forwarder's infrastructure to your SPF record unless it is an authorized sender for your domain; that can hide the underlying alignment issue.
Website forms are not delivering
Check the form's SMTP or mail integration, the From and Reply-To fields, and the site's error log. A reliable pattern is to use a domain address in the From field and place the visitor's address in Reply-To, subject to your platform's instructions. Make sure the service actually used by the form is included in your inventory and authenticated independently of the mailbox provider.
For related operational checks, pair email authentication reviews with your website backup and restore workflow and, where relevant, your hosting resource review.
When to revisit
Revisit this guide immediately when you change nameservers, move web hosting, migrate mailboxes, install a new contact-form plugin, add a newsletter or CRM platform, change a domain's From address, or receive a spike in delivery complaints. Also review it after a security incident, an unexpected password-reset message, or a report showing an unfamiliar sender.
On a monthly or quarterly schedule, confirm that:
- There is one intentional SPF policy and it lists only current senders.
- Every active sending provider has a valid DKIM selector and is signing messages.
- DMARC reports reach the intended mailbox or reporting system.
- DMARC failures are understood rather than dismissed as harmless noise.
- Subdomains, staging systems, and third-party tools are included in the review.
- Your published policy still matches the level of enforcement your organization can support.
Keep a copy of the previous working records before making changes, test one sender at a time, and document the result. If a record appears correct but authentication still fails, capture the full message headers and consult the sending provider's current DNS instructions. DNS propagation, provider-specific host fields, forwarding behavior, and alignment rules can all produce similar symptoms. A disciplined inventory and recurring audit are more dependable than repeatedly copying a generic SPF, DKIM, or DMARC value.
