Email authentication can feel like back-office plumbing—until a campaign goes to spam, password-reset emails disappear, or criminals impersonate your brand. A thorough email domain audit turns SPF, DKIM, and DMARC from checkbox items into a practical system for protecting deliverability and customer trust.

A recent discussion in r/Emailmarketing made the right basic point: many businesses still have incomplete or misconfigured email authentication. But the most useful takeaway from the thread is the nuance added by commenters. Publishing three DNS records is not the finish line. Your sending domains need aligned authentication, manageable SPF complexity, a deliberate DMARC rollout, healthy recipient lists, and monitoring that catches changes before mailbox providers do.

Why an email domain audit matters more now

Email authentication has long been important for combating spoofing and establishing legitimate sending identity. It has also become more operationally important because major mailbox providers formalized stronger expectations for bulk senders in 2024.

Google says senders delivering more than 5,000 messages per day to Gmail accounts must use SPF and DKIM, publish DMARC, and meet additional requirements such as easy unsubscribe options. Yahoo’s sender guidance similarly requires bulk senders to implement SPF and DKIM, publish a valid DMARC policy at least at p=none, pass DMARC, support easy unsubscribe, and keep spam complaint rates below 0.3%. (support.google.com)

That does not mean smaller senders can ignore authentication. A five-person SaaS company can suffer just as much from an impersonated invoice email or a failed password reset as a company sending millions of promotions. The difference is that smaller teams often have more fragmented tooling: Google Workspace or Microsoft 365 for employee mail, an email API for product notifications, a CRM for sales sequences, a support platform, a billing tool, and a marketing platform. Every one of those systems may send mail as the same domain.

An audit gives you a reliable answer to four essential questions:

  1. Who is allowed to send email for our domain?
  2. Which messages are actually signed and aligned with the visible From address?
  3. What happens when a fraudulent or broken message claims to be from us?
  4. Are recipients responding in a way that supports a good sender reputation?

The original Reddit PSA correctly frames SPF, DKIM, and DMARC as foundational. The practical upgrade is to treat them as a connected control plane—not three independent DNS records.

The three protocols: what each one really does

SPF authorizes infrastructure, not the visible From address

Sender Policy Framework, or SPF, is a DNS-published policy that identifies the servers authorized to use a domain in the SMTP envelope sender or HELO/EHLO identity. In simple terms, it helps a receiver ask: “Was this sending server allowed to use this return-path domain?” RFC 7208 defines SPF as a way for domain owners to explicitly authorize hosts to use their domain names. (datatracker.ietf.org)

A typical SPF record can look like this:

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

That example may authorize Google Workspace and a sending provider, but it does not automatically prove that the visible From: hello@yourbrand.com address is authentic. The visible From domain and the envelope sender are separate parts of an email. That distinction becomes critical when DMARC evaluates alignment.

SPF is useful, but it is fragile when organizations keep adding tools. A new CRM, webinar platform, HR platform, or support desk can introduce another include: mechanism. Over time, a record that once worked can exceed SPF’s DNS-query budget and begin returning a permanent error.

DKIM signs mail so receivers can verify it survived transit

DomainKeys Identified Mail, or DKIM, adds a cryptographic signature to a message. The receiving server retrieves the corresponding public key from DNS and checks whether the message was signed by the stated domain and whether signed portions were changed in transit. DKIM lets a domain take responsibility for a message without relying solely on the IP address that delivered it. (datatracker.ietf.org)

A DKIM signature typically contains a signing domain (d=) and a selector (s=). The selector points receivers to a DNS record such as:

selector1._domainkey.yourbrand.com

The selector is not cosmetic. It enables key rotation and allows different systems to sign using distinct keys. For example, Google Workspace might use one selector, your transactional-email provider another, and your marketing platform a third. That separation makes it easier to identify which sender generated an authentication problem.

A key point from the Reddit comments deserves emphasis: 1024-bit DKIM should be considered a legacy compatibility floor, not the target for a new implementation. RFC 8301 updated DKIM cryptographic guidance because earlier key-size and algorithm assumptions had become obsolete; it states that signers should use keys of at least 1024 bits and receivers must not treat keys under 1024 bits as acceptable. In practice, 2048-bit RSA keys are the sensible default where your provider and DNS setup support them. (datatracker.ietf.org)

DMARC connects authentication to the address recipients see

DMARC—Domain-based Message Authentication, Reporting, and Conformance—is the layer that tells receivers how to evaluate mail claiming to be from the domain shown in the visible From header. It uses SPF and DKIM results, but it requires that at least one passing result be aligned with that visible From domain.

This is the issue most often missed in “I have all three records” setups. SPF may pass for a third-party provider’s bounce domain. DKIM may pass for a vendor-owned signing domain. Yet DMARC can still fail because neither authenticated identity aligns with the domain the recipient sees.

Yahoo explicitly describes this requirement in its sender guidance: the domain in the From header must align with either the SPF domain or DKIM domain for DMARC alignment. (senders.yahooinc.com)

DMARC also publishes a policy:

  • p=none asks receivers to monitor and report failures without requesting enforcement.
  • p=quarantine asks receivers to treat failing mail suspiciously, often placing it in spam.
  • p=reject asks receivers to refuse failing mail.

Those are requests, not an absolute guarantee of mailbox-provider behavior. Still, the policy is a crucial signal: it states what your organization believes should happen to unauthenticated mail impersonating your domain.

The most common audit mistake: checking presence instead of alignment

A DNS checker can report that SPF, DKIM, and DMARC records exist. That is useful, but it is only the first layer of an email domain audit.

Consider a brand using news.example.com as the visible From domain. Its email service provider sends with an envelope sender at bounce.vendor-mail.net and DKIM signs using d=vendor-mail.net. SPF passes. DKIM passes. But neither identity aligns with news.example.com, so DMARC fails.

This situation commonly happens when a team skips a provider’s “custom return-path,” “authenticated domain,” or “domain alignment” configuration step. They can send successfully for months, see green checks for SPF and DKIM in a dashboard, and still fail the policy that mailbox providers actually use to connect the email to the brand.

What aligned authentication looks like

Under relaxed alignment—the common default—subdomains can align with their organizational domain. For example:

  • Visible From: updates@news.example.com
  • DKIM signing domain: example.com
  • Result: generally aligned under relaxed DKIM alignment

Under strict alignment, the domains must match exactly. Strict mode can make sense for particular high-control environments, but it increases the chance that legitimate systems will fail during rollout.

For most companies, aligned DKIM is the more durable path. SPF often breaks in forwarding scenarios or when a third party controls the envelope sender. A custom DKIM signing domain is typically easier to keep aligned with the visible From identity across marketing and transactional streams.

How to test alignment instead of guessing

Send representative messages from every sending platform to a Gmail or other mailbox where you can inspect full headers. Look for:

  • Authentication-Results:
  • spf=pass or spf=fail
  • dkim=pass or dkim=fail
  • dmarc=pass or dmarc=fail
  • the visible From: domain
  • the SPF-authenticated envelope domain, often reflected in Return-Path
  • DKIM’s d= signing domain

Do not test only a newsletter. Test password resets, receipts, contact-form notifications, calendar invitations, support replies, sales automation, and internal mail. Authentication configuration often differs by message type, and the forgotten system is usually the one that blocks a safe move to DMARC enforcement.

SPF’s 10-lookup limit is a quiet deliverability risk

One of the best additions in the discussion was the warning about SPF’s DNS lookup limit. SPF is not infinitely expandable. RFC 7208 limits SPF evaluation to 10 DNS-query-causing mechanisms and modifiers; exceeding the limit produces permerror. (datatracker.ietf.org)

The risk is cumulative. Your root record may include Google Workspace, which includes several other records. Your marketing platform may include another domain with more includes. A CRM, support platform, and outbound-sales provider can push the policy over the limit faster than the team expects.

The important operational lesson is this: SPF can fail after a vendor change even if nobody touched the root SPF record directly. A provider may alter its own include chain, and your record inherits the complexity.

Signs your SPF record needs attention

Audit SPF when any of these are true:

  • You have more than two or three email-sending vendors.
  • Multiple teams independently add DNS records.
  • You see spf=permerror in message headers or DMARC reports.
  • A vendor asks you to add another include: without reviewing the existing record.
  • You maintain separate sending systems for employee, marketing, product, support, and sales email.

Safer ways to control SPF complexity

First, inventory senders and remove services you no longer use. Old vendors should not remain authorized simply because no one knows whether they are still needed.

Second, use separate subdomains for distinct send types where it makes operational sense. For example, mail.example.com can handle marketing mail while notify.example.com handles product notifications. This limits the number of systems competing for one root-domain SPF policy and creates clearer boundaries for reputation and troubleshooting.

Third, do not create multiple SPF TXT records at the same hostname. SPF expects one policy record; publishing several independent v=spf1 records can cause evaluation problems. Consolidation is required, but consolidation should be deliberate—not a rushed copy-and-paste exercise.

Some teams use SPF “flattening” services to reduce lookups. That can work, but it introduces maintenance responsibility because provider IP ranges can change. If you flatten, make sure the process is automated, monitored, and owned by someone—not a static record forgotten after launch.

DKIM key strength, selectors, and rotation

The original post’s note that stronger keys are easy to use is directionally right, but the community correction is more actionable: use 2048-bit DKIM keys for new deployments when possible. Treat 1024-bit keys as a compatibility exception, not a modern baseline.

A 2048-bit key can be longer than what some older DNS management interfaces comfortably display. DNS TXT records can be published as quoted segments, and the DNS system combines those segments for the record value. The real failure mode is not that longer keys are inherently invalid; it is copying them incorrectly, truncating them, adding unexpected characters, or using a provider that cannot publish the required record properly.

A sensible DKIM operating model

Use a distinct selector per sending platform or stream. Name it clearly enough to be useful during an incident: gws1, mkt1, txn1, or a provider-generated selector if the platform requires it.

Then rotate keys periodically or whenever a vendor instructs you to rotate. The safe pattern is to publish the new public key first, configure the sender to use it, validate real messages, and only then retire the old selector after you are sure no mail still depends on it.

Avoid one shared DKIM setup that obscures responsibility. If the marketing platform signs with the same selector as your product-email provider, a broken signature becomes harder to trace. Separate selectors make audit evidence clearer and reduce the blast radius of changes.

DMARC monitoring is not DMARC protection

A p=none record is valuable, especially when you are beginning. It lets you collect aggregate reports and discover systems sending on your behalf. But it is a monitoring policy, not an enforcement policy.

That distinction was another strong theme in the community reaction. Organizations frequently publish p=none, see that a DMARC record exists, and assume the brand is protected. Meanwhile, a phisher can keep sending unauthenticated mail that uses the company’s visible From domain. Receivers may independently filter it, but the domain owner has not requested quarantine or rejection.

DMARC’s reporting function is powerful because it can reveal both legitimate and illegitimate senders. Aggregate reports show which IP addresses and domains are sending messages claiming to be from your domain, along with authentication outcomes and volumes. The reports are XML, so most teams use a reporting service or internal parser rather than read raw files manually.

A safe DMARC rollout path

Do not jump directly to p=reject because the record generator said it was “best practice.” A bad enforcement rollout can reject your own password-reset messages, invoices, customer notifications, or executive mail. The safer progression is:

  1. Publish DMARC with p=none and a valid aggregate reporting address via rua.
  2. Collect reports long enough to cover normal sending cycles, including monthly invoices, campaigns, and infrequent systems.
  3. Classify every known sender as legitimate, obsolete, or suspicious.
  4. Fix SPF or DKIM alignment for legitimate senders.
  5. Move to p=quarantine, potentially using a limited pct value if appropriate.
  6. Monitor for unintended failures.
  7. Advance to p=reject once legitimate traffic is consistently aligned.

This is not a one-week project for every organization. If your company has a clean, well-understood stack, it may move quickly. If business units have bought email tools independently for years, the discovery phase can take much longer. The priority is avoiding false confidence at p=none and avoiding self-inflicted outages at p=reject.

Authentication is the entry ticket; recipient behavior drives reputation

One Reddit commenter summarized the relationship well: authentication gets a sender allowed to participate, while list hygiene helps keep the sender trusted. That distinction matters because an organization can authenticate perfectly and still land in spam.

Mailbox providers observe signals beyond DNS. High complaint rates, weak engagement, sudden volume spikes, misleading content, and repeated sends to dead addresses all hurt reputation. Yahoo advises senders to keep spam rates below 0.3%, while Google’s sender guidance emphasizes avoiding unwanted mail and making unsubscribe easy for high-volume senders. (senders.yahooinc.com)

Hard bounces are particularly useful operational signals. A hard bounce indicates that an address is invalid or no longer able to receive mail. Continuing to send to those addresses makes the sender look careless at best and spam-like at worst.

Before importing leads, launching reactivation campaigns, or migrating an old list, use an address verification workflow to identify obviously invalid or risky addresses. Verification is not a replacement for permission, consent, or engagement management, but it is a practical control for lowering avoidable bounces.

The four-part deliverability system

Strong deliverability is better understood as a system:

  • Identity: SPF, DKIM, DMARC, aligned domains, and valid sending infrastructure.
  • Permission: Clear opt-in practices, no purchased lists, and messages consistent with subscriber expectations.
  • List quality: Suppression of hard bounces, unsubscribes, complaints, and persistently inactive contacts where appropriate.
  • Experience: Useful content, sensible frequency, recognizable branding, and a simple way to leave.

Authentication cannot rescue a list that never opted in. Conversely, an excellent opt-in list cannot compensate for mail that fails DMARC. The two disciplines must be managed together.

Segment domains and streams before they become a problem

A root domain that handles corporate mail, marketing campaigns, product receipts, and cold outbound mail creates unnecessary coupling. Each stream has different volume patterns, reputation risks, and technical requirements.

Consider a company that sends employee mail from example.com, newsletters from news.example.com, transactional mail from notify.example.com, and partner communications from partners.example.com. This does not magically solve deliverability, but it gives the company clearer authentication boundaries and makes incidents easier to isolate.

Subdomains can also improve DMARC deployment. You can gain enforcement confidence for transactional mail without waiting for every legacy marketing workflow to be fixed, provided the architecture and policy design are carefully planned. Be mindful, however, that DMARC policies can inherit to subdomains depending on configuration, so this is not a reason to create subdomains without understanding policy scope.

There is a strategic tradeoff. Too many domains create administrative overhead, diluted reputation signals, and more chances for configuration drift. The goal is not maximal segmentation. The goal is enough separation to make sending ownership, authentication, and monitoring intelligible.

A practical email domain audit checklist

Use this checklist quarterly, after any ESP migration, and whenever a department introduces a new email-sending tool.

1. Build a sender inventory

Document every system that sends as your organization, including:

  • Google Workspace or Microsoft 365
  • transactional email provider and product-email API
  • marketing automation platform
  • CRM and sales engagement tools
  • help desk and customer-success systems
  • billing, invoicing, and subscription platforms
  • form builders, scheduling tools, and webinar services
  • internal apps, servers, and legacy systems

For each, record the visible From domain, envelope sender domain, DKIM signing domain, selector, sending IP ownership, owner, purpose, and expected volume.

2. Review SPF once, as a complete policy

Confirm that there is only one SPF policy per hostname. Count DNS-query-causing mechanisms across included records rather than merely counting vendors. Remove retired senders. Confirm every active sender is authorized, but do not authorize broad ranges “just in case.”

3. Validate DKIM on actual messages

Make sure every major sender produces a passing DKIM signature. Check that the signing domain aligns with the visible From domain under your DMARC policy. Prefer 2048-bit RSA keys for new configurations, and verify that DNS publication has not truncated the public key.

4. Inspect DMARC policy and reports

Confirm a DMARC record exists at _dmarc.yourdomain.com. Check policy level, rua reporting destination, alignment settings, and subdomain behavior. Review reports regularly; a report address that nobody reads is only slightly better than no report address.

5. Test real-world mail flows

Send from each platform and inspect headers. Test replies, forwarding, marketing campaigns, receipts, password resets, and support messages. A DNS record audit alone cannot prove that a vendor is signing mail correctly in production.

6. Review reputation and list controls

Monitor bounces, complaints, unsubscribes, and sudden changes in volume or placement. Suppress hard bounces promptly. Keep marketing and transactional traffic operationally distinct so a weak campaign does not create confusion around essential account emails.

7. Document ownership and change control

Someone must own the sending-domain inventory. DNS edits should be reviewed against that inventory, and vendors should not be allowed to add authentication records without a technical check for SPF lookup impact and DMARC alignment.

Tools help, but a green dashboard is not proof

Domain health checkers, DNS lookup tools, and DMARC platforms are useful for quickly surfacing missing records, malformed syntax, weak keys, and obvious policy gaps. The Reddit post mentioned tools such as MXToolbox and Suped’s checker; tools in that category are a reasonable first pass.

But automated checks have limits. They may not know every business application that sends mail, whether a sender is authorized by your security team, or whether a message type is critical. They can also report a record as valid while your production messages still fail alignment.

The best workflow combines automated scans with live-message validation and report analysis:

  1. Scan DNS for obvious errors.
  2. Compare findings against the sender inventory.
  3. Send controlled test messages from each system.
  4. Inspect headers for SPF, DKIM, and DMARC results.
  5. Review DMARC aggregate reports for sources you did not expect.
  6. Make one controlled change at a time and retest.

This is also why email authentication belongs in change management. A marketing-platform migration, a new billing provider, or a DNS provider move can alter email behavior. Put an email domain audit on the launch checklist—not the post-incident checklist.

The bigger lesson: email authentication is brand infrastructure

It is tempting to describe SPF, DKIM, and DMARC as deliverability settings. That is true, but incomplete. They are also brand-security controls.

When a company moves toward an enforcing DMARC policy, it becomes harder for attackers to successfully impersonate its domain in the inbox. When it aligns product and marketing mail, it gives receivers a clearer identity signal. When it monitors reports, it gains visibility into unknown senders and forgotten systems. When it maintains clean lists, it reduces the behavioral evidence that makes legitimate mail resemble spam.

None of this guarantees inbox placement. DMARC itself does not confer special delivery privileges; it is a policy and reporting mechanism, not a reputation bypass. But a well-run authentication program removes preventable failure modes and gives the sender a cleaner foundation for every other deliverability decision. (rfc-editor.org)

The Reddit PSA was worth sharing because the basics still get missed. The more durable version of that advice is simple: audit the records, audit the messages, audit the vendors, and audit the recipient experience. Do that consistently, and SPF, DKIM, and DMARC become a working operational discipline rather than three acronyms in DNS.

FAQ

What is an email domain audit?

An email domain audit reviews the technical and operational systems that send mail for a domain. It should cover SPF, DKIM, DMARC, domain alignment, sending vendors, DNS lookup limits, real message headers, DMARC reports, bounces, complaints, and unsubscribe processes.

Do SPF, DKIM, and DMARC all need to pass?

For DMARC to pass, at least one of SPF or DKIM must pass and align with the visible From domain. In practice, organizations should configure both SPF and DKIM because major mailbox-provider guidance expects both for bulk senders and because each protocol covers different failure scenarios. (support.google.com)

Is a DMARC policy of p=none enough?

p=none is useful for monitoring and discovering legitimate senders before enforcement. It does not ask receiving servers to quarantine or reject unauthenticated impersonation attempts, so it should be treated as a temporary observation stage rather than the final goal for domains vulnerable to spoofing.

Should I use a 1024-bit or 2048-bit DKIM key?

Use 2048-bit DKIM keys for new deployments when your sending platform and DNS provider support them. RFC 8301 established 1024 bits as the minimum acceptable RSA key size, but 2048-bit keys are the stronger practical default. (datatracker.ietf.org)

How often should I run an email domain audit?

Run a lightweight review quarterly and a full review whenever you add, remove, or migrate an email-sending provider. Also review immediately after unexplained deliverability changes, phishing incidents, DNS migrations, or a significant increase in send volume.