Bulk DMARC Check: How Agencies Can Audit Client Domains Faster

A bulk DMARC check helps an agency review many client domains at once instead of opening DNS tools one domain at a time. The practical goal is simple: find which domains have no DMARC record, which are still on p=none, which use quarantine or reject, and which have reporting or alignment details that need a closer look.

For agencies, this is an operations problem as much as a DNS problem. A single client domain can be checked manually. Twenty client domains across onboarding, support tickets, and quarterly reviews become slow and inconsistent. A bulk view gives the team a repeatable way to identify email-authentication risk before a client asks why invoices, password resets, or campaign emails are not behaving as expected.

CertPilot's Inbox Pulse is built for this kind of first-pass agency audit. It checks DMARC, SPF, DKIM, MTA-STS, TLS-RPT, and BIMI configuration risk across multiple domains. It does not replace a full DMARC RUA monitoring platform when you need continuous report aggregation, but it is useful when you need a fast configuration snapshot.

Need the broader website risk view too? Run a free 10-domain agency audit for SSL, DNS, and domain expiry checks.

Bulk DMARC check: what agencies should look for

A bulk DMARC check should answer five questions quickly:

| Question | Why it matters for agencies | |---|---| | Does the domain publish DMARC? | Missing DMARC leaves the domain without a published policy for unauthenticated mail. | | What is the policy? | p=none, quarantine, and reject mean very different operational things. | | Are report destinations present? | rua and ruf show whether the domain asks receivers to send reports. | | Is there a subdomain policy? | sp= can protect or expose subdomains differently from the root domain. | | Can SPF or DKIM align? | DMARC depends on aligned authentication, not just records existing somewhere. |

The output does not need to be complicated. For an agency operations queue, the best first result is a sorted list: missing records first, weak policies next, then domains that look configured but deserve verification.

Why checking one domain at a time breaks down

Manual DNS checks are fine when the task is narrow. They are poor when the agency needs consistency across a portfolio.

Common agency situations include:

• New client onboarding with 10 to 40 inherited domains.
• A client moving email sending from one platform to another.
• Quarterly client risk reviews.
• A deliverability complaint where the client is not sure which domain sends mail.
• Website launches where DNS changes may affect email records.

In each case, the issue is not only whether one domain has a DMARC record. The issue is whether the agency can see patterns across the client base. If five clients use the same sender and all have incomplete SPF or DKIM setup, that is a process problem. If newly onboarded domains often have p=none and no reporting destination, that is an onboarding checklist problem.

Use Inbox Pulse when you need this bulk view. Use the tools page when you want to choose between email authentication checks, SSL renewal readiness, Watchtower SSL calendars, or broader audits.

Understand DMARC policy values

DMARC policy is published in a TXT record at _dmarc.example.com. The policy tag is usually the first thing an agency should read after confirming the record exists.

p=none

p=none means the domain is asking receivers to monitor DMARC results but not to apply a blocking policy based on DMARC alone.

This can be valid during rollout. It is often used while the organization learns which services send mail on behalf of the domain. For agencies, it should not be treated as an automatic failure, but it should be flagged as a review item.

Useful questions:

• Is this intentionally in monitoring mode?
• Does the client receive aggregate reports somewhere?
• Are SPF and DKIM aligned for legitimate senders?
• Is there a plan to move to a stronger policy once senders are known?

p=quarantine

p=quarantine asks receivers to treat failing mail suspiciously, often by placing it in spam or a similar folder.

This is stronger than p=none, but it still requires care. If legitimate senders are not aligned, mail can be affected. For an agency, quarantine is a sign that the domain may be further along, but it is not proof that all sending paths are correct.

p=reject

p=reject asks receivers to reject mail that fails DMARC.

This is usually the strongest published policy. It can reduce abuse of the domain, but only when legitimate sending sources are configured correctly. Agencies should avoid pushing a client straight to reject without verifying mail flows, especially when the client uses multiple platforms for marketing, invoices, CRM, helpdesk, or ecommerce messages.

rua and ruf: reporting signals

DMARC records can include reporting destinations:

• rua asks for aggregate reports.
• ruf asks for forensic or failure reports, where supported.

For a bulk configuration audit, the important question is whether reporting is present and whether it points somewhere the client or their provider actually monitors.

Do not assume a rua address means someone reads the reports. It may point to an old mailbox, a former vendor, or a platform the client no longer uses. Inbox Pulse can help flag that reporting exists, but continuous report analysis belongs in a dedicated DMARC monitoring platform.

That distinction matters. CertPilot helps agencies find configuration risk. It does not claim to replace platforms built to ingest, normalize, and analyze DMARC RUA feeds over time.

Subdomain policy: the quiet gap

DMARC can include an sp= tag for subdomains. If sp= is not present, subdomains inherit the root policy. That may be fine, but agencies should still know what is happening.

Subdomains are common in agency-managed environments:

• mail.client.com
• news.client.com
• shop.client.com
• crm.client.com
• staging.client.com

Some of these send mail. Some should never send mail. Some are controlled by vendors. A subdomain policy helps clarify how receivers should handle mail from those subdomains.

When a client uses subdomains heavily, include DMARC subdomain handling in the review. A domain with p=reject at the root but messy vendor subdomains may still need operational cleanup.

Alignment is the point

DMARC passes when either SPF or DKIM passes and aligns with the visible From domain. This is where many agency audits find confusion.

SPF can exist and still not align. DKIM can exist and still not align. A sender can pass authentication for a vendor domain while failing alignment for the client's domain.

For agency workflows, use this rule:

| Record exists? | Alignment likely? | What to do | |---|---|---| | DMARC missing | No published DMARC policy | Add DMARC planning to the client backlog. | | SPF present only | Maybe | Verify which systems send mail and whether SPF aligns. | | DKIM present only | Maybe | Verify selector configuration for each sender. | | SPF and DKIM present | Better | Check whether legitimate senders align with the client's From domain. | | Strong DMARC policy | Depends | Confirm legitimate sending paths before assuming the domain is healthy. |

This is why a bulk DMARC check should sit beside SPF and DKIM checks, not apart from them.

Agency workflow for a bulk DMARC audit

Use this simple process when auditing a client portfolio.

1. Normalize the domain list

Start with root domains, not random URLs. Strip protocols, paths, ports, and duplicates. If the client gives you a spreadsheet with website URLs, clean it before checking.

Inbox Pulse accepts pasted domains and normalizes common URL noise for the audit flow.

2. Run the bulk check

Run the domain list through Inbox Pulse. Capture the domains with missing DMARC, weak policy, missing SPF, missing DKIM signals, or optional records that may matter for the client.

3. Sort by operational risk

A practical order is:

1. Domains used for active email sending.
2. Domains with no DMARC.
3. Domains with p=none and no clear rollout plan.
4. Domains with many third-party senders.
5. Domains with MTA-STS, TLS-RPT, or BIMI goals.

4. Validate with the client

Ask which platforms send email:

• Google Workspace or Microsoft 365
• CRM
• ecommerce
• helpdesk
• invoicing
• marketing automation
• transactional email
• hosting platform mail

This prevents the agency from treating DNS as the whole truth. DNS shows configuration, but the client knows which services are supposed to send.

5. Track fixes like operations work

Do not bury findings in a chat thread. Create tickets with domain, issue, suggested action, owner, and follow-up date.

For broader web infrastructure checks, pair the email-authentication review with a free 10-domain agency audit. For SSL-specific calendar monitoring, use Watchtower. For renewal readiness, use 47-Day Renewal Pre-Flight.

Common bulk DMARC findings

Agencies often find the same patterns:

• The main website domain has DMARC, but parked domains do not.
• DMARC is set to p=none years after rollout.
• rua points to a mailbox nobody owns.
• SPF includes many old vendors.
• DKIM is configured for one platform but not another.
• Marketing sends from a subdomain with unclear policy.
• The client believes Microsoft or Google "handles DMARC" automatically.

None of these automatically proves mail is failing. They are review signals. The value of a bulk audit is that the agency can find them before a client asks during a launch, campaign, or incident.

What Inbox Pulse is and is not

Inbox Pulse is a bulk email-authentication configuration auditor. It helps agencies check visible DNS-based signals for DMARC, SPF, DKIM-related setup, MTA-STS, TLS-RPT, and BIMI.

It is useful for:

• onboarding reviews
• quarterly checks
• pre-campaign checks
• client deliverability complaints
• finding domains that need deeper email work

It is not:

• a guarantee of inbox placement
• a legal or compliance guarantee
• a replacement for full DMARC RUA monitoring
• an enterprise email security platform
• a substitute for testing real mail flows

That boundary keeps the workflow honest. Use Inbox Pulse to find configuration risk quickly. Use dedicated DMARC monitoring if the client needs continuous receiver-report analysis.

Related resources

• Inbox Pulse email authentication checker
• DMARC, SPF, and DKIM explained for agencies
• Google bulk sender DMARC agency checklist
• SPF 10 lookup limit agency debugging guide
• How CertPilot checks domains

Frequently Asked Questions

What is a bulk DMARC check?

A bulk DMARC check reviews DMARC records across multiple domains at once. For agencies, it is faster than checking each client domain manually and helps prioritize missing records, weak policies, reporting gaps, and alignment questions.

Is p=none bad?

Not always. p=none can be appropriate during rollout, but it should have a reason and a next step. If a client has been on p=none for years with no reporting review, it deserves attention.

Does DMARC require SPF and DKIM?

DMARC needs either SPF or DKIM to pass and align with the visible From domain. Having SPF and DKIM records is helpful, but alignment is what makes them useful for DMARC.

Does Inbox Pulse monitor DMARC reports?

No. Inbox Pulse audits public configuration signals. If a client needs continuous DMARC RUA report ingestion and analysis, use a dedicated DMARC monitoring platform.

Where should an agency start?

Start with the domains that actively send client email. Run them through Inbox Pulse, then run a broader agency audit for SSL, DNS, and domain expiry risk.