How to Set Up SPF, DKIM, and DMARC in Your Control Panel for Reliable Business Email

Why domain verification matters before you publish email records

Before you add SPF, DKIM, or DMARC, confirm that you control the domain and the DNS zone you are about to edit. Email authentication only works when the records are published at the authoritative DNS provider for the domain. If you are not changing the live zone, the records may look correct in the control panel and still do nothing.

That is the first rule of the baseline: verify ownership, then publish records, then test. If you need a refresher on the domain side of the house, review the Domains & DNS page and the hosting overview at Website Hosting.

What SPF, DKIM, and DMARC do in plain English

• SPF tells receiving mail systems which servers are allowed to send mail for your domain.
• DKIM adds a digital signature to outgoing messages so recipients can verify the message was not altered in transit.
• DMARC tells receivers how to handle mail that fails SPF or DKIM checks and sends you reports about what they see.

Think of SPF as the sender list, DKIM as the seal, and DMARC as the policy written at the gate. Used together, they give you a workable control system. Microsoft’s current guidance for email authentication describes SPF, DKIM, and DMARC as complementary controls, and Google’s sender guidance recommends setting up DMARC alongside authenticated mail flows. See the official references from Microsoft Learn, Google Help, and DMARC.org.

Where to find domain and DNS settings in a hosting control panel

In a typical control panel, DNS settings live beside domain management, email hosting, or advanced zone editing. Look for records such as TXT, CNAME, and MX. If your provider splits hosting from DNS, confirm which service is authoritative before you change anything. The wrong zone is a common failure mode and a waste of a careful afternoon.

If your plan includes hosted mail, the Email Hosting, Control Panel, and Webmail pages show the related tools in one place.

Step-by-step: verify domain ownership

1. Sign in to the control panel that manages your live DNS.
2. Open the domain or DNS section and confirm the zone name matches your domain exactly.
3. Use the provider’s verification method if one is required, usually a TXT record, email confirmation, or account-level check.
4. Wait for the provider to confirm the domain is active under your account before changing mail records.

Common issue: adding records to an unused parked zone or a stale nameserver setup. If verification fails, check which nameservers are actually delegated at the registrar. The ICANN Lookup tool is useful for confirming the public registration state of the domain: ICANN Lookup.

Step-by-step: add or update SPF without creating duplicate records

SPF is published as a single TXT record. The usual mistake is creating a second SPF record instead of merging all approved senders into one line. That breaks the record, and it is avoidable.

1. Search existing TXT records for one that starts with v=spf1.
2. If one exists, edit that record rather than adding a new SPF record.
3. Include every service that sends mail for your domain, such as your hosting mail server, help desk system, or newsletter platform.
4. End with an enforcement qualifier such as ~all or -all after you have confirmed the allowed senders.

Example:

v=spf1 include:_spf.yourhost.example include:spf.examplemail.com ~all

Keep the list tight. SPF has lookup limits, and a bloated record becomes difficult to maintain. If you need the hosting-side route, the Website Hosting area should show whether mail is sent from the same platform or a separate service.

Step-by-step: enable DKIM signing for outgoing mail

DKIM is usually enabled from the mail or security section of the control panel. The process often creates a selector and a public key record in DNS. The sender signs outbound messages with the private key; receiving systems check the public key you published.

1. Find the DKIM or email authentication settings for your domain.
2. Generate the DKIM key pair if the control panel offers that option.
3. Publish the DKIM TXT or CNAME record exactly as provided.
4. Enable signing for outbound mail from the mail service.
5. Send a test message and confirm the header shows DKIM=pass.

Do not shorten the selector or copy only part of the key. DKIM fails quietly when the published record does not match the signer.

Step-by-step: publish a DMARC record and start with monitoring

DMARC should begin in monitoring mode. That gives you reports without forcing a hard reject policy on mail that still needs cleanup. Start with p=none, review reports, and only move to stricter policies after you know which systems are sending on your behalf.

Example starter record:

v=DMARC1; p=none; rua=mailto:[email protected]; adkim=s; aspf=s

1. Create a mailbox or alias that can receive DMARC aggregate reports.
2. Publish the DMARC TXT record at _dmarc.yourdomain.example.
3. Leave the policy at p=none while you review the reports.
4. Check whether legitimate senders align with your From domain.

Google’s current sender guidance and Microsoft’s email security guidance both support a staged approach. Set up the authentication first, then review reports before tightening the policy. That is the orderly path.

How to test results in webmail, message headers, and DNS lookups

Testing is not optional. Send a message to an external mailbox you control, then inspect the full headers. You want to see SPF, DKIM, and DMARC all passing, or at least understand exactly which part failed.

• Use your Webmail inbox to send a test message from the configured domain.
• Review the message headers in the receiving mailbox.
• Run DNS lookups for the SPF, DKIM, and DMARC records.
• Confirm the records are live after DNS propagation, not just saved in the control panel.

For additional background on authentication checks, Microsoft’s documentation on how email authentication works is a practical reference: How email authentication works in Microsoft 365.

Common mistakes that break deliverability

Mistake	Why it matters	Safer approach
Multiple SPF records	Only one SPF record should exist per domain	Merge all senders into a single TXT record
Missing DMARC alignment	Mail may authenticate but still fail policy checks	Use matching From, SPF, and DKIM domains where possible
Starting with strict DMARC	Legitimate mail can be blocked before you see the reports	Begin with monitoring and tighten later
Editing the wrong DNS zone	Records never reach the authoritative nameservers	Confirm the active zone and registrar delegation first
Forgetting third-party senders	Apps and services can suddenly fail authentication	Keep a current inventory of every sender

A forwarding hop can also interfere with SPF, which is why DKIM and DMARC matter as part of the set rather than as a single fix. That is the operational reality.

A practical minimum-safe setup

If you want a simple baseline, use this order:

1. Verify the domain in the live control panel.
2. Publish one clean SPF record.
3. Enable DKIM signing.
4. Add DMARC in monitoring mode.
5. Test with external mail and review the reports.

Once the setup is stable, document the record values and the people who can change them. Reliability is not a decoration; it is a habit.

Need help reviewing your setup? Use Support if a record will not validate, or return to the homepage for the main hosting and email paths.