How to Check SPF DKIM and DMARC for Client Domains: An MSP Audit Guide

Why MSPs Need to Audit Client Email Authentication

If you manage email for multiple clients, each domain is a potential vector for spoofing, phishing, and deliverability problems. One client's misconfigured SPF record can result in bounces and blacklists that affect your reputation as a whole. Checking authentication records regularly is not optional for a serious MSP -- it is the baseline.

The challenge is that most clients do not know what SPF, DKIM, or DMARC are. They rely on you to catch problems before they cause damage. That means you need a repeatable, scalable process for auditing multiple domains, not a one-off investigation when something breaks.

This guide covers the full audit workflow: how to check each record type manually, how to run checks across many domains efficiently, what problems to flag, and how to communicate findings to non-technical clients.

Understanding SPF DKIM and DMARC in a Client Audit Context

Email authentication has three main layers. Each one prevents a different type of abuse.

SPF (Sender Policy Framework) says which mail servers are allowed to send email for a domain. It is a DNS TXT record. If a server is not listed and it tries to send mail "from" your client's domain, that is an SPF failure. SPF does not say whether the email is legitimate -- only whether the sending server is permitted.

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to emails sent from your client's domain. Receiving servers can verify the signature using a public key published in DNS. If the signature does not verify, the email was altered in transit or sent from an unauthorized server. DKIM is the only layer that proves an email was not tampered with after leaving your client's mail server.

DMARC (Domain-based Message Authentication, Reporting, and Conformance) ties SPF and DKIM together and tells receiving servers what to do when authentication fails. It also includes a reporting mechanism (rua and ruf) so you can see who is trying to send email on behalf of your client's domain and whether authentication is passing or failing.

The three records work together. SPF and DKIM each check one aspect of email legitimacy. DMARC enforces alignment between them and gives you visibility into what is happening.

How to Check SPF for Client Domains

To check a domain's SPF record, query its DNS TXT records.

dig txt example.com +short

Look for a record that starts with v=spf1. That is the SPF record.

Common mechanisms in an SPF record:

• +all -- permits all mail (not a real policy)
• -all -- hardfail, rejects mail from unauthorized servers
• ~all -- softfail, marks unauthorized mail but accepts it
• include:thirdparty.com -- authorizes third-party servers
• mx -- authorizes the domain's MX servers

What to flag when auditing SPF:

The most common SPF problems on client domains are using ~all or +all instead of -all. Softfail is not a real enforcement policy -- it tells receiving servers to accept mail from unauthorized servers and mark it as suspicious. Sophisticated spoofers can work around that.

Another common problem is the 10-lookup limit. Each include: directive counts as a DNS lookup. SPF evaluation stops when the count exceeds 10, and all subsequent lookups fail silently. If a client's SPF record has long include chains, verify the total lookup count stays under 10. You can check this with online SPF analyzers or by counting manually.

A third issue is SPF records that are missing entirely. Some clients rely only on DKIM. Without SPF, there is no baseline authentication for servers not covered by DKIM.

Run this check per client domain:

dig txt clientdomain.com +short | grep -i spf

If the output is empty, the domain has no SPF record -- a finding to flag.

How to Check DKIM for Client Domains

DKIM is harder to check than SPF because DKIM signatures use selectors, and a domain can have multiple selectors. There is no single DNS record that lists all active DKIM keys.

To check for DKIM, you need to know the selector. Common default selectors include selector1 and google. The practical approach for an MSP audit is:

1. Ask the client which email service they use and what DKIM selector they publish 2. Look up the selector DNS record

dig txt google._domainkey.clientdomain.com +short

If the output contains v=DKIM1, the domain has DKIM configured.

If the domain uses Google Workspace, the selector is typically google. For Microsoft 365, the selector is listed in the Exchange admin center under Mail Flow > DKIM. For other providers, check their documentation.

What to flag when auditing DKIM:

The most common DKIM problem is that it was set up once and then forgotten. If a client changed email providers but kept the old DKIM selector, the new provider's mail will not be DKIM-signed. Run a test email through a gateway that logs DKIM results to confirm signatures are valid.

Another issue is domains with no DKIM record at all. Many smaller clients rely entirely on SPF. Without DKIM, there is no cryptographic proof that their emails were not altered in transit.

DKIM failures also indicate problems. If DMARC reports show DKIM failing for legitimate email, the selector may be misconfigured or the signing domain may not align with the From address.

How to Check DMARC for Client Domains

To check DMARC, query the _dmarc subdomain:

dig txt _dmarc.clientdomain.com +short

A DMARC record starts with v=DMARC1. The key tag is p= (policy), which has three values:

• p=none -- monitoring mode. The domain is collecting reports but not enforcing anything.
• p=quarantine -- the domain instructs receivers to treat failed mail as suspicious.
• p=reject -- the domain instructs receivers to reject failed mail outright.

What to flag when auditing DMARC:

p=none with no rua or ruf reporting is a red flag. The client has no visibility into authentication failures and no enforcement. It is the equivalent of a fire alarm with no smoke detector -- technically present, not doing anything useful.

p=none with an rua report address means the client is trying to monitor. That is a reasonable starting point, but it should eventually move toward enforcement.

p=quarantine or p=reject without a functioning rua address means the client cannot see the reports. They are enforcing policy but blind to what is happening.

rua (aggregate reports) and ruf (forensic reports) specify where DMARC reports should be sent. If those tags are missing, no reports are being collected. If they point to an address at the same domain, many receivers will silently discard the reports because they cannot verify the address is legitimate.

Run this check per client domain:

dig txt _dmarc.clientdomain.com +short

If the output is empty, the domain has no DMARC record -- the highest-priority gap to fix.

Running Email Authentication Audits Across Multiple Clients

Checking one domain manually with dig is fine for a handful of clients. It does not scale to 20, 50, or 100 domains. For multi-client audits you need a repeatable process.

The spreadsheet approach works for small portfolios. Create a sheet with one row per client domain and columns for SPF status, SPF policy, DKIM status, DKIM selector, DMARC status, DMARC policy, and reporting. Fill in the results manually or with scripted dig queries. Update it quarterly.

The tool-based approach works better for ongoing monitoring. Once you have more than a few client domains, manual audits stop happening consistently. Tools that continuously monitor DMARC aggregate reports and alert on changes are more reliable than quarterly spreadsheet reviews.

The minimum viable audit for any MSP client portfolio:

• Check SPF, DKIM, and DMARC records for every domain once per quarter
• Review DMARC aggregate (rua) reports monthly
• Flag any domain where authentication failures affect legitimate email
• Remediate misconfigured records before they cause deliverability problems

A note on MXToolbox: MXToolbox is useful for checking a single domain quickly. It does not track changes over time and does not give you aggregate visibility across your entire client portfolio. For ongoing MSP workflows, it is a spot-check tool, not a monitoring platform.

Warning Signs That a Client Domain Needs Remediation

These findings should trigger a client conversation, not just a note in your audit log:

SPF: ~all or +all with no plans to move to -all Softfail policies are not enforcement. Any server can send mail claiming to be from that domain and receivers will accept it. This is a spoofing risk.

SPF: more than 10 lookups The lookup count is cumulative across all includes. When it exceeds 10, SPF evaluation stops and all bets are off. This is a silent failure mode.

DKIM: not configured or selector changed without updating DNS If the client changed email providers and DKIM stopped working, legitimate email will fail authentication.

DMARC: p=none with no rua reporting The client has no visibility. If someone starts spoofing their domain, they will not know.

DMARC: p=none with rua pointing to the same domain Most major receivers (Google, Microsoft) will not send DMARC reports to an address at the same domain being reported on. The reports will not arrive.

DMARC: rua or ruf address is a free email address Free email providers can reject or discard DMARC forensic reports (ruf). Aggregate reports (rua) usually work but free addresses create deliverability risk for ongoing reports.

DMARC: record present but malformed Missing colons, incorrect tags, or syntax errors cause receivers to ignore the record entirely. Validate DMARC records with a checker before deploying.

How to Communicate Email Authentication Findings to Clients

Clients do not care about SPF mechanisms or DKIM selectors. They care about whether their email gets delivered and whether someone can impersonate them. Frame your findings accordingly.

The no-jargon summary template:

• "Your domain has no protection against email spoofing. This means someone can send emails that look like they come from your company. We recommend setting up DMARC."
• "Your domain is collecting reports but not enforcing any policy. You can see who is trying to send email on your behalf, but fake emails will still get through. We recommend moving to quarantine mode."
• "Your domain has a strong policy but we are not receiving the reports. Without reports, we cannot tell if legitimate email is failing or if someone is trying to spoof your domain. We recommend fixing the report destination."

Always offer a specific next step. "Set up DMARC" is not actionable. "I will add a DMARC record to your DNS that collects reports for 30 days, then we review the data and decide on enforcement" is actionable.

If you find an urgent problem -- active spoofing, a domain being impersonated in DMARC reports -- communicate it within 24 hours regardless of your normal reporting cycle.

Multi-Client DMARC Monitoring with DMARCFlow

Manual audits catch configuration problems but miss what is actually happening in traffic. DMARC aggregate reports tell you which IPs are sending email for a domain, whether authentication is passing, and whether spoofing attempts are occurring.

For MSPs managing multiple client domains, DMARCFlow provides centralized aggregate monitoring across your entire portfolio. Each client domain gets its own reporting view, and you receive alerts when authentication patterns change or when new sending sources appear -- without having to log into each client's DNS or mail systems separately. This is the core difference between a quarterly audit and ongoing monitoring: you catch problems when they start, not three months later.

The practical workflow for MSP client onboarding: set up DMARC monitoring for all client domains during onboarding. Review the initial 30-day aggregate reports to establish a baseline of normal traffic. Move clients from p=none to p=quarantine once you have confirmed legitimate sending sources are passing authentication. Move to p=reject once you have verified the full sending infrastructure is covered.

This approach avoids the common mistake of enforcing DMARC before understanding what the client's normal traffic looks like. A rejected mail flood because you set p=reject without reviewing reports first is a bad client experience. A phased approach with DMARCFlow monitoring is how you avoid it.

For spot checks during quarterly audits, dig commands remain the fastest way to verify a single domain's current record state. For ongoing multi-client visibility, DMARCFlow is what makes the monitoring sustainable at scale.