DMARC, SPF, and DKIM Explained for Agency Operations Teams

Here is DMARC SPF DKIM explained for agency operations teams: SPF says which servers are allowed to send mail for a domain, DKIM signs messages so receivers can verify they were not altered and were authorized by a domain, and DMARC tells receivers how to evaluate SPF or DKIM alignment with the visible From domain.

The agency version is even simpler. SPF, DKIM, and DMARC help answer whether a client domain is configured to send trustworthy email. They do not guarantee inbox placement, and they do not replace good list practices or deliverability work. But missing or weak records can create risk during onboarding, campaigns, vendor migrations, and client support incidents.

CertPilot's Inbox Pulse helps agencies audit DMARC, SPF, DKIM-related configuration risk, MTA-STS, TLS-RPT, and BIMI across multiple client domains. For the broader domain operations picture, run a free 10-domain agency audit or choose from the free tools at /tools. For how CertPilot uses public DNS and email-authentication data, review the CertPilot methodology.

SPF, DKIM, and DMARC: The Simple Difference

The simple difference between SPF, DKIM, and DMARC is that each one answers a different question.

| Protocol | Simple question it answers | DNS record involved | Common agency mistake | |---|---|---|---| | SPF | Is this sending server allowed for this domain? | TXT record beginning with v=spf1 | Adding every vendor include without sender ownership | | DKIM | Was this message signed with a valid domain key? | TXT or CNAME record under a selector such as selector._domainkey | Assuming one selector covers every sender | | DMARC | Do SPF or DKIM align with the visible From domain, and what should receivers do if they do not? | TXT record at _dmarc.example.com | Moving policy before legitimate senders are aligned |

In a normal client setup, Google Workspace may handle employee inboxes while Mailchimp, HubSpot, or another platform sends campaigns. The agency must verify that SPF, DKIM, and DMARC reflect all legitimate senders. Google may be aligned while a campaign platform is not, or DKIM may work for one sender while another still relies on SPF.

None of these protocols alone guarantees inbox placement. They are configuration signals that help receivers evaluate mail, and they need to be paired with platform checks, message-header review, and sender hygiene when deliverability work goes deeper.

DMARC SPF DKIM explained without RFC language

Think of the three records as a basic trust system.

| Record | Plain-language job | Agency question | |---|---|---| | SPF | Lists who may send for the domain | Are the client's senders authorized? | | DKIM | Adds a cryptographic signature | Is the sender signing as the client domain? | | DMARC | Sets policy based on aligned SPF or DKIM | What should receivers do when mail fails? |

They work together, but they are not the same thing. A domain can have SPF and still fail DMARC. A domain can have DKIM for one sender and still have another sender unsigned. A domain can have DMARC at p=none and still need an operational plan.

SPF explained for agency teams

SPF is a DNS TXT record that lists authorized senders. It often contains mechanisms such as include:, ip4:, ip6:, and all.

Example:

v=spf1 include:_spf.google.com include:send.example.net ~all

For agencies, SPF becomes messy because clients use many tools:

• mailbox provider
• CRM
• marketing platform
• ecommerce platform
• invoicing system
• helpdesk
• website forms
• transactional email provider

Each tool may ask to be added to SPF. Over time, the record can collect old vendors and nested includes. That creates risk, including the SPF 10 lookup limit. For a deeper workflow, read the SPF 10 lookup limit guide.

What SPF proves:

• The connecting sender is authorized by the domain used in the return path.

What SPF does not prove by itself:

• That the visible From domain aligns.
• That the message should land in the inbox.
• That every client sender is configured correctly.

DKIM explained for agency teams

DKIM signs a message with a private key controlled by the sender. The public key is published in DNS under a selector, usually at:

selector._domainkey.example.com

The selector is included in the message header. Receivers use it to find the right public key.

For agencies, DKIM is usually configured inside each sending platform. Google Workspace may have one setup. Microsoft 365 may have another. SendGrid, Mailgun, Klaviyo, HubSpot, or ecommerce tools may each need their own records.

What DKIM proves:

• A message was signed by a system with access to the private key.
• The signed parts of the message were not changed after signing.

What DKIM does not prove by itself:

• That every sender is configured.
• That the signature aligns with the visible From domain.
• That deliverability is guaranteed.

For selector examples, use the DKIM selectors cheat sheet.

DMARC explained for agency teams

DMARC sits on top of SPF and DKIM. It checks whether either SPF or DKIM passes and aligns with the visible From domain. It also publishes a policy for receivers.

A basic DMARC record might look like:

v=DMARC1; p=none; rua=mailto:dmarc@example.com

The policy values are:

• p=none
• p=quarantine
• p=reject

For agencies, DMARC is the record that turns separate sender checks into a domain-level policy. It is also where rollout discipline matters. A stricter policy can be useful, but only after legitimate senders are understood and aligned.

What DMARC proves:

• The domain has published a policy for failed aligned authentication.

What DMARC does not prove by itself:

• That all legitimate senders are aligned.
• That reports are being reviewed.
• That inbox placement is guaranteed.

Alignment is the agency concept that matters most

Alignment means the authenticated domain matches, or is acceptably related to, the visible From domain.

Example:

| Scenario | Authentication result | Agency interpretation | |---|---|---| | SPF passes for client.com and From is client.com | Aligned SPF likely | Good signal. | | DKIM passes for client.com and From is client.com | Aligned DKIM likely | Good signal. | | SPF passes for vendor-mail.com and From is client.com | Not aligned for client.com | May not help DMARC. | | DKIM signs as vendor.com and From is client.com | Not aligned for client.com | Needs sender setup review. | | DMARC exists but no sender aligns | DMARC may fail for real mail | Configuration is incomplete. |

This is why "SPF exists" or "DKIM exists" is not enough. Agencies need to know whether client mail actually aligns.

Agency operations checklist

Use this checklist during onboarding or quarterly reviews.

Domain inventory

• List all client domains.
• Separate active sending domains from parked domains.
• Include subdomains used for marketing, apps, or support.

Sender inventory

• Ask which platforms send email.
• Include website forms and ecommerce.
• Check old vendors and retired tools.
• Document who owns each sender.

DNS audit

• Check SPF exists and is valid.
• Check SPF does not contain obvious stale vendors.
• Check DKIM setup for each sender.
• Check DMARC exists and policy is intentional.
• Check MTA-STS, TLS-RPT, and BIMI if relevant.

Real-message verification

• Send test messages from important systems.
• Inspect authentication headers.
• Confirm SPF or DKIM alignment.
• Record unresolved senders as action items.

Run Inbox Pulse for the bulk configuration review, then use Audit 10 Domains for SSL, DNS, and domain expiry risk.

A simple triage framework

When an audit returns many findings, sort them by business use before sorting by technical detail.

| Priority | Domain type | Why it comes first | |---|---|---| | 1 | Active customer-facing sender | Problems can affect invoices, support, sales, or campaigns. | | 2 | Active internal mailbox domain | Staff mail issues create daily client friction. | | 3 | Marketing or campaign subdomain | Campaign failures can be visible and time-sensitive. | | 4 | Transactional app subdomain | Password resets and receipts may be affected. | | 5 | Parked or defensive domain | Important, but usually less urgent if it truly sends no mail. |

This keeps the agency from spending the first hour debating a parked domain while the client's CRM sender is still unauthenticated.

Where agencies get into trouble

The common failure is assuming one record covers every workflow.

Examples:

• Google Workspace is configured, but invoices are sent by a billing platform.
• DKIM is enabled for the newsletter tool, but CRM sequences use another sender.
• SPF authorizes a vendor, but DMARC alignment still fails.
• The main domain has DMARC, but a campaign subdomain does not.
• A previous agency left old records that nobody understands.

These are not rare edge cases. They are normal outcomes when multiple teams and vendors touch client email over several years.

How to explain this to non-technical clients

Use operational language:

"We are checking whether the services that send email for your domain are properly authorized and aligned. This reduces configuration risk, but it is not an inbox-placement guarantee."

Avoid:

"Your deliverability is fixed."

Better:

"The main mailbox sender is authenticated. The marketing platform still needs DKIM verification. DMARC is present but currently in monitoring mode."

This helps clients understand progress without creating false certainty.

What an agency handoff note should include

After the review, write a short handoff note that another team member can understand later.

Include:

• domains checked
• active senders confirmed by the client
• SPF status and risky includes
• DKIM status by sender
• DMARC policy and reporting destination
• unresolved access blockers
• recommended next action

The note does not need to include every DNS value. It should explain what was checked, what remains uncertain, and who owns the next step. This is especially useful when account managers, developers, and outside email vendors all touch the same client.

How often should agencies review records?

Review email authentication:

• when onboarding a client
• before major campaigns
• after changing email providers
• after a website or ecommerce launch
• during quarterly technical reviews
• when deliverability complaints appear

For web infrastructure, pair the review with SSL and DNS monitoring. The DNS drift agency guide explains why record changes need process. The client website health report template shows how to present recurring checks. For SSL renewal readiness, use 47-Day Renewal Pre-Flight and the ACME readiness check guide.

Inbox Pulse in the agency stack

Inbox Pulse is best used as a configuration audit layer. Paste multiple domains and look for email-authentication risk across the portfolio.

Use it for:

• onboarding checks
• quarterly reviews
• pre-campaign checks
• triage after client complaints
• finding domains that need deeper sender verification

Do not use it as:

• a guarantee of inbox placement
• a legal or compliance guarantee
• a replacement for continuous DMARC RUA monitoring
• a complete deliverability platform

That scope makes the tool useful without overstating what a DNS-based audit can prove.

Related resources

• Inbox Pulse email authentication checker
• Bulk DMARC check for client domains
• Multiple SPF records cleanup guide
• SPF 10 lookup limit agency debugging guide
• DKIM selectors cheat sheet
• DMARC policy none, quarantine, and reject guide

Frequently Asked Questions

What is the difference between SPF, DKIM, and DMARC?

SPF authorizes sending servers, DKIM signs messages, and DMARC checks whether SPF or DKIM aligns with the visible From domain and applies a published policy. In plain language: SPF asks whether the server is allowed, DKIM asks whether the message has a valid signature, and DMARC asks whether authentication aligns with the domain recipients see.

Do I need SPF, DKIM, and DMARC?

Most active sending domains should have a thoughtful SPF, DKIM, and DMARC setup. The exact rollout depends on the client's senders and risk profile.

Which matters most: SPF, DKIM, or DMARC?

DMARC is the policy layer, but it depends on SPF or DKIM alignment. In practice, agencies should not treat one protocol as the only important one. SPF helps authorize sending paths, DKIM gives durable message-level authentication, and DMARC ties those results to the visible From domain. The right priority depends on which client systems actually send mail.

Can SPF, DKIM, and DMARC fix deliverability?

No. SPF, DKIM, and DMARC can fix authentication and alignment problems, but they do not guarantee deliverability or inbox placement. Mailbox providers also evaluate reputation, engagement, content, complaints, sending volume, recipient behavior, and platform-specific signals. Treat email authentication as a foundation, not the whole deliverability program.

How should agencies check SPF, DKIM, and DMARC across client domains?

Use Inbox Pulse to audit visible DNS-based configuration across multiple client domains, then verify key senders with real messages and platform admin consoles where possible. For broader infrastructure context, use Audit 10 Domains to check SSL, DNS, and domain expiry alongside email-authentication work.

What else should agencies check?

For broader infrastructure risk, run Audit 10 Domains. It covers SSL, DNS, and domain expiry alongside your email-authentication workflow.