Understand what SPF, DKIM, and DMARC prove.

SPF authorizes sending systems

SPF is a TXT policy on the domain used for the SMTP envelope identity. It lists the systems allowed to send on that domain's behalf.

For the EmailDesk MailChannels gateway, the policy must include include:relay.mailchannels.net. EmailDesk requires one SPF record containing the active gateway's include and blocks supported sending paths when that check fails.

• Use one SPF policy per domain.
• Merge existing legitimate senders rather than replacing them blindly.
• Keep the all mechanism at the end.
• Remember that visible From and envelope identities can differ.

DKIM signs the message with a domain key

The active sending provider signs selected message headers and publishes the matching public key under a selector in DNS. Recipient systems can then check that the signed parts were not altered and that the signing domain owns the key.

Use the selector and value issued by the provider that will sign EmailDesk traffic. A DKIM record from a previous provider does not automatically authenticate a new provider, although multiple selectors can coexist during a controlled migration.

DMARC evaluates alignment and policy

DMARC checks whether a passing SPF or DKIM identity aligns with the domain visible in From. It can also publish monitoring, quarantine, or reject guidance and a reporting destination.

Begin with a reporting posture only when it fits the organization's plan. Review real reports and align every legitimate sender before moving to a stricter policy.

• A p=none policy monitors; it does not ask receivers to quarantine or reject.
• A stricter policy can affect valid mail from forgotten services.
• Protect the reporting mailbox and limit access to authentication reports.

Keep EmailDesk sender permission separate

EmailDesk verifies the exact From address where required and checks that the credential may use its domain. This is an application permission control, separate from public DNS authentication.

A verified sender cannot override missing gateway SPF, a disabled credential, quota, or suppression. Likewise, valid DNS cannot authorize a From address that the customer has not verified.

Authentication is evidence, not a delivery promise

SPF, DKIM, and DMARC do not prove that a message is wanted or harmless. Content, links, attachments, consent, complaint history, bounce behavior, and sender reputation still influence EmailDesk protection and recipient-provider filtering.

Provider acceptance is also not final inbox delivery. A recipient provider can later defer, reject, bounce, quarantine, or place an authenticated message in Spam/Junk.