A customer receives an invoice that appears to come from your business, but the sender address was forged. Or your legitimate order confirmations and password reset emails start landing in spam. Both problems often trace back to the same issue: email authentication.
For a small business, WordPress site operator, or WooCommerce merchant, email is operational infrastructure. It carries sales receipts, support replies, account notifications, invoices, and marketing campaigns. If recipients or mailbox providers cannot verify that those messages are really yours, delivery becomes less predictable and your domain becomes easier to impersonate.
What Email Authentication Actually Does#
Email authentication is a set of DNS-based controls that lets receiving mail servers verify whether a message was authorized by the domain shown in its sender address. The three main standards are SPF, DKIM, and DMARC. They work best together because each checks a different part of the sending process.
This is not encryption. It does not prevent every phishing message, and it does not guarantee an inbox placement. A legitimate message can still be filtered because of poor content, a bad sending reputation, or low recipient engagement. What authentication does provide is a verifiable identity layer that modern mail systems increasingly expect.
That expectation is no longer limited to large organizations. Major mailbox providers apply stricter standards to bulk senders, while spam filters of all sizes use authentication results as a trust signal. Even a small domain benefits from setting it up correctly before an urgent delivery problem appears.
SPF: Which Servers May Send for Your Domain#
Sender Policy Framework, or SPF, is a DNS TXT record that lists the servers and services allowed to send email on behalf of a domain. When a recipient server gets a message, it compares the sending server’s IP address with the SPF policy.
A simplified SPF record might look like this:
“`text v=spf1 include:mailprovider.example include:transactional.example -all “`
The record says that the listed providers are allowed to send mail for the domain, while `-all` tells receivers that other servers should fail the SPF check.
SPF is useful, but it has limits. It validates the envelope sender, also called the return-path, rather than necessarily validating the address a customer sees in the From field. Email forwarding can also break SPF because the forwarding server, not the original sending service, delivers the message. That is why SPF alone is not enough.
DKIM: A Signature That Can Be Checked#
DomainKeys Identified Mail, or DKIM, adds a digital signature to outgoing messages. The sending platform signs selected message headers and content using a private key. The receiving server retrieves the matching public key from DNS and verifies that the message was signed by an authorized domain and was not materially altered in transit.
DKIM is particularly valuable for mail sent through multiple systems. Your website may send WooCommerce receipts through an SMTP provider, your team may use a business mailbox platform, and your newsletter tool may send campaigns from the same domain. Each service can use its own DKIM selector and publish its own public key.
Unlike SPF, DKIM generally survives normal forwarding. However, it can fail if a mailing list or intermediary modifies a signed portion of the email. Key rotation also matters. Keep old keys available for a reasonable transition period when changing providers, then remove records you no longer use.
DMARC: The Policy and Reporting Layer#
Domain-based Message Authentication, Reporting, and Conformance, or DMARC, connects SPF and DKIM to the visible From address. It checks whether SPF or DKIM passes and whether the authenticated domain aligns with the domain displayed to the recipient.
DMARC also tells receiving providers what to do when authentication fails. Its main policy options are `p=none`, `p=quarantine`, and `p=reject`. Monitoring with `p=none` requests reports but does not ask providers to block mail. Quarantine marks failed mail as suspicious. Reject asks providers to refuse it.
A basic monitoring record may look like this:
“`text v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r “`
The reporting address receives aggregate XML reports from participating mailbox providers. Those reports can be difficult to read directly, but they reveal a critical fact: every service attempting to send mail using your domain. A reporting tool can make the data easier to review, but the underlying records should remain understandable to the person responsible for the domain.
Why Authentication Problems Are Common on WordPress Sites#
A WordPress site can send email through PHP mail, server-level mail transfer software, an SMTP plugin, a transactional delivery service, or a hosting provider. A site may also have plugins that generate unexpected messages, such as form notifications, backup alerts, membership notices, and store updates.
The technical issue is not WordPress itself. The issue is that these sources are often configured separately. A merchant may authorize their newsletter platform but forget that WooCommerce receipts are sent through the web host. They may set up SPF for one service while another service uses a different return-path domain. DMARC then exposes the gap.
Shared hosting adds another variable. Sending directly from a shared server can work for low-volume administrative messages, but delivery quality depends partly on server reputation and correct server configuration. For business-critical mail, an authenticated SMTP or transactional email provider usually offers more control, better logs, and clearer separation between website mail and promotional campaigns.
A Practical Email Authentication Setup Process#
Start by making an inventory before changing DNS. List every system that sends as your domain: employee mailboxes, website forms, WooCommerce, CRM software, help desk platforms, newsletter services, billing tools, and monitoring systems. Do not rely on memory alone. Review application settings, old integrations, and DNS records.
Next, publish or confirm DKIM for each active sending service. Most reputable providers show the exact DNS record required in their administration panel. Use the record exactly as provided, including the selector name. Avoid manually shortening long DKIM keys or combining records incorrectly.
Then build one SPF record for the domain. A domain must not have multiple SPF TXT records. If you find two or three separate SPF entries, merge their authorized mechanisms into one valid record. Keep it focused on real senders. Adding broad entries such as `+all` defeats the purpose, while unnecessary includes can create DNS lookup-limit failures.
After SPF and DKIM are in place, publish DMARC with `p=none`. Let reports accumulate long enough to cover regular business activity, including monthly billing, campaign sends, and automated notifications. Investigate unknown sources before moving to enforcement. Some will be forgotten legitimate services; others may reveal unauthorized sending attempts.
When the reports show that legitimate sources authenticate and align correctly, move gradually to `p=quarantine`. A staged percentage can reduce risk, for example applying the policy to only part of failing traffic at first. Move to `p=reject` when you are confident that valid mail is covered. The right pace depends on how many systems send mail for the domain and how well they are documented.
Common Mistakes That Cause Delivery Failures#
The most damaging mistake is enforcing DMARC before discovering all legitimate senders. A forgotten scanner, ticketing system, or website plugin may suddenly fail delivery. That is not a reason to avoid DMARC. It is a reason to monitor first and treat email configuration as an inventory problem.
Another frequent issue is a mismatch between the visible From address and the domain used by the email platform. For example, a website may show `sales@yourdomain.com` in the From field while its transactional provider signs mail with an unrelated shared domain. The message may pass DKIM but fail DMARC alignment. Configure a custom sending domain whenever the provider supports it.
SPF records also require maintenance. Replacing an email provider without removing its authorization leaves an unnecessary path for future abuse. Conversely, removing an old provider too early can interrupt messages from a legacy system that still sends invoices or support notifications.
Finally, do not confuse successful DNS publication with successful delivery. Check real messages in major mailbox providers. Review headers for SPF, DKIM, and DMARC results. Test password resets, contact forms, receipts, and replies, not only a single message sent from a desktop email client.
Authentication Is Ongoing Mail Administration#
Once email authentication is working, document it alongside your domain and hosting settings. Record which systems send mail, who owns each service, which DKIM selectors are active, and where DMARC reports are reviewed. This saves time when a developer changes a plugin, a marketing team adopts a new platform, or a provider migrates infrastructure.
Good mail delivery is rarely the result of one DNS record. It comes from accurate configuration, legitimate sending practices, and periodic review. Set the controls carefully now, and your next customer email has a much better chance of being recognized as exactly what it is: a message from your business.