Email DNS Records Checklist for Agencies: SPF, DKIM, DMARC, MX, MTA-STS, TLS-RPT, and BIMI

An email DNS records checklist helps agencies review the public records that affect mail routing, authentication, reporting, and client-domain configuration: MX, SPF, DKIM, DMARC, MTA-STS, TLS-RPT, BIMI, and related TXT verification records. These records do not guarantee deliverability or inbox placement, but they are important configuration signals for client onboarding, migrations, and maintenance.

Use Inbox Pulse for public email-authentication checks across client domains. Use the free 10-domain agency audit when email DNS should be reviewed alongside SSL, domain expiry, CAA, and broader DNS health. Review the CertPilot methodology when documenting that these checks use public DNS records and do not require DNS provider access or inbox access.

Quick answer: email DNS records checklist

The practical checklist is:

• MX records for inbound mail routing.
• SPF TXT records for authorized sending sources.
• DKIM selector records for message signing.
• DMARC records for alignment, policy, and reporting.
• MTA-STS records and policy files for SMTP TLS policy.
• TLS-RPT records for TLS report destinations.
• BIMI records for brand-indicator configuration.
• TXT verification records for platform ownership and vendor setup.

The agency goal is to identify what exists, what is missing, what is stale, what belongs to which platform, and what needs manual review before a DNS change.

When agencies should use this checklist

Use this checklist during:

• New-client onboarding.
• Website launches that involve DNS changes.
• Google Workspace or Microsoft 365 migrations.
• CRM, ecommerce, helpdesk, or marketing-platform setup.
• Domain registrar or DNS provider migrations.
• Monthly care-plan reporting.
• Investigation after a client says mail "is not working."
• Cleanup after vendor churn.

Do not wait until a campaign launch to review email DNS. The safest time to find missing records is before a client depends on them.

Email DNS records overview

| Record | DNS location | What it controls | Agency review action | |---|---|---|---| | MX | Root domain | Where inbound mail is routed | Confirm provider and priority values | | SPF | Root or sending subdomain TXT | Authorized sending sources | Confirm one valid v=spf1 record per sending domain | | DKIM | Selector under _domainkey | Message signing keys | Map selectors to active platforms | | DMARC | _dmarc TXT | Alignment policy and reporting | Confirm policy, rua, and sender alignment | | MTA-STS | _mta-sts TXT plus HTTPS policy file | SMTP TLS policy publication | Confirm DNS record and policy file match | | TLS-RPT | _smtp._tls TXT | TLS report destinations | Confirm reporting address ownership | | BIMI | Selector under _bimi | Brand indicator signal | Confirm prerequisites and avoid logo promises | | TXT verification | Provider-specific names | Ownership or service verification | Remove only after ownership is confirmed |

MX records

MX records control where inbound mail for the domain is routed. If a client uses Google Workspace, Microsoft 365, or another provider, the MX records should match that provider's instructions.

Agency checks:

• Are MX records present?
• Do they match the client's stated mailbox provider?
• Are old provider records still present?
• Are priorities sensible?
• Was DNS edited in the authoritative zone?

The MX record monitoring guide explains why MX changes deserve careful review.

SPF records

SPF records list allowed sending sources for a domain. A domain should not publish multiple SPF TXT records at the same DNS name.

Agency checks:

• Does the sending domain publish a v=spf1 TXT record?
• Is there exactly one SPF record at that location?
• Do includes match current vendors?
• Are old senders still authorized?
• Is the record near or over the SPF 10 lookup limit?

Use the SPF record not found guide when SPF is missing, the multiple SPF records guide when duplicates exist, and the SPF 10 lookup limit guide when the record is too complex.

DKIM selectors

DKIM records are selector-specific. A client can have several valid DKIM records because each sending platform may sign with a different selector.

Agency checks:

• Which selectors are documented by each platform?
• Are the selector records present?
• Are old selectors still needed?
• Does each important sender sign with an aligned domain?
• Are selectors CNAME-based or TXT-based?

Use the DKIM selectors cheat sheet for selector review and the DKIM record not found guide when a platform reports a missing selector.

DMARC record and policy

DMARC publishes alignment policy and reporting configuration at _dmarc.

Agency checks:

• Does the DMARC TXT record exist?
• Is the policy none, quarantine, or reject?
• Is the policy appropriate for current sender alignment?
• Is rua present and owned by a real process?
• Are subdomains intentionally handled?

Use the DMARC record not found guide, the DMARC policy guide, and the DMARC RUA/RUF explainer for deeper checks.

MTA-STS record and policy file

MTA-STS involves both DNS and an HTTPS-hosted policy file. The DNS TXT record alone is not the full setup.

Agency checks:

• Is _mta-sts.example.com published?
• Does the policy file exist over HTTPS?
• Does the policy file list the right MX patterns?
• Is the mode appropriate?
• Is max_age intentional?

Do not describe MTA-STS as encrypting all email by itself. It is a policy mechanism used by supporting systems. Use the MTA-STS record check guide for the full workflow.

TLS-RPT record

TLS-RPT tells supporting systems where to send reports about SMTP TLS delivery issues. It does not enforce TLS and does not fix delivery by itself.

Agency checks:

• Is _smtp._tls.example.com present?
• Does it publish v=TLSRPTv1?
• Who owns the reporting address?
• Is anyone reviewing reports?
• Does it align with the client's MTA-STS setup?

Use the TLS-RPT record explained guide when documenting this for clients.

BIMI record

BIMI is a brand-indicator signal, usually at default._bimi. It should come after the authentication foundation is understood.

Agency checks:

• Does a BIMI TXT record exist?
• Does it start with v=BIMI1?
• Does the logo URL resolve publicly?
• Does the client understand certificate and provider requirements?
• Has DMARC posture been reviewed?

Use the BIMI record check guide and avoid promising logo display.

TXT verification records

TXT verification records are added by platforms to prove domain ownership or activate services. They may belong to Google, Microsoft, HubSpot, Mailchimp, Facebook, Stripe, search consoles, analytics platforms, CRMs, or other tools.

Agency checks:

• Which platform owns each TXT verification record?
• Is the platform still active?
• Is the record required for ongoing service?
• Is the record duplicated or stale?
• Does removal risk breaking verification?

The TXT record monitoring guide is useful for managing this operational debt.

Common client-domain cleanup issues

Agencies commonly find:

• Old MX records from a previous mail provider.
• Multiple SPF records.
• SPF includes for vendors no longer used.
• Missing DKIM selectors after a platform migration.
• DMARC present but reporting to an abandoned mailbox.
• MTA-STS DNS present but policy file missing.
• TLS-RPT present with an unmanaged address.
• BIMI published before DMARC is ready.
• TXT verification records nobody can identify.

Do not remove records just because they look old. First identify ownership and risk.

New-client onboarding workflow

Use this workflow:

1. Run a public email DNS check.
2. Export or document current MX, SPF, DKIM, DMARC, MTA-STS, TLS-RPT, BIMI, and TXT records.
3. Ask the client for active mail and sending platforms.
4. Map each DNS record to an owner.
5. Mark records as current, stale, unknown, or risky.
6. Prioritize missing SPF, missing DMARC, duplicate SPF, and broken DKIM selectors.
7. Separate "quick DNS cleanup" from "deliverability investigation."
8. Document recommended changes before editing DNS.
9. Retest after DNS changes propagate.
10. Add recurring review to the client care plan.

This gives the client a visible QA process without overclaiming what DNS alone can prove.

Client email DNS records checklist

• [ ] Confirm authoritative nameservers.
• [ ] Confirm active mailbox provider.
• [ ] Check MX records.
• [ ] Check SPF presence and duplicate SPF risk.
• [ ] Check SPF 10 DNS lookup risk.
• [ ] Check DKIM selectors for active senders.
• [ ] Check DMARC record, policy, and reporting tags.
• [ ] Check MTA-STS DNS and HTTPS policy file.
• [ ] Check TLS-RPT reporting destination.
• [ ] Check BIMI record and prerequisites.
• [ ] Inventory TXT verification records.
• [ ] Map every record to a platform owner.
• [ ] Identify records that need client approval before removal.
• [ ] Record limitations and manual follow-up items.

What Inbox Pulse can check

Inbox Pulse can check public DNS/email-authentication configuration signals across client domains, including MX, SPF, DMARC, MTA-STS, TLS-RPT, BIMI, and related visible records where supported. It is useful for fast portfolio QA and client onboarding review.

It does not log in to DNS providers, change DNS records, read inboxes, send email tests, process DMARC aggregate reports, or guarantee deliverability. Treat it as a configuration auditor that helps agencies find issues faster.

What still needs manual review

Manual review is still needed for:

• Actual mail-platform settings.
• DKIM enablement inside each sender.
• DMARC aggregate-report analysis.
• Message-header review.
• Provider-specific deliverability dashboards.
• List quality, complaint rates, bounce rates, and sender reputation.
• Client approval before removing old records.
• Legal or brand requirements for BIMI.

DNS checks are the starting point, not the entire email operations program.

Related Resources

• Email authentication for agencies
• SPF record not found for agencies
• DMARC record not found for agencies
• MTA-STS record check
• TLS-RPT record explained

Frequently Asked Questions

What should an email DNS records checklist include?

An email DNS records checklist should include MX, SPF, DKIM, DMARC, MTA-STS, TLS-RPT, BIMI, and TXT verification records. Agencies should check what each record does, which platform owns it, whether it is still current, and what manual review is needed before changing DNS. The checklist should cover routing, authentication, policy, reporting, and cleanup.

Do email DNS records guarantee deliverability?

No. Email DNS records do not guarantee deliverability or inbox placement. They are public configuration signals that help mail systems evaluate routing, authentication, and policy. Deliverability also depends on sender reputation, engagement, complaints, bounce handling, content, list hygiene, mailbox-provider behavior, and platform-specific settings.

Should agencies check MX before SPF and DMARC?

Yes, MX is a good early check because it confirms inbound mail-routing context. SPF, DKIM, and DMARC focus on sending and authentication, but MX tells you where the domain receives mail. If MX does not match the client's stated provider, the rest of the review may be based on incomplete assumptions.

How often should client email DNS records be reviewed?

Review records during onboarding, before migrations, after mail-platform changes, before major campaigns, and during periodic care-plan checks. Monthly or quarterly review can be reasonable for agencies managing many client domains. The right cadence depends on how often clients change vendors and how critical email is to their operations.

Can Inbox Pulse change DNS records?

No. Inbox Pulse checks visible public DNS/email-authentication configuration signals. It does not manage DNS hosting, change records, or connect to DNS provider accounts. Agencies still need access to the client's authoritative DNS provider and should follow a documented approval process before making DNS changes.

What is the biggest mistake in email DNS cleanup?

The biggest mistake is deleting or rewriting records before identifying ownership. A TXT record that looks old may still verify a live platform. An SPF include may support a billing or helpdesk system. Agencies should map each record to a current or former vendor, confirm risk with the client, then change DNS deliberately.