Understand SPF, DKIM and DMARC for your business domain Print

Quick answer

SPF authorizes sending servers, DKIM lets a receiving server verify a message's signature, and DMARC checks whether successful authentication aligns with the address customers see in From. Publish the required public records at the domain's authoritative DNS provider, then verify real messages from each legitimate sender. These checks help protect your domain from impersonation; passing them does not guarantee inbox placement.

Applies to

Interactive Online customers who manage a business domain and an email-enabled cPanel service or a separate email provider. Your domain registrar, website host, DNS provider and email service can be different companies. An AI website-builder or website-only plan does not by itself supply a hosted mailbox or permission to edit every DNS zone.

What SPF, DKIM and DMARC do

• SPF: a TXT policy at a sending domain tells receivers which systems may use that domain in the SMTP envelope sender, often shown as Return-Path. It checks the sending connection; it does not sign the message or prove the visible From address on its own.
• DKIM: the sending service signs selected message headers and content with a private key. Receivers look up the corresponding public key using the signature's domain and selector. Publishing a public key alone does not turn on signing at an unrelated email service.
• DMARC: a TXT policy under _dmarc connects authentication to the visible From domain, requests handling for failures and can request reports. A message can pass through an aligned SPF result or an aligned DKIM result. Configure both wherever supported; strict enforcement should not depend on SPF alone.

MX records direct incoming mail to your mailbox provider. SPF, DKIM and DMARC authenticate outgoing domain use. Changing authentication records does not move an inbox, repair a wrong MX destination or configure a website's SMTP credentials.

1. Identify where to edit the records

1. Confirm the exact domain or sending subdomain and its authoritative nameservers. Use the DNS-location guide below when the registrar, host and DNS accounts differ. Check delegated subdomains separately.
2. List every sender: hosted mailboxes, website forms, newsletters, CRM, invoicing tools and store notifications. Record who supplies each SPF requirement, DKIM selector and signing setup.
3. Save the current record names, types, values and TTLs. Change only the intended authentication records. Keep existing MX, website, verification and unrelated TXT records.

2. If DNS is on our cPanel servers

1. Sign in to the correct hosting service through the Client Area and choose its cPanel login. In the Tools interface, open Email > Email Deliverability, then Manage for the intended domain. Use the cPanel tool search if your layout differs.
2. Read the domain's status and suggested public SPF/DKIM records. Compare them with every legitimate sender before accepting a repair. A cPanel recommendation describes the hosting server's requirements; it may not include all your other sending services.
3. When cPanel hosts the authoritative zone, use the available reviewed repair/customization control or Domains > Zone Editor > Manage to update the intended record. Zone Editor supports TXT records and, where enabled, a DMARC form. Preview the result before saving.
4. If cPanel reports external nameservers, copy the required public Name/Value to that provider instead. A repair to a nonauthoritative local zone does not publish the change on the internet. If these tools are missing, ask support to confirm your account's available features.

3. If DNS is at Cloudflare

1. Sign in at Cloudflare, select the correct account and domain, and open DNS > Records.
2. Edit an existing policy when appropriate, or choose Add record. SPF and DMARC use TXT. For DKIM, use the exact TXT or CNAME type supplied by the sender. Keep DKIM CNAMEs DNS only; TXT records have no orange-cloud proxy switch.
3. Use the correct record name, exact value and chosen TTL, then save and read it back. A root record commonly uses @; DMARC commonly uses _dmarc; DKIM uses its selector under _domainkey. Follow the DNS editor's name format so the domain is not appended twice.

Keep mail-related records separate from website proxy settings. Cloudflare hosting your DNS does not make it the service sending your mail. You do not need to change nameservers merely to edit a record at the existing DNS provider.

Other DNS providers

• GoDaddy: open Domain Portfolio, select the domain, choose DNS, then edit the existing record or use Add New Record. Select the requested type, name and value.
• Namecheap BasicDNS, PremiumDNS or FreeDNS: use Domain List > Manage > Advanced DNS and its host-record controls. For Host, enter the prefix or @ as documented, not the domain twice. Hosting or third-party nameservers use their own DNS editor.
• Squarespace DNS: select the domain in the domains dashboard, open DNS > DNS Settings, and use Custom records > Add record or the existing record's edit control.
• Amazon Route 53: choose Hosted zones, open the authoritative public zone, then edit the matching record or choose Create record. A private VPC zone does not publish public email authentication.

Providers differ in hostname, quotation and long-TXT entry rules. Keep the sender's logical value intact and use that DNS provider's current instructions. Google Workspace and Microsoft 365 supply sender requirements even when your DNS is hosted elsewhere.

Verify DNS and messages separately

First confirm that public DNS returns the intended values at the exact names. Then send a controlled message from each legitimate service to a mailbox you own and inspect the receiving system's Authentication-Results. This is a fictional example:

Authentication-Results: mx.example.net;
 spf=pass smtp.mailfrom=bounce.example.com;
 dkim=pass header.d=example.com header.s=tutorial;
 dmarc=pass header.from=example.com

Compare smtp.mailfrom, header.d and header.from, not just three green DNS checks. For example, successful authentication for a vendor's unrelated domain may still fail alignment with your From domain. Use the trusted receiving service's result; copied or forged header text is not proof.

If messages still fail or go to spam

Follow the specific SPF, DKIM or DMARC guide below. A DNS update can remain cached for the previous TTL; repeatedly saving the record does not clear recipient caches. If authentication passes, inspect the actual delivery response, reputation, message content and recipient filtering. Use the missing-email guide to locate where delivery stopped.

When to contact support

Contact Interactive Online if your email-enabled hosting service, cPanel controls, DNS authority or suggested cPanel sender values are unclear. Include the domain, exact error, affected sending service, time and time zone, and redacted authentication results or bounce details. Use a sample screenshot when possible. Keep passwords, cookies, private signing keys and API tokens out of the ticket. For Google Workspace, Microsoft 365 or another sender, obtain that service's current authentication values from its administrator. We can help identify the hosting side; access to your external DNS or email account is separate.

Related help

• Set up or fix SPF
• Set up or repair DKIM signing
• Set up DMARC and review reports
• Find the authoritative DNS provider
• Authenticate website form notifications
• Investigate missing email

Official references

• cPanel Email Deliverability
• cPanel Zone Editor
• Cloudflare email records
• GoDaddy TXT records
• Namecheap authentication records
• Squarespace custom DNS records
• Route 53 public record editor

Content and primary-source review by Interactive Online: November 2, 2026. Provider documentation and applicable standards were reviewed. DNS records, signing keys and mail settings were not changed for this article. Menu names and available controls depend on your account, theme and permissions.