Skip to main content

Fixing Email Authentication Issues

Palisade's DMARC Agent automatically creates tickets when it detects email authentication issues for your domains. This guide explains how to review and resolve those tickets.

How Tickets Are Created​

As Palisade processes incoming DMARC reports, it analyzes the results and creates actionable tickets when issues are detected. Each ticket includes details about the problem, the affected sending source, and a recommended course of action.

Common Ticket Types​

Unknown Sending Source Needs Verification​

A new sending source has been detected in your DMARC reports. You need to determine whether this source is a legitimate service that sends email on behalf of your domain or an unauthorized sender.

To resolve:

  1. Open the ticket and review the sending source details (IP address, organization name, volume).
  2. Determine if the source is a legitimate service (e.g., your email marketing platform, CRM, support desk).
  3. If legitimate, follow the ticket's guidance to authorize the source by updating your SPF or DKIM configuration.
  4. If not legitimate, dismiss the ticket. The source is likely unauthorized and will fail authentication as expected.

SPF Alignment Failure​

A legitimate sending source is failing SPF alignment checks. The Return-Path domain does not align with the From domain.

To resolve:

  1. Open the ticket to identify the affected sending source.
  2. Update the sending service's configuration to use your domain in the Return-Path, or add the source's domain to your SPF record.
  3. Verify the fix by checking subsequent DMARC reports.

DKIM Alignment Failure​

A legitimate sending source is failing DKIM alignment checks. The DKIM signing domain does not align with the From domain.

To resolve:

  1. Open the ticket to identify the affected sending source.
  2. Configure the sending service to sign emails with a DKIM key for your domain (most services support custom DKIM signing domains).
  3. Verify the fix by checking subsequent DMARC reports.
note

If the source is a security gateway, a filtering service or anything else that relays mail rather than originating it, the signature was probably valid when the message was sent and got broken in transit. See Relayed Mail, Gateways and ARC for why that happens, why ARC sealing does not resolve it, and what does.

SPF Record Issues​

Your SPF record has configuration problems that may cause authentication failures.

Common issues include:

  • Too many DNS lookups — SPF records are limited to 10 DNS lookups. Exceeding this limit causes SPF to fail for all senders, not just the one that pushed you over.
  • Permissive +all mechanism — an SPF record ending in +all effectively authorizes the entire internet to send email as your domain. This makes your domain trivially spoofable.
  • Missing includes — a sending service is not covered by your SPF record, causing its mail to fail authentication.

To resolve:

  1. Open the ticket to see the specific SPF issue.
  2. Follow the recommended action to optimize your SPF record (e.g., flatten includes, remove unused entries, change +all to ~all or -all).
tip

The 10-lookup limit is one of the most common SPF problems. Each include: counts as a lookup, and nested includes count too. Use the SPF Audit tool to see your current lookup count. If you are at or near the limit, consider switching to Hosted SPF where Palisade can help manage flattening.

Confirmed Sender Has Stopped Sending​

Listed against the domain as <sender name> - Has stopped sending. A sender you previously confirmed has sent no mail for the full activity window. This ticket is low priority on purpose: nothing is broken, nothing is failing, and nothing happens if you leave it open. An authorization is simply wider than it needs to be, and you are the only one who knows whether the service is really gone.

So the ticket brings evidence rather than a recommendation: when the sender was last seen sending, how long the domain has been monitored, the SPF entry that authorizes it, and the DKIM selectors published for it.

To resolve, tell Palisade which it is:

  1. We still use this service — the SPF entry and DKIM records are left exactly as they are, and Palisade will not raise this ticket again for the current quiet stretch. Seasonal senders such as annual renewal notices go quiet for months without anything being wrong. If the service sends again and later goes quiet again, the question comes back, because by then it is a new one.
  2. We no longer send through this service — the ticket closes and Palisade stops raising SPF and DKIM tickets for that sender. Removing its SPF entry and DKIM records is a change you make at your DNS host: Palisade does not touch your DNS on the strength of silence.

If mail from the sender starts flowing again before you answer, the ticket is withdrawn on its own.

note

Palisade only opens this ticket when it can prove the silence — the domain has to have been monitored for the entire window. See the activity window for what that means and why a newer domain will not raise these tickets yet.

General Workflow​

For any ticket type:

  1. Go to the Domain Overview page for the affected domain.
  2. Open the ticket to review the details and recommended action.
  3. Follow the guided steps -- the DMARC Agent walks you through identifying the source, deciding if it is legitimate, and applying the appropriate fix.
  4. Once resolved, mark the ticket as done.
  • See the Domain Overview page breakdown to understand where tickets appear and how to navigate them.
  • See the Locking Down DMARC guide for the overall process of moving toward a strict DMARC policy after resolving authentication issues.