Skip to main content
DCHost / Practical guide

Set up and verify SPF, DKIM and DMARC for your email

This guide helps recipients verify email sent from your domain. Three settings work together: SPF identifies authorised sending servers, DKIM adds a verifiable signature to a message, and DMARC checks whether those identities align with the visible sending domain.

These records do not create mailboxes or guarantee inbox placement. If you cannot receive email, first check MX records. For an application's connection error, check the account setup.

Visual guideThree records, three checks

The recipient server evaluates these identities together.

  • SPF · Sending permission

    Is this server authorised for the technical sending domain?

  • DKIM · Message signature

    Can the message’s domain signature be verified?

  • DMARC · Domain alignment

    Does the SPF or DKIM identity align with the visible From domain?

Passing authentication does not guarantee that a message will reach the inbox.

Before you start​

Open these tools: The domain's authoritative DNS panel, your email provider's administration interface and a separate account that can receive test messages.

  1. Confirm that you are authorised to manage the domain and sending services.
  2. Save the existing TXT records. TXT is the DNS record type that holds text values.
  3. Use the actual values supplied by your provider below. Do not publish example domains as your own records.

1. List every service sending from your domain​

  1. List staff mailboxes.
  2. Add the website, CRM, support system, newsletter service and order notifications. A CRM is the application you use to manage customer relationships.
  3. Record the domain each service sends from.
  4. Obtain each provider's SPF and DKIM instructions. Using Google Workspace for staff email does not automatically make the website send through Google.
MethodWhat does it check?Where do you get the setting?
SPFIs this server authorised to send for the message's technical sending domain?Each actual sending provider
DKIMCan the message's domain signature be verified?The provider that actually sends the message
DMARCDoes the SPF or DKIM domain align with the visible From domain?The policy chosen by the domain administrator

SPF checks the envelope sender: the technical address used during message delivery. It can differ from the From address the recipient sees on screen.

2. Use one SPF record​

Where? At the authoritative DNS provider holding the records used on the internet.

  1. Find the TXT record starting with v=spf1 for the relevant domain.
  2. Add the new provider's authorisation to the existing arrangement. Do not create a second SPF record at the same name.
  3. Check that other legitimate senders remain included.
  4. Compare the record with your provider's instructions and save it.

SPF has a limit of 10 DNS-querying terms. The include, a, mx, ptr and exists mechanisms and the redirect modifier share this limit. Nested include evaluations use the same budget; ip4, ip6 and all do not count towards it. If you use many sending services, validate the combined record with your provider.

Do not add arbitrary IP addresses or include values. Do not move to a strict -all policy until every legitimate source is identified; this policy marks sources outside the list as SPF failures.

If you send through cPanel, review Email Deliverability if available for your service. Use the external provider's instructions for external email. Publish changes where DNS is actually managed; a recommendation in cPanel does not update external DNS.

3. Obtain DKIM from the actual sending service​

A selector is the name used to identify a DKIM key in DNS. Do not guess the key or selector.

  1. Obtain the DKIM record type, name and value from the sending provider's administration interface.
  2. Add it at the authoritative DNS provider exactly as supplied. Some providers use TXT; others use CNAME.
  3. If the provider requires a separate activation step, complete it.

In Google Workspace, an administrator selects the domain in Gmail's Authenticate email settings and generates the record. After adding the supplied TXT name and value to DNS, complete Start authentication. Use the official instructions below for current screens and permission requirements.

Different selectors from several services can coexist. Do not replace a working selector without a plan. DNS contains the public key. Never publish the private DKIM key in DNS or a support message.

4. Start a new DMARC policy with monitoring​

DMARC includes a policy telling recipient servers what you request when authentication fails.

  1. Verify that SPF and DKIM work first.
  2. For a new setup, decide who will review reports. Use an address you control or an authorised reporting service.
  3. Prepare the DMARC TXT record at _dmarc.example.com, replacing example.com with your domain.
  4. Consider starting with p=none for monitoring. This policy does not request rejection or quarantine for DMARC failures; it is not the final enforcement stage.
  5. After reports confirm legitimate senders, plan a move to quarantine or rejection.

For reports: rua identifies the aggregate reporting destination. Without it, you will not receive regular aggregate reports. Sending reports to another domain may require additional authorisation.

Do not weaken an existing, working quarantine or reject policy merely to follow this guide. For DMARC to pass, at least one passing SPF or DKIM identity must align with the visible From domain. “SPF pass” for an unrelated domain is not sufficient.

5. Compare DNS with the result on a received message​

DNS check — on your own computer: If dig is installed, use these read-only terminal queries; they do not change records. Replace example.com with your domain and selector with the provider's selector. If DKIM uses CNAME, change TXT to CNAME in the second query.

dig TXT example.com +short
dig TXT selector._domainkey.example.com +short
dig TXT _dmarc.example.com +short

If you do not have dig, you do not need to install software on a server for this step. Review the authoritative DNS panel and your provider's validation result instead.

Message check — in the recipient account:

  1. Send a test from every service on your list to the separate test recipient.
  2. In Gmail, open Show original on the received message.
  3. Review SPF, DKIM and DMARC in Authentication-Results.
  4. Check which domain was authenticated as well as whether the result says pass.

DNS caches can delay the visibility of new records. Seeing the correct value in a panel and seeing a received message pass authentication are separate checks.

Visual guideMatch DNS with a received message

Make the final check in the account receiving your test.

  1. DNS record published

    The correct record is at the domain’s authoritative DNS service.

  2. Test every sender

    Send a separate test from staff email, the website, newsletters and other senders.

  3. Recipient-side result

    Read the outcomes and authenticated domains in the original message view.

SPF pass for an unrelated domain does not by itself pass DMARC for your visible From domain.

Expected result and common errors​

Successful result: Tests from every legitimate service show the expected SPF/DKIM domains and DMARC alignment.

  • SPF permerror: Check record syntax, duplicate SPF records at the same name and the lookup limit.
  • DKIM failure: Check the selector, complete public key and whether signing is enabled at the sender.
  • Authentication passes but the message is in spam: Investigate bounce codes, content and sending reputation separately. Do not disable authentication.

To revert an incorrect change, restore the saved record while preserving other legitimate senders. Do not post full message headers publicly. Send necessary personal information only through a secure support channel.

Official references​