A marketing email sent from the wrong service, a forgotten support inbox, or a copied DNS record can be enough to send legitimate mail to spam. When you build SPF DKIM records correctly, receiving mail servers can verify that your domain authorized the sender and that the message was not altered after it left the server.
For a business domain, email authentication is not a cosmetic DNS task. It affects invoice delivery, password resets, WooCommerce order messages, support replies, newsletters, and everyday communication with customers. The goal is simple: publish accurate records, enable signing where required, and keep the configuration aligned with the services that actually send mail for your domain.
Why SPF and DKIM Need to Work Together#
SPF and DKIM solve different parts of the same trust problem.
SPF, or Sender Policy Framework, identifies which servers and services may send email using your domain. A recipient checks the IP address or sending host against the SPF policy published in DNS. If your domain sends mail through Microsoft 365, Google Workspace, a transactional email provider, and a help desk platform, each authorized source needs to be accounted for.
DKIM, or DomainKeys Identified Mail, adds a cryptographic signature to outgoing messages. The sending platform signs selected email headers using a private key. The recipient retrieves the matching public key from your DNS record and verifies the signature. This helps prove that the message was sent by an authorized system and was not materially changed in transit.
Neither record guarantees inbox placement by itself. Spam complaints, poor list quality, misleading content, and a newly used domain can still hurt delivery. But SPF and DKIM are the technical baseline for credible business email and are also necessary for a useful DMARC policy.
Map Every System That Sends Email First#
The most common SPF failure is building a record before identifying all senders. Start with an inventory of systems that send mail using your primary domain or a subdomain. This may include your company mailbox provider, web host, WordPress site, WooCommerce store, SMTP relay, newsletter service, billing application, CRM, and support desk.
Do not assume that a website sends through the same server as employee mail. A WordPress installation may use PHP mail, a hosting account, or a third-party SMTP plugin. Those paths have different authorization requirements and different reliability levels. In practice, configuring WordPress to send through a proper authenticated SMTP service is usually more dependable than relying on a shared hosting server’s default mail function.
Also separate direct domain mail from delegated subdomains. For example, employee mail might use example.com, while promotional mail uses marketing.example.com and automated receipts use notify.example.com. This structure can make policies easier to maintain and protects the reputation of core business mail when one sending stream develops a problem.
How to Build SPF DKIM Records for Your Domain#
Create one SPF record, not several#
SPF is published as a TXT record at the domain level. A basic example for a domain that sends mail through Google Workspace might look like this:
“` v=spf1 include:_spf.google.com -all “`
The `v=spf1` portion identifies the record as SPF. The `include` mechanism authorizes the provider’s published mail servers. The `-all` mechanism indicates that all other senders should fail SPF.
If you use multiple services, the record may contain multiple authorized mechanisms:
“` v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.25 -all “`
This example authorizes Google Workspace, a service that publishes SPF through `sendgrid.net`, and one dedicated server IP address. Your actual include value must come from the provider’s current documentation or setup screen. Do not copy an include value simply because it appears in another company’s record.
A domain must have only one SPF TXT record. Publishing separate TXT records for each platform does not combine them. Receivers may return a permanent error, often called SPF PermError. Merge all valid mechanisms into one record instead.
Be cautious with `~all`, which is a soft fail. It can be useful during a short migration while you verify that no legitimate sender was missed. Once the inventory is complete and mail flow is stable, `-all` provides a clearer policy. The right choice depends on how confident you are that every sender is known.
SPF has another practical limit: DNS lookups. A record cannot trigger more than 10 DNS-based lookups during evaluation. Too many nested `include`, `a`, `mx`, `ptr`, `exists`, or `redirect` mechanisms can cause SPF to fail even when the record appears reasonable. If your policy has accumulated several vendors over time, remove services you no longer use or assign high-volume platforms to authenticated subdomains.
Generate and publish the DKIM public key#
DKIM requires both DNS configuration and settings in the system that sends mail. Most modern providers generate the key pair for you. You enable DKIM in the provider’s administration panel, then add the DNS records it supplies.
A DKIM record typically uses a selector in its hostname. It may resemble this example:
“` selector1._domainkey.example.com TXT v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A… “`
The selector, shown as `selector1`, lets a domain maintain multiple DKIM keys. Different platforms can use different selectors without conflict. The public key after `p=` is normally a long single value. Keep it intact. Splitting, truncating, adding quotes incorrectly, or inserting a space inside the key can make verification fail.
Some providers use CNAME records instead of a direct TXT public key. This is normal. The provider may give you hostnames such as `s1._domainkey.example.com` that point to a managed DKIM hostname. Create the CNAME exactly as provided, including the selector. Do not replace a requested CNAME with a TXT record unless the provider explicitly supports that method.
Use a 2048-bit DKIM key when your provider supports it. It offers stronger cryptographic protection than older 1024-bit keys. The trade-off is a longer DNS value, which older DNS interfaces sometimes handle poorly. A reputable DNS provider and a current email platform should support 2048-bit DKIM without special handling.
Publish Records Carefully in Your DNS Provider#
DNS interfaces differ, but the workflow is consistent: select the correct domain zone, add the record type and hostname supplied by the email provider, paste the value, save it, and allow DNS time to propagate.
Pay close attention to how the provider handles the domain name. Some control panels automatically append `example.com` when you enter a host such as `selector1._domainkey`. Others expect the complete hostname. Entering the full domain where it is appended automatically can create an invalid name such as `selector1._domainkey.example.com.example.com`.
TTL settings are usually not the deciding factor. A value of 300 to 3600 seconds is practical while deploying or changing records. What matters more is avoiding duplicate TXT records, incorrect hostnames, and stale entries left by a previous email service.
After publishing DKIM, return to the sending platform and complete its verification step. Adding the DNS record alone does not always turn on signing. Confirm that the platform reports DKIM as active before treating the job as complete.
Test Authentication With a Real Message#
A DNS lookup can confirm that records exist, but a real delivered message confirms that your systems use them correctly. Send a test message from each significant source: your employee mailbox, WordPress transactional mailer, support platform, and marketing service.
Open the received message headers and look for the authentication results. You want to see SPF pass for the envelope sender and DKIM pass for the signing domain. If you use DMARC, the domains must also align. In plain terms, the domain visible in the From address should match, or be organizationally aligned with, the domain validated by SPF or DKIM.
If SPF passes but DKIM fails, inspect the DKIM selector, record type, and public key. If DKIM passes but SPF fails, compare the sending IP or provider to the SPF policy. If both pass but DMARC fails, the usual cause is domain alignment rather than a missing DNS record.
Keep Email Authentication Maintainable#
Email systems change more often than DNS records suggest. A new newsletter platform, a migration from shared hosting, or an abandoned SMTP plugin can make an old policy inaccurate. Review SPF and DKIM whenever you add or remove an email service, change your website mail configuration, or move DNS management.
Avoid adding an SPF include “just in case.” Every authorization expands the number of systems that can send as your domain and makes troubleshooting harder. Record why each include, IP address, and DKIM selector exists. A short internal note can save hours when a contractor, hosting provider, or marketing tool changes later.
Once your legitimate mail passes SPF and DKIM consistently, DMARC is the practical next step. Start in monitoring mode, review the results, then tighten enforcement gradually. Good email authentication is less about a one-time DNS entry and more about keeping your sending setup accurate as the business grows.