Email Authentication Audit: SPF, DKIM, DMARC Checks

An email authentication audit proves that your domains can send mail safely before volume exposes the gaps. You check SPF, DKIM, and DMARC record by record, then confirm the same results in real message headers.

What an Email Authentication Audit Should Prove

An email authentication audit should prove that every legitimate sending source is authorized, aligned, and visible in reporting.

Good email authentication answers four practical questions:

1. Is this system allowed to send for your domain?
2. Does the message carry a valid DKIM signature?
3. Does DMARC pass based on SPF or DKIM alignment?
4. Can you see failures before they damage sender reputation?

This matters more as you scale. Mailbox providers use SPF, DKIM, and DMARC as baseline trust signals. They also use them to enforce bulk sender requirements, detect spoofing, and decide whether mail deserves inbox placement.

Confirm the sending domain is authorized to send mail

SPF tells receiving servers which IPs or services can send for a domain.

A simple SPF record might look like this:

example.com.  TXT  "v=spf1 include:_spf.google.com include:sendgrid.net -all"

That record says Google and SendGrid can send mail for example.com.

But SPF has limits. It checks the envelope sender domain, also called the return-path or bounce domain. That domain may differ from the visible From: domain your recipients see.

So an SPF pass does not automatically mean DMARC passes.

Verify that DKIM signatures are present, valid, and aligned

DKIM signs the message with a private key. The receiving server checks the public key in DNS.

A DKIM signature includes a signing domain:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=mail2024; ...

For DMARC alignment, the d= domain should match, or be a subdomain of, the visible From: domain depending on your alignment mode.

DKIM gives you a stronger audit trail than SPF. It also survives many forwarding scenarios where SPF breaks.

Check whether DMARC is published, aligned, and enforceable

DMARC ties SPF and DKIM to the visible From: domain. It also tells receivers what to do when authentication fails.

A monitoring-only DMARC record looks like this:

_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

An enforced record might use quarantine or reject.

Your audit should identify whether the record exists, whether it is valid, whether reports go somewhere useful, and whether the current policy matches your risk tolerance.

Identify authentication gaps that can cause spam placement, spoofing risk, or compliance issues

Authentication gaps usually fall into three buckets:

Gap	What it means	Risk
Missing SPF include	A sender is not authorized in SPF	SPF fail, DMARC fail if DKIM also fails
Missing or broken DKIM	Messages are unsigned or signatures fail	Weaker authentication, forwarding issues
DMARC misalignment	SPF or DKIM passes on the wrong domain	DMARC fail despite “passing” SPF/DKIM

Do not treat these as cosmetic DNS issues. They can affect spam placement, spoofing exposure, and compliance with mailbox provider bulk sender requirements.

Step 1: Inventory Every Sending Source

Start by listing every system that sends email using your domain or subdomains.

You cannot audit what you have not found. Most authentication failures come from overlooked tools, not from the primary marketing platform.

List every sender

Include:

• Email service providers
• CRMs
• Transactional email platforms
• Product notification systems
• Cold outreach tools
• Sales engagement platforms
• Help desk software
• Billing systems
• Internal mail servers
• Recruiting platforms
• Event and webinar tools
• Legacy systems still sending automated mail

Ask finance for vendor lists. Ask sales ops for sequencing tools. Ask engineering for transactional providers. Ask customer support for ticketing systems. Shadow senders often live outside marketing.

Map each tool to its domains

For each tool, document:

• Visible From: domain
• Return-path or bounce domain
• DKIM signing domain
• DKIM selector
• Sending IPs, if dedicated
• Mail stream type
• Owner
• Volume range
• Current SPF, DKIM, and DMARC status

Use a simple table:

Tool	Stream	From domain	Return-path domain	DKIM domain	Owner
Marketing ESP	Marketing	example.com	bounce.example.com	example.com	Lifecycle
Product mail	Transactional	app.example.com	mail.app.example.com	app.example.com	Engineering
Sales tool	Sales	example.com	vendor-domain.com	vendor-domain.com	RevOps

That last row deserves attention. If the sales tool signs with the vendor domain and uses a vendor return-path, SPF and DKIM may pass technically, while DMARC fails for your visible domain.

Document streams separately

Separate marketing, transactional, lifecycle, and sales mail.

Each stream has a different risk profile. Transactional mail often has better authentication because engineering set it up carefully. Sales outreach often has weaker authentication because teams added tools quickly.

This separation also helps during a sender reputation audit or inbox placement audit. If one stream causes complaints or failures, you need to isolate it fast.

Step 2: Audit SPF Without Breaking It

Audit SPF by checking authorization, syntax, lookup count, and alignment.

SPF looks simple. It is easy to break when you add too many vendors or flatten records without a maintenance plan.

Check each sending source

For every source in your inventory, confirm the SPF record includes the right sending service.

Common mechanisms include:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:mailgun.org -all

Check the vendor’s current documentation. Do not copy SPF includes from old tickets or blog posts.

Also check the domain that SPF actually evaluates. SPF validates the envelope sender domain, not always the visible From: domain.

Look for multiple SPF records

A domain must have only one SPF TXT record.

This is broken:

example.com. TXT "v=spf1 include:_spf.google.com -all"
example.com. TXT "v=spf1 include:sendgrid.net -all"

Receivers may return a permanent error. Merge the records into one:

example.com. TXT "v=spf1 include:_spf.google.com include:sendgrid.net -all"

Also look for obsolete mechanisms:

• ptr is deprecated and slow.
• Broad a and mx mechanisms can authorize more than you intend.
• +all allows everything and defeats the point of SPF.

Respect the 10-DNS-lookup limit

SPF evaluation allows up to 10 DNS lookups. Includes, redirects, a, mx, and some other mechanisms count.

If you exceed the limit, SPF can return permerror. That can break DMARC when DKIM does not save the message.

Flattening can help in narrow cases, but it creates maintenance risk. Prefer reducing unused vendors first. Use subdomains for separate streams when needed.

Verify SPF alignment

SPF alignment means the authenticated return-path domain aligns with the visible From: domain.

Example:

Visible From	Return-path	SPF result	DMARC SPF alignment
news@example.com	bounce.example.com	Pass	Pass, relaxed alignment
news@example.com	mail.vendor.com	Pass	Fail
news@example.com	bounce.example.net	Pass	Fail

This is the most common SPF audit mistake. Teams see “SPF pass” and stop. DMARC may still fail.

Step 3: Audit DKIM Signatures

Audit DKIM by confirming that every sender signs mail with a valid, aligned domain and current DNS selector.

DKIM should be present on every production stream. It protects authentication when SPF breaks due to forwarding. It also gives receivers a stable identity tied to your domain.

Confirm every sender signs

Send a test message from each platform. Inspect headers. Look for:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=s1; ...

Then confirm the receiver reports dkim=pass.

A Gmail-style authentication result might look like:

Authentication-Results: mx.google.com;
       spf=pass smtp.mailfrom=bounce.example.com;
       dkim=pass header.d=example.com;
       dmarc=pass (p=quarantine) header.from=example.com

That is what you want to see.

Check selector records and key length

The selector tells receivers where to find the public key:

s1._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."

During the audit, confirm:

• The selector exists in DNS.
• The public key is not truncated.
• The key is strong enough for current provider requirements.
• The sender is using the selector you expect.
• Old selectors are removed only after traffic has fully moved.

Many providers now expect 1024-bit as a floor and prefer stronger keys where supported. Follow the sending platform’s current guidance.

Look for broken DKIM after migrations

DKIM often breaks after:

• ESP migrations
• DNS provider changes
• Domain rebrands
• Subdomain moves
• Selector rotations
• Shared-to-dedicated IP transitions

A common failure looks like this:

dkim=fail (bad signature) header.d=example.com

That means a signature existed, but validation failed. Causes include modified message content, wrong DNS key, wrong selector, or platform misconfiguration.

Use DKIM to survive forwarding

SPF checks the server that delivered the message to the final receiver. Forwarding can change that path and break SPF.

DKIM signs the message content and headers. If forwarding does not modify signed parts, DKIM can still pass. That lets DMARC pass through DKIM alignment even when SPF fails.

This is why DKIM should not be optional for any important stream.

Step 4: Audit DMARC Policy and Alignment

Audit DMARC by validating the record, reviewing the policy, checking alignment, and making sure reports are monitored.

DMARC is where SPF, DKIM, and the visible From: domain come together.

Confirm the record exists and is valid

DMARC lives at:

_dmarc.example.com

A basic record:

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

An enforcement record:

v=DMARC1; p=reject; rua=mailto:dmarc@example.com; adkim=r; aspf=r

Check for:

• One DMARC TXT record only
• Correct v=DMARC1
• Valid p= value
• Correct rua= destination
• No malformed tags
• No accidental quotes or line break issues from DNS editing

Review policy level

DMARC policy has three main levels:

Policy	Receiver instruction	Best use
p=none	Monitor only	Discovery and reporting
p=quarantine	Treat failing mail as suspicious	Gradual enforcement
p=reject	Reject failing mail	Strong spoofing protection

Do not jump to reject before you know every legitimate sender passes DMARC. You can block your own mail.

A safe path is:

1. Publish p=none.
2. Review dmarc reporting.
3. Fix legitimate failures.
4. Move selected domains or subdomains to quarantine.
5. Move to reject when failures are understood.

Check relaxed vs strict alignment

DMARC alignment can be relaxed or strict.

Relaxed alignment allows subdomains to align with the organizational domain.

Strict alignment requires exact domain match.

Mode	Example	Result
Relaxed DKIM	From: example.com, d=mail.example.com	Aligned
Strict DKIM	From: example.com, d=mail.example.com	Not aligned
Relaxed SPF	From: example.com, return-path bounce.example.com	Aligned
Strict SPF	From: example.com, return-path bounce.example.com	Not aligned

Most teams use relaxed alignment unless they have a specific security reason for strict alignment. Strict mode can be useful for high-risk domains, but it requires tighter operational control.

Make sure rua reporting is enabled and monitored

rua tells receivers where to send aggregate DMARC reports.

Example:

rua=mailto:dmarc-reports@example.com

Those reports show which IPs and domains send mail using your domain and whether SPF, DKIM, and DMARC pass.

But raw XML reports are painful. Use a DMARC reporting tool or internal parser. Assign an owner. Review trends, not just one-off failures.

DMARC reporting is not a checkbox. It is your radar.

Step 5: Review Authentication in Real Messages

Validate authentication in real production-like messages, not only DNS lookup tools.

DNS tools help. They do not prove that your actual messages are signed, aligned, and accepted the same way by major mailbox providers.

Send tests to major providers

Send real test messages to:

• Gmail
• Outlook / Microsoft 365
• Yahoo / AOL
• Apple Mail accounts where possible
• A mailbox on your own corporate domain

Inspect full headers. Look for Authentication-Results.

You want to see:

spf=pass
dkim=pass
dmarc=pass

Then check the domains attached to each result.

Compare results across providers

Different receivers display and evaluate headers differently. The underlying authentication standards are consistent, but implementation details can vary.

Compare:

• SPF result
• DKIM result
• DMARC result
• DKIM signing domain
• Return-path domain
• Visible From: domain
• ARC results for forwarded mail, if present
• Spam folder placement during inbox placement audit testing

Do not rely on one mailbox.

Look for differences between tools and production

A test tool may say your DNS is valid while production mail still fails.

Common reasons:

• The ESP is using a different selector than documented.
• Only some message types are signed.
• A template editor modifies signed content.
• A shared sending domain is still active.
• The test uses a subdomain, but production uses the root domain.
• Sales users send through a plugin that bypasses the authenticated path.

Validate each sending stream separately. Marketing campaigns, password resets, invoices, and sales sequences should each get their own check.

Common Email Authentication Audit Findings

Most audits find a small set of repeat problems.

The value of the audit is not only finding them. It is ranking which ones can hurt you fastest.

Missing DKIM on one ESP or subdomain

One tool sends unsigned mail. Everything else looks fine.

This often happens when a team adds a new platform, verifies the sending domain enough to launch, but skips the DKIM CNAME records.

Fix it by adding the provider’s DKIM records and sending a real test. Confirm dkim=pass and dmarc=pass.

SPF passes but DMARC fails because of misalignment

This is very common.

The vendor’s infrastructure passes SPF for its own return-path domain. But your visible From: domain is example.com.

Result:

spf=pass smtp.mailfrom=vendor.com
dkim=fail header.d=vendor.com
dmarc=fail header.from=example.com

Fix this by configuring a custom bounce domain, aligned DKIM, or both.

Old vendors remain in DNS

Old SPF includes and DKIM selectors often stay behind after migrations.

This creates two problems:

• You may authorize systems you no longer use.
• You may hit SPF lookup limits sooner.

Remove obsolete records carefully. Confirm no legitimate traffic still uses them. DMARC aggregate reports can help you prove that.

DMARC reporting exists but no one reviews it

A rua address that dumps XML into an unmonitored inbox does not help.

Assign ownership. Review reports at least during onboarding, migration, and volume increases. Watch for unknown senders, failing high-volume sources, and sudden alignment changes.

Transactional mail is authenticated but sales outreach is not

This pattern shows up in many audits.

Engineering configured transactional mail correctly. Marketing configured the ESP correctly. Sales added a sequencing tool later and sends from the same domain with weak or misaligned authentication.

That can affect more than sales mail. It can bleed into domain reputation and complicate a sender reputation audit.

What to Fix First

Fix the highest-volume unauthenticated or misaligned mail first, then move toward DMARC enforcement.

Not every finding has equal risk. Prioritize by volume, business impact, and likelihood of failing DMARC.

Prioritize unauthenticated high-volume sources

Start with any source that sends meaningful volume and has:

• No DKIM signature
• DKIM failure
• SPF failure
• DMARC failure
• Vendor-domain signing with no alignment
• Unknown ownership

High-volume failures create the most reputation risk. They also make dmarc reporting noisy.

Fix DMARC alignment before enforcement

Do not enforce DMARC until legitimate mail passes.

Before moving from p=none to quarantine or reject, confirm:

• Every major stream passes DMARC.
• SPF or DKIM aligns with the visible From: domain.
• DMARC aggregate reports do not show unknown legitimate sources.
• Support, sales, product, and marketing teams know the change is coming.
• You have rollback steps.

Use subdomains if one stream needs stricter control than another.

Remove obsolete DNS includes carefully

Clean DNS improves security and reduces SPF complexity.

But do it in order:

1. Identify old vendor includes and selectors.
2. Check DMARC reports for recent traffic.
3. Ask the internal owner to confirm the tool is retired.
4. Remove one change at a time.
5. Test real messages after each change.

Avoid large DNS cleanup batches right before a campaign launch.

Pair authentication fixes with bounce reduction

Authentication proves you are allowed to send. It does not prove recipients want your mail or that addresses are valid.

For better sender reputation, pair your email authentication work with:

• Email verification before import or signup
• Bounce monitoring by stream
• Complaint-rate review
• Suppression of invalid and risky addresses
• Engagement-based segmentation
• Inbox placement audit checks before large sends

Bounceable can help here by verifying addresses before you send, flagging disposable domains, identifying risky addresses, and reducing avoidable hard bounces.

Use this final audit checklist

Before sending at scale, confirm:

• Every sender is inventoried.
• Every stream has an owner.
• SPF includes only active senders.
• SPF stays under the 10-lookup limit.
• SPF alignment passes where you rely on SPF for DMARC.
• DKIM signs every important stream.
• DKIM selectors resolve in DNS.
• DKIM signing domains align with the visible From: domain.
• DMARC record exists and is valid.
• DMARC reporting is enabled and reviewed.
• DMARC policy matches your readiness.
• Real Gmail, Outlook, and Yahoo headers show expected results.
• Old vendors are removed from DNS.
• High-volume lists are verified before launch.