A client says they never received your invoice. A prospect asks why your sales follow-up landed in spam. Your team is certain the message was sent, but that is only one part of the question. An email authentication audit shows whether receiving mail systems can verify that your domain really authorized the message.
The straight answer: an audit checks the public records and mail settings that identify your approved senders, protect your domain from impersonation, and support trustworthy delivery. It does not promise inbox placement. It does give you a clear view of problems you can measure and fix before they become missed appointments, delayed transactions, or lost customer confidence.
What an email authentication audit checks
Email authentication is a set of technical checks that happen after you press Send. Most of the work is visible in your domain’s Domain Name System, or DNS, records. DNS is the public directory that tells the internet where your email is handled and which systems may send on your behalf.
A useful email authentication audit starts with three core standards: Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM), and Domain-based Message Authentication, Reporting, and Conformance (DMARC).
SPF is a DNS record that lists the mail servers and third-party services allowed to send email using your domain. If a marketing platform, invoice system, customer relationship management system, or website form sends mail for you, it may need to be included. SPF answers a narrow question: was this sending server permitted?
DKIM adds a digital signature to outgoing email. Receiving servers use a public key published in DNS to verify that the message was signed by an approved sender and was not changed in transit. DKIM is especially useful when multiple services send mail for your business.
DMARC tells receiving servers what to do when SPF and DKIM checks fail, and it can send reports about mail using your domain. DMARC also checks alignment. In plain language, alignment means the domain your recipient sees in the From address matches the domain used by SPF or DKIM. A message can technically pass an SPF or DKIM check but still fail DMARC if the domains do not line up.
A complete audit also examines the records and settings around those standards. That usually includes your mail exchange, or MX, records, which identify where your domain receives mail; reverse DNS, which connects a sending server’s internet address back to a domain; and SMTP connectivity, which checks whether Simple Mail Transfer Protocol mail servers can communicate as expected.
Two additional standards may apply. Brand Indicators for Message Identification (BIMI) can associate a verified brand logo with supported inboxes, but it depends on a properly configured DMARC policy and other requirements. Mail Transfer Agent Strict Transport Security (MTA-STS) tells other mail servers to require encrypted delivery to your domain when supported. TLS Reporting (TLS-RPT) provides reports about failures involving that encrypted transport. These are not substitutes for SPF, DKIM, and DMARC. They extend visibility and protection once the core setup is sound.
Why a passing record is not always a passing setup
Many businesses have an SPF record, DKIM key, and DMARC record in place, yet still have meaningful gaps. The audit needs to test how the records work together, not simply whether they exist.
An SPF record can be incomplete because a new vendor was added without updating DNS. It can also contain too many lookups. SPF has a limit on how many DNS lookups a receiving server must perform. When that limit is exceeded, legitimate mail can fail evaluation. The exact fix depends on how your sending services are arranged. Removing unused services may help, but consolidating or restructuring SPF entries is sometimes necessary.
DKIM can fail when a service is not signing messages, when the public key in DNS does not match the active private key, or when an old selector remains after a vendor change. A selector is simply the label that points a receiving server to the right DKIM key. An audit should identify which senders are signing and which are not.
DMARC is often published in monitoring mode with a policy of `p=none`. That setting lets you collect reports without asking recipients to quarantine or reject failing mail. It is a sensible starting point, particularly for a domain with several sending tools. But it is not the same as enforcement. Moving to `p=quarantine` or `p=reject` can reduce spoofing, but only after you confirm that legitimate senders align correctly. Otherwise, your own messages may be affected.
This is why an audit is not a one-time box to check. Your setup changes when you replace an email provider, add appointment software, move your website, launch a newsletter, or give a vendor permission to send customer notices. Each change can create a new authentication dependency.
The business problems an audit can uncover
Authentication failures are not always obvious to the sender. Your employee may see a message leave the Outbox while the recipient’s server sees an unverified or suspicious message. An audit helps connect those two views.
Common findings include:
- A business application sends from your domain but is missing from SPF.
- DKIM signatures are absent, broken, or published under the wrong selector.
- DMARC exists but does not align with the visible From domain.
- Multiple SPF records are published, even though a domain can have only one valid SPF record.
- An old mail vendor still has permission to send as your business.
- MX, reverse DNS, or transport settings make your mail infrastructure look incomplete or inconsistent.
- Your domain or sending address appears on a blocklist, which can affect how some recipients handle mail.
The impact varies. A law office may need confidence that a client receives a deadline-related message. A medical office may depend on appointment and operational notices arriving consistently. A real estate team may lose momentum when time-sensitive follow-up is delayed. For every business, the immediate goal is the same: make it easier for recipient systems to recognize legitimate mail and harder for criminals to impersonate your domain.
How to run an audit without guessing
Start by documenting every system that sends email using your domain. Do not limit the list to employee inboxes. Include marketing platforms, website forms, billing tools, scheduling systems, customer portals, scanners, and any outside provider that sends notices as your business.
Then review the DNS records for SPF, DKIM, and DMARC. Confirm that there is one SPF record and that it includes only active, authorized senders. Check that each sending platform has current DKIM signing enabled and that its required DNS key is published. For DMARC, identify the policy, reporting address, and whether the domains used by your senders align with the From address customers see.
Next, send test messages from each system to several major mailbox providers and inspect the authentication results in the message headers. Headers are the technical delivery details attached to a message. You are looking for SPF, DKIM, and DMARC pass or fail results, plus the domains that were evaluated. This step catches a frequent problem: the configuration looks correct in a vendor dashboard but the actual message is sent from an unexpected domain.
Finally, check the surrounding infrastructure. Confirm that MX records point where you expect, outbound servers have valid reverse DNS, and no stale DNS entries remain from former providers. Review blocklist status as a separate signal. A blocklist listing does not automatically explain every delivery problem, but it deserves prompt investigation alongside authentication results.
Prioritize fixes in the right order
Fix problems that affect your active mail first. If your billing system or employee mail is failing authentication, correct that before spending time on optional branding features. Next, remove stale permissions and duplicate records. Old DNS entries create confusion for receiving systems and can leave your domain exposed to unauthorized use.
After your legitimate senders consistently pass and align, consider strengthening DMARC policy. Do this deliberately. Monitoring reports may reveal services that send rarely, such as an annual renewal notice or a device alert. A stricter policy is valuable only when you understand those sources and have accounted for them.
BIMI, MTA-STS, and TLS-RPT are worthwhile next steps for some organizations, but their value depends on your mail environment. BIMI is most relevant when brand presentation in supported inboxes is a priority. MTA-STS and TLS-RPT are more relevant when you want greater control and visibility over encrypted mail transport. The core authentication records come first.
Run MailArrive’s free email health check and use the Report Card to grade your domain, see the issues in plain language, and identify the exact fix before changing DNS or mail server settings.