What email authentication records are and why they matter
Email authentication records are DNS-based policies that help receiving mail servers verify whether a message was authorized by the domain owner.
The three core standards are SPF, DKIM, and DMARC, and they work together to reduce spoofing, phishing, and spam placement.
If you are trying to improve inbox placement or troubleshoot rejected mail, learning how to check email authentication records is one of the fastest ways to find the problem.
The trick is knowing what each record does, where to look, and how to read the results correctly.
What you need before you check records
Before you start, gather the domain name used in the sender address and any third-party platforms that send mail on your behalf, such as Google Workspace, Microsoft 365, Mailchimp, SendGrid, HubSpot, or Salesforce.
You will also want access to a DNS lookup tool and, ideally, the full email header of a recent message.
The most useful record types for email authentication are:
- SPF for listing authorized sending servers
- DKIM for signing messages with a cryptographic key
- DMARC for defining policy and reporting
- MX for mailbox routing, which is not authentication but often checked during diagnostics
How to check email authentication records in DNS
The simplest method is to query your domain’s DNS records using a lookup tool.
You can use command-line utilities, web-based DNS checkers, or your domain registrar’s DNS management panel.
Check SPF records
SPF records are published as TXT records on the sending domain.
They tell recipient servers which IP addresses and mail services are allowed to send mail for that domain.
Look for a TXT record that starts with v=spf1.
A valid record may include mechanisms such as:
- ip4 and ip6 for specific addresses
- a and mx for authorized hosts
- include for third-party sending services
- all for the final rule, often paired with –, ~, or ?
Example SPF record:
v=spf1 include:_spf.google.com include:sendgrid.net -all
To check if it is working, confirm that the domain has only one SPF record.
Multiple SPF TXT records can cause a permanent error and break validation.
Check DKIM records
DKIM records are also stored in DNS as TXT records, but they live under a selector-specific subdomain, not the root domain.
A DKIM record usually appears in the format selector._domainkey.example.com.
To check DKIM, you need the selector used by the sending platform.
The record should contain a public key and a version tag such as v=DKIM1.
A valid DKIM record lets the receiving server verify that the message body and selected headers were not altered in transit.
Example DKIM record structure:
v=DKIM1; k=rsa; p=PUBLIC_KEY_VALUE
If DKIM is missing, the email may still send, but it will not have a cryptographic signature that DMARC can evaluate.
That often reduces trust, especially for high-volume senders.
Check DMARC records
DMARC records are published at _dmarc.example.com as TXT records.
They tell receivers what to do when SPF and DKIM checks fail and where to send reports.
Look for a record that begins with v=DMARC1.
Important tags include:
- p for policy, such as none, quarantine, or reject
- rua for aggregate report destinations
- ruf for forensic report destinations, when supported
- adkim and aspf for alignment settings
- pct for policy percentage
Example DMARC record:
v=DMARC1; p=quarantine; rua=mailto:[email protected]; adkim=s; aspf=s
If you are asking how to check email authentication records for deliverability issues, DMARC is often the record that explains the final outcome because it ties SPF and DKIM together with policy.
How to verify authentication using email headers
DNS records show what is configured, but email headers show what actually happened when a message was delivered.
Open the full message source or message details in your mailbox and locate authentication results.
Look for header fields such as:
- Authentication-Results
- Received-SPF
- DKIM-Signature
- ARC-Authentication-Results
In a healthy message, you may see results like spf=pass, dkim=pass, and dmarc=pass.
If one of them fails, inspect whether the sending service is authorized, whether the DKIM key is correct, or whether the domain alignment is broken.
Common problems when checking records
Many email authentication issues come from small DNS mistakes or mismatched sending setups.
The most common errors include:
- Multiple SPF records published for the same domain
- SPF records that exceed the DNS lookup limit
- DKIM selectors that point to the wrong subdomain
- Expired or rotated DKIM keys not updated in DNS
- DMARC policy set too aggressively before full testing
- Alignment mismatches between the visible From domain and the authenticated domain
DNS changes can also take time to propagate.
If you recently updated a record, allow for propagation before assuming the configuration is still broken.
How to interpret pass, fail, and neutral results?
A pass means the receiving server accepted the authentication check.
A fail means the check did not match the published policy or signature.
A neutral or none result usually means the sender was not explicitly authorized or the message was not evaluated in a strict way.
For SPF, a pass confirms the sending IP is allowed.
For DKIM, a pass confirms the signature verified successfully.
For DMARC, a pass requires that at least one of SPF or DKIM passes with alignment to the From domain.
Tools that make checking easier
You do not need to inspect everything manually.
Several tools can speed up the process and reduce mistakes:
- MXToolbox for quick SPF, DKIM, and DMARC lookups
- Google Admin Toolbox for DNS and message header analysis
- Microsoft Remote Connectivity Analyzer for Microsoft 365 environments
- DNS checker tools for verifying record propagation across regions
- Mail-tester for a test message and authentication summary
These tools are especially helpful when you manage multiple domains or send through several platforms, because they can reveal where a record exists, whether it is valid, and how receivers are evaluating it.
Best practices for maintaining email authentication
Checking records is only part of the job.
The goal is to keep them accurate as your sending infrastructure changes.
- Review SPF whenever you add a new email service
- Rotate DKIM keys according to your security policy
- Start DMARC with monitoring mode if you are unsure about all senders
- Use one documented list of all authorized mail platforms
- Test changes with sample messages before broad deployment
- Monitor DMARC aggregate reports for unauthorized sources
Organizations that send marketing mail, transactional mail, and internal mail often need separate authentication planning for each stream.
That makes documentation essential.
How to check email authentication records quickly during troubleshooting
If you need a fast workflow, follow this order:
- Identify the sender domain used in the From address
- Check SPF, DKIM, and DMARC TXT records in DNS
- Verify the DKIM selector used by the sending platform
- Review the message header for authentication results
- Compare the authenticated domain with the visible From domain
- Look for policy, alignment, or lookup-limit errors
This sequence helps you isolate whether the issue is in DNS, in the sending service, or in message handling by the receiving server.
When to escalate to your email provider or DNS host
If DNS records look correct but messages still fail authentication, the problem may be outside your domain.
Contact your email service provider if DKIM signing is missing or if the platform is using the wrong selector.
Contact your DNS host if records are not publishing correctly or if edits are not visible after propagation.
For high-volume senders, it is also worth checking whether a new IP, relay, or outbound gateway was added without updating SPF or DKIM.
That is a frequent cause of sudden authentication failures and inbox placement drops.