Email Authentication for Agencies: SPF, DKIM, DMARC, MTA-STS, TLS-RPT, and BIMI

Email authentication for agencies means reviewing public DNS records that help receivers understand whether messages using a domain are authorized, signed, aligned, or policy-controlled. It includes SPF, DKIM, DMARC, MTA-STS, TLS-RPT, and BIMI, but these signals do not guarantee deliverability. They are configuration signals agencies should understand before client onboarding, campaign launches, platform migrations, or monthly reporting.

Use Inbox Pulse as a public DNS/email-authentication configuration auditor for one or more client domains. Use the free 10-domain agency audit when email authentication should be reviewed alongside SSL, DNS, CAA, and domain expiry. CertPilot explains how it uses public DNS and email-authentication data in the CertPilot methodology.

Quick answer: email authentication for agencies

Email authentication gives agencies a way to review whether client domains publish the public DNS records receivers expect. The main records and protocols are:

• SPF for allowed sending sources.
• DKIM for message signing.
• DMARC for alignment and policy.
• MTA-STS for SMTP TLS policy publication.
• TLS-RPT for receiving reports about TLS delivery issues.
• BIMI for brand indicator configuration where supported.
• MX records for mail routing context.

The agency job is to check what exists, find obvious configuration issues, identify the owner, and decide what needs platform or mail-admin review.

Who this guide is for

This guide is for agencies, MSPs, web teams, and operations leads who inherit client email-domain records during website work, DNS changes, marketing-platform setup, or care-plan reporting.

You do not need to become an enterprise DMARC analyst to use this workflow. You do need to know when a DNS record is missing, duplicated, stale, or misaligned with the client's real sending platforms.

Why agencies inherit messy email DNS

Email DNS gets messy because clients add vendors over time:

• Google Workspace or Microsoft 365 for inboxes.
• Mailchimp, HubSpot, Klaviyo, ConvertKit, or CRM tools for campaigns.
• Help desks and ticketing platforms.
• Billing systems.
• Website forms and SMTP services.
• Old vendors that were never removed.

Each tool may ask for SPF, DKIM, tracking, verification, or reporting records. Over time, nobody remembers which record belongs to which system. The TXT record monitoring guide explains why this becomes operational debt.

The email authentication operating model

| Record/protocol | What it answers | DNS location | Common mistake | |---|---|---|---| | SPF | Is this sender allowed for the domain? | TXT at root or sending domain | Multiple SPF records or too many includes | | DKIM | Is the message signed with a valid key? | Selector under _domainkey | Assuming one selector covers every vendor | | DMARC | Do SPF or DKIM align with the visible From domain, and what policy applies? | TXT at _dmarc | Jumping policy before sender review | | MTA-STS | Is an SMTP TLS policy published? | TXT plus HTTPS policy file | DNS record and policy file do not match | | TLS-RPT | Where should TLS reports be sent? | TXT at _smtp._tls | Expecting it to enforce delivery behavior | | BIMI | Is a BIMI assertion published? | TXT at selector under _bimi | Treating BIMI as the first email-auth step | | MX | Where inbound mail routes | MX at domain | Ignoring mail routing context |

The operating model is: inventory records, map vendors, identify conflicts, confirm legitimate senders, and document client-facing next steps.

SPF

SPF is often where agencies first see problems. A domain should publish one SPF TXT record. That record can include multiple vendor domains, but those includes count toward the SPF 10 DNS lookup limit.

Use the multiple SPF records guide when a domain publishes duplicate v=spf1 records. Use the SPF 10 lookup limit guide when a single record contains many includes or nested vendor lookups.

The main agency caution is not to delete a vendor include just because the record looks long. First identify the sender, owner, and current platform use.

DKIM

DKIM uses selector-specific DNS records. A client can have multiple DKIM selectors because each sending platform may sign with its own key. That is normal when the records are current and documented.

Use the DKIM selectors cheat sheet to explain selector behavior to non-specialists. Use the DKIM record not found guide when a platform reports that a selector is missing or misconfigured.

Agency review should ask:

• Which platforms send as the client domain?
• Which selectors belong to each platform?
• Are old selectors still needed?
• Does the visible From domain align through SPF or DKIM for DMARC?

DMARC

DMARC ties SPF and DKIM to the visible From domain and publishes a policy. That policy can be p=none, p=quarantine, or p=reject.

The SPF, DKIM, and DMARC explainer is the best starting point for teams that need the simple difference. The DMARC policy guide explains why p=none is often a monitoring phase and why agencies should not move directly to stricter policy without reviewing legitimate senders and alignment.

DMARC is powerful, but policy changes can affect real senders. Treat policy progression as a mail-admin decision, not a generic SEO checklist item.

MTA-STS

MTA-STS publishes a policy that receiving mail systems can use when delivering to a domain over SMTP TLS. It involves a DNS TXT record and an HTTPS policy file.

Use the MTA-STS record check guide when reviewing the DNS record, policy file, mode, max_age, and MX patterns. Do not describe MTA-STS as encrypting all email by itself. It is a policy signal that depends on support and behavior across sending and receiving systems.

TLS-RPT

TLS-RPT tells supporting systems where to send reports about SMTP TLS delivery issues. It is useful context, but it does not enforce anything by itself.

Use the TLS-RPT record explained guide when a client asks why the record exists or what the reporting address means.

BIMI

BIMI is usually not the first email-authentication fix. It depends on the broader foundation: SPF, DKIM, DMARC policy posture, and brand requirements. Agencies should treat BIMI as a later-stage brand indicator configuration rather than the core deliverability lever.

Inbox Pulse can help check visible BIMI-related DNS where supported, but deeper validation may still require mail-platform and brand-asset review.

MX records and routing context

MX records show where inbound mail routes. They are not the same as SPF or DKIM, but they provide important context. A domain using Google Workspace has different operational assumptions than one using Microsoft 365, a security gateway, or a legacy host.

Use the MX record monitoring guide when DNS changes could affect mail routing. For agency-wide DNS operations, pair email-auth checks with DNS monitoring for agencies.

Common failure patterns

| Issue | What it may indicate | Agency action | Tool/check | |---|---|---|---| | Multiple SPF records | Duplicate SPF setup | Consolidate carefully after sender review | Inbox Pulse | | SPF lookup limit risk | Too many includes or nested lookups | Remove stale vendors or redesign record | Inbox Pulse | | Missing DKIM selector | Vendor setup incomplete | Confirm selector and platform docs | Inbox Pulse | | DMARC p=none with no plan | Monitoring mode with no progression owner | Assign mail-admin review | Inbox Pulse | | MTA-STS DNS without policy file | Partial setup | Review DNS and HTTPS policy | Inbox Pulse | | TLS-RPT missing | No TLS report destination | Decide if reporting is needed | Inbox Pulse |

Agency workflow for new client onboarding

1. List client domains used for email.
2. Identify inbound mail platform from MX records.
3. Identify known senders: inbox provider, CRM, marketing, billing, support, forms.
4. Check SPF for duplicates, stale includes, and lookup-limit risk.
5. Check DKIM selectors for active sending platforms.
6. Check DMARC record, reporting addresses, and policy.
7. Check MTA-STS and TLS-RPT if the client has advanced email-domain requirements.
8. Document who owns email changes.
9. Separate quick DNS cleanup from deeper deliverability review.
10. Add the result to a client-ready proof report.

Bulk email-authentication checks across client domains

One domain review is useful during onboarding. Agencies also need portfolio-level checks because many clients share the same failure patterns. The bulk DMARC check guide explains how agencies can review multiple domains without opening each DNS zone manually.

Bulk review is best for:

• Finding missing DMARC.
• Finding duplicate SPF records.
• Spotting common SPF include problems.
• Prioritizing client outreach.
• Creating monthly report items.

It is not the same as an enterprise DMARC aggregate-reporting program.

When to use Inbox Pulse

Use Inbox Pulse when you need a fast public DNS/email-authentication configuration audit. It is especially useful for:

• New client onboarding.
• Sender platform migration.
• SPF cleanup.
• DKIM selector review.
• DMARC policy review.
• MTA-STS or TLS-RPT visibility.
• Agency portfolio checks.

Pair it with the free agency audit when the same client needs SSL, DNS, CAA, and domain expiry reviewed.

What Inbox Pulse can and cannot do

Inbox Pulse checks visible public DNS and related email-authentication records where supported. It helps agencies find configuration risks faster.

It does not read inboxes, send test emails, guarantee deliverability, guarantee inbox placement, replace Google Postmaster Tools or Microsoft SNDS, or replace an enterprise DMARC aggregation platform. For deeper deliverability work, combine public DNS checks with mail-platform tools, message-header review, aggregate reports where available, and manual review.

Client email-authentication audit checklist

• Identify all sending domains.
• Identify MX provider.
• List known mail, CRM, marketing, support, and form vendors.
• Check for one SPF record per domain.
• Review SPF includes and lookup-limit risk.
• Check DKIM selectors for known platforms.
• Check DMARC record, policy, alignment context, and reporting addresses.
• Check MTA-STS DNS and policy file where relevant.
• Check TLS-RPT destination where relevant.
• Check BIMI only after the foundation is understood.
• Assign a record owner for each change.
• Document limitations and next steps.

One-domain check vs bulk agency review vs enterprise DMARC platform

| Tool/check | Best for | Limitation | Next step | |---|---|---|---| | One-domain Inbox Pulse check | Onboarding or troubleshooting one client domain | Does not show long-term aggregate traffic | Review sender list | | Bulk agency review | Finding common issues across client domains | Still public DNS focused | Prioritize client fixes | | Enterprise DMARC platform | Aggregate reports, enforcement projects, advanced analysis | More process and client commitment | Use for mature mail programs | | Manual mail-platform review | Confirming sender setup | Requires account access | Coordinate with client or IT |

How CertPilot fits

CertPilot uses public DNS and email-authentication data to help agencies spot configuration risks and produce client-ready proof reports. It does not replace the systems that send email, host mail, route messages, or provide deliverability analytics.

Use CertPilot to create the operational layer:

• Inbox Pulse for focused email-authentication checks.
• Audit for broader domain portfolio proof.
• Methodology for explaining public data sources and limits.
• Supporting resource guides for client education and internal SOPs.

Tool CTA: run an email-authentication check

Run Inbox Pulse when a client domain needs SPF, DKIM, DMARC, MTA-STS, TLS-RPT, BIMI, or MX context reviewed from public DNS. Run the free 10-domain agency audit when email authentication should be part of a broader client-domain proof report.

Cluster map: supporting email-authentication resources

• SPF, DKIM, and DMARC explained for agencies
• Bulk DMARC checks for client domains
• SPF 10 lookup limit for agencies
• Multiple SPF records cleanup
• DKIM selectors cheat sheet
• DKIM record not found
• DMARC p=none, quarantine, and reject
• MTA-STS record check
• TLS-RPT record explained
• Google bulk sender DMARC guide
• MX record monitoring for agencies
• TXT record monitoring for agencies

Related Resources

• DNS monitoring for agencies
• TXT record monitoring for agencies
• SPF multiple includes and lookup limit
• DMARC policy guide
• Agency client reporting guide

Frequently Asked Questions

What is email authentication for agencies?

Email authentication for agencies is the process of reviewing client-domain DNS records such as SPF, DKIM, DMARC, MTA-STS, TLS-RPT, BIMI, and MX so the agency understands how the domain is configured for mail. It is especially useful during onboarding, sender migration, DNS cleanup, and monthly reporting. It is a configuration review, not a promise of inbox placement.

Do SPF, DKIM, and DMARC guarantee deliverability?

No. SPF, DKIM, and DMARC are important configuration signals, but they do not guarantee deliverability or inbox placement. Receivers evaluate many other factors, including sender reputation, content, engagement, list quality, complaint behavior, and platform-specific signals. Agencies should treat these records as the foundation for domain authentication, then use mail-platform tools and manual review for deeper deliverability work.

What should agencies check first on a new client domain?

Start with MX, SPF, DKIM, and DMARC. MX shows the mail-routing context. SPF shows authorized sending sources. DKIM shows whether known platforms have signing records. DMARC shows alignment policy and reporting. After that, review MTA-STS, TLS-RPT, BIMI, and vendor-specific TXT records if they are relevant to the client.

Is Inbox Pulse a DMARC monitoring platform?

No. Inbox Pulse is a public DNS/email-authentication configuration auditor. It checks visible records and helps agencies find configuration risks faster. It does not replace enterprise DMARC aggregate-reporting platforms, Google Postmaster Tools, Microsoft SNDS, mail-platform dashboards, or manual message-header review.

Should every domain move to DMARC p=reject?

Not automatically. A stricter DMARC policy can be appropriate after legitimate senders are identified and SPF or DKIM alignment issues are addressed. Agencies should avoid jumping directly to p=reject without reviewing client senders, campaign tools, support systems, billing platforms, and reporting data where available.

What is the difference between MTA-STS and TLS-RPT?

MTA-STS publishes a policy related to SMTP TLS delivery behavior for supporting systems. TLS-RPT publishes a reporting destination for TLS-related delivery reports. TLS-RPT does not enforce delivery behavior by itself. Agencies should review both as configuration signals and avoid presenting either as a standalone deliverability guarantee.

How often should agencies review email authentication?

Review email authentication during onboarding, DNS migrations, mail-platform changes, campaign-platform setup, sender-domain changes, and recurring care-plan reviews. Monthly portfolio checks are useful for spotting missing DMARC, duplicate SPF records, stale vendor includes, and changes that deserve client or IT follow-up.