SPF, DKIM and DMARC, explained

SPF, DKIM and DMARC are three email authentication mechanisms that help receiving mail systems determine whether a message claiming to come from your domain is legitimate.

They are especially important for WordPress websites because WordPress regularly sends email such as:

• password resets;
• new-user notifications;
• contact-form messages;
• order confirmations;
• membership emails;
• security alerts;
• administrative notifications.

Configuring SMTP can improve how WordPress sends those messages, but SMTP authentication and domain authentication are not the same thing.

A website can successfully connect to an SMTP server and still send messages that fail:

SPF

DKIM

DMARC

Likewise, a domain can have a valid SPF record while messages still fail DMARC because the SPF-authenticated domain does not align with the domain users actually see in the From: header.

This is where email authentication becomes confusing.

The simplest useful model is:

SPF
→ Which servers are authorized
  to send for a domain?

DKIM
→ Was this message cryptographically
  signed by an authorized domain?

DMARC
→ Does SPF or DKIM authenticate
  a domain aligned with the visible
  From: domain, and what should
  receivers do if neither does?

This guide explains how SPF, DKIM and DMARC work, how they interact, what email alignment means, how DNS records are structured, why forwarding causes problems, how DMARC policies work, what changed with the current DMARC standard and how all of this applies to outgoing WordPress email.

Why email authentication exists

The original email protocols were designed in a much more trusting Internet.

An email sender can claim identities in several different places during message delivery.

Conceptually:

SMTP server says:

MAIL FROM:
bounce@example.com

Message header says:

From:
Company <hello@example.com>

Without additional authentication, receiving systems need a way to determine whether the sending infrastructure is actually authorized to use those domain names.

Email spoofing is easy without authentication

An attacker could attempt to send:

From:
billing@example.com

without owning:

example.com

The recipient sees the visible From address

That visible identity carries enormous trust.

Users may assume:

From: accounts@example.com

therefore

example.com sent this email.

SPF, DKIM and DMARC provide receivers with evidence they can use to evaluate that assumption.

The three technologies solve different problems

They are complementary rather than interchangeable.

SPF
checks sending infrastructure

DKIM
checks a cryptographic signature

DMARC
connects authentication
to the visible From domain

Start with the different email identities

Understanding email authentication becomes considerably easier once you stop assuming an email has only one sender address.

The visible From header

This is what users normally see in their email client:

From:
The Company <hello@example.com>

In standards terminology this is commonly called the:

RFC5322.From

or, in the current DMARC specification, the:

Author Domain

The SMTP MAIL FROM identity

During SMTP delivery another address may be used:

MAIL FROM:
bounce@mailer.example.com

This is sometimes referred to as:

• envelope sender;
• envelope-from;
• return path;
• RFC5321.MailFrom.

These identities can be different

For example:

Visible From:
news@example.com

Envelope sender:
bounce@send.example.net

That distinction is central to SPF

SPF does not primarily authenticate the address ordinary users see in the message’s From: header.

It authenticates an SMTP identity, most importantly the domain used in:

MAIL FROM

DKIM introduces another domain

A DKIM signature contains a:

d=

tag identifying the signing domain.

For example:

d=example.com

One email can therefore involve several domains

Visible From:
example.com

SPF domain:
mailer.example.net

DKIM signing domain:
example.com

DMARC connects these identities

That connection is called:

alignment

We will come back to it shortly.

What is SPF?

SPF stands for:

Sender Policy Framework

It is defined by RFC 7208.

SPF lets a domain authorize sending infrastructure

The domain publishes an SPF policy through DNS.

Conceptually:

example.com says:

These servers are authorized
to send email using my domain
in the relevant SMTP identity.

An SPF record is published as a DNS TXT record

A simple example:

v=spf1 ip4:203.0.113.20 -all

This says, conceptually:

SPF version 1

authorize:
203.0.113.20

everything else:
fail

A receiver checks the sending IP

Suppose the message arrives from:

203.0.113.20

The recipient looks up the SPF record for the relevant domain.

If that IP is authorized:

SPF = pass

If an unauthorized server sends the message

For example:

198.51.100.40

while the SPF policy authorizes only:

203.0.113.20

then the SPF evaluation may result in:

SPF = fail

SPF can authorize providers using include

A common record might resemble:

v=spf1 include:_spf.example-provider.com -all

The:

include:

mechanism tells the receiver to evaluate another domain’s SPF policy as part of the authorization decision.

Multiple email services may need to be included

A company may send email through:

• Google Workspace;
• Microsoft 365;
• a WordPress SMTP provider;
• a CRM;
• a newsletter platform;
• transactional email infrastructure.

The SPF policy needs to account for legitimate infrastructure that sends using the relevant SPF identity.

Do not create separate SPF records for every provider

This is a common mistake.

Bad:

TXT:
v=spf1 include:provider-a.example -all

TXT:
v=spf1 include:provider-b.example -all

A domain should publish one applicable SPF policy

The required sending mechanisms need to be combined appropriately into that policy.

Conceptually:

v=spf1
include:provider-a.example
include:provider-b.example
-all

SPF mechanisms

Common SPF mechanisms include:

ip4:
ip6:
a
mx
include:
exists:
all

ip4 and ip6 authorize addresses

For example:

ip4:203.0.113.20

or:

ip4:203.0.113.0/24

The a mechanism uses address records

Conceptually:

a

allows addresses associated with the specified domain’s A or AAAA resolution under the SPF mechanism’s rules.

The mx mechanism uses mail-exchanger information

It can authorize addresses associated with the domain’s MX hosts.

include delegates part of the authorization logic

This is extremely common with external email services.

The all mechanism matches everything

It normally appears at the end of the record with a qualifier.

SPF qualifiers

Common forms include:

+all
-all
~all
?all

-all means fail

Conceptually:

If nothing above matched,
this sender is not authorized.

~all means softfail

It indicates the sender is probably not authorized, but the policy is less definitive than -all.

?all produces neutral

The domain is effectively making no useful authorization assertion for unmatched senders.

+all authorizes everything

A record ending with:

+all

effectively authorizes every sender that reaches that mechanism.

This generally defeats the reason somebody created an SPF record in the first place.

SPF has a DNS lookup limit

RFC 7208 limits SPF evaluation to:

10 DNS-query-causing terms

during an SPF check.

This matters with many includes

A record can appear small:

v=spf1
include:provider-a.example
include:provider-b.example
include:provider-c.example
-all

while each included record performs additional DNS lookups.

Exceeding the SPF lookup limit can produce permerror

This means a record that looks syntactically reasonable can still fail operationally.

Do not blindly add providers forever

Audit SPF whenever:

• a mail provider is added;
• a marketing service is replaced;
• a CRM is retired;
• WordPress changes SMTP provider.

Remove obsolete SPF mechanisms

An old:

include:

for a service no longer used creates unnecessary authorization and consumes lookup budget.

SPF alone does not authenticate the visible From domain

This is one of the most misunderstood points in email authentication.

Consider:

Visible From:
billing@example.com

MAIL FROM:
bounce@mailer.example.net

The message can pass SPF for:

mailer.example.net

without proving that:

example.com

authorized the visible From: identity.

This is why DMARC alignment exists

SPF authentication alone is not enough to protect the identity users actually see.

SPF also has forwarding limitations

Imagine:

Original sender
↓
forwarding server
↓
recipient

The final recipient may see the forwarding server’s IP rather than the original sender’s IP.

That forwarding server may not be authorized by the original SPF policy

SPF can therefore fail even though the original message was legitimate.

This is a structural limitation of SPF

It is one reason email authentication should not depend on SPF alone.

What is DKIM?

DKIM stands for:

DomainKeys Identified Mail

It is defined by RFC 6376 and subsequent updates.

DKIM uses cryptographic signatures

The sending system signs selected parts of an email using a private cryptographic key.

The corresponding public key is published in DNS.

The basic model

Sending server
↓
sign message with private key
↓
message contains DKIM-Signature
↓
recipient obtains public key from DNS
↓
recipient validates signature

The private key stays with the sender

The public key can safely be published in DNS.

A DKIM signature contains several parameters

A simplified example might include:

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

The d= tag identifies the signing domain

For example:

d=example.com

The s= tag identifies the selector

For example:

s=selector1

The receiver combines the selector and signing domain

It queries DNS at a location conceptually like:

selector1._domainkey.example.com

The DNS record contains the public key

A simplified DKIM TXT record may resemble:

v=DKIM1;
k=rsa;
p=MIIBIjANBgkqh...

The recipient verifies the signature

If the signature validates:

DKIM = pass

DKIM does not encrypt the email

This is important.

DKIM provides:

• domain-level signing;
• message-integrity evidence;
• authentication of the signing domain.

It does not make the message body secret.

A DKIM-signed email can still be read normally

Encryption and signing solve different problems.

Encryption
→ who can read it?

DKIM signature
→ can the signature be validated
  against the signing domain?

DKIM can survive forwarding better than SPF

Forwarding normally changes:

the server sending the message

but may leave the signed message content intact.

The original DKIM signature can therefore remain valid

This gives DKIM an advantage for many forwarding scenarios.

But intermediaries can break DKIM

If a system modifies signed message content, for example by:

• rewriting the body;
• altering signed headers;
• adding mailing-list footers;
• transforming message encoding;

the cryptographic signature may no longer verify.

DKIM canonicalization provides some tolerance

DKIM supports canonicalization methods intended to handle certain harmless formatting changes.

But canonicalization does not mean:

anything may modify the email
and DKIM will remain valid.

Selectors make DKIM key management practical

A domain is not limited to one permanent DKIM key.

For example:

google._domainkey.example.com

mail2026._domainkey.example.com

transactional._domainkey.example.com

Different services can use different selectors

This enables:

• key rotation;
• multiple email providers;
• separate transactional infrastructure;
• controlled provider migrations.

Rotate DKIM keys periodically

The exact rotation schedule depends on provider and security policy, but selectors make it possible to introduce a new key without immediately destroying validation for messages signed with the previous one.

Use sufficiently strong keys

Current Gmail sender requirements require DKIM keys of at least:

1024 bits

for messages to personal Gmail accounts and recommend:

2048 bits

where the provider supports them.

Yahoo similarly requires at least 1024-bit DKIM keys and recommends 2048-bit keys where possible.

DKIM alone still does not solve visible-From impersonation

Consider a message:

From:
billing@example.com

DKIM:
d=attacker.example.net

DKIM result:
pass

The DKIM signature can be completely valid for:

attacker.example.net

while telling us nothing about whether:

example.com

authorized the visible sender identity.

A valid DKIM signature is not enough for DMARC

The signing domain also needs to:

align

with the visible From domain.

What is DMARC?

DMARC stands for:

Domain-based Message Authentication,
Reporting, and Conformance

The current DMARC standard is RFC 9989

As of May 2026, the current core protocol is RFC 9989.

It supersedes the original DMARC specification, RFC 7489.

DMARC reporting now has separate specifications

Aggregate reporting is defined in RFC 9990.

Failure reporting is defined separately by RFC 9991.

DMARC sits on top of SPF and DKIM

DMARC does not replace either technology.

Instead it asks:

Did SPF pass and align?

OR

Did DKIM pass and align?

If either aligned mechanism succeeds, DMARC can pass

Conceptually:

SPF pass + SPF aligned
→ DMARC pass

OR

DKIM pass + DKIM aligned
→ DMARC pass

Both do not need to pass for DMARC to pass

This is a frequent misunderstanding.

DMARC requires at least one supported authentication path to pass with alignment.

But using both SPF and DKIM is still strongly recommended

The two mechanisms fail in different ways.

Having both provides resilience.

What is DMARC alignment?

Alignment compares the domain users see in:

From:

with the authenticated SPF or DKIM domain.

SPF alignment

Consider:

From:
sales@example.com

MAIL FROM:
bounce@example.com

SPF:
pass

The authenticated SPF domain is:

example.com

and the visible From domain is:

example.com

They align.

DKIM alignment

Consider:

From:
sales@example.com

DKIM:
d=example.com

DKIM:
pass

The domains align.

A message can authenticate but still fail alignment

For example:

From:
sales@example.com

MAIL FROM:
bounce@email-provider.example

SPF:
pass

DKIM:
d=email-provider.example

DKIM:
pass

Both SPF and DKIM may technically authenticate their own domains.

But neither authenticated domain necessarily aligns with:

example.com

DMARC can therefore fail

This is one of the most important concepts in modern email deliverability:

authentication pass

does not automatically mean

DMARC pass.

Relaxed alignment

DMARC normally uses relaxed alignment unless configured otherwise.

Under relaxed alignment, related subdomains with the same Organizational Domain can align.

Conceptually:

From:
example.com

Authenticated:
mail.example.com

→ relaxed alignment can pass

Strict alignment

Strict alignment requires the domains to match exactly.

Conceptually:

From:
example.com

Authenticated:
mail.example.com

→ strict alignment fails

DMARC controls alignment modes with tags

Common tags include:

adkim=
aspf=

For example

adkim=s
aspf=s

requests strict alignment.

Using:

adkim=r
aspf=r

uses relaxed alignment.

Strict is not automatically better

Strict alignment can be appropriate in some controlled environments, but relaxed alignment accommodates legitimate use of related subdomains.

Choose based on actual mail architecture rather than the appealing idea that the word “strict” must obviously mean “more professional.”

Where is the DMARC record published?

DMARC is published as a DNS TXT record under:

_dmarc.example.com

A simple monitoring record

v=DMARC1; p=none;

A more useful monitoring record might include aggregate reports

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

The v tag specifies the protocol version

v=DMARC1

The p tag specifies the policy

The three familiar policies are:

none
quarantine
reject

p=none

This is monitoring mode.

Conceptually:

Evaluate DMARC.

Generate requested reports.

Do not request special
disposition because of
DMARC failure.

p=none does not mean DMARC is useless

It gives domain owners visibility into how their domain is being used.

This is normally the safest starting point

Before enforcing rejection, you need to discover every legitimate system sending email for the domain.

p=quarantine

This asks receivers to treat failing messages suspiciously.

That may result in handling such as:

spam folder
quarantine
additional filtering

depending on the receiving system.

p=reject

This asks receiving systems to reject messages that fail DMARC validation.

p=reject provides stronger spoofing protection

But only after legitimate senders are correctly configured.

Do not jump blindly from no DMARC to p=reject

A domain may send legitimate mail through:

• company mailboxes;
• WordPress;
• CRM;
• newsletter service;
• invoice platform;
• support desk;
• ecommerce platform;
• HR software;
• monitoring services.

Every legitimate flow needs to be understood

Otherwise:

p=reject

can successfully protect the domain from an attacker and, with equal commitment, protect customers from receiving your invoices.

DMARC aggregate reporting

The:

rua=

tag requests aggregate reports.

For example:

rua=mailto:dmarc@example.com

Aggregate reports provide authentication visibility

They can show information such as:

• sending IPs;
• message counts;
• SPF results;
• DKIM results;
• DMARC disposition;
• domains involved in authentication.

Current aggregate reporting is standardized separately

As of 2026 it is defined by:

RFC 9990

rather than being embedded entirely in the original DMARC specification.

DMARC reports are normally machine-oriented

Aggregate reports are structured data rather than pleasant emails saying:

Everything looks splendid today.

They are commonly processed through dedicated DMARC reporting tools.

Do not send reports into somebody’s normal inbox forever

A busy domain can receive substantial reporting volume.

Use:

• a dedicated mailbox;
• a DMARC analysis service;
• automated processing.

Failure reports are different

The:

ruf=

tag can request message-specific failure information.

Failure reporting has privacy considerations

These reports can potentially expose more message-level information than aggregate reports and are not universally generated by receivers.

Use them deliberately rather than assuming every domain needs them.

The old pct tag has changed

This is especially important for documentation written before 2026.

The older RFC 7489 supported:

pct=

to request percentage-based application of DMARC enforcement.

RFC 9989 removes pct

The current specification explicitly removed the:

pct

tag after operational experience showed inconsistent implementation.

The current specification introduces t

The new:

t=

tag provides a policy testing signal.

For example

t=y

indicates that the domain is testing its declared enforcement policy.

This is not the same as the old arbitrary percentage model

If you are reading a DMARC deployment guide that still recommends:

pct=10
pct=25
pct=50
pct=75

as the modern staged-enforcement strategy, that guide is describing the older DMARC specification.

Legacy receivers still exist

Email infrastructure changes slowly.

Existing deployments and tooling may continue to understand older DMARC syntax for compatibility, but new documentation and architecture should be based on the current RFC 9989 model.

DMARC subdomain policy

The:

sp=

tag can specify a policy for existing subdomains.

For example:

v=DMARC1;
p=reject;
sp=quarantine;

Without an applicable separate subdomain policy

The main policy can also apply according to DMARC policy-discovery rules.

Current DMARC also includes policy for nonexistent subdomains

RFC 9989 incorporates the:

np=

policy concept for non-existent domains.

This can provide more deliberate handling of spoofed mail claiming to originate from subdomains that do not actually exist.

SPF, DKIM and DMARC together

Consider a correctly configured WordPress transactional email.

Visible From:
notifications@example.com

MAIL FROM:
bounce@mail.example.com

DKIM:
d=mail.example.com

SPF

The sending server is authorized for:

mail.example.com

so:

SPF = pass

SPF relaxed alignment

The SPF domain:

mail.example.com

shares the Organizational Domain:

example.com

with the visible From domain.

Therefore:

SPF alignment = pass

DKIM

The DKIM signature for:

mail.example.com

validates.

Therefore:

DKIM = pass

DKIM relaxed alignment

The signing domain shares:

example.com

as its Organizational Domain.

Therefore:

DKIM alignment = pass

DMARC

At least one aligned authentication mechanism passes.

In this example both do.

Therefore:

DMARC = pass

Example: SPF passes but DMARC fails

From:
billing@example.com

MAIL FROM:
bounce@provider.example.net

SPF:
pass

DKIM:
none

SPF successfully authenticated:

provider.example.net

but it does not align with:

example.com

Therefore:

DMARC = fail

Example: SPF fails but DKIM saves DMARC

Imagine forwarding changes the sending IP.

SPF:
fail

DKIM:
pass
d=example.com

From:
hello@example.com

The DKIM signing domain aligns with the visible From domain.

Therefore:

DMARC = pass

This demonstrates why DKIM is valuable

DMARC does not require both mechanisms to survive every delivery path.

Example: DKIM passes but is not aligned

From:
hello@example.com

DKIM:
pass
d=mail-vendor.example.net

SPF:
fail

The signature is valid.

But the signing domain does not align with:

example.com

Therefore:

DMARC = fail

Authentication and alignment are separate checks

This distinction deserves repetition:

SPF pass
≠ necessarily DMARC pass

DKIM pass
≠ necessarily DMARC pass

How this applies to WordPress

WordPress normally sends email through:

wp_mail()

which uses WordPress’s bundled PHPMailer implementation.

For the transport-level distinction, see WordPress SMTP vs. PHP mail, explained.

wp_mail() does not create SPF for you

SPF lives in:

DNS

and describes authorized sending infrastructure.

WordPress does not magically create DKIM either

DKIM signing is usually handled by:

• the SMTP server;
• transactional email provider;
• mail infrastructure.

DMARC is also published at DNS level

A WordPress plugin cannot make:

example.com

DMARC-compliant simply by adding a setting labelled:

Enable DMARC

unless it also has controlled access to the domain’s DNS infrastructure and correctly coordinates the sending identities.

SMTP and domain authentication are different layers

WORDPRESS / SMTP

How does the application
hand the message to
sending infrastructure?


SPF / DKIM / DMARC

How can receiving systems
authenticate the domains
associated with that message?

TheOneWP Mail Manager handles the WordPress transport layer

TheOneWP Mail Manager can configure WordPress’s PHPMailer instance with:

• SMTP host;
• port;
• TLS or SSL configuration;
• authentication credentials;
• sender identity;
• Reply-To;
• BCC recipients;
• a test-email workflow.

It does not replace SPF, DKIM or DMARC

The SMTP provider and DNS still need to be configured correctly.

This is a critical architectural distinction

A test email successfully leaving WordPress proves something like:

WordPress successfully handed
the message into its configured
mail-delivery path.

It does not automatically prove:

SPF aligned

DKIM aligned

DMARC passed

message reached Inbox

For the wider deliverability problem

See Why WordPress emails go to spam.

Choose the WordPress From domain carefully

A problematic configuration can look like:

WordPress From:
wordpress@website-domain.example

SMTP authenticated account:
user@completely-different-domain.example

This may create identity problems

The exact outcome depends on the mail provider.

Some providers:

• rewrite the sender;
• reject unauthorized From addresses;
• sign with their own domain;
• support custom-domain authentication.

Use a sending provider that supports your domain properly

For business WordPress email, the ideal architecture usually lets the provider authenticate mail using domains aligned with the organization’s visible From domain.

Custom DKIM domains are particularly useful

A transactional provider may allow:

DKIM:
d=mail.example.com

instead of:

d=vendor.example.net

This makes DMARC alignment straightforward

The recipient sees:

From:
notifications@example.com

while DKIM signs with:

mail.example.com

which can align under relaxed DMARC alignment.

Custom return-path domains can align SPF too

Some providers support a custom MAIL FROM or bounce domain such as:

bounce.example.com

This can make SPF alignment possible as well.

A strong setup aims for both

SPF:
pass + aligned

DKIM:
pass + aligned

DMARC:
pass

Only one aligned mechanism is necessary for DMARC

But having both aligned provides better operational resilience.

Modern Gmail requirements

The current Gmail sender guidelines require authentication for email sent to personal Gmail accounts.

For all senders to Gmail

Google requires at least:

SPF or DKIM

along with other infrastructure and sending requirements.

For bulk senders

Senders delivering roughly:

5,000 or more messages
per day to personal Gmail accounts

are subject to stronger requirements.

These include:

SPF

DKIM

DMARC

and DMARC alignment for direct email.

Google’s current enforcement is no longer merely theoretical

Gmail increased enforcement against non-compliant traffic beginning in November 2025, including temporary and permanent rejections for messages that fail sender requirements.

Bulk sender status is persistent

According to Google’s current guidance, once a sender is classified as a Gmail bulk sender, reducing volume later does not remove that classification.

Yahoo has similar requirements

The current Yahoo Sender Hub requirements require:

SPF or DKIM
for ordinary senders

and for bulk senders:

SPF
DKIM
DMARC

with DMARC alignment.

Authentication is now baseline infrastructure

SPF, DKIM and DMARC should no longer be treated as exotic optimizations for giant newsletter companies.

They are normal components of professionally managed domain email.

Authentication does not guarantee Inbox placement

This is equally important.

A message can have:

SPF = pass
DKIM = pass
DMARC = pass

and still land in Spam.

Mailbox providers evaluate many other signals

These can include:

• sender reputation;
• IP reputation;
• domain reputation;
• spam complaints;
• user engagement;
• message content;
• sending patterns;
• list quality;
• unsubscribe practices.

Authentication answers authenticity questions

It does not answer:

Does the recipient want this email?

A perfectly authenticated spam campaign remains spam

Cryptography has many talents.

Making people want your newsletter is not among them.

SPF does not protect the domain by itself

A common misconception:

We have SPF,
so nobody can spoof our domain.

Not necessarily.

SPF does not directly protect the visible From header

An attacker may use:

From:
ceo@example.com

while using a completely different envelope sender that passes SPF for the attacker’s domain.

DMARC is what connects authentication to the visible identity

This is why deploying:

SPF
+
DKIM
+
DMARC

provides a much more complete authentication architecture.

DKIM does not authorize sending IPs

That is SPF’s job.

DMARC does not create cryptographic signatures

That is DKIM’s job.

DMARC does not replace SPF authorization

It consumes SPF results as one possible authentication input.

Keep the layers conceptually separate

SPF
Infrastructure authorization

DKIM
Cryptographic domain signature

DMARC
Visible-domain alignment,
policy and reporting

A safe DMARC rollout

A new DMARC deployment should generally begin with discovery.

Step 1: inventory every legitimate sender

List everything that sends mail using your domain.

For example:

Google Workspace
WordPress
CRM
newsletter platform
support system
billing system
transactional provider
monitoring service

Step 2: verify SPF

Determine whether each relevant sending service:

• is included in SPF where appropriate;
• uses the expected MAIL FROM domain;
• passes SPF;
• aligns with the visible From domain.

Step 3: verify DKIM

Confirm each service:

• signs outgoing email;
• uses valid selectors;
• has valid public keys;
• uses sufficiently strong keys;
• aligns the signing domain where possible.

Step 4: publish DMARC in monitoring mode

For example:

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

Step 5: collect reports

Look for:

• unknown sending IPs;
• legitimate providers failing SPF;
• DKIM failures;
• alignment failures;
• unexpected domains;
• possible spoofing.

Step 6: fix legitimate mail streams

Do not tighten enforcement while known legitimate mail still fails authentication.

Step 7: move toward enforcement

Once legitimate traffic is understood, move from:

p=none

toward an appropriate enforcement policy such as:

p=quarantine

and ultimately, where suitable:

p=reject

Use the current testing model

For deployments based on current RFC 9989, understand the new:

t=

testing mechanism rather than relying on old percentage-based pct deployment advice.

Monitor after enforcement too

Email infrastructure changes over time.

A company may add:

• a new CRM;
• a new WordPress website;
• a new transactional provider;
• a new marketing system.

DMARC is not “configure once and forget forever”

Authentication should be part of the change-management process whenever a new sender is introduced.

Common SPF mistakes

Publishing multiple SPF records

Combine legitimate senders into one valid policy rather than publishing competing SPF policies.

Forgetting a third-party sender

The CRM sends legitimate mail but is absent from the SPF authorization.

Keeping retired providers forever

Old authorizations increase complexity and potentially authorize infrastructure you no longer control operationally.

Exceeding the DNS lookup limit

Nested include: chains can make an apparently short record exceed SPF’s evaluation limit.

Using +all

Authorizing everybody provides admirably universal access and remarkably little authentication.

Assuming SPF authenticates From:

SPF primarily authenticates an SMTP identity, not automatically the visible author domain.

Common DKIM mistakes

Publishing the key but not enabling signing

A DNS record achieves nothing if the sending infrastructure never attaches a DKIM signature.

Using the wrong selector

The message says:

s=selector2

while DNS contains only:

selector1._domainkey

Deleting an old key too quickly during rotation

Messages already in transit may still contain signatures using the previous selector.

Assuming DKIM encrypts email

It signs rather than hides the message content.

Assuming any valid DKIM signature satisfies DMARC

The signing domain must also align with the Author Domain.

Common DMARC mistakes

Publishing p=reject immediately

You may reject legitimate mail whose infrastructure you forgot existed.

Never moving beyond p=none

Monitoring is useful, but a domain permanently staying in monitoring mode does not obtain the same anti-spoofing enforcement as a deliberate enforcement policy.

Ignoring aggregate reports

Requesting reports without analyzing them creates a sophisticated XML collection hobby.

Assuming SPF and DKIM must both pass

DMARC can pass when either SPF or DKIM passes with alignment.

Ignoring alignment

Authentication without alignment may still fail DMARC.

Following obsolete pct rollout advice without checking the current standard

RFC 9989 removed the old pct tag.

Using strict alignment automatically

Strict alignment should solve an actual requirement, not merely make the DNS record look more serious.

Ignoring subdomains

Understand how policy applies to legitimate and nonexistent subdomains.

Common WordPress email authentication mistakes

Installing an SMTP plugin and assuming SPF is configured

SMTP transport and DNS authorization are separate layers.

Sending through one domain while using another From domain

This can cause DMARC alignment failures.

Testing only whether wp_mail() returned success

That does not prove authentication or final delivery.

Using the hosting server’s default PHP mail configuration

The infrastructure may not properly align with or authenticate the site’s visible domain.

Configuring SPF but not DKIM

Forwarding and other delivery paths make relying on SPF alone fragile.

Configuring DKIM but no DMARC

Receivers can validate a signature, but the domain has not yet connected that authentication to a policy for the visible From identity.

Using a personal mailbox as the sender for every website

Business transactional mail should use an intentional domain and sending architecture.

How to inspect authentication on a received email

Major email clients can display the full message headers.

Look for Authentication-Results

You may see something conceptually like:

Authentication-Results:
spf=pass
dkim=pass
dmarc=pass

Inspect the domains too

Do not stop at:

pass

Check which domains authenticated.

For SPF

Look for information around:

smtp.mailfrom

For DKIM

Look for:

header.d

or the DKIM:

d=

signing domain.

For DMARC

Verify the result against the visible:

header.from

domain.

A useful diagnostic comparison

Visible From:
example.com

SPF domain:
mail.example.com
PASS

DKIM domain:
mail.example.com
PASS

DMARC:
PASS

A suspicious diagnostic comparison

Visible From:
example.com

SPF:
provider.example.net
PASS

DKIM:
provider.example.net
PASS

DMARC:
FAIL

The authentication worked

The identity alignment did not.

A WordPress SPF/DKIM/DMARC checklist

• Inventory every service that sends email for the domain.
• Identify the visible From domain used by WordPress.
• Identify the SMTP MAIL FROM domain.
• Identify the DKIM signing domain.
• Publish one valid SPF policy for the relevant domain.
• Include every legitimate SPF sender that needs authorization.
• Remove obsolete SPF senders.
• Stay within SPF’s DNS lookup limit.
• Do not use +all as a convenient shortcut.
• Enable DKIM signing at the email provider.
• Publish the provider’s DKIM public key correctly.
• Use at least the provider-required DKIM key strength.
• Prefer 2048-bit DKIM where supported by the infrastructure.
• Verify the DKIM selector.
• Plan DKIM key rotation.
• Configure a DKIM domain aligned with the visible From domain where possible.
• Configure a custom aligned MAIL FROM domain where appropriate.
• Publish a DMARC record under _dmarc.
• Begin with monitoring when the sending environment is not yet fully understood.
• Configure aggregate reporting.
• Review DMARC reports.
• Fix legitimate senders that fail authentication or alignment.
• Move toward enforcement only after validating legitimate flows.
• Understand relaxed versus strict alignment.
• Understand subdomain policy.
• Use current RFC 9989 guidance rather than relying blindly on older RFC 7489 tutorials.
• Remember that the old pct tag has been removed from the current specification.
• Understand the current t testing mechanism.
• Retest after changing SMTP providers.
• Retest after adding CRM, newsletter or ecommerce infrastructure.
• Inspect received-message headers, not just WordPress success messages.
• Monitor sender reputation and complaint rates in addition to authentication.

A simple authentication decision tree

Message arrives
│
├── SPF passes?
│   │
│   ├── Yes
│   │   └── SPF domain aligned
│   │       with From?
│   │       │
│   │       ├── Yes
│   │       │   └── DMARC can pass
│   │       │
│   │       └── No
│   │           └── Check DKIM
│   │
│   └── No
│       └── Check DKIM
│
└── DKIM passes?
    │
    ├── Yes
    │   └── DKIM d= aligned
    │       with From?
    │       │
    │       ├── Yes
    │       │   └── DMARC can pass
    │       │
    │       └── No
    │           └── DMARC fails
    │
    └── No
        └── DMARC fails

A WordPress troubleshooting decision tree

WordPress email not arriving
│
├── Did WordPress send successfully?
│   │
│   ├── No
│   │   └── SMTP / application /
│   │       connection problem
│   │
│   └── Yes
│       │
│       └── Inspect received or
│           rejected message
│
├── SPF pass?
│   └── If no:
│       inspect authorized sender
│       and MAIL FROM domain
│
├── DKIM pass?
│   └── If no:
│       inspect signing,
│       selector and DNS key
│
├── DMARC pass?
│   └── If no:
│       inspect alignment
│
└── All pass but Spam?
    └── Inspect reputation,
        content, complaints,
        list quality and
        sending behavior

A DMARC rollout decision tree

Do you know every legitimate sender?
│
├── No
│   └── Inventory senders
│       + p=none monitoring
│
└── Yes
    │
    └── Do legitimate flows
        pass aligned SPF or DKIM?
        │
        ├── No
        │   └── Fix authentication
        │       and alignment
        │
        └── Yes
            │
            └── Review reports
                ↓
                consider quarantine
                ↓
                validate
                ↓
                consider reject

Quick reference: SPF vs. DKIM vs. DMARC

SPF

Published:
DNS TXT

Checks:
Sending IP/server authorization

Main authenticated identity:
SMTP MAIL FROM domain

Major weakness:
Forwarding can break it


DKIM

Published:
Public key in DNS

Checks:
Cryptographic message signature

Main authenticated identity:
d= signing domain

Major weakness:
Message modification can break signature


DMARC

Published:
_dmarc DNS TXT

Checks:
Alignment of visible From domain
with valid SPF or DKIM identity

Adds:
Policy + reporting

Pass requirement:
At least one aligned
authentication mechanism passes

Related WordPress email and deliverability guides

For the wider WordPress email, SMTP and deliverability cluster, continue with:

• WordPress SMTP vs. PHP mail, explained
• Why WordPress emails go to spam
• Preparing a WordPress site for launch
• Mail Manager

Final thoughts

SPF, DKIM and DMARC are easiest to understand when each one is given exactly one job.

SPF says:

Is this sending infrastructure
authorized for this SMTP domain?

DKIM says:

Does this message contain
a valid cryptographic signature
from this signing domain?

DMARC says:

Does either authenticated identity
align with the domain users see
in the From: header?

and:

If not, how does the domain owner
want receivers to treat the failure?

For WordPress, that means configuring only SMTP is not enough.

TheOneWP Mail Manager can route WordPress email through properly configured SMTP infrastructure and control the sender identity used by the application, but the domain’s sending provider and DNS still need to support the corresponding SPF, DKIM and DMARC architecture.

A strong setup therefore looks something like:

WordPress
↓
authenticated SMTP provider
↓
SPF authorized infrastructure
↓
DKIM signed message
↓
aligned From domain
↓
DMARC pass

And even then, authentication is not the entire deliverability story.

It establishes that the message has credible authorization to use the domain.

It does not establish that recipients wanted the email, that the sending reputation is healthy or that the message deserves the Inbox.

The important operational sequence is:

Authenticate
↓
Align
↓
Monitor
↓
Enforce
↓
Keep monitoring

Do that before switching straight to p=reject because somebody on the Internet called it a “best practice.” A technically flawless DMARC rejection of your own legitimate order confirmations remains, regrettably, a technically flawless disaster.