Review your email authentication records
Understand SPF and DMARC declarations, confirm your legitimate senders, and test real messages before changing a mail policy.
For your setup.
Choose your platform. A report may suggest one from source or delivery hints; confirm it matches the website you control.
The general steps below work across platforms. Choose a setup above for supported code examples.
Why this matters
Email authentication is separate from website speed. A declaration describes an intended policy; it does not establish that every sending service is authorized or that messages arrive in an inbox.
Check the actual sending domain
Enter your email domain in the Email DNS inspector for SPF, DMARC, MX, MTA-STS DNS and a bounded search of four common DKIM selectors. A miss does not mean the domain has no DKIM: custom selectors may be outside this list. For an exact check, enter the selector from s= in a sent message’s DKIM-Signature and its d= signing domain. You do not need to upload the message. The tool does not remove www or discover inherited DMARC policies. A website audit checks its discovered DNS zone, which may differ from your mail domain. Pasted SPF and DMARC records can also be reviewed locally.
Check SPF structure and every sending service
Review multiple SPF declarations, misspelled mechanisms, permissive +all and unreachable terms. Include your mail provider, newsletters and transactional email services. The inspector counts declared lookup-causing terms but does not expand includes or redirect policies. Confirm the full recursive lookup budget with your provider.
Read DMARC as a requested policy
Check the version, requested policy, alignment modes and reporting destinations. Under current RFC 9989, a missing p tag defaults to none and t=y changes the requested treatment for testing. The older pct tag is legacy. Receivers can differ; a declaration is not proof of enforcement or alignment.
Review routing and transport declarations
MX lists inbound mail-server destinations in priority order; a lone 0 . explicitly declares no inbound mail. Missing MX alone does not prove delivery is impossible. An MTA-STS TXT record advertises a separate HTTPS policy; this tool checks the DNS declaration only. Ask your provider to verify that policy’s mode, MX coverage, certificate and SMTP TLS behavior.
Test mail before tightening a policy
Send representative messages through each legitimate service. Review Authentication-Results and aligned SPF or DKIM outcomes at receiving mailboxes, plus aggregate reports where configured. Ask your provider to verify DKIM selectors, signatures and external reporting authorization. Avoid replacing a working record with a generic example.
For your setup
DNS control panel
Edit TXT records where authoritative DNS is managed. Provider interfaces may display long TXT values as multiple quoted chunks; these can still be a single DNS record. Keep a copy of the previous configuration.
Email provider
Use its exact sending-domain and DKIM-selector instructions. SPF covers an envelope identity, while DMARC also considers identifier alignment; a website hostname alone is not enough to test either.
Check your work
- Inspect the published record after the DNS cache lifetime has elapsed.
- Test legitimate transactional, personal and newsletter messages separately.
- Review alignment and reports before requesting stricter treatment.
- Remember that the Bare Score does not grade email authentication or deliverability.