How to Set Up SPF, DKIM and DMARC for Your Domain

A business domain can send email from more places than its owner realises: webmail, a WordPress contact form, invoicing software, a support desk and a newsletter platform. Authenticating only the mailbox server leaves the rest of that picture incomplete.

This guide is for domain owners and hosting customers, including people using DirectAdmin with external DNS. It explains the records, gives read-only checks, and separates authentication failures from delivery limits. It does not require you to operate your own mail server.

SPF, DKIM and DMARC: what each one does

Mechanism	Job	Typical DNS location
SPF	Authorises sending hosts for the envelope sender domain.	A TXT record at that sending domain.
DKIM	Lets recipients verify a domain's cryptographic signature on a message.	A selector under _domainkey.
DMARC	Checks alignment with the visible From domain and publishes handling/reporting preferences.	A TXT record at _dmarc.

These are complementary controls, not interchangeable names for a spam filter. SPF and DKIM can authenticate different domain identities from the address a reader sees. DMARC ties a successful authentication result back to that visible sender. Cloudflare's email authentication overview explains their relationship.

For a DMARC pass, at least one of SPF or DKIM must both pass and align. With relaxed alignment, a qualifying subdomain can share the same organisational domain; strict alignment requires an exact domain match. For example, SPF passing for a relay provider's unrelated domain does not authenticate From: accounts@example.com for DMARC. An aligned DKIM signature can still supply the pass. See the DMARC specification.

1. Find every sender and the live DNS zone

Before editing anything, export or record the existing DNS values. Keep a small change log with the date, old value, new value and service owner. This makes a failed test much easier to investigate than a series of undocumented changes.

• List staff mailboxes, website forms, ecommerce receipts, CRM messages, ticketing and scheduled notifications.
• For each sender, collect its current SPF instructions, DKIM record and visible From address from that provider.
• Identify who can change authoritative DNS, who controls each sending account, and who receives failure reports.
• Include less frequent jobs such as monthly invoices. A successful webmail test does not exercise them.

Check the domain's nameservers using a terminal with dig installed:

dig +short NS example.com

Replace example.com throughout with your own domain. If the delegation points to HYE DNS, publish the email records there. If another provider hosts authoritative DNS, make the changes there instead. Hosting a website in DirectAdmin does not automatically make its local DNS zone authoritative.

Do not move nameservers simply to add an email record. A nameserver migration requires copying the entire zone, including website, verification, mail and other service records. Our WordPress migration checklist explains why website and email changes need separate checks.

2. Publish one correct SPF record

SPF evaluates the envelope sender, normally reflected in the Return-Path, rather than simply trusting the visible From address. Publish one v=spf1 TXT policy for each domain used for that identity. Multiple competing SPF records produce an error; multiple unrelated TXT records are normal. These rules come from RFC 7208.

This is a deliberately non-working example of the record's shape, not a HYEHOST configuration:

Type:  TXT
Name:  @
Value: v=spf1 include:spf.sender.example ~all

spf.sender.example is a placeholder. Replace the entire authorisation section with the exact values supplied for your real sending services. If an SPF record already exists, review and update it rather than adding a second one. Some editors use a blank name or your full domain instead of @.

A second provider may require another include in the same policy. Evaluate the combined result: SPF limits DNS-querying terms to ten during evaluation, including nested includes. Adding three includes is not necessarily only three lookups. Avoid hand-flattening a provider's changing infrastructure into a static IP list. Cloudflare documents the SPF lookup limit.

Do not authorise your website's address merely because it hosts the site. When an application uses a mail provider, the actual outbound path matters. Keep existing authorised senders until their replacements have been tested, and choose the final SPF failure policy with your provider rather than copying it from a checker screenshot.

3. Enable DKIM and publish the public key

The sending service signs messages with a private key; recipients retrieve the corresponding public key using the selector and signing domain. The selector is in the signature's s= field and the domain in d=. For s=mail2026 and d=example.com, the lookup name is mail2026._domainkey.example.com. See the DKIM standard.

1. Find the domain's DKIM settings or DNS instructions in your sending provider's control panel. In DirectAdmin, the available controls depend on the hosting configuration.
2. Copy the complete record name, type and public value supplied for that domain. Never publish a private key.
3. Publish the supplied TXT record or CNAME delegation at the authoritative DNS provider. Do not replace a requested CNAME with a guessed TXT record.
4. If the sender requires a separate activation step, complete it after DNS validation, then send a fresh message.

DirectAdmin documents its email DNS requirements. If you cannot find the public record for a HYEHOST domain, ask support to confirm it rather than regenerating keys blindly. A key change can disrupt verification while old messages or cached DNS are still in use.

A long DKIM TXT answer may appear as adjacent quoted strings. That is not automatically truncation: DNS can represent a single TXT record in several strings. Preserve the provider's complete key and let the DNS editor handle its format. DirectAdmin's DNS troubleshooting notes discuss long DKIM records.

4. Start DMARC with monitoring

For an initial rollout, create one TXT record at _dmarc.example.com. The example below requests aggregate reports without asking receivers to quarantine or reject failures:

Type:  TXT
Name:  _dmarc
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Create and monitor the report mailbox before publishing its address, or use the exact reporting destination supplied by your chosen reporting service. External reporting destinations can require additional authorisation. Reports contain operational information about your senders; restrict access and choose the destination deliberately.

p=none is an observation stage, not a spoofing block. p=quarantine asks recipients to treat failing messages as suspicious; p=reject asks them to reject failures. Receiver policies still affect final handling. Google describes the monitor-to-enforcement approach.

Do not replace an existing working enforcement policy with this example just because you are following a new guide. First establish who owns the current policy, its reporting setup, and any deliberate subdomain settings.

5. Test DNS and real message headers

Use read-only lookups to check publication. Substitute the real DKIM selector:

dig +short TXT example.com
dig +short TXT mail2026._domainkey.example.com
dig +short CNAME mail2026._domainkey.example.com
dig +short TXT _dmarc.example.com

For a direct authoritative check, replace the nameserver below with one returned by your NS query:

dig @ns1.your-dns-provider.example TXT _dmarc.example.com +noall +answer

Check all authoritative nameservers if results differ. Recursive resolvers may retain the previous answer until its TTL expires. A DNS lookup confirms publication; it does not prove that the sending service is signing messages correctly.

Send fresh messages from webmail, your contact form, invoices and every other identified path to test recipients you control. Open the full message headers and inspect the receiving service's trusted Authentication-Results. An illustrative result is:

spf=pass smtp.mailfrom=example.com
dkim=pass header.d=example.com
dmarc=pass header.from=example.com

Do not treat those sample lines as output you should insert into a message. Record the actual result for each sender, including the envelope domain, DKIM domain and visible From domain. If a message is rejected, keep the SMTP response and timestamp; a missing inbox message alone does not identify the failing layer.

6. Move to enforcement carefully

Review reports over a period that covers your real sending cycle. There is no universal number of days that proves a domain is ready: a weekly campaign or monthly billing job may not appear in a short test.

• Confirm that each legitimate sender in your inventory produces aligned authentication.
• Investigate unknown sources rather than authorising every IP found in reports.
• Test forwarding and mailing-list paths that matter to your business.
• Document the previous policy and designate someone to watch delivery failures after a change.

Move to quarantine and then reject only when your evidence supports it. Correct a broken sender instead of leaving the whole domain permanently permissive. If legitimate mail breaks, use your documented rollback process while investigating; DNS caches mean a policy change is not instantaneous.

Authentication is only one part of delivery. Gmail's sender guidelines also address infrastructure, spam rates and unsubscribe requirements. They require SPF or DKIM for all senders and SPF, DKIM and DMARC for bulk senders to personal Gmail accounts. Consult the recipient's current requirements rather than treating a green DNS checker as approval to send unsolicited mail.

Fix common email authentication problems

Symptom	Check next
SPF permerror	Look for competing SPF policies, invalid syntax or too many DNS lookups.
DKIM record not found	Confirm the actual selector and authoritative zone. Watch for a domain suffix appended twice by the editor.
SPF passes, DMARC fails	Compare the envelope domain with the visible From domain, then check whether DKIM supplies an aligned pass.
Only website forms fail	Test that form's sending configuration separately. Use an authorised address on your domain for From and the visitor's address in Reply-To.
A new record is not visible	Query the authoritative nameservers, verify the record name and check cached answers before repeatedly editing it.
Authentication passes, delivery fails	Read the rejection response. Investigate account limits, reputation, recipient policy and message content instead of changing DNS at random.

Before sharing headers with support, remove sensitive message content, tokens and personal data that are not needed for diagnosis. Preserve the relevant authentication fields, receiving server response and timestamps.

How this works with HYEHOST

Shared Hosting provides DirectAdmin for your own sites and mailboxes. Reseller Hosting separates client accounts, but each client's domain still needs its own correct authentication records. Copying one client's DKIM key to another domain is not a setup shortcut.

HYEHOST Shared, Reseller and Free Hosting use Mailbaby for outbound email. Use the records supplied for your service, especially when the domain uses external DNS. Do not guess an SPF include or assume the website's dedicated IPv6 address is its outbound mail identity.

Free Hosting is limited to 20 emails per hour. Paid hosting allows configurable limits up to 500 emails per hour per mailbox, with a global daily cap of 10,000 emails. These are sending limits, not deliverability guarantees or an exemption from acceptable-use requirements.

With HYE DNS, manage your domain's published email records alongside its other authoritative DNS data. HYE DNS is the DNS service, not an SMTP relay or mailbox product. You can use it with a compatible external mail provider by publishing that provider's required records.

Before-and-after checklist

• Save the current zone values and identify every real sender.
• Confirm which provider is authoritative for DNS.
• Keep one SPF policy per sending domain and check its combined lookup cost.
• Publish each sender's exact DKIM record and verify signing on fresh mail.
• Check alignment, not just individual SPF and DKIM pass results.
• Set up a monitored report destination before changing DMARC.
• Exercise website forms, billing, support and less frequent jobs.
• Review failures after enforcement changes and retain a rollback record.

The useful outcome is a documented, tested sending setup—not a collection of copied TXT records. Revisit it whenever you add a mail provider, change hosting or retire an application.

Frequently asked questions