An email authentication error usually means a receiving mail system could not verify that your domain authorized a message, signed it correctly, or aligned that proof with the address recipients see in the From field. The fix is rarely “try sending again”: you need to identify the sending service, inspect the message headers, and correct the relevant DNS or signing configuration.

For founders, marketers, and developers, this matters because authentication is now baseline email infrastructure. Gmail requires all senders to use SPF or DKIM, while bulk senders sending more than 5,000 messages per day to Gmail accounts must use SPF, DKIM, and DMARC. Yahoo also strongly urges senders to publish DMARC and warns that noncompliant mail can be spam-foldered or rejected. (support.google.com)

First: what kind of email authentication error do you have?

The phrase “email authentication error” is overloaded. Before editing DNS, distinguish outbound domain authentication from a mailbox login problem.

Domain authentication errors

This guide focuses on errors involving your sending domain, such as:

SPF fail, SPF softfail, SPF permerror, or “sender is not authorized”
DKIM fail, “DKIM signature did not verify,” or “no DKIM signature”
DMARC fail, “From domain does not align,” or “message rejected due to DMARC policy”
SMTP bounces such as 550 5.7.x, including SPF-specific enhanced status codes
Messages that technically deliver but land in spam because authentication is missing or inconsistent

SPF, DKIM, and DMARC are separate systems. They solve related but different problems: SPF authorizes sending infrastructure, DKIM cryptographically signs message content, and DMARC checks whether SPF or DKIM authentication aligns with the visible From domain and publishes a policy for failures. (learn.microsoft.com)

Mailbox login or app-password errors

If Apple Mail, Outlook, an iPhone, or another client says “authentication failed” while trying to read or send mail, that is usually an IMAP, SMTP submission, OAuth, password, MFA, or app-password issue. SPF, DKIM, and DMARC changes will not fix it.

A quick rule:

If a recipient server rejects a message after you send it, investigate domain authentication.
If your mail app cannot connect to the mailbox at all, investigate account credentials and client settings.

How SPF, DKIM, and DMARC work together

A reliable fix starts with understanding which identity each protocol checks. The important detail is that the address people see is not always the address used for SPF.

SPF: is this server allowed to send for the envelope domain?

SPF, or Sender Policy Framework, is a DNS TXT record that lists the servers or services permitted to send mail for a domain. Receiving servers compare the connecting sender’s IP address against the SPF policy for the SMTP envelope sender domain, commonly visible after delivery as the Return-Path domain. (learn.microsoft.com)

A simple SPF record looks like this:

Host/name: @
Type: TXT
Value: v=spf1 include:spf.protection.outlook.com -all

That is valid syntax for a domain that sends only through Microsoft 365. The include: mechanism delegates authorization checks to the provider’s SPF policy; -all says all other sources should fail. Microsoft documents that SPF is published in DNS as a TXT record and identifies valid sources for a custom domain. (learn.microsoft.com)

SPF does not inherently protect the visible From: hello@yourdomain.com identity. A message can pass SPF for a different envelope domain. That distinction is exactly why DMARC alignment matters.

DKIM: was the message signed, and did it remain intact?

DKIM, or DomainKeys Identified Mail, adds a cryptographic signature to outgoing mail. The receiving server uses the domain and selector in the DKIM-Signature header to retrieve a public key from DNS and verify the signature. (support.google.com)

A DKIM public-key record has this general shape:

Host/name: marketing1._domainkey.example.com
Type: TXT
Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A...

The long p= value must be the complete public key produced by your email provider. Do not manually shorten, wrap incorrectly, or substitute an example key. Many providers instead ask you to publish CNAME records that point to provider-managed DKIM keys; use the exact selector and target they generate.

DKIM proves that a signing domain took responsibility for the message and that the signed portions survived transit unchanged. It can fail when a message is modified by an intermediary, when the selector record is missing, when the wrong key is published, or when the sender has not enabled signing for the domain. (rfc-editor.org)

DMARC: does the proof match the domain in From?

DMARC, or Domain-based Message Authentication, Reporting, and Conformance, evaluates the domain in the visible RFC 5322 From: header. It passes when either SPF passes and aligns with that From domain, or DKIM passes and aligns with that From domain. It also lets the domain owner publish a requested handling policy and receive aggregate reports. (dmarc.org)

A monitoring-mode DMARC record looks like this:

Host/name: _dmarc.example.com
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r; pct=100

What those tags mean:

v=DMARC1 identifies the record as DMARC.
p=none asks receivers to monitor rather than quarantine or reject failing mail.
rua= requests aggregate reports at the listed address.
adkim=r and aspf=r use relaxed alignment, which permits aligned organizational domains rather than requiring an exact subdomain match.
pct=100 applies the policy request to all applicable mail; it is useful when you deliberately phase enforcement later.

DMARC policy options include none, quarantine, and reject. A p=none record is not enforcement; it is visibility. It is a sensible first step only if you actually inspect the reports and fix every legitimate sender before moving to stronger policy. (support.google.com)

The fastest way to diagnose an email authentication error

Do not start by changing records blindly. First capture one failed message, one successful message if available, and the exact SMTP bounce text if the message was rejected.

Step 1: identify every system that sends as your domain

Make a complete sender inventory. This is where most authentication projects fail: the company configures Google Workspace or Microsoft 365 but forgets the product that sends invoices, password resets, form notifications, sales sequences, support replies, or job-application emails.

Include at least:

Your primary mailbox provider, such as Google Workspace or Microsoft 365.
Your transactional email API or SMTP relay.
Marketing automation and newsletter platforms.
CRM, support desk, scheduling, billing, ecommerce, and form tools.
Servers, scripts, WordPress sites, and cloud applications that send directly.
Agencies or vendors permitted to send on your behalf.

Google’s SPF setup guidance explicitly recommends identifying all email senders before constructing the record, and updating SPF whenever you add a new server or third-party sender. (support.google.com)

Step 2: inspect the full message headers

Send a test from the failing source to a Gmail or Microsoft 365 inbox you control. In Gmail on the web, open the message and inspect the message details or original headers. Gmail also exposes “Mailed by” and “Signed by” details for authenticated messages, while other clients can expose an Authentication-Results header. (support.google.com)

Look for a block similar to this:

Authentication-Results: mx.google.com;
       spf=pass smtp.mailfrom=bounce.example.com;
       dkim=pass header.i=@example.com header.s=marketing1;
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=example.com

Interpret it in this order:

SPF result: pass, fail, softfail, neutral, none, temperror, or permerror.
DKIM result: whether the signature passed and the domain after header.i= or in the DKIM d= tag.
DMARC result: whether it passed, and the visible From domain shown after header.from=.
Source identity: the envelope sender after smtp.mailfrom= or the Return-Path header.
Signing selector: the DKIM selector, normally shown as header.s= or s=.

A useful result is not merely spf=pass. For a branded message from news@example.com, you want DMARC to pass for header.from=example.com, preferably with DKIM signing aligned to example.com or an aligned subdomain.

Step 3: classify the failure before making a change

Use this decision tree:

SPF fails, DKIM passes and aligns, DMARC passes: delivery may still work. Fix SPF for resilience, but do not break working DKIM while doing so.
SPF passes, DKIM fails, DMARC passes: likely SPF alignment is carrying DMARC. Fix DKIM because forwarding, routing changes, or vendor configuration can make SPF fragile.
SPF passes but DMARC fails: the SPF domain is not aligned with the visible From domain, and DKIM is absent, failing, or not aligned.
DKIM passes but DMARC fails: the signing d= domain does not align with the visible From domain.
Both SPF and DKIM fail: find the actual sending source first. DNS edits alone cannot authorize a system you have not identified.
spf=permerror: inspect the SPF record structure, especially duplicate records and DNS lookup complexity.

Fix SPF errors without breaking other senders

SPF is easy to publish and easy to misconfigure. Its most common failure is not a typo; it is incomplete ownership of the sending stack.

Publish exactly one SPF TXT record per domain

A domain should have one SPF policy record. If you publish separate TXT records such as these:

v=spf1 include:_spf.google.com ~all
v=spf1 include:spf.protection.outlook.com ~all

receivers can treat SPF evaluation as a permanent error. Merge authorized mechanisms into one record instead:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all

That example is syntactically valid, but do not copy it unless you genuinely use both services to send mail from the same envelope domain. Authorization should match reality, not a generic checklist.

Use the provider’s documented mechanism, not guessed IP addresses

If a provider gives you an SPF include: value, use that value. Hard-coding a provider’s IP ranges can become stale, is difficult to maintain, and may miss infrastructure the provider uses for your mail stream.

Use direct ip4: or ip6: mechanisms only when you own or have stable control over the sending IPs. For example:

v=spf1 ip4:198.51.100.24 -all

The IP above is documentation-only and must be replaced with your real sending IP if you use this structure.

Stay within SPF’s DNS lookup limits

SPF evaluation has a limit on DNS-query-causing terms. RFC 7208 requires SPF implementations to limit those terms to 10 during evaluation; exceeding the limit can generate permerror. Nested include, redirect, a, mx, exists, and ptr mechanisms can contribute, so a record that looks short may still exceed the limit after expansion. (rfc-editor.org)

If you have too many vendors, do not keep appending includes indefinitely. Better options are:

Move distinct products to dedicated subdomains, such as updates.example.com for marketing and notify.example.com for product email.
Consolidate sending through fewer platforms.
Ask providers whether they support a custom bounce domain and aligned DKIM for a dedicated subdomain.
Review whether inactive tools still need authorization.

Choose `-all` only after the inventory is complete

-all is a strong statement that other sources should fail SPF. It is the correct destination for a tightly controlled sending domain, but it can create surprises if an overlooked app sends mail from that domain.

A safer rollout is to identify all sources, publish a correct combined record, test each sending stream, then choose the policy qualifier appropriate to your environment. SPF alone is not sufficient anti-spoofing protection; Microsoft specifically notes that DKIM and DMARC are also needed. (learn.microsoft.com)

Fix DKIM errors: selectors, keys, and third-party senders

DKIM configuration is provider-specific, but the diagnostic logic is consistent.

Confirm that the sender is signing the message

Open a test message’s raw source and find DKIM-Signature:. Important fields include:

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

d= is the signing domain.
s= is the selector.
The public key should be published at marketing1._domainkey.example.com.

If there is no DKIM signature, do not troubleshoot the DNS key first. Find the sender’s domain-authentication panel and enable DKIM signing, complete its verification process, or contact the platform’s support documentation. Some platforms sign with their own domain until you add and verify a custom domain.

Check the record name, record type, and provider mode

A common error is publishing a valid key at the wrong hostname. The DKIM lookup uses the selector plus ._domainkey. plus the signing domain; a key at _domainkey.example.com without the selector is not the same record. DKIM standards define lookup using the signing domain and selector and use DNS TXT records to distribute verification keys. (rfc-editor.org)

Also distinguish between the two provider patterns:

TXT-key pattern: you copy a long v=DKIM1; ... p= key into DNS.
CNAME-delegation pattern: you create one or more CNAME records to provider-owned DKIM records.

Do not convert one pattern into the other. If the vendor gave a CNAME target, publishing it as TXT will fail. If it gave a public key, putting that key in a CNAME target field will fail.

Fix alignment, not just signature validity

A message can show dkim=pass and still show dmarc=fail. That usually means the signing domain differs from the visible From domain.

For example:

From: Acme Updates <news@acme.com>
DKIM d=mailvendor.example

The DKIM signature may be cryptographically valid, but it is not aligned with acme.com. Configure the provider to sign with acme.com or a permitted aligned subdomain such as mail.acme.com, then verify the final headers.

Expect forwarding and message modification to affect results

Forwarding often breaks SPF because the forwarder’s IP address is not in the original sender’s SPF record. Microsoft describes this as expected behavior and recommends DKIM as an important way to preserve authentication through forwarding. ARC can preserve original authentication results through legitimate intermediaries, but it is receiver- and provider-dependent rather than a replacement for correct SPF, DKIM, and DMARC setup. (learn.microsoft.com)

Fix DMARC errors and move safely toward enforcement

DMARC errors are usually alignment errors, not proof that every DNS record is absent.

Start with monitoring mode

If you have no DMARC record, publish one in monitoring mode:

Host/name: _dmarc.example.com
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r; pct=100

Aggregate reports are XML files generated by participating receivers. They show which IPs and domains are sending mail that claims to be from your domain, along with SPF, DKIM, alignment, and disposition outcomes. DMARC reporting is intended to give domain owners insight into legitimate infrastructure and possible unauthorized use. (rfc-editor.org)

Create a mailbox or reporting destination that can receive and process these reports. Raw XML can be reviewed manually for a small domain, but DMARC analysis tools are more practical once reports arrive from multiple receivers.

Find and repair legitimate failures

Before moving from p=none, inspect reports and headers for every legitimate stream:

Corporate mailboxes
Transactional product mail
Marketing campaigns
Support and CRM systems
Inbound systems that send automated replies
Vendors using your visible From domain

For each legitimate sender, ensure at least one route achieves DMARC alignment:

Aligned DKIM: best for third-party platforms. The provider signs with your domain or an aligned subdomain.
Aligned SPF: the envelope sender uses your domain or an aligned subdomain, and your SPF record authorizes the sender.

In practice, configure both wherever the provider supports it. That gives you redundancy when a message is forwarded or routed through systems that affect one method.

Move from monitoring to quarantine or reject

Once reports show only known, authenticated senders, you can consider enforcement:

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r; pct=100

Later, a mature policy may be:

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

quarantine asks receivers to treat failing mail suspiciously, while reject asks them to refuse it. The recipient ultimately makes its own delivery decision, so DMARC is not a guarantee that every receiver will take identical action. DMARC itself does not grant special delivery privileges to authenticated email; reputation, recipient engagement, content, and other signals still matter. (support.google.com)

Worked example: fixing a rejected product-email stream

Assume Acme runs normal staff email through Microsoft 365 and sends product receipts through a transactional email platform. Employees send successfully, but receipt emails from receipts@acme.com are rejected by some recipients with a DMARC-related bounce.

What Acme finds in the failed message

The raw headers show:

From: Acme Receipts <receipts@acme.com>
Return-Path: <bounce@provider-mail.example>
Authentication-Results: recipient.example;
       spf=pass smtp.mailfrom=provider-mail.example;
       dkim=pass header.i=@provider-mail.example;
       dmarc=fail header.from=acme.com

This is not an SPF failure in the narrow sense. SPF passes for the provider’s envelope domain, and DKIM passes for the provider’s signing domain. But neither authenticated identity aligns with acme.com, the visible From domain, so DMARC fails.

The correct repair

Acme should open the transactional provider’s domain-authentication settings and add acme.com as a verified sending domain. The provider will typically provide DNS records for custom DKIM, a tracking domain, a custom return-path domain, or some combination of these.

Acme then:

Publishes the provider-provided DKIM TXT or CNAME records exactly as given.
Adds the provider’s documented SPF authorization only if the provider requires SPF for its custom return-path domain.
Verifies the domain in the provider’s dashboard.
Sends a new receipt to a test inbox.
Confirms the new headers show dkim=pass with header.i=@acme.com or an aligned Acme subdomain.
Confirms dmarc=pass header.from=acme.com.

The ideal post-fix result looks like this:

Authentication-Results: recipient.example;
       spf=pass smtp.mailfrom=bounce.mail.acme.com;
       dkim=pass header.i=@acme.com header.s=tx1;
       dmarc=pass header.from=acme.com

The exact hostnames vary by provider. What matters is the relationship: the visible From domain is acme.com, and at least one passing SPF or DKIM identity is aligned with acme.com under the DMARC policy.

If you are implementing the sending side in an application, keep the sending domain configuration, DNS verification, and header tests alongside your deployment process rather than treating them as a one-time marketing task. Your email API setup guides should be part of the same operational runbook as your domain and DNS changes.

Common mistakes that cause recurring failures

Adding a new platform without updating authentication

A new marketing tool or SaaS feature may appear to work initially because messages reach some inboxes. Later, stricter receivers, higher volume, or an enforced DMARC policy exposes the missing configuration.

Treat every new sender as a domain-authentication change. Add it to the sender inventory, publish the required DNS records, verify it in the vendor dashboard, and test a real message before using it in production.

Using the root domain for every sending purpose

Using example.com for all corporate, transactional, marketing, and vendor mail makes SPF complexity and incident response harder. Subdomains can isolate streams and make authorization clearer:

notify.example.com for product notifications
mail.example.com for transactional mail
updates.example.com for newsletters

This does not remove the need for DMARC alignment, but it can reduce SPF sprawl and lets you apply purpose-specific policies. Confirm that your provider supports custom From domains, DKIM, and bounce domains for the subdomain you choose.

Publishing records at the wrong DNS host

DNS dashboards differ. Some automatically append your domain name; others expect a fully qualified host. Entering _dmarc.example.com into a field that already appends .example.com can accidentally create _dmarc.example.com.example.com.

After publishing, query the public DNS record or use an independent checker. Do not assume a green check inside one vendor dashboard proves the record exists exactly where all receivers will query it.

Changing DNS and not retesting the actual mail stream

A domain verification badge is not the same as an authenticated delivered message. Send a live test from each source and inspect the headers after the change.

Test more than one path where possible: a Gmail personal inbox, a Microsoft 365 inbox, and a recipient domain representative of your customer base. Microsoft 365 exposes SPF, DKIM, DMARC, and composite authentication outcomes in the Authentication-Results header for received messages. (learn.microsoft.com)

Assuming authentication alone fixes inbox placement

Authentication is foundational, but it is not a spam-folder bypass. Gmail’s sender guidance also addresses unwanted mail, unsubscribe mechanisms for bulk senders, TLS, valid DNS, and spam rates; Gmail says bulk senders should keep Postmaster Tools spam rates below 0.3%. (support.google.com)

Once SPF, DKIM, and DMARC pass, continue monitoring list quality, recipient complaints, bounce rates, consent, frequency, and content relevance.

How to verify that the fix worked

A correct configuration has evidence at three layers: DNS, provider configuration, and a real delivered message.

DNS verification checklist

Confirm that:

Your sending domain has one SPF TXT policy, not multiple competing SPF records.
Each DKIM selector used by a provider resolves to the expected TXT public key or CNAME target.
_dmarc.yourdomain.com returns one valid DMARC record.
Your DNS changes are visible publicly, not only inside a pending draft in the DNS control panel.

Message-level verification checklist

For every sender, send a production-like test and confirm:

spf=pass

dkim=pass

dmarc=pass

For DMARC specifically, confirm the passing identity aligns with the visible From domain. dkim=pass d=vendor.example is not sufficient for a message from you@yourdomain.com unless that vendor domain is aligned, which it normally is not.

Operational verification checklist

After the immediate issue is resolved:

Monitor SMTP bounces and provider event logs for authentication-related rejects.
Review DMARC aggregate reports for unknown senders and alignment failures.
Use Gmail Postmaster Tools if you send enough mail to Gmail for meaningful data; its dashboards include authentication, delivery errors, reputation, and spam-rate data. (support.google.com)
Re-run tests after changing email providers, DNS providers, return-path settings, or routing rules.

A practical authentication maintenance routine

Email authentication breaks most often during change, not because SPF, DKIM, or DMARC spontaneously stop working. Build a small recurring process around your sending infrastructure.

Maintain a sender inventory with owner, purpose, From domain, return-path domain, DKIM signing domain, and DNS records.
Require domain-authentication review when a team adopts a new email tool.
Keep DMARC aggregate-report monitoring active even after reaching p=reject.
Rotate DKIM selectors according to the capabilities and guidance of your email provider.
Test critical transactional flows after releases: password resets, receipts, invoices, account verification, and support notifications.
Remove SPF authorization and DKIM records for retired providers after confirming they no longer send mail.

This routine is less glamorous than campaign design or API development, but it prevents a simple vendor rollout from turning into a revenue-impacting delivery incident.

FAQ

What does “email authentication failed” mean?

It usually means a receiving server could not validate SPF, DKIM, DMARC, or the alignment between those checks and the visible From domain. Read the bounce message and Authentication-Results header to determine which protocol failed.

Can SPF pass while DMARC fails?

Yes. SPF can pass for the envelope sender or Return-Path domain while the visible From address uses another domain. DMARC requires aligned SPF or aligned DKIM, not merely an SPF pass. (dmarc.org)

Do I need SPF, DKIM, and DMARC if I send only a few emails?

Yes, as a practical baseline. Gmail requires all senders to have SPF or DKIM, and using all three gives your domain stronger spoofing protection and more reliable diagnostics. Bulk senders have stricter Gmail requirements. (support.google.com)

How long does an email authentication fix take to work?

The configuration is complete only after your DNS provider publishes the new records, your email provider verifies them, and a real test message shows passing results. DNS caching behavior depends on record TTLs and resolver behavior, so test after publication rather than relying on a fixed waiting period.

Will DMARC reject stop all phishing with my domain?

DMARC with p=reject substantially improves protection against unauthorized direct use of your exact domain in the visible From field, but it does not eliminate lookalike domains, compromised legitimate accounts, or all forms of abuse. Continue using mailbox security, monitoring, and recipient-awareness controls. (rfc-editor.org)

Email Authentication Error: Fix SPF, DKIM, and DMARC Failures