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

If your business uses professional email, configuring SPF, DKIM and DMARC should be an important part of setting up your domain. These three email authentication standards help receiving mail servers verify messages, reduce certain forms of email impersonation and improve the information available when deciding whether an email is legitimate.

Without appropriate authentication, criminals may find it easier to impersonate your company’s domain. Incorrect configuration can also cause legitimate business emails to fail authentication, potentially affecting deliverability.

For businesses in Zimbabwe, this matters whether you use a .co.zw or .com domain. If you send invoices, quotations, contracts and customer communications using your company email address, your domain should be configured properly.

This guide explains what SPF, DKIM and DMARC do, how to obtain the correct DNS values from your email provider, how to publish the records and how to test the configuration safely.

You do not need to become a DNS expert to understand the process, but you should be careful when changing records because an incorrect configuration can interfere with legitimate email.

If you use Tremhost for business email, you can review the service and its authentication features at Tremhost Business Email Hosting.

What Are SPF, DKIM and DMARC?

SPF, DKIM and DMARC are email authentication standards that work together to help receiving mail servers evaluate messages claiming to come from your domain.

They address different parts of the authentication process.

SPF (Sender Policy Framework) identifies which sending servers are authorised to send email for your domain.

DKIM (DomainKeys Identified Mail) uses a cryptographic signature that allows receiving servers to verify that a message was signed by an authorised sending system and that the signed content has not been altered in transit.

DMARC (Domain-based Message Authentication, Reporting and Conformance) allows you to publish a policy for handling messages that fail relevant authentication and alignment checks. It also supports reporting so you can understand how your domain is being used.

These technologies are especially important because an attacker may attempt to send an email that appears to come from your company’s domain.

For example, a criminal could try to send a fraudulent invoice using an address that resembles [email protected]. Proper authentication helps receiving systems identify certain unauthorised messages claiming to come from your domain.

However, SPF, DKIM and DMARC are not complete email security solutions. They do not prevent every phishing attack, and they cannot guarantee that messages from compromised legitimate accounts are safe.

Before You Start: What You Need

Before changing your DNS records, prepare the information and access required for the configuration.

First, you need access to the DNS management account for your domain. This may be your domain registrar, hosting provider or an external DNS service such as Cloudflare.

Second, you need access to your email hosting account or administration panel. Your email provider should supply the exact SPF and DKIM configuration required for its service.

Third, identify every platform that sends email using your domain. This is extremely important because your business may send messages from several different systems.

For example, your organisation may use:

• Business email accounts for employees.
• Website contact forms.
• An invoicing or accounting platform.
• A customer relationship management system.
• A helpdesk or ticketing platform.
• An email marketing service.
• Automated website notifications.

All legitimate sending systems should be considered before creating or changing your authentication records.

Finally, make a copy of your existing DNS records. Record the current values and the date before making changes. If something goes wrong, this information makes troubleshooting and recovery easier.

Step 1: Identify Where Your Domain’s DNS Is Managed

The first step is to establish which service is responsible for your domain’s authoritative DNS records.

Your domain registrar and DNS provider are not necessarily the same company.

For example, you may register a domain through Tremhost but use Cloudflare to manage its DNS. In that situation, DNS records should be published in the authoritative Cloudflare zone rather than simply added to an inactive DNS zone at the registrar.

You can identify the authoritative nameservers using a DNS lookup tool or a terminal command:

dig NS yourdomain.com

Replace yourdomain.com with your actual domain.

The returned nameservers indicate which DNS service is authoritative for the domain.

If you are using a DNS management dashboard, check the nameservers shown there against the domain’s actual delegation.

Do not change nameservers just to add SPF, DKIM or DMARC records. Changing nameservers can affect your entire DNS configuration, including your website, email and other connected services.

If you need help understanding your domain’s DNS configuration, read How to Set Up DNS Records for Your Domain.

Step 2: Configure Your SPF Record

SPF stands for Sender Policy Framework. It allows your domain to publish a list of authorised sending servers.

When a receiving mail server receives a message, it can examine the sending server’s IP address and compare it against the SPF policy published by the domain.

If the sending server is not authorised, SPF authentication may fail.

How to Create an SPF Record

Your email hosting provider should supply the SPF value required for its mail servers.

In your DNS management dashboard, locate the section for adding a new record.

Select TXT as the record type.

For a typical root-domain SPF record, the hostname or name is often entered as @, although the exact format depends on the DNS provider.

The value will begin with:

v=spf1

A simplified example of an SPF policy is:

v=spf1 include:YOUR-EMAIL-PROVIDER -all

This is an illustrative template, not a working record. Replace the placeholder with the exact SPF mechanism supplied by your email provider.

If your company uses more than one service to send messages, the SPF policy must account for the legitimate sending sources. Do not simply add a second SPF record.

Important SPF Rules

A domain should normally publish only one SPF record for a particular hostname.

If you already have an SPF record, update the existing policy rather than creating another independent SPF TXT record.

SPF also has a limit of 10 DNS-querying mechanisms and modifiers during evaluation. Too many nested includes and lookups can cause a permerror result.

Avoid copying SPF records from another company’s domain. Different providers use different sending infrastructure.

Finally, do not automatically use -all or a strict policy without checking every legitimate sending service. An incomplete record could cause genuine business messages to fail SPF.

Step 3: Configure Your DKIM Record

DKIM stands for DomainKeys Identified Mail. It allows an email-sending service to attach a cryptographic signature to outgoing messages.

The receiving server can retrieve the corresponding public key from DNS and use it to verify the signature.

This helps establish that the message was signed by an authorised system associated with the domain and that the signed content has not been altered.

How to Enable DKIM

Your email provider should supply the DKIM configuration details. In many hosting environments, the control panel provides a dedicated email authentication section.

For a cPanel-based hosting account, look for:

cPanel → Email → Email Deliverability

Select the relevant domain and inspect its authentication status.

Where supported, the interface may show the required DKIM and SPF configuration and indicate whether the records are valid.

If your DNS is hosted externally, the control panel may provide the records without being able to publish them automatically. In that situation, copy the supplied record into your authoritative DNS dashboard.

Understanding a DKIM DNS Record

A DKIM record is usually published as a TXT record under a selector-specific hostname.

A simplified example might look like:

default._domainkey.yourdomain.com

The corresponding TXT value may contain a public key:

v=DKIM1; k=rsa; p=YOUR-PUBLIC-KEY

This is an illustrative example only. Your actual selector and public key must come from your email provider.

Some providers use different selectors or CNAME-based DKIM configuration. Follow the exact instructions supplied by the service.

Do not create a new DKIM key and assume it will automatically match your provider’s outgoing email signatures. The private signing key and published public key must correspond.

Once the record has been published, ask your provider or administrator to verify that outgoing messages are being signed and that receiving servers can validate the signature.

Step 4: Configure Your DMARC Record

DMARC stands for Domain-based Message Authentication, Reporting and Conformance.

It builds on SPF and DKIM by allowing your domain to specify what receiving mail servers should do with messages that fail relevant authentication and alignment checks.

DMARC also supports reporting, helping domain owners understand which services are sending messages using their domain.

Understanding DMARC Policies

There are three main DMARC policy values:

p=none: Requests monitoring without asking receiving systems to quarantine or reject messages based on the DMARC policy.

p=quarantine: Requests that messages failing DMARC be treated as suspicious, often by placing them in spam or junk folders.

p=reject: Requests that messages failing DMARC be rejected.

A sensible starting point for a domain that has not previously used DMARC is often a monitoring policy. This allows the organisation to discover legitimate sending sources before enforcing a stricter policy.

How to Create a DMARC Record

In your DNS management dashboard, create a new TXT record.

The hostname is:

_dmarc

A basic monitoring example is:

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

Replace yourdomain.com with your actual domain and ensure that the reporting mailbox or address is configured to receive reports.

The rua tag specifies where aggregate DMARC reports should be sent.

These reports can help identify which systems are sending messages using your domain and whether SPF or DKIM authentication is passing.

A DMARC report address should be monitored. Aggregate reports can contain technical XML data, so a dedicated reporting tool may make them easier to understand.

Moving Towards a Stronger DMARC Policy

Once you have monitored the reports and confirmed that legitimate sending services are correctly configured, you can consider moving from p=none to p=quarantine and eventually p=reject.

Do not rush this process.

If your company uses an invoicing platform or website that sends messages using your domain, those messages must also be considered. A strict policy introduced before legitimate services are properly authenticated can interfere with genuine communication.

DMARC alignment is important. A message may pass SPF or DKIM in isolation but still fail DMARC if the authenticated domain does not align with the domain shown in the visible From address.

A gradual implementation is safer than immediately enforcing rejection without testing.

Step 5: Make Sure All Three Records Work Together

Once SPF, DKIM and DMARC have been published, you need to test the configuration.

Adding the records to DNS is not enough. You must confirm that your email system is actually using them correctly.

Send a test message from your business mailbox to an external account, such as a Gmail address.

If the recipient uses Gmail, they can open the message, select the message options and choose Show original.

The authentication results should indicate whether SPF, DKIM and DMARC passed.

Ideally, the message should show results similar to:

SPF: PASS
DKIM: PASS
DMARC: PASS

These results are examples of the desired outcome, not a guarantee that every email will produce identical results.

If one of the checks fails, investigate the associated domain, sending server and DNS configuration.

For example, an SPF failure may indicate that the sending server is missing from the SPF policy. A DKIM failure may indicate an incorrect public key, missing record or signature problem. A DMARC failure may indicate that neither SPF nor DKIM passed with the required domain alignment.

Test messages from every legitimate sending platform, not just your ordinary business mailbox.

Step 6: Allow for DNS Changes to Become Visible

After publishing a DNS record, it may take time for the updated information to become visible to different DNS resolvers.

The time depends on the record’s previous TTL, DNS caching and the provider’s infrastructure.

Some changes become visible quickly, while others take longer.

Do not repeatedly delete and recreate records because they do not appear immediately in every lookup tool.

Check the authoritative DNS provider first, then use an independent DNS lookup to verify the published values.

Also remember that a DNS record being visible does not automatically mean that the email service is using it correctly. You still need to test actual outgoing messages.

Step 7: Review Your DMARC Reports

After DMARC monitoring has been enabled, review the aggregate reports regularly.

They can help you identify:

• Which mail servers are sending messages using your domain.
• Whether those messages are passing SPF authentication.
• Whether DKIM signatures are valid.
• Whether authentication results align with your domain.
• Whether unexpected systems appear to be sending email using your domain.

For example, you may discover that your website sends contact-form notifications through a separate service that was not included in your original email authentication configuration.

You can then work with that service provider to configure the appropriate authentication.

Do not treat every unfamiliar sending IP address as evidence of an attack. Some legitimate services use third-party infrastructure, and reports may include forwarded messages or other indirect sending paths.

Investigate unfamiliar sources before changing your DMARC policy.

Common SPF, DKIM and DMARC Configuration Mistakes

Even experienced administrators can make mistakes when configuring email authentication. The following problems are worth checking before enforcing a strict DMARC policy.

Publishing Multiple SPF Records

Multiple SPF records for the same hostname can result in an SPF permanent error.

Maintain one valid SPF policy and combine the authorised sending mechanisms appropriately.

Forgetting Website and Application Email

A company may configure its main email server correctly but forget that its website, CRM or invoicing system also sends messages using the domain.

These systems must be considered when building the authentication configuration.

Using the Wrong DKIM Selector

DKIM selectors are provider-specific. A record published under the wrong selector may not match the signature attached to outgoing messages.

Always use the exact selector supplied by the email provider.

Publishing DMARC with an Incorrect Hostname

A DMARC record belongs under the _dmarc hostname for the relevant domain.

Publishing it under the wrong name may prevent receiving servers from finding the policy.

Enforcing a Strict DMARC Policy Too Early

Moving directly to p=reject without identifying all legitimate sending sources can cause genuine messages to fail DMARC.

Begin with monitoring, examine the reports, correct legitimate authentication failures and then gradually strengthen the policy.

Changing Nameservers Instead of Editing the Required Records

If your DNS is managed by Cloudflare, changing the domain’s nameservers simply to add an SPF or DKIM record is unnecessary.

Publish the record in the DNS service that is already authoritative for your domain.

Changing nameservers without migrating the complete DNS zone can affect your website and email services.

How Tremhost Business Email Hosting Supports Authentication

Tremhost provides business email hosting for organisations that want professional email addresses using their own domain names.

Its published business email service includes SPF, DKIM and DMARC authentication support, alongside spam and virus filtering, two-factor authentication and encryption in transit.

The service also supports IMAP, POP3 and SMTP for connecting compatible email applications, including Outlook, Apple Mail and Thunderbird.

For businesses that need help configuring their email environment, it is useful to confirm the current DNS requirements and the responsibilities of the hosting provider before making changes.

You can review the available plans and features at Tremhost Business Email Hosting.

If you are registering a new business domain, you can also explore Tremhost Domain Registration.

Frequently Asked Questions About SPF, DKIM and DMARC

Do I need SPF, DKIM and DMARC for my business domain?

They are strongly recommended for organisations using domain-based email. Together, they help receiving systems authenticate messages and provide domain owners with more control over unauthorised email use.

Can I use SPF, DKIM and DMARC with a .co.zw domain?

Yes. These are DNS-based email authentication standards and can be configured for a .co.zw, .com, .org or other domain extension, provided the DNS provider supports the required records.

Where do I add SPF, DKIM and DMARC records?

Add them in the authoritative DNS zone for your domain. This may be managed by your registrar, hosting company or an external DNS provider such as Cloudflare.

Can I have more than one SPF record?

A hostname should normally have one SPF record. If several services send email using your domain, their authorised sending mechanisms should be combined into that one policy, while staying within SPF’s DNS lookup limit.

Does DKIM encrypt my email?

No. DKIM provides a cryptographic signature that helps receiving systems verify message authenticity and integrity. It is not the same as encrypting the message contents.

Should I start DMARC with p=reject?

Not without first checking your legitimate sending services. A monitoring policy is often a safer starting point. Review reports, correct authentication and alignment problems, and then move gradually towards stronger enforcement.

How long does it take for SPF, DKIM and DMARC to work?

It depends on the DNS provider, record TTLs, caching and the email service’s configuration. Some changes become visible quickly, but you should verify the records and test actual outgoing messages before assuming the setup is complete.

Can SPF, DKIM and DMARC stop all phishing attacks?

No. They help authenticate messages claiming to come from your domain and reduce certain types of spoofing. They cannot eliminate phishing from unrelated domains or guarantee protection when a genuine account has been compromised.

Does Tremhost support SPF, DKIM and DMARC?

Tremhost’s published business email service includes these authentication features. The exact DNS values should be obtained from the relevant email account or provider configuration rather than copied from another domain.

Final Thoughts: Secure Your Business Domain Before Problems Start

SPF, DKIM and DMARC are important parts of a professional business email configuration. They help receiving mail servers evaluate messages, protect your domain against certain forms of impersonation and provide useful information about how your domain is being used.

The correct process is straightforward: identify all legitimate email-sending services, obtain their exact authentication records, publish them in your authoritative DNS zone, test outgoing messages and monitor DMARC reports.

Most importantly, do not copy random DNS values or enforce strict policies before confirming that your legitimate email services are properly configured.

If your business needs professional email hosting with authentication support, explore Tremhost Business Email Hosting. For a new company domain, visit Tremhost Domain Registration.