Understanding Email Authentication: SPF, DKIM, and DMARC

Email and Webmail | Updated 2026

If your emails are landing in spam folders, or if someone is sending fake emails that look like they come from your domain, you're likely dealing with a missing or misconfigured email authentication record. SPF, DKIM, and DMARC are three DNS records that prove to receiving mail servers that your emails are legitimate. This guide explains what each one does, how to check yours, and how to fix them on your Ultra Web Hosting account.

Why This Matters

01. Why Email Authentication Matters

Without proper email authentication records, receiving mail servers have no way to verify that an email from your domain actually came from your server. This causes two problems:

  • Your legitimate emails land in spam - Gmail, Outlook, and Yahoo all check for SPF, DKIM, and DMARC. Missing or failing records is one of the top reasons emails get filtered.
  • Anyone can forge emails from your domain - without these records, a spammer can send emails that appear to come from you@yourdomain.com. This is called spoofing, and it can damage your reputation and even be used for phishing attacks against your customers.

As of February 2024, Google and Yahoo require SPF and DKIM authentication for all bulk senders, and DMARC is required for anyone sending more than 5,000 emails per day. Even if you're a small sender, having all three records in place significantly improves your delivery rates.

Breaking down the SPF record

  • v=spf1 - identifies this as an SPF record (required)
  • +a - authorize the IP address in your domain's A record
  • +mx - authorize the servers in your MX records
  • +ip4:YOUR.SERVER.IP - explicitly authorize your server's IP address
  • ~all - soft fail for anything not listed (recommended). Use -all for strict rejection once you're confident everything is set up correctly.
Common Mistake

Never create multiple SPF TXT records for the same domain. If you need to authorize additional senders (like a marketing email service), add them to your existing SPF record with an include: directive. For example: v=spf1 +a +mx include:sendgrid.net ~all

03. DKIM: Digital Signatures on Your Emails

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to every email you send. The receiving server uses a public key published in your DNS to verify the signature, confirming that the email hasn't been tampered with and really came from your domain.

Think of it like a wax seal on a letter. If the seal is intact when it arrives, the recipient knows the letter hasn't been opened or altered.

How DKIM works

  1. Your mail server signs each outgoing email with a private key
  2. The signature is added as a header in the email
  3. The receiving server looks up your public key in DNS (a TXT record under default._domainkey.yourdomain.com)
  4. If the signature matches, the email passes DKIM validation

Setting up DKIM on Ultra Web Hosting

cPanel can generate DKIM records automatically:

  1. Log into cPanel
  2. Click Email Deliverability (under the Email section)
  3. Find your domain and click Manage
  4. If DKIM shows an issue, click Install the suggested record
  5. cPanel will add the DKIM TXT record to your DNS automatically

04. DMARC: Tying SPF and DKIM Together

DMARC (Domain-based Message Authentication, Reporting, and Conformance) tells receiving mail servers what to do when an email fails SPF and DKIM checks. Without DMARC, it's up to the receiving server to decide, and different servers handle failures differently.

A basic DMARC record

Add this as a TXT record for _dmarc.yourdomain.com:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

Breaking it down

  • v=DMARC1 - identifies this as a DMARC record (required)
  • p=none - policy for failures. Start with none (monitor only), then move to quarantine (send to spam), and eventually reject (block entirely) once you're confident everything is working.
  • rua=mailto:... - where to send aggregate reports. These reports show you who's sending email using your domain, which helps you identify spoofing.
Recommended Approach

Start with p=none and monitor the reports for a few weeks to make sure all your legitimate email sources are properly authenticated. Then move to p=quarantine and eventually p=reject. Going straight to reject without monitoring first can cause legitimate emails to bounce if something isn't configured right.

05. How to Check Your Current Records

Before making changes, check what records you currently have:

Using cPanel Email Deliverability

The easiest way: go to cPanel > Email Deliverability. It shows the status of SPF, DKIM, and reverse DNS for each domain, and flags any issues with a clear "Repair" button.

Using online tools

Using the command line

# Check SPF
dig TXT yourdomain.com | grep spf

# Check DKIM
dig TXT default._domainkey.yourdomain.com

# Check DMARC
dig TXT _dmarc.yourdomain.com

06. Setting Up Records in cPanel

If you manage your DNS through cPanel (which is the default for Ultra Web Hosting customers), here's how to add or fix each record:

  1. Log into cPanel and click Zone Editor (under the Domains section)
  2. Find your domain and click Manage
  3. Click + Add Record to add a new TXT record, or click the pencil icon to edit an existing one

Adding an SPF record

  • Type: TXT
  • Name: yourdomain.com. (or leave blank, depending on your cPanel version)
  • Value: v=spf1 +a +mx ~all

Adding a DMARC record

  • Type: TXT
  • Name: _dmarc
  • Value: v=DMARC1; p=none; rua=mailto:your@email.com

For DKIM, use the Email Deliverability tool instead of Zone Editor. It generates the correct key pair and adds the DNS record automatically.

07. Using Google Workspace or Microsoft 365?

If you use an external email provider while hosting your website with us, your SPF and DKIM records need to reference your email provider, not our mail server.

Google Workspace SPF

v=spf1 include:_spf.google.com ~all

Microsoft 365 SPF

v=spf1 include:spf.protection.outlook.com ~all

Both Ultra + Google Workspace

If you send from both (e.g., website forms from your server, business email from Google):

v=spf1 +a +mx include:_spf.google.com ~all

For DKIM with Google Workspace or Microsoft 365, follow your email provider's documentation. They each provide specific DKIM keys to add to your DNS. The process is the same as above (add a TXT record in Zone Editor), just with different values.

Need Help?

If you're not sure how to combine records for multiple email providers, open a support ticket and we'll set it up for you. Getting SPF wrong can break email delivery, so it's worth asking if you're unsure.

08. Common Problems and Fixes

"Emails going to spam"

Check all three records (SPF, DKIM, DMARC) using the tools in section 05. The most common causes are a missing SPF record, a missing DKIM record, or having multiple SPF records (which invalidates all of them).

"Someone is sending spam pretending to be us"

This is spoofing. Set up DMARC with a p=quarantine or p=reject policy so receiving servers will block or spam-folder these fake emails. Without DMARC, there's nothing stopping anyone from putting your domain in the "From" field.

"SPF record has too many DNS lookups"

SPF records are limited to 10 DNS lookups. Each include: directive counts as one, and some of them nest additional lookups. If you're using multiple email services (your hosting server, Google Workspace, Mailchimp, SendGrid, etc.), you can hit this limit. Tools like MXToolbox will show your current lookup count.

"DKIM signature not valid"

This usually means the DKIM key in DNS doesn't match the key your mail server is signing with. Re-run the cPanel Email Deliverability tool to regenerate and reinstall the DKIM record.

09. Testing Your Email Authentication

After setting up your records, test that everything is working:

  1. Send a test email to a Gmail address and open it. Click the three dots menu and select "Show original." Look for SPF: PASS, DKIM: PASS, and DMARC: PASS in the headers.
  2. Use mail-tester.com - send an email to the address it gives you and you'll get a detailed report showing whether your SPF, DKIM, and DMARC are passing.
  3. Check MXToolbox - run your domain through their SPF, DKIM, and DMARC checkers to validate the DNS records themselves.
  4. Wait 24-48 hours after making DNS changes before testing. Records need time to propagate, especially if you recently changed nameservers.
  5. Monitor DMARC reports - if you included a rua= address in your DMARC record, you'll start receiving XML reports showing who's sending email using your domain and whether they're passing authentication.

Need Help With Email Deliverability?

If your emails are still landing in spam after setting up these records, open a ticket and our team will check your DNS configuration, mail server settings, and IP reputation.

Open a Support Ticket

Last updated March 2026 · Browse all email articles

  • 0 Users Found This Useful

Was this answer helpful?

Related Articles

Why can I not send email?

It is possible your internet service provider may be blocking you from sending email outside of...

What port does POP3 run on?

POP3 Port Number   The standard POP3 ports are: Port 995 - POP3 with SSL/TLS encryption...

Server does not support TSL Connections

I received an error message when checking my email "Server does not support TSL Connections."...

IP Address Has Changed! Error When Using Webmail

"IP Address Has Changed" Error in Webmail   The error "IP Address Has Changed" can appear in...

Does email on the server count towards my allotted space?

Does Email Count Toward My Disk Space?   Yes, email stored on the server counts toward your...



Save 30% on web hosting - Use coupon code Hosting30