Fix sender authentication status problems

Start with the exact status

Allowed to post means the group permits that address to send. Authenticated as that sender is a separate security check proving that the received message came from the domain shown in its From address. An address must satisfy both checks before TellTell can safely depend on it.

• Ready: the received message authenticated as the visible sender. No repair is needed.
• Ready with a DMARC recommendation: aligned SPF or DKIM authenticated the message, but the From domain has no DMARC record or uses monitoring mode (p=none). The sender can be used now; the domain administrator should complete a careful DMARC rollout.
• Needs attention: TellTell received the message but could not find SPF or DKIM authentication aligned with the visible From domain. Use the specific explanation in the card and the matching repair below.
• Could not verify: the message or provider result was incomplete, inconsistent, or could not be processed safely. Send a fresh verification message before changing DNS.
• Not checked or Check again: there is no current result. Start a new check and send the prepared message from the sender's normal mailbox and mail service.

Send a clean verification message first

1. Confirm the exact From address

   Open the normal mail app for the address shown in TellTell. Check aliases and delegated mailboxes carefully; a different From address produces a different result.

2. Start a new check

   In the group's Settings, choose Send a verification message. If an earlier address expired or was replaced, use the newly generated address.

3. Use the normal sending path

   Send the prepared message directly from the provider and mailbox the group will use. Do not forward an old message or route the test through an unrelated service.

4. Read the message-specific result

   TellTell evaluates the message it actually receives. This is more reliable than guessing a DKIM selector from DNS because the message identifies the selector and signing domain its provider used.

Fix From-address problems

• Different From address: choose the address being checked in the mail app's From control, then send a new verification message. If the other address is intentional, add and verify that exact address separately.
• No visible From address: send a newly composed message from a normal mailbox. Ask the mail provider to correct malformed outbound messages if the problem repeats.
• Multiple From addresses: configure the mail client or sending service to emit exactly one visible From mailbox. TellTell fails closed because it cannot choose which identity to trust.

Fix SPF problems

SPF authorizes servers for the message's envelope-sender domain. The domain administrator should inventory every legitimate sending service before editing DNS.

• No SPF record found: publish one SPF TXT policy for the envelope-sender domain using the mail provider's current instructions.
• More than one SPF record: merge all legitimate senders into one valid SPF policy. Do not publish a second v=spf1 record.
• Neutral, soft fail, or not authorized: update the existing policy so it authorizes the service that sent this message, while retaining every other legitimate sender.
• SPF passed but did not align: the authorized envelope domain differs from the visible From domain. Configure a custom aligned return-path domain if the provider supports it, or use aligned DKIM instead.
• SPF could not be processed: send another check after DNS and provider service recover. If it repeats, ask the mail provider or DNS host to investigate lookup errors.

Fix DKIM problems

• No usable DKIM signature: enable DKIM signing for the sender's domain in the mail provider, then send a new message.
• Selector is not published: publish the exact TXT or CNAME record supplied by the provider for the selector used by the message. Wait for DNS propagation before retrying.
• Signature did not verify: confirm that DNS contains the current public key and that the provider is using the matching private key. Replace stale or malformed records through the provider's key-rotation process.
• DKIM passed but did not align: the signing domain belongs to another domain, often the provider's shared domain. Enable custom-domain DKIM so the signing domain aligns with the visible From domain.
• DKIM could not be processed: retry with a new message. If it repeats, ask the mail provider to inspect its signing service and DNS key publication.

Fix DMARC and alignment problems

• No aligned mechanism: make either the passing SPF envelope domain or a verified DKIM signing domain align with the visible From domain. Authentication for an unrelated third-party domain does not qualify.
• No DMARC record: if aligned SPF or DKIM passed, TellTell reports a recommendation rather than blocking the sender. Publish DMARC in monitoring mode, review reports, and advance enforcement gradually when the domain is ready.
• DMARC monitoring mode (p=none): this is a valid rollout stage. TellTell can use the sender when the same received message proves aligned SPF or DKIM. Continue reviewing reports before moving to quarantine or reject.
• DMARC could not be processed: send a new check. Repeated indeterminate results need investigation by the mail provider, DNS host, or TellTell Support.

Follow the current provider instructions

• Google Workspace: use Google's SPF setup, DKIM setup, and recommended DMARC rollout.
• Microsoft 365: use Microsoft's SPF setup, DKIM setup, and DMARC setup.
• Another provider: follow that provider's current custom-domain authentication instructions and your DNS host's record-entry format. Do not copy a record intended for a different provider.

Verify the repair

1. Wait for the provider and DNS

   Finish every provider-side activation step and allow the provider's stated DNS propagation time.

2. Start a fresh TellTell check

   Use a new verification address and send from the exact mailbox and route the group will use.

3. Escalate repeated indeterminate results

   Contact TellTell Support with the group address, sender address, approximate send time, status, and displayed explanation. Do not send the message body, private DKIM keys, passwords, or raw authentication headers unless Support specifically requests a safe diagnostic.