DMARC does not decide whether a form submission is genuine. It checks whether the domain visible in From aligns with a domain authenticated by SPF or DKIM, then applies the From domain owner’s policy.
A legitimate enquiry can therefore be rejected when WordPress sends with the visitor’s address or an unverified website domain.
Read the rejected identity
Preserve the bounce or recipient authentication result from a synthetic test. Record the visible From domain, SPF-authenticated envelope domain, DKIM signing domain and DMARC result.
Do not share the whole message or recipient address. The alignment domains and redacted SMTP code are normally enough to identify the fault.
Confirm which domain published the DMARC policy being enforced.
Stop impersonating visitors
If the form places a submitted Gmail, Outlook or company address in From, the website is sending as a domain it does not control. That visitor domain may publish a strict DMARC policy.
Use a fixed address on the website’s verified sending domain as From. Put the visitor in Reply-To so the recipient can answer naturally.
Validate Reply-To through supported form fields and prevent raw header injection.
Choose an aligned authentication path
DMARC can pass through aligned SPF or aligned DKIM. The authenticated domain must match or be a permitted subdomain relationship with the visible From, depending on strict or relaxed alignment settings.
Configure the mail provider’s custom return path for SPF alignment where supported, or sign with DKIM using the From domain. DKIM often survives normal forwarding better than SPF.
Do not assume an SPF pass for the provider’s own domain aligns with yours.
Verify the provider’s domain setup
Complete sender-domain verification in the SMTP or transactional provider. Publish its exact DKIM and custom bounce-domain records at authoritative DNS.
Check for provider verification status, selector rotation and old records left by a previous service. Keep one valid SPF policy for each envelope hostname.
Never publish a private DKIM key or copy one from an unrelated server.
Treat policy changes as controlled work
Changing p=reject to p=none may allow unauthenticated messages but weakens protection for the entire domain and does not fix alignment. Do not make that the default form repair.
If a temporary monitoring policy is genuinely required, coordinate it with the domain’s mail owner, document the reason and rollback, and inspect aggregate reports.
Apply policy gradually only after inventorying all legitimate senders.
Check forwarding and mailing lists
SPF can fail after forwarding because the forwarding IP is not authorised by the original envelope domain. An aligned DKIM signature may still let DMARC pass if message content is not modified.
Mailing lists and gateways that rewrite subjects or bodies can break DKIM. Compare direct delivery with the forwarded route and inspect ARC evidence where the recipient system supports it.
Repair the modifying or routing system rather than weakening every sender.
Test all WordPress message types
Forms, WooCommerce, password resets and security plugins may set From independently. Test the affected form first, then inventory other transactional messages that use the same domain.
Visitor confirmation emails can use a different template and header configuration from administrator notifications. Confirm both.
Keep marketing platforms and transactional providers documented as separate sending sources.
Prove alignment and mailbox delivery
After correcting From or provider authentication, submit a new labelled form. Confirm SPF and/or DKIM pass with alignment, dmarc=pass, provider acceptance and final mailbox arrival.
Test the real company recipient and review bounces from the failure window. Retain a redacted authentication record for future migrations.
Request urgent repair when a strict organisational policy spans several services or forwarded mail still fails. Share public DNS and redacted authentication results—never account credentials or real submissions.