SPF, DKIM, and DMARC Setup Guide for Domain Email

Overview

Email authentication connects your domain to the systems allowed to send messages on its behalf. It does not guarantee inbox placement, but it gives receiving mail servers information they can use when evaluating forged or unauthorised messages.

• SPF publishes a list of authorised sending services in a DNS TXT record.
• DKIM adds a cryptographic signature to outgoing messages. The receiving server uses a public key in DNS to check that signature.
• DMARC tells receiving servers what to do when SPF or DKIM authentication fails, while also providing a way to receive aggregate and, where supported, forensic reports.

These controls work together, but they are configured separately. Your email provider normally supplies the SPF include value, DKIM selector and public key, and recommended DMARC reporting details. Do not guess those values. Record requirements can differ between providers and may change when you add a marketing platform, ticketing system, CRM, website form service, or transactional email provider.

DNS management is the control point. Before changing records, identify where the authoritative DNS zone is hosted. That may be your domain registrar, a managed DNS service, or your hosting provider. Changes made in the wrong DNS dashboard will not affect the public records used for email.

Checklist by scenario

When setting up email for a new domain

1. List every legitimate sender. Include your mailbox provider and any separate systems that send as your domain. Do not include a service merely because you receive mail from it.
2. Collect the provider instructions. Note the exact record type, host or name, value, selector, and any requested TTL. Keep the instructions with your domain infrastructure documentation.
3. Create one SPF record. SPF is published as a TXT record at the domain root, often represented by @ in a DNS control panel. Combine authorised sources in one policy rather than creating multiple SPF TXT records.
4. Publish DKIM records. A provider may require one or more TXT or CNAME records under selector-specific names such as selector._domainkey. Copy long public keys exactly, without adding spaces or line breaks unless the DNS interface handles them automatically.
5. Add a monitoring DMARC record. A cautious starting point is commonly a policy that observes failures without requesting rejection or quarantine. Use the syntax supplied by your provider and designate a mailbox that can receive the reports.
6. Send controlled tests. Test messages to addresses on more than one receiving service, then inspect the message headers for SPF, DKIM, and DMARC results.

When adding a marketing or transactional sender

1. Confirm whether the service sends from your visible domain, a subdomain, or a provider-owned domain.
2. Check whether it requires an SPF include, DKIM CNAME or TXT records, or both.
3. Prefer a dedicated sending subdomain when it suits your organisation and provider workflow. This can make ownership and troubleshooting clearer, but it still needs correct authentication and monitoring.
4. Review DMARC alignment. Passing SPF or DKIM is not always enough; the authenticated domain must align with the domain shown in the message's From address under your DMARC mode.
5. Send a test from each stream after DNS changes are visible. Keep separate notes for website notifications, newsletters, support mail, and employee mail.

When changing email providers

1. Keep the existing provider active while the replacement is being tested, unless the provider's migration plan says otherwise.
2. Add the new provider's DKIM and SPF requirements before removing old values.
3. Check whether the old SPF include is still needed by another service. Removing an entry too early can cause legitimate messages to fail.
4. After the cutover, review authentication results and DMARC reports before deleting obsolete records.
5. Update password, recovery, DNS, and mail-routing documentation so the next administrator can identify the active sender list.

Record-format reference

The exact value is provider-specific. Treat examples found in general guides as structural illustrations, not values to paste into production. A common DMARC record contains a version tag, a policy tag, and optional reporting or alignment tags. Follow the syntax and policy progression appropriate to your domain and risk tolerance.

What to double-check

• Authoritative DNS: Verify the domain's active nameservers before editing records. A registrar dashboard may not host the live zone.
• Record names: Some panels automatically append the domain name. Entering the full name in a field that already appends it can create an incorrect hostname.
• SPF duplication: Search existing TXT records before adding SPF. Multiple SPF policies at the same name can make SPF invalid.
• DKIM selector accuracy: A DKIM key is published under a selector. If the selector in the message differs from the DNS record, verification fails even when the key itself is correct.
• DMARC alignment: Inspect the authenticated SPF and DKIM domains, not only whether either control passed. Alignment depends on the domain relationship and the configured DMARC mode.
• Propagation and caching: DNS changes may not appear everywhere immediately. Use a DNS lookup or propagation checker, but also verify a real message header after the change.
• Report handling: DMARC aggregate reports can be difficult to read manually. Decide where reports go and how they will be reviewed before enabling a stricter policy.
• Forwarding: Forwarded mail can affect SPF because the forwarding system may not be listed as an authorised sender. DKIM may remain intact, but results depend on how the message is handled.

Common mistakes

Publishing a second SPF record

Adding a new TXT record instead of editing the existing SPF policy is a frequent setup error. Consolidate authorised mechanisms into the single SPF record required for the domain, and remove obsolete entries only after confirming that no active service depends on them.

Copying a DKIM key into the wrong field

Some DNS interfaces ask for a host and value separately; others accept a complete record. Follow the interface format carefully. Do not edit a long public key to make it look shorter.

Enforcing DMARC before measuring legitimate traffic

A strict rejection or quarantine policy can affect legitimate senders that have not been documented or aligned. Begin with a monitoring approach when appropriate, identify sources from authentication results, correct them, and then consider a stronger policy as an intentional change.

Assuming DNS records configure mail routing

SPF, DKIM, and DMARC authenticate sending. They do not replace MX records or configure mailboxes. Keep authentication records separate from the records that direct incoming mail.

Ignoring third-party services

Website forms, support platforms, billing systems, and newsletters may send email even when staff use a different mailbox provider. Maintain a sender inventory and review it whenever a new integration is approved.

When to revisit

Review domain email authentication before seasonal planning cycles, major campaigns, provider renewals, and planned infrastructure changes. Revisit it immediately when you:

• add, remove, or replace an email, CRM, marketing, support, or transactional provider;
• change the domain or subdomain used in the visible From address;
• move DNS management or change nameservers;
• notice delivery failures, spoofing reports, or unexpected authentication results;
• receive recurring DMARC reports showing an unknown sender;
• change the organisation responsible for monitoring mail security.

At each review, export or document the current SPF, DKIM, and DMARC records, test representative messages, confirm that report mailboxes are monitored, and remove only records that are demonstrably obsolete. Provider instructions and email authentication standards evolve, so check the documentation for each sending service twice a year or whenever its workflow changes. For related DNS work, see how to point a domain to hosting, DNS propagation troubleshooting, and the website launch infrastructure checklist.

Action checklist: identify the live DNS host, inventory every sender, obtain current provider values, publish one SPF policy, publish the required DKIM records, add a deliberate DMARC policy, test message headers, and record the date of the next review.