An authentication record is failing, and the question is which dashboard opens, which value copies out of it, and which record at which registrar is where it belongs. The arrival path varies (a red row in the DNS Auth Checker, a Google Postmaster warning, a plugin test send that Gmail flagged), but the fix chain is the same in each case.
The chain changes shape with the sending provider and the mailer plugin. This is the per-provider, per-plugin checklist for the WordPress SPF, DKIM, and DMARC setup.
Two roles: the plugin, and the provider
A common misconception is that installing a mailer plugin publishes the authentication records. It does not. The three-record chain has three separate owners:
- The sending provider (Postmark, SendGrid, Amazon SES, Mailgun, and every other SMTP or API service) generates the DKIM key pair and holds the private half. The provider’s dashboard shows the DNS values you publish so receiving mail servers can find the public key.
- The mailer plugin (WP Mail SMTP, FluentSMTP, Post SMTP) picks which provider signs outgoing mail. It routes
wp_mail()through the provider’s SMTP endpoint or API. It does not touch DNS. - The DNS registrar (Cloudflare, Namecheap, Route 53, GoDaddy, whichever runs the domain’s nameservers) is where the records are published.
DMARC is different. No provider generates it, no plugin knows about it. It is a policy record the domain owner writes and publishes at the registrar. A DMARC record can be added before any provider is configured; it has effect once at least one sending path aligns SPF or DKIM to the From-header domain.
Per-provider records: where they come from
| Provider | SPF | DKIM | Where in the dashboard |
|---|---|---|---|
| Postmark | Return-Path CNAME (pm_bounces to pm.mtasv.net) |
One TXT record, per-domain hostname and value | Sender Signatures, the domain, DNS Settings |
| SendGrid | One CNAME (emXXXX.yourdomain.com) |
Two CNAMEs (s1._domainkey, s2._domainkey) |
Settings, Sender Authentication, Authenticate Your Domain |
| Amazon SES | Automatic via amazonses.com; needs a custom MAIL FROM for alignment |
Three CNAMEs (Easy DKIM) | SES console, Verified Identities, the domain, Authentication |
| Mailgun | One TXT (v=spf1 include:mailgun.org ~all) at the sending subdomain |
One TXT at a Mailgun-generated selector shown in the dashboard | Sending, Domains, the domain, DNS records |
Postmark publishes SPF alignment through a pm_bounces Return-Path CNAME, not a direct v=spf1 include: in the domain’s own SPF record. The Return-Path CNAME is what makes Postmark align. The DKIM record is a single TXT with a hostname unique to your Postmark account. Both values live under Sender Signatures for the domain; a manual verify button in Postmark’s dashboard shortens the propagation wait.
SendGrid issues three CNAMEs when Automated Security is enabled (the default): one for SPF via a subdomain of the sending domain, and two for DKIM. The two DKIM selectors let SendGrid rotate keys without further DNS changes on the domain owner’s side.
Amazon SES treats SPF as covered by default: mail leaves through amazonses.com, which publishes its own SPF, so SPF pass alignment is satisfied for the envelope sender. That is not enough for DMARC alignment: DMARC requires the envelope From to match the From-header domain, and by default the envelope is amazonses.com. The fix is a Custom MAIL FROM Domain (SES console, Verified Identities, MAIL FROM Domain), which points an MX and TXT record at an SES subdomain and restores alignment. Without it, SES passes DKIM alignment through Easy DKIM but fails SPF alignment; DMARC still passes at p=none, but strict policies see intermittent failures.
Mailgun issues per-sending-domain credentials, and the DNS records follow the same pattern. A site using mg.example.com as its Mailgun sending domain publishes SPF and DKIM under that subdomain, not the root. This keeps Mailgun’s records isolated and avoids the SPF merge that would otherwise be needed when Google Workspace or Microsoft 365 also publishes SPF for the root.
For the DMARC record, every provider is the same: publish _dmarc.example.com as a TXT record with a starting policy of v=DMARC1; p=none; rua=mailto:[email protected]. DMARC does not live in any provider dashboard.
Per-plugin: what the mailer does at the authentication step
| Plugin | Setup flow | DNS diagnostics from inside WordPress | Publishes any DNS records |
|---|---|---|---|
| WP Mail SMTP | Per-mailer setup wizard for the major providers, linking out to each provider’s authentication docs | No | No |
| FluentSMTP | Per-mailer connection modal, links to the provider’s own authentication docs | No | No |
| Post SMTP | 3-step wizard (pick mailer, enter credentials, send test) | SPF, DKIM, and DMARC diagnostic checks under the settings screen | No |
The last column is the point of the table. No WordPress mailer plugin publishes DNS. Every SPF, DKIM, and DMARC value is added at the registrar by hand or via a registrar API. The plugin’s job is to pick the sending path so DKIM signs with the right domain and SPF has a Return-Path or envelope to align against.
WP Mail SMTP has the most complete setup flow for supported providers. SendGrid, Mailgun, Postmark, Brevo, and SMTP.com each get a dedicated setup screen inside the Mailers tab that walks through the credential fields and links out to the provider’s authentication documentation. Amazon SES has a dedicated screen too, but sits behind the Pro tier. The plugin does not fetch DNS values itself; it can send test messages that verify the connection but not the DNS chain end-to-end.
FluentSMTP takes the same credentials-plus-link approach in a lighter shell. The connection modal for each mailer collects the API key or OAuth token and links out to the provider’s authentication docs. There is no wizard on the WP Mail SMTP scale, so a first-time SES or Mailgun configurator will spend more time flipping between the plugin and the provider dashboard.
Post SMTP runs a 3-step wizard: pick the mailer from a list (Gmail, Outlook, Amazon SES, or generic SMTP), enter credentials or complete the OAuth flow, and send a test message before saving. It does not walk through DNS setup, but the settings screen does run SPF, DKIM, and DMARC diagnostic checks against the current sending domain, which flags a misconfigured record before mail starts bouncing.
For any of the three, the sequence is: complete the provider’s own domain authentication (records published, provider shows “verified”), configure the mailer plugin with credentials, then run the plugin’s test send. Reversing the order produces a working plugin with mail that still fails DMARC alignment.
Where each record goes at the registrar
The target for every SPF and DKIM record is the domain’s authoritative DNS zone at the registrar (Cloudflare, Namecheap, Route 53, GoDaddy, Hover, and every other DNS-hosting service).
Three registrar-level details cause more failed authentications than any provider or plugin quirk:
- Root vs subdomain. Provider dashboards usually show DNS hostnames as fully qualified (
s1._domainkey.example.com). Most registrar UIs want the relative name only (s1._domainkey) and append the domain automatically. Pasting the fully qualified hostname producess1._domainkey.example.com.example.comat the registrar, a record that does not resolve. If in doubt, check the registrar’s tooltip; a common giveaway that the record is doubled is a_domainkeyselector that the DNS Auth Checker cannot find. - The SPF merge. SPF requires exactly one TXT record per hostname. A site that already has an SPF record for Google Workspace and adds a second record for a mailer provider ends up with two records, and per
RFC 7208 § 3.2 authentication then returns PermError. Merge the include:directives into one record:v=spf1 include:_spf.google.com include:sendgrid.net ~all. This is the single most common SPF failure the DNS Auth Checker catches; the WordPress DNS setup guide covers the merge and the 10-lookup limit in detail. - TTL and propagation. Cloudflare typically applies changes within seconds; traditional registrars honour the existing record’s TTL, often 3600 (one hour) or higher. Postmark’s manual verify button cites a 48-hour propagation window; SES polls DNS automatically and cites up to 72 hours. In practice, most changes are visible within 10 to 15 minutes.
Verifying the fix
- Re-run the DNS Auth Checker. It reads the current SPF, DKIM, and DMARC records for the domain and flags syntax errors, missing includes, and alignment problems. A pass on all three rows is the DNS-level success signal.
- Send a real message and read the receiving server’s authentication results. The swaks-based end-to-end test guide covers issuing a live SMTP session that returns the
Authentication-Resultsheader from the receiving MTA. That header reportsspf=pass dkim=pass dmarc=passwhen all three are aligned; anything else identifies which check is still failing.- If the checker is green but the receiver still reports DMARC failure, the problem is alignment (envelope From vs header From, or DKIM
d=vs header From), not a missing record. The SES custom MAIL FROM case above is the most common instance; a Postmark install that skipped thepm_bouncesReturn-Path CNAME is another.
- If the checker is green but the receiver still reports DMARC failure, the problem is alignment (envelope From vs header From, or DKIM
Related coverage
- Gmail and Yahoo bulk-sender rules for WordPress – the pillar this checklist supports; the diagnostic that decides whether authentication is required in the first place.
- How to set up DNS records for WordPress email – the registrar-level record authoring guide, with the SPF merge and 10-lookup limit worked through in detail.
- What are DKIM and SPF in WordPress? – the concept-level primer for readers who want the definitions before the fix.
- Best WordPress SMTP plugins – the mailer plugin comparison, if the authentication problem sits alongside a plugin choice.
Changelog
- 2026-09-03 – Published. Records verified against Postmark, SendGrid, Amazon SES, and Mailgun documentation at publication date.