The standards that decide if your mail is trusted.

Lists which servers are allowed to send mail for your domain.

SPF is a single TXT record on your domain that names the mail servers and services authorized to send on its behalf. A receiving server reads it, checks the sending server's IP against the list, and records a pass or fail. You publish exactly one SPF record per domain; multiple SPF records silently break authentication, so additional senders are added as `include:` mechanisms inside the one record.

why it matters: Without SPF, anyone can put your domain in the envelope sender and a receiver has no authorized-sender list to check it against. SPF is the oldest and most widely honored of these checks, and DMARC needs at least one of SPF or DKIM to align before it will pass.

↳ RadMail RadMail's outbound setup helps a tenant assemble the correct single SPF record, including the send-path `include:` it needs, and flags the two-SPF-records mistake.

Cryptographically signs each message so tampering is detectable.

DKIM attaches a digital signature to every outbound message using a private key held by your sending service; the matching public key is published as a TXT record at a selector subdomain (for example `selector._domainkey.yourdomain.com`). A receiver fetches the public key, verifies the signature, and confirms the signed parts of the message were not altered in transit. Unlike SPF, DKIM survives a simple relay because it travels with the message, not the connection.

why it matters: DKIM proves a message genuinely came from your domain and arrived intact, which both raises trust and is the auth result most likely to still pass after mail is forwarded. A DMARC policy passes when either SPF or DKIM aligns with the visible From domain — DKIM is usually the more resilient of the two.

↳ RadMail RadMail's outbound setup helps a tenant publish the DKIM public-key record and manage the selector so signed mail verifies.

Tells receivers what to do when SPF and DKIM don't line up — and reports back.

DMARC is a TXT record at `_dmarc.yourdomain.com` that sets a policy (`p=none`, `p=quarantine`, or `p=reject`) for mail that fails alignment, and an address to send aggregate reports to (`rua=`). Alignment means the domain that passed SPF or DKIM matches the domain a human sees in the From header. DMARC ties SPF and DKIM together and makes their results actionable.

why it matters: SPF and DKIM alone don't tell a receiver what to do with a failure — DMARC does, and its reports are how you discover who is sending as your domain before you tighten the policy. The safe rollout is `p=none` first to watch the reports, then `quarantine`, then `reject` once your legitimate mail all aligns.

↳ RadMail RadMail's outbound setup helps a tenant publish DMARC and walk the policy from none to quarantine to reject with a readiness view — the safe, staged path, never a jump straight to reject.

Preserves the original pass results when mail is forwarded or relayed, so honest forwarded mail isn't wrongly failed.

ARC is designed for the case that breaks plain SPF and DMARC: forwarding. When a mailing list, a forwarder, or a relay modifies a message or re-sends it from its own servers, the original SPF can no longer match and a strict DMARC policy may reject a perfectly legitimate message. ARC lets each intermediary cryptographically record the authentication results it saw on arrival and seal that record into the message, so a later receiver can see 'this message failed SPF now, but a trusted hop already verified it passed before forwarding' and choose to honor that chain.

why it matters: This is the real-deliverability problem behind a lot of 'my forwarded mail lands in spam' reports: a legitimate message relayed through a forwarder trips the receiver's DMARC check because the path changed. ARC gives receivers a way to trust the earlier verdict instead of blaming the forwarder, which is exactly why it matters for anyone whose mail is forwarded, run through a list, or relayed through another service. ARC does not override a receiver's own judgment — it supplies evidence a receiver may weigh.

↳ RadMail RadMail respects and recommends ARC: when RadMail relays or forwards mail, preserving the received chain is how honest forwarded messages keep their earned trust. RadMail does not ask you to configure ARC on your DNS — it is handled by the relaying service, not by a record you publish.

Requires that mail to your domain be delivered over encrypted, certificate-validated TLS.

MTA-STS lets a domain declare that sending servers must use TLS with a valid certificate when delivering mail to it, closing a downgrade gap where an attacker on the network could strip encryption. It is published as a DNS TXT record at `_mta-sts.yourdomain.com` plus a policy file served over HTTPS at `mta-sts.yourdomain.com`. A companion record, TLS-RPT (`_smtp._tls.yourdomain.com`), asks receivers to report TLS delivery failures back to you.

why it matters: Without MTA-STS, SMTP will quietly fall back to an unencrypted connection if TLS negotiation is interfered with. For a domain that handles sensitive correspondence, requiring validated TLS on inbound mail is a meaningful hardening step and its TLS-RPT reports surface delivery problems you would otherwise never see.

↳ RadMail RadMail recommends MTA-STS for regulated and sensitive senders and explains it here. It involves a DNS record plus an HTTPS-hosted policy file on your own infrastructure — RadMail does not host that policy file for you.

Pins the exact TLS certificate for your mail server using DNSSEC, an alternative to MTA-STS.

DANE publishes a TLSA record that ties your mail server's TLS certificate to your domain, so a sending server can verify it is talking to the right server with the right certificate. Its trust comes from DNSSEC — the cryptographic signing of DNS itself — rather than from the public certificate authorities and HTTPS that MTA-STS relies on. DANE and MTA-STS solve the same downgrade problem by different roots of trust.

why it matters: DANE gives strong, DNSSEC-anchored assurance against TLS downgrade and man-in-the-middle interception on the mail path, and is favored in environments that already run DNSSEC. It requires DNSSEC to be enabled on your zone, which not every DNS provider supports, so it is the more advanced of the two transport-security options.

↳ RadMail RadMail recommends DANE where a domain already runs DNSSEC, and treats it as an alternative to MTA-STS rather than a duplicate. It depends on DNSSEC support at your DNS provider — RadMail explains it but does not enable DNSSEC or publish TLSA records on your zone.

Shows your verified logo next to authenticated mail — but only after DMARC is at enforcement.

BIMI lets a domain publish a TXT record pointing at a logo (an SVG Tiny P/S file) that participating mailbox providers can display beside your messages. Crucially, BIMI only takes effect once your domain is at an enforcing DMARC policy (`quarantine` or `reject`), and some providers additionally require a Verified Mark Certificate (VMC) proving you own the trademark on the logo. BIMI is the visible reward for having done the authentication work underneath it.

why it matters: BIMI turns invisible authentication into something a recipient can actually see, which supports recognition and trust — but it is strictly downstream of SPF, DKIM, and an enforced DMARC policy, so it is the last step, not the first. Chasing the logo before DMARC is enforced simply won't work.

↳ RadMail RadMail recommends BIMI as the final step after DMARC reaches enforcement, and explains its DMARC and VMC prerequisites honestly. Publishing the BIMI record and obtaining any Verified Mark Certificate are steps you take with your DNS provider and a certificate issuer.