Yes. WordPress can send mail from [email protected], [email protected], or any address on a domain you control, provided you publish three things at your DNS host: an SPF record authorising your transactional email provider to send as your domain, one or two DKIM records with the public key your provider uses to sign outgoing messages, and (optionally but strongly recommended) a DMARC policy telling mailbox providers what to do with mail that fails either check. All three records live at your registrar or DNS host; WordPress doesn’t manage DNS.
The setup is not WordPress-specific: it’s how authenticated email works on the internet. What is WordPress-specific is that many WordPress sites skip this setup entirely, rely on their host’s default mail() function, and end up sending mail that authenticates for the host’s domain (or authenticates for nothing) rather than for the site’s own domain. The result is spam-foldering at best and outright rejection at Gmail after February 2024.
The three DNS records, and what each one does
SPF (Sender Policy Framework). A TXT record on the domain’s apex that lists the servers or providers authorised to send mail as @yourdomain.com. Looks like v=spf1 include:spf.messagingengine.com include:sendgrid.net -all. When a mailbox provider receives a message claiming to be from your domain, it checks the sending IP against the list. If the IP isn’t authorised, SPF fails.
You publish one SPF record for your entire domain. If you send through multiple providers (Postmark for transactional, Brevo for marketing, Google Workspace for human mail from your team), the record has multiple include: clauses (one per provider). Each provider’s docs tell you which include to add.
DKIM (DomainKeys Identified Mail). One or two TXT records on a provider-specified subdomain (typically <selector>._domainkey.yourdomain.com). The record contains the public half of a cryptographic key. The provider signs every outgoing message with the private half; the receiving mailbox provider fetches your public key to verify the signature. If the message was altered in transit or came from someone who doesn’t hold the private key, DKIM fails.
Every provider publishes its own DKIM record shapes. Postmark uses one record on a selector like 20240101._domainkey.yourdomain.com. Amazon SES uses three CNAME records pointing at Amazon-hosted keys. Google Workspace uses google._domainkey.yourdomain.com. Publish exactly what your provider’s DKIM setup page tells you.
DMARC (Domain-based Message Authentication, Reporting, and Conformance). One TXT record at _dmarc.yourdomain.com that tells mailbox providers what to do with mail that fails SPF and DKIM, and where to send reports about failures. Looks like v=DMARC1; p=quarantine; rua=mailto:[email protected]; adkim=r; aspf=r.
DMARC is not strictly required for a WordPress site to send authenticated mail: SPF and DKIM alone are enough for the message to authenticate at the mailbox provider. But Gmail’s post-February-2024 sender requirements ask for a DMARC policy on sending domains, and Yahoo has the same requirement. A DMARC record at p=none (report-only) is the safe way to publish one initially; graduate to p=quarantine once the reports show your mail is authenticating cleanly.
The WordPress side, once DNS is published
The WordPress side is small compared with the DNS side. Two settings inside the SMTP plugin:
- The
From:address. Set it to an address on your domain:[email protected],[email protected], whatever fits the site’s tone. The address doesn’t have to be a real inbox that receives replies (though it can be); it just has to be on the domain you published SPF and DKIM for. - “Force From Email.” Enable this. WooCommerce, membership plugins, and contact form plugins routinely set their own
From:headers per-message, and any override that doesn’t match your authenticated domain will fail DKIM alignment. Forcing the From address makes the SMTP plugin overwrite these per-message overrides.
That’s it. The plugin sends mail through your provider’s authenticated pipeline, the provider signs it with the DKIM key on your domain, and mailbox providers receive it as legitimately-from-your-domain. See Change WordPress’s default email sender details for the mechanical setup.
Choosing the provider whose DNS you’ll be publishing
Every transactional provider works the same way from the WordPress operator’s side: publish their SPF include and their DKIM records, and mail authenticates as your domain. The providers differ on price, deliverability reputation, and how easy the DNS setup is. Common choices:
- Postmark: the cleanest reputation for transactional mail. DNS setup is one SPF include plus one DKIM record. $15/mo for 10,000 messages.
- SMTP2GO: generous free tier (1,000 messages/month, no card), straightforward DNS.
- Amazon SES: cheapest at real volume ($0.10 per 1,000 messages). DNS setup is three CNAME records and the initial “sandbox” account limits sending to verified recipients until you request production access.
- Brevo: one account covers both transactional and marketing. Free tier caps at 300 messages per day.
See transactional email providers for WordPress for the full comparison. See Best SMTP plugin for WordPress for the plugin side.
Common mistakes
Publishing SPF as a plain A record or MX record. SPF must be a TXT record. Registrars sometimes have a separate “SPF” record type that maps to the deprecated SPF DNS record type; use TXT.
Publishing multiple SPF records for the same domain. RFC 7208 allows only one SPF TXT record per domain; multiple records are treated as a permanent error and the SPF check fails. If you already have a Google Workspace SPF include and are adding a transactional provider, merge them into a single record: v=spf1 include:_spf.google.com include:spf.messagingengine.com -all.
Publishing DKIM on the apex instead of the provider’s selector. The provider’s DKIM setup page names the exact host to publish on (e.g., 20240101._domainkey). Publishing the record at the domain apex or at dkim.yourdomain.com won’t work: mailbox providers know exactly which selector to fetch based on the d= and s= values in the DKIM signature.
Publishing DMARC too strictly on day one. p=reject on a fresh setup will reject legitimate mail if there’s any misconfiguration or if a hosted service you forgot about is sending as your domain. Publish p=none initially, watch the reports for a week or two, then tighten.
Full walkthrough: How to set up DNS for WordPress email: SPF, DKIM, DMARC.
What happens if you skip the DNS setup
The WordPress site sends mail, WordPress sees no errors, and the messages either:
- Land in Junk at Microsoft 365 and Yahoo, which score unauthenticated mail heavily but don’t reject it outright.
- Get rejected at the SMTP layer at Gmail, which enforces authentication as a hard gate for anything that looks like bulk or promotional mail (which includes automated WordPress notifications).
- Arrive as coming from the host’s domain rather than your domain, if the host’s default
mail()sends from[email protected]and the host has published SPF for its own IPs but not for your domain. This works technically but breaks your brand: recipients see[email protected]instead of[email protected].
The fix in every case is the same: publish SPF and DKIM on your domain, point the WordPress SMTP plugin at a provider whose records you published, and set an explicit From: on your domain. See WordPress email setup: the complete guide for the end-to-end.