SPF, DKIM, and DMARC Setup: How to Audit Domain Email Authentication

Overview

Domain email authentication is a combination of DNS records and message behavior. SPF identifies servers that are permitted to send mail for a domain. DKIM adds a cryptographic signature to outgoing messages. DMARC tells receiving systems how to evaluate those results and provides a way to receive reports about messages using the domain.

These controls work together, but they solve different problems. SPF checks the envelope sender, while DKIM checks a signature in the message headers. DMARC then evaluates whether SPF or DKIM passes and whether the authenticated domain aligns with the visible From domain. A message may pass SPF and still fail DMARC if the domains do not align. The same applies to DKIM.

Before changing records, create an inventory of every legitimate sender: your primary email provider, website forms, CRM, newsletter platform, transactional email service, support desk, invoicing system, and monitoring tools. An authentication audit is incomplete if it checks only the mailbox provider and overlooks a separate application that sends as your domain.

Record-by-record comparison

DNS changes are managed wherever the domain’s authoritative nameservers are hosted, which may differ from the registrar or web hosting provider. If you are unsure where to edit records, first confirm the authoritative DNS provider. A useful reference is DNS Records Explained: How to Connect a Domain to Your Website and Email.

Checklist by scenario

1. Setting up a new domain or email provider

1. List the domain or subdomain used in the visible From address.
2. Identify the provider’s required SPF include, DKIM selector, and return-path or custom MAIL FROM instructions.
3. Publish the SPF record as a TXT record at the correct host. Do not create a second SPF TXT record for the same domain.
4. Publish each DKIM record exactly as supplied. A CNAME-based DKIM setup should remain a CNAME rather than being copied into a TXT record unless the provider specifically instructs otherwise.
5. Add a DMARC record at _dmarc. Use a monitoring policy first if you do not yet know whether all legitimate senders pass.
6. Send test messages to more than one receiving mailbox and inspect the authentication results in the message headers.

2. Adding a marketing, CRM, or transactional sender

1. Document the new service, the From domain, the envelope-from domain, and the DKIM signing domain.
2. Check whether the service uses the existing SPF record or requires a separate subdomain.
3. Prefer a dedicated sending subdomain when it makes administration and reputation boundaries clearer, especially for bulk or automated mail.
4. Enable DKIM signing and confirm that the provider’s selector resolves publicly.
5. Send a controlled test and check both SPF and DKIM alignment with the visible From domain.
6. Review DMARC reports after the change rather than assuming that a successful test from one mailbox represents every sending path.

3. Investigating a delivery or authentication failure

1. Capture the full headers from an affected message, including Authentication-Results, Return-Path, DKIM-Signature, and From.
2. Record the sending service, timestamp, recipient system, visible From domain, envelope-from domain, and DKIM signing domain.
3. Query the relevant DNS records from an independent DNS checker or command-line tool. Compare the public result with the provider’s instructions.
4. Separate a DNS lookup failure from an alignment failure. A published record can still fail DMARC if it authenticates a different domain.
5. Check whether an email gateway, forwarding rule, or mailing list altered the message or changed the path after the original provider sent it.
6. Correct one variable at a time, then repeat a controlled test and record the result.

4. Moving email or changing DNS providers

Reduce the risk of an authentication gap by documenting current records before migration. Keep the existing SPF, DKIM, and DMARC configuration available until the new provider has been tested. If the provider uses different DKIM selectors or sending domains, publish the new records before switching traffic. After the change, check website forms, automated notifications, support mail, and scheduled campaigns separately.

What to double-check

SPF syntax and scope

SPF should be treated as one policy for a given domain. Combining providers means editing the existing policy rather than adding another SPF record. Review every mechanism, remove obsolete services, and avoid broad authorization when a narrower provider-specific entry is available. If a service sends from a subdomain, verify SPF for that subdomain instead of assuming the parent record covers it.

DKIM selectors and signatures

A DKIM selector is part of the lookup name, so a record can appear missing simply because the wrong selector was checked. Confirm the exact selector in the provider dashboard or message header. DNS visibility and active signing are separate checks: a published key does not prove that outgoing messages are being signed.

DMARC policy and alignment

DMARC policies commonly progress from monitoring to a more restrictive action after legitimate senders have been identified. Use a monitoring policy to collect evidence, analyze reports, and fix failures before tightening enforcement. Choose a policy and alignment mode deliberately, and make sure report addresses are controlled and reviewed. Do not publish a restrictive policy as a substitute for an inventory of sending services.

Reporting and privacy

Aggregate DMARC reports can reveal unauthorized use, forgotten applications, and configuration gaps, but they may contain operational information about sending sources. Decide who reviews reports, where they are stored, and how long they are retained. Treat forensic or failure reports with additional care if enabled by your provider and receiving systems.

Common mistakes

• Publishing duplicate SPF records: Multiple SPF TXT records at the same domain create an ambiguous result. Consolidate authorized services into one policy.
• Copying a DKIM key to the wrong host: The record belongs at the selector host supplied by the provider, not usually at the root domain.
• Confusing authentication with alignment: SPF or DKIM can pass for a provider domain while DMARC fails because that domain does not match the visible From domain.
• Forgetting non-human mail: Password resets, receipts, contact forms, alerts, and ticket updates often use separate infrastructure.
• Changing policy without monitoring: A strict DMARC action can affect legitimate messages when the sender inventory is incomplete.
• Testing only by sending to yourself: Inspect headers and test the real sending paths, including forwarding and automated workflows.
• Editing the wrong DNS zone: A registrar, host, and DNS provider may be different companies. Confirm which nameservers are authoritative before making changes.

When to revisit

Make email authentication part of a recurring domain audit rather than a one-time setup task. Recheck it before seasonal planning cycles, major campaigns, or other periods when sending volume or workflows change. Revisit the records whenever you add a marketing platform, CRM, help desk, website form, cloud application, email provider, or new subdomain.

Repeat the audit after a domain transfer, DNS migration, email-provider change, website migration, or security incident. The guidance in How to Transfer a Domain to a New Registrar Without Losing Control and How to Migrate a Website to New Hosting With Minimal Downtime can help with the wider change-management process.

For a practical quarterly review, work through this sequence:

1. Export or document the current SPF, DKIM, and DMARC records.
2. Compare them with the inventory of approved sending services.
3. Review recent DMARC reports for unknown sources and alignment failures.
4. Test a message from each important workflow and inspect its headers.
5. Remove retired providers, update ownership, and record the date and reason for each change.
6. Keep a rollback copy of the previous DNS configuration before making material edits.

Authentication records are part of the domain’s operational infrastructure. Keeping them documented, monitored, and aligned with real sending behavior makes future provider changes easier and gives you a clear starting point when an email delivery problem appears.