Setting Up DNS Records for WordPress Forms and E-Commerce
Why Every WordPress Site With Forms or E-Commerce Needs These DNS Records
A few years ago, setting up a WordPress form was simple: install a form plugin, choose your fields, and the server sent out notification and confirmation emails without any extra setup. That started changing around 2024, when Google and Yahoo rolled out stricter requirements for accepting email — they now expect proof that the sending server is actually authorized to send mail for that domain. Without it, the message doesn’t even land in spam; it just gets rejected outright, and Microsoft’s Outlook and Microsoft 365 have moved in the same direction. If you’ve ever filled out a contact form on a client’s website and the notification email never arrived — or a customer says they never got their order confirmation — the problem usually isn’t the plugin. It’s DNS.
The Root Problem: WordPress’s Default Mail Function Isn’t Reliable
By default, WordPress sends email using PHP’s built-in mail() function. This email doesn’t come from a real mail server with any reputation behind it, so many inboxes flag it as spam or reject it outright. This affects two things students and clients run into constantly:
- Form plugins (Contact Form 7, Ninja Forms, Gravity Forms, WPForms) — the notification email telling you someone filled out your form
- WooCommerce — order confirmations, shipping updates, and password reset emails sent to customers
The Fix: An SMTP Plugin Plus a Real Email Service
The standard solution is a plugin like WP Mail SMTP, which routes outgoing email through a real email delivery service instead of PHP’s mail() function. Popular choices include Google Workspace, Microsoft 365, SendGrid, Brevo, and Amazon SES.
Every one of these services will ask you to add DNS records to your domain before they’ll send email on your behalf. This proves you actually own the domain and aren’t just claiming to send email as someone else.
Step-by-Step: Setting Up WP Mail SMTP with Brevo
Here’s what this actually looks like in practice. Brevo is a good choice for most small business sites — its free tier covers 300 emails a day, and it’s much less of a headache to configure than Google Workspace.
- Install the free version of the WP Mail SMTP plugin.
- In the setup wizard, choose Brevo as your mailer.
- Set up a Brevo account (or log in if you already have one).
- In Brevo, go to your company name > Senders, Domains & IPs > Domains, and add your website’s domain.
- Brevo will give you the DNS records — mainly a DKIM record — needed to authenticate your domain. Add these at your domain’s DNS host (see Hover’s guide to managing DNS records if that’s where your domain lives). This is the same SPF, DKIM, and DMARC setup covered above.
- Give the DNS changes time to propagate (up to 24–48 hours), then confirm the domain shows as verified in Brevo.
- Back in Brevo, go to the SMTP & API menu, open the API Keys tab, and generate a new API key. Copy it immediately — Brevo only shows it once.
- In WordPress, go to WP Mail SMTP > Settings, paste in the API key, and enter your verified domain.
- Send a test email from WP Mail SMTP > Tools > Email Test to confirm everything is working.
The Three DNS Records You’ll Need
SPF (Sender Policy Framework)
A TXT record that lists which servers are allowed to send email for your domain. Without it, receiving mail servers have no way to know if an email claiming to be from your domain is legitimate. (Hover’s guide to creating an SPF record)
DKIM (DomainKeys Identified Mail)
A TXT record containing a public encryption key. It lets the receiving server verify that an email actually came from your authorized sender and wasn’t altered in transit.
DMARC (Domain-based Message Authentication, Reporting & Conformance)
A TXT record that tells receiving servers what to do if an email fails the SPF or DKIM check — reject it, send it to spam, or let it through — and where to send reports about failed attempts. (Hover’s guide to DMARC requirements)
How to Add These Records
- Log into wherever your domain’s DNS is managed (often your registrar, sometimes your host). If your domain is registered at Hover, see Hover’s guide to managing DNS records.
- Before you add anything: DNS records can only be added at your registrar if your domain is still using that registrar’s own nameservers. If the nameservers have been pointed to your hosting provider instead (common once a site is live), you’ll need to add these records in your host’s DNS settings, not your registrar’s. (Here’s how to check and change nameservers at Hover.)
- Your email service will give you the exact values to enter — copy them exactly, including any periods at the end.
- Add each one as a TXT record (occasionally a service uses a CNAME instead for DKIM — follow their instructions).
- DNS changes can take anywhere from a few minutes to 48 hours to propagate.
- Most email services have a “verify” button that checks whether the records are live yet.
Do You Need This If the Site Doesn’t Have Forms or WooCommerce?
If you only think about DNS and SMTP when a client’s site has a contact form or an online store, it’s worth reconsidering. WordPress relies on that same unreliable mail function for a few other things, and the most important is the “Lost your password?” reset link. If that email doesn’t arrive, your client is locked out of their own WordPress admin, with no easy way back in short of a database-level reset or a support ticket to their host — a worse problem than a missing marketing email.
Security and backup plugins lean on it too. Wordfence login alerts, UpdraftPlus backup failure notices, and WordPress’s own auto-update failure emails all go out through the same channel. If a client has any kind of plugin that emails them when something goes wrong, and that email silently fails, they lose the safety net without ever knowing it.
For a simple site where you’re the only WordPress user, the risk is low. But for any client site where they log in themselves — which is most of them — it’s worth setting up SPF, DKIM, and DMARC as standard practice, not just for sites with forms or an online store.
FAQ: Common DNS Pitfalls
There are two different ways to connect a domain to a hosting provider, and they lead to very different DNS setups. With an A record, you keep your domain on your registrar’s default nameservers (Hover’s, for example) and simply add an A record there that points to your host’s server IP address. Your registrar stays the authoritative DNS zone for everything — email records, subdomains, all of it. With nameservers, you change the nameservers themselves at your registrar to point to your host’s nameservers instead. This hands over full control of the domain’s DNS to the host, and your registrar’s DNS panel becomes irrelevant — every record, including email records, has to be added at the host instead. Neither approach is wrong, but you have to know which one is in use before you touch any DNS records, because it determines where those records actually belong.
There are three separate things DNS controls for a domain, and it helps to think of them separately. First, where the website itself is hosted — controlled by the A record (or by nameservers, if you’re using the nameserver method) and pointing to the server the site files actually live on. Second, email on the domain — real mailboxes like you@yourbusiness.com that a person checks, controlled by MX records, usually pointing to a provider like Google Workspace, Microsoft 365, or Hover Email. Third, server email — the automated email a WordPress site sends out on its own, like form notifications and WooCommerce order confirmations, which is what SPF, DKIM, and DMARC (the subject of this article) are for. These three are independent of each other, but they can interact: if a domain uses Google Workspace for real mailboxes and Brevo for server email, the SPF record needs to authorize both services, not just one, or something will break.
The most common cause is adding the record in the wrong place. A domain has only one active DNS zone at a time, and it’s determined by wherever the domain’s nameservers currently point — not by who’s hosting the website or who’s providing email. If your domain’s nameservers point to your hosting provider, any records you add at your registrar (like Hover) are simply ignored, even though they show up fine in that dashboard.
This is one of the most common points of confusion, and it trips up experienced developers too. It always comes down to the same rule: records go wherever the nameservers point, period. For example, say a site is hosted at SiteGround but the domain was originally registered at Hover. If the nameservers were changed to point to SiteGround, then all DNS records — including anything related to email — need to be added in SiteGround’s DNS zone editor, not Hover’s. Adding them at Hover in that scenario won’t do anything, because Hover’s DNS panel isn’t the one being consulted for that domain anymore. Mixing this up is a great way to lose an afternoon.
Check the nameserver section of your registrar’s dashboard, or use a free lookup tool like whatsmydns.net to see a domain’s current nameservers from the outside. This is worth checking before you touch any DNS records, especially on a site you didn’t originally set up.
No — a domain can only have one SPF TXT record. If a second SPF record gets added, most receiving mail servers will consider both invalid, which can break deliverability entirely. If a domain already has SPF from an old email provider or hosting company, you need to combine the values into a single record rather than adding a new one.
Most DNS changes are live within a few minutes to a few hours, though technically it can take up to 48 hours to fully propagate everywhere. If a record still isn’t showing as verified after an hour or two, it’s much more likely you added it in the wrong place (see the nameserver question above) than that you just need to wait longer.
Yes. Leftover SPF, DKIM, or MX records from a previous provider can conflict with the new ones and cause authentication to fail. When switching services, check for and remove records tied to the old provider instead of just adding new ones on top.
The Bottom Line
If a client’s contact form emails or WooCommerce order emails aren’t showing up, don’t assume the plugin is broken — check whether SPF, DKIM, and DMARC are actually set up. These records take a few minutes to add and are usually the real fix.