DEV Community

Cover image for SPF, DKIM, and DMARC for Newsletters: The Setup You’re Probably Missing
frederic
frederic

Posted on

SPF, DKIM, and DMARC for Newsletters: The Setup You’re Probably Missing

#email #newsletter #dns #security

Your newsletter content can be brilliant. If authentication is broken, some subscribers may never see it.

Last month, I audited the publicly visible email-authentication setup of 20 newsletter domains.

Fourteen had at least one missing or questionable configuration. Six had no published DMARC record at all.

That does not automatically mean every message from those domains went to spam.

Newsletter deliverability also depends on:

  • subscriber engagement;
  • complaint rates;
  • list quality;
  • sending history;
  • content;
  • domain reputation;
  • IP reputation;
  • the infrastructure operated by the newsletter platform.

But SPF, DKIM, and DMARC form the technical foundation.

This guide explains what each protocol does, how to inspect your current configuration, how to deploy DMARC safely, and how to verify the result without copying DNS records that belong to somebody else’s account.

Important: Never copy a DKIM selector, CNAME target, return-path value, or SPF include from a random tutorial. Use the exact DNS records generated inside your own newsletter-platform account.

How This Audit Was Conducted

I checked the publicly accessible DNS records of 20 newsletter domains.

The review covered:

  • SPF records published on the sending domain;
  • DMARC records published under _dmarc;
  • duplicate or malformed SPF policies;
  • visible authentication inconsistencies;
  • DKIM records when the active selector could be identified;
  • delivered-message headers when test messages were available.

The audit assessed whether the authentication configuration was publicly visible and technically consistent.

It did not attempt to guarantee inbox placement.

A domain can have perfect SPF, DKIM, and DMARC records and still suffer from poor deliverability because of list quality, spam complaints, low engagement, or sender reputation.

Likewise, the absence of a visible record does not prove that every message sent by the organization fails authentication. Some platforms use separate sending domains or delegated subdomains.

Why Email Authentication Matters

When Gmail, Outlook, Yahoo, or another mailbox provider receives an email, it tries to answer several questions.

Was this server authorized to send for the domain?

SPF helps answer that question.

Was the message cryptographically signed?

DKIM helps determine whether the message was signed by an authorized service and whether it was modified after being sent.

Does the authenticated domain align with the visible sender?

DMARC evaluates whether SPF or DKIM aligns with the domain visible in the email’s From: address.

DMARC can also tell receiving mail servers what to do when authentication and alignment fail.

Authentication does not guarantee inbox placement.

However, missing or broken authentication can increase the likelihood of:

  • message rejection;
  • spam placement;
  • DMARC failure;
  • domain impersonation;
  • damage to sender reputation.

SPF, DKIM, and DMARC Explained Without the Jargon

SPF: Who Is Allowed to Send?

SPF stands for Sender Policy Framework.

It publishes a list of servers and services authorized to send email for a domain.

A simplified SPF record might look like this:

example.com. IN TXT "v=spf1 include:provider.example ~all"
Enter fullscreen mode Exit fullscreen mode

This is only an illustration.

The real include: value must come from your email provider or newsletter platform.

When a receiving server evaluates SPF, it normally checks the message’s envelope-from or return-path domain.

It does not simply inspect the friendly From: address shown to the recipient.

That distinction becomes important when discussing DMARC alignment.

DKIM: Was the Message Genuinely Signed?

DKIM stands for DomainKeys Identified Mail.

It adds a cryptographic signature to each outgoing email.

The sending platform keeps the private key. The corresponding public key is published in DNS.

A DKIM lookup uses a selector:

selector._domainkey.example.com
Enter fullscreen mode Exit fullscreen mode

The selector is not universal.

One Beehiiv account may receive different DNS values from another account. The same is true for Kit, Mailchimp, Ghost, and other platforms.

Depending on the service, DKIM may be published as:

  • a TXT record containing the public key;
  • one or more CNAME records pointing to keys managed by the platform.

The hostname, record type, and value must match the instructions displayed inside your own account.

DMARC: Does Authentication Align With the Visible Sender?

DMARC stands for Domain-based Message Authentication, Reporting, and Conformance.

DMARC does not replace SPF or DKIM.

Instead, it checks whether at least one of them passes and aligns with the domain shown in the visible From: header.

DMARC also lets the domain owner publish a policy.

Monitoring policy 

p=none
Enter fullscreen mode Exit fullscreen mode

The receiving server is not asked to quarantine or reject failing messages.

Aggregate reports can still be collected.

Quarantine policy 

p=quarantine
Enter fullscreen mode Exit fullscreen mode

The receiving server is asked to treat failing messages as suspicious.

Depending on the mailbox provider, they may be placed in spam or processed differently.

Reject policy 

p=reject
Enter fullscreen mode Exit fullscreen mode

The receiving server is asked to reject messages that fail DMARC.

A domain without DMARC can still send authenticated email.

However, it has no published DMARC policy and does not receive aggregate DMARC reports unless another monitoring system is used.

Step 1: Inspect Your Current DNS

Before adding or changing anything, determine what already exists.

Replace example.com with your own domain.

Check SPF 

dig TXT example.com
Enter fullscreen mode Exit fullscreen mode

To filter the result:

dig TXT example.com +short | grep "v=spf1"
Enter fullscreen mode Exit fullscreen mode

You should normally see no more than one SPF policy for the same domain.

Check DMARC 

dig TXT _dmarc.example.com +short
Enter fullscreen mode Exit fullscreen mode

A valid result should begin with:

v=DMARC1;
Enter fullscreen mode Exit fullscreen mode

Check DKIM

You need the selector provided by your platform.

For a TXT-based DKIM record:

dig TXT selector._domainkey.example.com +short
Enter fullscreen mode Exit fullscreen mode

For a CNAME-based DKIM record:

dig CNAME selector._domainkey.example.com +short
Enter fullscreen mode Exit fullscreen mode

Do not guess the selector.

Open your newsletter platform’s domain-authentication settings and copy the hostname exactly.

Query Multiple Public Resolvers

Your local DNS resolver may still be caching an older answer.

Check several public resolvers:

dig @8.8.8.8 TXT _dmarc.example.com +short
dig @1.1.1.1 TXT _dmarc.example.com +short
dig @9.9.9.9 TXT _dmarc.example.com +short
Enter fullscreen mode Exit fullscreen mode

If the results differ shortly after an update, DNS propagation may still be underway.

Step 2: Fix SPF Without Creating a Second Record

One of the most common SPF mistakes is publishing several separate TXT records beginning with v=spf1.

For example, this is incorrect:

example.com. IN TXT "v=spf1 include:_spf.google.com ~all"
example.com. IN TXT "v=spf1 include:newsletter-provider.example ~all"
Enter fullscreen mode Exit fullscreen mode

These policies must be merged into one SPF record:

example.com. IN TXT "v=spf1 include:_spf.google.com include:newsletter-provider.example ~all"
Enter fullscreen mode Exit fullscreen mode

Again, newsletter-provider.example is only a placeholder.

Use the exact include or delegated record supplied by your service.

Do Not Add an SPF Include Unless the Platform Requests It

Some newsletter platforms authenticate custom sending domains through generated CNAME records and DKIM alignment rather than asking customers to edit the root SPF record manually.

Beehiiv, for example, may provide account-specific DNS records through its domain-authentication workflow.

You should copy the records displayed in your own Beehiiv dashboard.

Do not blindly add a value such as:

include:spf.beehiiv.com
Enter fullscreen mode Exit fullscreen mode

unless that exact value is explicitly displayed inside your account.

The same rule applies to:

  • Kit;
  • Mailchimp;
  • Ghost;
  • transactional email services;
  • CRMs;
  • support platforms;
  • ecommerce tools.

The platform dashboard is the source of truth.

For a broader analysis of Beehiiv’s custom domains, pricing, automations, monetization features, growth tools, and limitations, read my complete Beehiiv review.

For smaller newsletters, I also examined what can be used without paying in this guide to Beehiiv’s free plan.

Understand SPF’s 10-Lookup Limit

SPF evaluation allows a maximum of 10 DNS-query-producing mechanisms.

These can include:

  • include;
  • a;
  • mx;
  • redirect;
  • exists.

The limit applies to the complete recursive evaluation.

It does not apply only to the number of visible include: strings in the root record.

For example:

v=spf1 include:service-a.example include:service-b.example ~all
Enter fullscreen mode Exit fullscreen mode

This appears to contain only two includes.

However, each included policy may expand into several additional DNS lookups.

The complete evaluation can therefore exceed the limit even when the original record looks short.

A command such as:

grep -o "include:"
Enter fullscreen mode Exit fullscreen mode

does not calculate the recursive lookup count.

Use an SPF validator that expands the complete policy, or inspect each included record recursively.

Understand ~all Versus -all

The final SPF mechanism indicates how unauthorized sending sources should be treated.

Soft fail 

~all
Enter fullscreen mode Exit fullscreen mode

This indicates that sources not explicitly authorized should be treated as suspicious.

Hard fail 

-all
Enter fullscreen mode Exit fullscreen mode

This indicates that sources not listed in the SPF policy are unauthorized.

A hard-fail policy may be appropriate after every legitimate sender has been inventoried.

Do not switch to -all merely because one newsletter test passed.

Your domain may also be used by:

  • Google Workspace;
  • Microsoft 365;
  • a support-desk platform;
  • a transactional email service;
  • a CRM;
  • a payment provider;
  • a website contact form;
  • an invoicing tool;
  • an ecommerce platform.

First identify every service that sends email using the domain.

Then confirm that each one is authenticated correctly.

Step 3: Configure DKIM Using Generated Values

DKIM is not something you should construct manually unless you operate your own mail infrastructure.

Your newsletter platform normally generates the required DNS records.

A platform may display something similar to this:

Host:
generated-selector._domainkey.example.com

Type:
CNAME

Value:
generated-selector.platform-domain.example
Enter fullscreen mode Exit fullscreen mode

Another platform may request a TXT record:

Host:
generated-selector._domainkey.example.com

Type:
TXT

Value:
v=DKIM1; k=rsa; p=...
Enter fullscreen mode Exit fullscreen mode

Copy the following values exactly:

  • hostname;
  • record type;
  • target or public key;
  • selector;
  • subdomain.

Common DKIM Configuration Mistakes

The domain is added twice

The platform asks for:

selector._domainkey.example.com
Enter fullscreen mode Exit fullscreen mode

But the DNS interface automatically appends example.com.

The resulting hostname becomes:

selector._domainkey.example.com.example.com
Enter fullscreen mode Exit fullscreen mode

Check whether your DNS provider expects the complete hostname or only the host portion.

The wrong record type is used

If the platform requests a CNAME, publishing its value as a TXT record will not work.

The CNAME is proxied

Some DNS providers allow CNAME records to pass through a proxy.

Email-authentication CNAMEs normally need to resolve directly to the platform’s target.

Set them to DNS-only unless the platform explicitly instructs otherwise.

The record is created on the wrong domain

A record added to the website’s root domain will not authenticate a different sending subdomain unless the configuration explicitly uses it.

DNS is correct, but the platform is not verified

Some platforms require a final verification step.

After propagation, return to the newsletter dashboard and click the relevant verification or authentication button.

Step 4: Deploy DMARC Gradually

A basic monitoring record can look like this:

_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
Enter fullscreen mode Exit fullscreen mode

This record tells participating receivers:

  • the record uses DMARC;
  • no enforcement is currently requested;
  • aggregate reports should be sent to dmarc@example.com.

A more explicit monitoring policy may look like this:

_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=r; aspf=r"
Enter fullscreen mode Exit fullscreen mode

Here:

  • adkim=r enables relaxed DKIM alignment;
  • aspf=r enables relaxed SPF alignment.

Relaxed alignment is already the default.

These tags are optional unless you want the policy to be explicit.

Why You Should Begin With p=none

Starting with p=none provides visibility before enforcement.

DMARC aggregate reports can reveal:

  • your newsletter platform;
  • your corporate mailbox provider;
  • transactional email systems;
  • forgotten marketing tools;
  • unauthorized senders;
  • forwarded traffic;
  • authentication failures;
  • alignment failures.

Do not move to p=quarantine or p=reject only because a fixed number of weeks has passed.

Move when the reports show that legitimate traffic is authenticated and aligned.

The appropriate timeline depends on:

  • how many services send for the domain;
  • how often each service sends;
  • whether every legitimate source has appeared in the reports;
  • whether subdomains are used;
  • whether third-party vendors send on your behalf.

Example DMARC Enforcement Policies

After monitoring and correcting legitimate senders, you can begin with partial enforcement:

_dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.com"
Enter fullscreen mode Exit fullscreen mode

This asks participating receivers to apply the quarantine policy to 25% of messages that fail DMARC.

You may then increase the percentage:

_dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc@example.com"
Enter fullscreen mode Exit fullscreen mode

When legitimate mail is consistently authenticated and aligned, a reject policy may look like this:

_dmarc.example.com. IN TXT "v=DMARC1; p=reject; pct=100; rua=mailto:dmarc@example.com"
Enter fullscreen mode Exit fullscreen mode

A strict policy should be based on evidence, not a fixed deadline.

Use a Dedicated Address for DMARC Reports

Aggregate DMARC reports are normally delivered as XML files.

They can become difficult to read manually and may create a large amount of email.

Instead of sending them to your personal inbox, use a dedicated address:

dmarc@example.com
Enter fullscreen mode Exit fullscreen mode

You can also use a specialist DMARC reporting service.

A reporting dashboard makes it easier to identify:

  • sending sources;
  • SPF results;
  • DKIM results;
  • alignment;
  • message volume;
  • unexpected infrastructure;
  • unauthorized senders.

The reporting address must exist or be managed by the reporting service you selected.

How DMARC Alignment Works

Suppose the visible From address is:

newsletter@example.com
Enter fullscreen mode Exit fullscreen mode

The email may use a return-path such as:

bounce.provider.example
Enter fullscreen mode Exit fullscreen mode

SPF could pass for provider.example.

However, that domain does not necessarily align with example.com.

The message may also carry a valid DKIM signature using:

d=example.com
Enter fullscreen mode Exit fullscreen mode

In that case, DKIM passes and aligns with the visible From domain.

DMARC can therefore pass through DKIM alignment.

DMARC requires aligned SPF or aligned DKIM.

It does not require both mechanisms to align simultaneously.

This is why seeing only:

SPF: PASS
Enter fullscreen mode Exit fullscreen mode

is not enough.

You must inspect the domain authenticated by SPF and compare it with the domain visible in the From: header.

Step 5: Verify a Real Email, Not Only DNS

A DNS record can exist while outgoing messages still fail authentication.

Always test a real newsletter email.

Send a test message to:

  • a Gmail account;
  • an Outlook account;
  • a Yahoo account if relevant;
  • an authentication-testing mailbox;
  • an inbox-placement testing service.

Then inspect the raw headers.

Inspect Authentication in Gmail

Open the message.

Select the three-dot menu.

Choose Show original.

Look for results such as:

SPF: PASS
DKIM: PASS
DMARC: PASS
Enter fullscreen mode Exit fullscreen mode

In the raw Authentication-Results header, inspect the domains involved:

spf=pass smtp.mailfrom=bounce.provider.example
dkim=pass header.d=example.com
dmarc=pass header.from=example.com
Enter fullscreen mode Exit fullscreen mode

The exact domains will vary depending on your platform.

The important part is that DMARC passes through aligned SPF or DKIM.

Useful Command-Line Checks

Confirm That Only One SPF Policy Exists 

dig TXT example.com +short | grep -c "v=spf1"
Enter fullscreen mode Exit fullscreen mode

Expected result:

1
Enter fullscreen mode Exit fullscreen mode

A result of 0 means no SPF policy was found at that hostname.

A result greater than 1 suggests multiple SPF policies and should be investigated.

Confirm That DMARC Exists 

dig TXT _dmarc.example.com +short | grep -c "v=DMARC1"
Enter fullscreen mode Exit fullscreen mode

Expected result:

1
Enter fullscreen mode Exit fullscreen mode

Check a CNAME-Based DKIM Record 

dig CNAME selector._domainkey.example.com +short
Enter fullscreen mode Exit fullscreen mode

Check a TXT-Based DKIM Record 

dig TXT selector._domainkey.example.com +short
Enter fullscreen mode Exit fullscreen mode

Trace a DNS Answer 

dig +trace TXT _dmarc.example.com
Enter fullscreen mode Exit fullscreen mode

This can help diagnose delegation or nameserver issues, although the output is more technical.

Platform-Specific Guidance

Modern newsletter platforms do not all use the same DNS architecture.

Do not assume that one platform’s records will work for another.

Beehiiv

Beehiiv’s custom-domain authentication process supplies account-specific DNS records.

When configuring Beehiiv:

  • do not guess the SPF include;
  • do not guess the DKIM selectors;
  • copy the records displayed in your Beehiiv account;
  • keep authentication CNAMEs unproxied;
  • wait for DNS propagation;
  • verify the domain inside Beehiiv;
  • publish and monitor DMARC;
  • inspect a real delivered message.

For a complete analysis of its features, pricing, automations, growth tools, monetization options, and limitations, read my complete Beehiiv review.

For a smaller publication that wants to begin without paying immediately, my Beehiiv free-plan guide explains what is included for free and when an upgrade may become necessary.

You can also create a Beehiiv account through this affiliate link.

Affiliate disclosure: The Beehiiv link above is an affiliate link. It does not increase the price you pay, and I may receive a commission if you register or purchase a plan through it.

Kit

Kit supports verified sending domains through automatic or manual configuration.

The required records are displayed inside the account’s email settings.

Copy those values exactly rather than taking selectors or targets from a third-party tutorial.

The same principle applies to any DMARC guidance generated by the platform.

Mailchimp

Mailchimp distinguishes domain verification from domain authentication.

Its authentication workflow provides generated DNS values inside the customer account.

Do not replace them with selectors copied from an old guide.

Make sure every hostname, record type, and value matches the current instructions displayed by Mailchimp.

Substack

When a platform sends using its own authenticated infrastructure and domains, much of the authentication may be managed by the platform.

The correct way to understand a delivered Substack message is to inspect its headers.

Identify:

  • the visible From domain;
  • the return-path domain;
  • the DKIM d= domain;
  • the SPF result;
  • the DKIM result;
  • the DMARC result;
  • the domain used for alignment.

Do not assume that the DNS configuration of your website automatically controls every part of Substack’s sending infrastructure.

Ghost

Ghost’s email authentication depends on how the newsletter is hosted and which mail provider is used.

A managed Ghost installation and a self-hosted installation may not use the same DNS records.

Follow the values supplied by the actual sending provider rather than searching for a universal “Ghost SPF record.”

Common Authentication Failure Modes

Multiple SPF Records

You find two TXT records beginning with:

v=spf1
Enter fullscreen mode Exit fullscreen mode

This can produce an SPF permanent error.

Merge all legitimate senders into one SPF policy.

Correct DNS Type, Wrong Hostname

The platform requests:

selector._domainkey.example.com
Enter fullscreen mode Exit fullscreen mode

But your DNS provider automatically appends example.com.

The final record becomes:

selector._domainkey.example.com.example.com
Enter fullscreen mode Exit fullscreen mode

Check how your DNS interface handles hostnames.

DKIM Published as TXT Instead of CNAME

If the platform requests a CNAME, publishing the target as a TXT record will not work.

Use the record type explicitly requested by the platform.

Authentication CNAMEs Are Proxied

Some DNS providers allow CNAME records to be proxied.

Email-authentication records normally need to resolve directly to the platform’s target.

Set them to DNS-only unless the platform states otherwise.

DMARC Enforcement Begins Too Early

A domain is moved directly to:

p=reject
Enter fullscreen mode Exit fullscreen mode

before every legitimate sender has been identified.

Transactional emails, support messages, invoices, contact-form notifications, or password-reset emails may then fail DMARC.

Monitor first.

DMARC Has No Reporting Address

A record such as:

"v=DMARC1; p=none"
Enter fullscreen mode Exit fullscreen mode

is valid, but it does not provide an aggregate-report destination.

Adding rua gives you visibility:

"v=DMARC1; p=none; rua=mailto:dmarc@example.com"
Enter fullscreen mode Exit fullscreen mode

SPF Exceeds the Lookup Limit

The visible SPF policy appears short, but nested includes push the complete evaluation above 10 DNS lookups.

Use a recursive SPF analyzer rather than counting only the includes shown in the root record.

SPF and DKIM Pass, but DMARC Fails

SPF and DKIM may technically pass for third-party domains while DMARC fails because neither authenticated domain aligns with the visible From domain.

Inspect the authenticated domains, not only the word pass.

DNS Is Correct, but the Platform Is Not Verified

Some platforms require a final verification step after the DNS records are published.

Return to the dashboard and complete the verification process.

BIMI: Optional, Useful, and Often Misunderstood

BIMI stands for Brand Indicators for Message Identification.

It can allow a brand-controlled logo to appear beside authenticated emails in supporting mailbox providers.

BIMI is not a replacement for SPF, DKIM, or DMARC.

It builds on them.

The typical foundation includes:

  • SPF authentication;
  • DKIM authentication;
  • DMARC alignment;
  • an enforcement policy such as p=quarantine or p=reject;
  • a compliant BIMI SVG logo;
  • a BIMI DNS record.

A simplified BIMI record may look like this:

default._bimi.example.com. IN TXT "v=BIMI1; l=https://example.com/bimi-logo.svg"
Enter fullscreen mode Exit fullscreen mode

Some implementations also use an a= tag referencing a mark certificate:

default._bimi.example.com. IN TXT "v=BIMI1; l=https://example.com/bimi-logo.svg; a=https://example.com/mark-certificate.pem"
Enter fullscreen mode Exit fullscreen mode

The logo must use the required SVG Portable/Secure profile rather than an ordinary web SVG.

Certificate requirements vary according to the mailbox provider and implementation.

BIMI is worth exploring only after the authentication foundation is stable.

Do not begin with BIMI while SPF, DKIM, or DMARC is still failing.

What Healthy Newsletter Deliverability Looks Like

There is no universal inbox-placement percentage that every newsletter should achieve.

Results depend on:

  • recipient mix;
  • list source;
  • sending frequency;
  • engagement;
  • mailbox providers;
  • content;
  • domain reputation;
  • IP reputation;
  • complaint rates;
  • bounce rates.

However, several indicators remain useful.

Authentication Results

A healthy result should normally show:

SPF: PASS
DKIM: PASS
DMARC: PASS
Enter fullscreen mode Exit fullscreen mode

At least one of SPF or DKIM must also align with the visible From domain for DMARC to pass.

Spam Complaints

Keep complaint rates as low as possible.

A low complaint rate matters more than chasing a perfect open rate.

Monitor the complaint data available through your newsletter platform and mailbox-provider tools.

Bounce Rate

A growing hard-bounce rate usually indicates a list-quality problem rather than a DNS problem.

Remove hard bounces.

Avoid importing addresses without clear permission.

Review inactive and invalid contacts regularly.

Engagement

Open rates can be distorted by:

  • privacy features;
  • image blocking;
  • automated security scanners;
  • mailbox-provider prefetching;
  • bot activity.

Use a combination of:

  • clicks;
  • replies;
  • conversions;
  • unsubscribes;
  • complaints;
  • bounce data;
  • subscriber growth.

Authentication results and open rates answer different questions.

Authentication Cannot Fix a Bad List

A technically perfect domain can still have poor deliverability.

SPF, DKIM, and DMARC do not compensate for:

  • purchased lists;
  • scraped addresses;
  • inactive subscribers;
  • misleading signup forms;
  • excessive sending;
  • irrelevant content;
  • hidden unsubscribe links;
  • repeated spam complaints.

Authentication proves and protects identity.

It does not prove that recipients want the email.

For bulk marketing messages, one-click unsubscribe support and a visible unsubscribe mechanism are also important.

Most reputable newsletter platforms implement the necessary headers automatically, but you should still verify that unsubscribe links work.

The DNS Timing Mistake That Causes Avoidable Failures

DNS updates are not always visible everywhere immediately.

The TTL, or time to live, determines how long resolvers may cache an older value.

Suppose an existing record has:

TTL = 86400
Enter fullscreen mode Exit fullscreen mode

That represents 24 hours.

When practical, lower the TTL before a planned migration or authentication change.

For example:

TTL = 300
Enter fullscreen mode Exit fullscreen mode

That represents five minutes.

However, lowering the TTL immediately before changing the record does not instantly remove old cached answers.

Resolvers may retain the previous value until its original TTL expires.

A Safer DNS Migration Workflow

Several days before the change

Lower the TTL on the records you expect to modify.

Monday morning

Publish the new SPF, DKIM, and DMARC records.

Monday afternoon

Check the records through multiple public DNS resolvers.

Monday evening

Verify the domain inside the newsletter platform and send test emails.

Tuesday

Inspect the delivered headers before sending to the full list.

Avoid major email-DNS changes immediately before an important campaign or over a weekend.

A propagation delay is easier to handle while support teams and technical contacts are available.

Frequently Asked Questions

Do I Need to Add a Universal Beehiiv SPF Record?

No.

Use only the DNS records displayed in your own Beehiiv domain-authentication settings.

Depending on the current setup, Beehiiv may provide account-specific CNAME and DKIM records instead of asking you to add a universal SPF include.

Do not copy selectors or SPF values from another Beehiiv account.

Can SPF and DKIM Pass While DMARC Fails?

Yes.

SPF or DKIM can pass for a third-party domain while failing DMARC alignment with the domain visible in the From: header.

DMARC passes only when at least one successful authentication mechanism also aligns with the visible sender domain.

Does DMARC Require Both SPF and DKIM to Align?

No.

DMARC can pass through aligned SPF or aligned DKIM.

Both do not have to align simultaneously.

However, configuring both correctly provides better resilience.

Should I Publish p=reject Immediately?

No.

Start with p=none, collect aggregate reports, identify every legitimate sender, and correct authentication or alignment failures.

Move gradually to p=quarantine or p=reject only after the legitimate sending infrastructure has been verified.

Is BIMI Required for Newsletter Deliverability?

No.

BIMI is optional.

It does not replace SPF, DKIM, DMARC, list hygiene, sender reputation, or subscriber engagement.

Configure BIMI only after the main authentication setup is stable.

Can Perfect Authentication Guarantee the Primary Inbox?

No.

Authentication helps mailbox providers identify the sender.

It does not guarantee placement in Gmail’s Primary tab or any other inbox category.

Engagement, complaints, content, sending reputation, and user behavior still influence placement.

Why Does My Platform Show Verified While DMARC Still Fails?

A platform may verify that its DNS records exist while the final delivered message still fails alignment.

Inspect the raw headers of a real message and compare:

  • the visible From domain;
  • the SPF-authenticated return-path domain;
  • the DKIM signing domain;
  • the final DMARC result.

Final Verification Checklist

SPF Checklist

  • Only one SPF policy exists for the relevant domain.
  • Every legitimate SPF-authorized sender is included.
  • Recursive DNS lookups remain within the limit.
  • The final mechanism is appropriate for the deployment stage.
  • Obsolete sending services are no longer authorized.

DKIM Checklist

  • The exact platform-generated hostname was used.
  • The requested DNS record type was used.
  • The record resolves publicly.
  • The platform confirms that the domain is authenticated.
  • A real delivered message passes DKIM.
  • The DKIM domain aligns with the visible From domain when used for DMARC.

DMARC Checklist

  • The record is published at _dmarc.example.com.
  • A reporting address is configured.
  • Aggregate reports are being received and reviewed.
  • Legitimate sending services have been inventoried.
  • Enforcement is increased only after authentication is verified.
  • A real delivered message passes DMARC.

Deliverability Checklist

  • Hard bounces are removed.
  • Spam complaints are monitored.
  • One-click unsubscribe is available when required.
  • Sending volume is increased responsibly.
  • The From name and domain remain consistent.
  • Test messages are inspected across several mailbox providers.
  • Subscriber permission can be demonstrated.
  • Inactive contacts are reviewed regularly.

Final Takeaway

SPF, DKIM, and DMARC are not magic inbox buttons.

They are identity and policy controls.

A correct configuration helps mailbox providers verify that your newsletter is authorized, cryptographically signed, and aligned with the domain shown to the subscriber.

A broken configuration can undermine an otherwise excellent publication.

The safest approach is straightforward:

  • inspect the current DNS before changing anything;
  • use the exact values generated by the platform;
  • publish only one SPF policy per domain;
  • verify DKIM on a real delivered message;
  • begin DMARC in monitoring mode;
  • study the reports before enforcement;
  • test again after every DNS or platform change.

Your content still determines whether readers care.

Your list quality still determines whether they want the email.

But authentication determines whether mailbox providers can reliably identify who sent it.

For a closer look at Beehiiv’s features, custom-domain options, pricing, and limitations, read my complete Beehiiv review.

To understand what can be done without a paid subscription, see my guide to the Beehiiv free plan.

You can also try Beehiiv through this affiliate link.

Affiliate disclosure: The Beehiiv link above is an affiliate link. It does not change the price you pay. I may receive a commission if you register or purchase a plan through it.

This guide reflects the email-authentication landscape reviewed in July 2026. Newsletter platforms can change their domain-verification workflows, selectors, and required DNS records. Always compare this guide with the current documentation and the exact values displayed inside your own platform account.

Top comments (0)