How We Brought Email Authentication to Every Domain We Host

Last month, we brought centralized email authentication monitoring to every domain across our hosting fleet. Each one now has DMARC, SPF, and DKIM properly configured and reporting — which means each one is protected against email spoofing, phishing, and the deliverability problems that come with unauthenticated email.

If those acronyms mean nothing to you, don't worry. By the end of this post, you'll understand what they do, why they matter, and why your hosting company should have set them up for you already.

The Problem: Anyone Can Pretend to Be You

Here's something most business owners don't realize: by default, anyone in the world can send an email that appears to come from your domain. There's no built-in verification in email. The "From" field is just text — it can say anything the sender wants.

That means a scammer in any country can send an email that looks like it came from info@yourbusiness.com, complete with your company name in the sender field. They can send phishing emails to your customers. They can send fake invoices to your suppliers. They can send malware-laden attachments that your contacts will open because the email appears to come from someone they trust.

And when those emails get reported as spam or phishing — which they will — it's your domain's reputation that takes the hit. Email providers like Gmail, Outlook, and Yahoo start treating your legitimate email with suspicion. Your real invoices land in spam folders. Your contact form notifications disappear. Your password reset emails never arrive.

This isn't theoretical. One of our clients — a Caribbean media company — had exactly this happen. A spoofed "DocuSign" email was sent from their domain to one of their business contacts, attempting to steal login credentials. The email had nothing to do with the actual company — someone simply used their domain as the "From" address because there was nothing stopping them.

After we deployed email authentication, that attack vector is closed. If someone tries to spoof that domain now, the receiving email server checks the authentication records, sees the email didn't come from an authorized source, and rejects it outright.

The Three Pillars of Email Authentication

Email authentication works through three complementary DNS records that work together. Think of them as three questions that a receiving email server asks about every incoming message:

SPF: "Is This Server Allowed to Send Email for This Domain?"

SPF (Sender Policy Framework) is a DNS record that lists every server and service authorized to send email on behalf of your domain. When Gmail receives an email claiming to be from yourbusiness.com, it checks the SPF record. If the sending server isn't on the list, the email fails the SPF check.

For our hosting clients, the SPF record typically includes our hosting servers (for WordPress notification emails), Amazon SES (for transactional email delivery), and any other legitimate services — Google Workspace, Microsoft 365, marketing platforms like Mailchimp, or CRM systems that send email on behalf of the domain.

DKIM: "Was This Email Actually Sent by Us, and Has It Been Tampered With?"

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to every outgoing email. It works like a digital seal: the sending server signs the email with a private key, and the receiving server verifies the signature using a public key published in the domain's DNS records.

If even a single character of the email was altered in transit — whether by a man-in-the-middle attacker or a mailing list that modifies headers — the DKIM signature won't match. The receiving server knows the email has been tampered with.

DKIM is particularly important because it survives email forwarding. SPF can break when email is forwarded (the forwarding server's IP won't be in the original domain's SPF record), but the DKIM signature remains intact because the email content hasn't changed.

DMARC: "What Should We Do If SPF and DKIM Don't Pass?"

DMARC (Domain-based Message Authentication, Reporting, and Conformance) ties SPF and DKIM together and tells receiving servers what to do when authentication fails. It also sets up reporting — receiving servers send reports back to the domain owner showing who's sending email claiming to be from their domain.

DMARC has three policy levels, and we use them as an escalation ladder:

This escalation is important. You don't jump straight to "reject" because you might accidentally block legitimate email from a service you forgot to add to your SPF record. The monitoring phase catches those gaps before enforcement causes problems.

How We Deployed It Fleet-Wide

Most of our hosting clients don't manage their own DNS — we handle it as part of the hosting service. That gave us the ability to roll out DMARC fleet-wide using automated tooling, rather than making dozens of manual DNS edits through a web interface.

We used our server management CLI to update DNS records programmatically, server by server, domain by domain. Each domain's existing DMARC policy was preserved — domains that were already at "quarantine" stayed at quarantine, domains that were at "reject" stayed at reject. The change was adding centralized reporting to a single monitoring endpoint, so all DMARC reports from every domain flow into one place.

The rollout covered domains across all of our servers — from New York to Chicago to Amsterdam. Every domain was verified after deployment, and the first reports started arriving within 24 hours.

What We Found in the Reports

Within the first week, DMARC reports confirmed exactly what we expected: the vast majority of email from our clients' domains was legitimate, properly authenticated, and passing both SPF and DKIM checks. The authenticated senders matched what we'd configured — our hosting servers, Amazon SES for transactional delivery, and client-specific services like Google Workspace.

The few anomalies we found were edge cases: email forwarding chains that broke SPF alignment, or third-party services that clients had configured without informing us. In each case, we either added the legitimate sender to the SPF record or confirmed the source wasn't actually authorized and could be safely blocked.

What We Skipped (and Why)

Not every domain in our fleet got the centralized DMARC treatment. We deliberately excluded several categories:

• Client-managed DMARC: Several domains had existing DMARC records pointing to client-controlled monitoring. These clients manage their own email infrastructure, and we don't override their configuration without discussion.
• Government-managed domains: Government clients have their own security and compliance requirements for email reporting. We respect those boundaries.
• External DNS: Some domains use external nameservers that we can't manage through our server CLI. These need manual coordination with whoever controls the DNS.

Why Most Hosting Providers Skip This

Setting up DMARC properly takes expertise. You need to understand SPF syntax (and the 10-lookup limit that trips up almost everyone). You need to generate and deploy DKIM keys for each sending service. You need to start with monitoring, analyze the reports, and escalate to enforcement only when you're confident legitimate email won't be blocked.

Most hosting providers don't do any of this. The typical approach is:

• Set up a basic SPF record that includes the hosting server
• Maybe enable DKIM if the control panel makes it easy
• Never set up DMARC at all
• Hope for the best

"Hope for the best" works until someone spoofs your domain, or until Google tightens its email authentication requirements (which it did in February 2024, requiring DMARC for bulk senders), or until your real business email starts landing in spam because your domain has no authentication reputation.

We treat email authentication as infrastructure — the same way we treat SSL certificates, server monitoring, or bot protection. It's not an add-on. It's not an upsell. It's part of properly hosting a business website.

The Custom DMARC Tooling

To make ongoing monitoring practical, we built a custom CLI tool for fetching, parsing, and auditing DMARC reports. Major email providers (Google, Microsoft, Yahoo, Mimecast) send DMARC aggregate reports as XML files attached to daily emails. Our tool automatically processes these reports and surfaces the data we need:

• Pass/fail rates: What percentage of email is passing authentication?
• Source identification: Which servers are sending email as each domain?
• Failure analysis: When authentication fails, is it a spoofing attempt or a misconfigured legitimate sender?
• Policy escalation readiness: Is this domain ready to move from "monitor" to "quarantine" to "reject"?

This turns DMARC from a set-and-forget DNS record into an active monitoring tool. We review the reports regularly, catch misconfigurations early, and escalate enforcement policies as each domain's authentication profile stabilizes.

What This Means for Your Business Email

If you're a WebOps client, your domain's email authentication is already handled. SPF records list your authorized senders. DKIM keys are deployed for each sending service. DMARC policies are in place and being monitored. If someone tries to spoof your domain, the receiving server knows to reject it.

If you're not a WebOps client, here's a quick way to check your own domain: search for "DMARC check" online and enter your domain. If the result says "No DMARC record found," your domain is unprotected — anyone can send email pretending to be you, and there's nothing stopping them.

Email authentication matters more than most people realize. It protects your customers from phishing. It protects your brand from being associated with spam. It protects your own email deliverability by building a verified sending reputation. And in a world where email providers are increasingly requiring authentication for delivery, it's becoming table stakes for any business that depends on email — which is essentially every business.

Our technology stack includes email authentication as a standard component, not an afterthought. Combined with our premium plugin suite and active fleet management, it's part of the comprehensive hosting infrastructure that keeps your business running smoothly.

Want to know if your domain's email authentication is properly configured? Send us a message — we'll check it for free. And if you're ready for hosting that includes email security as standard, take a look at our managed WordPress hosting plans.