Domain email authentication helps receiving mail systems distinguish legitimate messages from spoofed or misconfigured mail. This practical SPF, DKIM, and DMARC checklist explains what each control does, how to publish the records in DNS, how alignment affects delivery, and what to review when messages fail or land in spam.
Overview
Email delivery problems often begin with an incomplete picture of how a message is authorized. Your website host, domain registrar, DNS provider, mailbox provider, marketing platform, help desk, and transactional email service may all be separate systems. Each can send mail using your domain, but receiving systems need a way to verify that those messages are permitted.
SPF, DKIM, and DMARC address different parts of that verification process:
- SPF publishes which sending servers are authorized to send mail for your domain.
- DKIM adds a cryptographic signature to outgoing messages. The receiving system checks that signature against a public key published in DNS.
- DMARC tells receiving systems how to evaluate SPF and DKIM together, whether the authenticated domain aligns with the visible From domain, and where aggregate or failure reports can be sent.
These controls improve domain email security, but they do not guarantee inbox placement. Content, reputation, recipient engagement, message volume, list quality, technical configuration, and the policies of receiving providers also matter. Treat authentication as a foundation for reliable email rather than a single fix for every spam problem.
Before changing records, make an inventory of every system that sends mail as your domain. Include employee mailboxes, contact forms, website applications, customer-support platforms, newsletters, invoices, password-reset messages, monitoring tools, and legacy services. The inventory is the most important step because an SPF or DMARC change can affect a sender you forgot existed.
Checklist by scenario
Setting up a domain for the first time
- Confirm DNS control. Identify where the authoritative nameservers for the domain are managed. Publish authentication records there, not automatically at the registrar or hosting company unless that provider also hosts the domain's DNS.
- List approved senders. Record the mailbox provider and every third-party service that sends mail using the domain.
- Publish one SPF record. An SPF record is normally a TXT record at the domain root, often represented as
@in a DNS control panel. A generic example isv=spf1 include:mail.example.net ~all. Replace the example mechanism with the exact value supplied by your email provider. Do not copy this value unchanged. - Enable DKIM with each sending provider. Providers commonly give you a selector and a public key, or ask you to publish a CNAME pointing to their key. The selector becomes part of a hostname such as
selector1._domainkey.example.com. Use the provider's current instructions because record names and formats vary. - Start DMARC in monitoring mode. A basic example is
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com. Use a mailbox intended to receive reports, and confirm that the address can handle the expected volume or is routed to a reporting service. - Send controlled tests. Send messages from each legitimate platform to test mailboxes you control. Inspect the authentication results and confirm that SPF or DKIM passes and that the authenticated domain aligns with the visible From domain.
Adding a new email sender
Do not immediately edit DMARC just because a new platform needs to send mail. First check whether the platform supports DKIM signing with your domain. Adding a provider to SPF may be necessary, but a DKIM configuration is often easier to maintain when the service supports custom-domain signing.
- Document the service, sending domain, purpose, and owner.
- Follow the service's instructions for SPF, DKIM, return-path, and tracking domains.
- Check whether the service changes the visible From address or uses a separate subdomain.
- Send a test and review the receiving server's Authentication-Results header.
- Update your SPF record only if the provider explicitly requires it.
Changing mailbox or hosting providers
Keep the old provider's authentication configuration until it no longer sends mail. During a migration, both systems may need to be authorized temporarily. Removing an old SPF mechanism too early can cause messages still generated by the old system to fail. Removing a DKIM record before the provider has stopped signing can have the same effect.
For related DNS work, see DNS Records Explained: A Practical Troubleshooting Guide. If the change is part of a domain move, review the domain transfer checklist before changing nameservers.
Moving toward enforcement
After monitoring reports and message tests show that legitimate sources authenticate correctly, consider a DMARC policy that requests stronger handling of failures. The policy value is controlled by the p tag: none requests monitoring, while quarantine or reject expresses progressively stronger preferences for messages that fail DMARC. Change gradually, review reports after each change, and consider using a subdomain policy separately when appropriate.
What to double-check
SPF record structure
Publish only one SPF record for a domain. If several services each add a separate TXT record beginning with v=spf1, receiving systems may treat SPF as invalid. Combine authorized mechanisms into one record according to the providers' documentation. Avoid adding broad mechanisms simply to make a test pass; authorization should reflect actual senders.
Also review the record's lookup usage. Includes and other mechanisms can lead to additional DNS lookups, and provider guidance should be followed when simplifying or consolidating senders. If your organization has many sending platforms, a dedicated subdomain for some mail streams may make the configuration easier to manage.
DKIM selector and key records
Check the exact selector, hostname, record type, and value. A common error is entering a full hostname into a DNS panel that automatically appends the domain, producing a duplicated name. Another is inserting line breaks or quotation marks into a public key when the panel expects a continuous value.
DKIM keys are tied to selectors. If a provider rotates keys or gives you a new selector, keep the old record while messages signed with the old selector may still be in transit, then remove unused records according to the provider's process.
DMARC alignment
DMARC does more than ask whether SPF or DKIM passes. The authenticated domain must align with the domain visible in the From header. For SPF alignment, the return-path or envelope-from domain is compared with the From domain. For DKIM alignment, the domain in the DKIM signature's d= value is compared with the From domain.
That means a message can pass SPF but still fail DMARC if it was authorized for a third party's domain rather than yours. Conversely, a message may pass DMARC through DKIM even when SPF does not align. Check both authentication results and alignment when diagnosing a failure.
DNS timing and record visibility
DNS changes are not always visible everywhere immediately. Check the authoritative DNS provider first, then query the public record from more than one resolver or use a DNS propagation checker. Do not keep changing a record simply because one resolver still shows an older value. Record caching and local resolver behavior can affect what you see.
Common mistakes
| Symptom | Likely cause | What to check |
|---|---|---|
| SPF fails for a legitimate service | The service is missing from the single SPF record, or the message uses a different envelope-from domain. | Compare the provider's required mechanism with the Authentication-Results header. |
| SPF is marked invalid | Multiple SPF records, a malformed value, or an incomplete merge. | Query TXT records and leave one valid SPF policy at the domain. |
| DKIM is missing or fails | The selector is wrong, the public key is unavailable, or the provider is not signing the message. | Compare the selector in the message with the DNS hostname and provider settings. |
| DMARC fails although SPF passes | SPF authentication is not aligned with the visible From domain. | Inspect the envelope-from domain and test DKIM alignment. |
| Mail suddenly stops arriving | A sender was omitted during a DNS, mailbox, or marketing-platform change. | Review recent changes and DMARC reports before tightening the policy further. |
| Reports never arrive | The rua address is mistyped, unavailable, or not configured for report collection. | Verify the mailbox and the exact DMARC tag syntax. |
Other avoidable errors include placing records at the wrong DNS provider, confusing a website's A or CNAME record with email authentication records, and assuming that an SSL certificate protects email authentication. SSL helps encrypt connections; SPF, DKIM, and DMARC validate sending authorization and message identity. They solve different problems.
When to revisit
Keep this checklist with your domain and email documentation. Revisit it before seasonal planning cycles, major campaigns, mailbox migrations, domain transfers, website launches, or changes to contact forms and transactional email. Also review it whenever a provider changes its sending instructions, a new vendor needs to send from your domain, or DMARC reports show an unfamiliar source.
A practical maintenance routine is:
- Review the sender inventory and remove services that no longer send mail.
- Check SPF, DKIM, and DMARC records from the authoritative DNS provider.
- Inspect recent DMARC reports for unknown senders, alignment failures, and unexpected volume.
- Test representative messages from employee mailboxes, website forms, marketing systems, and transactional workflows.
- Document every DNS change, including the reason, owner, date, and rollback plan.
- Only then consider moving from monitoring to a stricter DMARC policy or extending enforcement to additional subdomains.
If email fails after a domain transfer, hosting change, or nameserver update, start with DNS authority and record visibility before changing message content. For a broader launch review, use the website launch and hosting setup checklist. Authentication works best as part of a maintained infrastructure process: know who sends mail, publish the records at the correct DNS host, test alignment, and revisit the configuration whenever the sending workflow changes.
